Integrating On-Premise Inductive Automation Ignition with Tulip Using Amazon MQ for RabbitMQ

Context and Purpose

Manufacturing operators juggle multiple disconnected systems—SCADA, MES, ERP—creating inefficiencies and data silos. Integrating Inductive Automation's Ignition with Tulip solves this by providing a unified interface. This article guides you through deploying this integration on AWS using Amazon MQ for RabbitMQ as the MQTT broker, enabling real-time data exchange between on-premise machine systems and cloud-based workflows.

---

Overview

This article explains how to integrate an on-premise Inductive Automation Ignition deployment with Tulip's frontline operations platform using Amazon MQ for RabbitMQ as the cloud-based MQTT broker. This hybrid architecture allows manufacturers to maintain Ignition close to their plant floor equipment while leveraging AWS managed services for reliable, scalable messaging infrastructure.

The following sections walk through the architecture, configuration steps, and best practices for establishing this integration.

---

Use Cases

The Challenge

Manufacturing environments typically rely on multiple disconnected systems. These include SCADA and HMI systems for machine monitoring, MES platforms for work orders and scheduling, ERP systems for inventory and logistics, and paper checklists for quality and compliance.

This fragmentation causes productivity loss, data silos, and increased error rates. Valuable time is wasted switching between applications. Additionally, correlating information across systems for effective decision-making becomes difficult.

How This Integration Helps

The integration creates a single pane of glass where all critical information converges. Ignition runs on-premise, capturing high-frequency PLC and machine data close to the source. Meanwhile, Tulip runs in the cloud, providing no-code apps and enterprise system integration. Amazon MQ for RabbitMQ serves as the managed MQTT broker in AWS, enabling reliable message exchange between these platforms.

Key Use Cases

The following table summarizes primary use cases enabled by this integration:

Use Case	Description
Unified Operations	Single interface combining machine data, work instructions, and production tracking
Predictive Maintenance	Monitor equipment parameters and trigger maintenance workflows before failures occur
Inline Quality	Embed quality checks at workstations with automated data capture
OEE Monitoring	Real-time visibility into availability, performance, and quality metrics
Supply Chain Visibility	Track materials through production with ERP integration
Role-Based Interfaces	Customize views for different roles and responsibilities

---

Solution Architecture

This hybrid architecture places Ignition on-premise for low-latency machine connectivity. AWS cloud services handle managed messaging and integration with Tulip.

┌──────────────────────────────────────────────────────────────────────┐
│                        AWS Cloud                                      │
│  ┌────────────────────────────────────────────────────────────────┐  │
│  │                         VPC                                     │  │
│  │  ┌─────────────────────────────────────────────────────────┐   │  │
│  │  │           Amazon MQ for RabbitMQ                         │   │  │
│  │  │           (MQTT Plugin Enabled)                          │   │  │
│  │  │           - Publicly Accessible or via VPN               │   │  │
│  │  └─────────────────────────┬───────────────────────────────┘   │  │
│  │                            │                                    │  │
│  └────────────────────────────┼────────────────────────────────────┘  │
└───────────────────────────────┼───────────────────────────────────────┘
                                │
                                │ MQTT over TLS (Port 8883)
                                │
              ┌─────────────────┴─────────────────┐
              │                                   │
              ▼                                   ▼
    ┌───────────────────┐             ┌────────────────────────────────┐
    │ Tulip Cloud       │             │ On-Premise Plant               │
    │ Platform          │             │                                │
    │                   │             │  ┌──────────────────────────┐  │
    │                   │             │  │ Ignition Gateway         │  │
    │                   │             │  │ (with Tulip embedded     │  │
    │                   │             │  │  in Perspective)         │  │
    │                   │             │  └─────────────┬────────────┘  │
    │                   │             │                │               │
    │                   │             │                ▼               │
    │                   │             │       ┌────────────────┐       │
    │                   │             │       │ PLCs/Machines  │       │
    │                   │             │       └────────────────┘       │
    │                   │             │                                │
    └───────────────────┘             └────────────────────────────────┘

Data Flow

Connection	Description
Amazon MQ ↔ Tulip Cloud	MQTT messages for work orders, machine status, and production data
Amazon MQ ↔ Ignition Gateway	MQTT messages published and subscribed by Ignition
Ignition Gateway ↔ PLCs/Machines	OPC-UA, Modbus, or other industrial protocols for machine data

Architecture Benefits

This design offers several advantages for manufacturing environments:

Benefit	Description
Low Latency	Ignition remains close to PLCs and machines for real-time control
Managed Messaging	Amazon MQ eliminates broker infrastructure management
Secure Connectivity	TLS encryption protects all data in transit
Scalability	Cloud-based broker scales with messaging needs
Reliability	Multi-AZ deployment options ensure high availability

---

Prerequisites

Before beginning this integration, ensure you have the following:

• On-premise server running Inductive Automation Ignition
• AWS account with appropriate permissions
• Tulip account with API access
• Network connectivity from on-premise to AWS (internet or VPN/Direct Connect)
• Firewall rules allowing outbound MQTT traffic on port 8883

---

Step 1: Verify On-Premise Ignition Installation

System Requirements

First, confirm your on-premise Ignition server meets minimum requirements:

Component	Minimum	Recommended
CPU	4 cores	8+ cores
Memory	8 GB RAM	16+ GB RAM
Storage	50 GB	100+ GB SSD
OS	Windows Server 2016+ or Linux	Latest stable version
Java	Included with Ignition	Keep updated

Verify Ignition Gateway Status

Access your Ignition Gateway web interface and confirm the following:

1. Gateway is running and properly licensed
2. Connectivity to PLCs and machine data sources is established
3. Tag providers are configured and collecting data

For detailed information on Ignition Gateway configuration, refer to the Inductive Automation documentation.

Network Requirements

Your on-premise network must allow outbound connectivity to AWS. The following ports are required:

Destination	Port	Protocol	Purpose
Amazon MQ endpoint	8883	TCP/TLS	MQTT messaging
Tulip cloud	443	TCP/TLS	REST API calls (optional)

Note that inbound connections from AWS are not required. All connections are initiated outbound from the on-premise Ignition server, simplifying firewall configuration.

---

Step 2: Configure Network Connectivity to AWS

Several options exist for connecting your on-premise environment to AWS. Choose the approach that best fits your security requirements and infrastructure.

Option A: Public Internet with TLS

Amazon MQ for RabbitMQ supports public accessibility. This allows your on-premise Ignition to connect over the internet using TLS encryption.

Advantages:

• No additional infrastructure required
• Quick setup process
• Suitable for most use cases

Requirements:

• Firewall allows outbound traffic on port 8883
• TLS encryption protects data in transit

This option works well for organizations without strict requirements for private connectivity.

Option B: AWS Site-to-Site VPN

For enhanced security, establish a VPN connection between your on-premise network and AWS VPC. This creates an encrypted tunnel for all traffic.

To set up a Site-to-Site VPN, you need to create a Virtual Private Gateway, configure a Customer Gateway representing your on-premise router, and establish the VPN connection. Detailed instructions are available in the AWS Site-to-Site VPN documentation.

Advantages:

• Private connectivity over encrypted tunnel
• No exposure of broker to public internet
• Consistent network performance

Option C: AWS Direct Connect

For high-throughput, low-latency requirements, AWS Direct Connect provides dedicated network connectivity. This option suits organizations with significant data transfer needs or strict latency requirements.

Advantages:

• Dedicated bandwidth
• Consistent latency
• Suitable for high-frequency data exchange

For most manufacturing environments, Option A (Public Internet with TLS) provides sufficient security and simplicity. Consider VPN or Direct Connect for high-security requirements or large data volumes.

---

Step 3: Deploy Amazon MQ for RabbitMQ

Amazon MQ for RabbitMQ provides a fully managed message broker service with native MQTT support. The MQTT plugin comes enabled by default, eliminating manual configuration.

Why Amazon MQ for RabbitMQ?

Choosing a managed broker service offers several benefits:

Benefit	Description
Fully Managed	AWS handles patching, maintenance, and backups
Built-in MQTT Support	MQTT plugin enabled by default
High Availability	Multi-AZ deployment options available
Security	Encryption at rest and in transit
Monitoring	CloudWatch metrics integration
Hybrid Friendly	Supports connections from on-premise systems

For more details, see the Amazon MQ documentation.

Create Amazon MQ Broker via AWS Console

Follow these steps to create your broker:

1. Navigate to Amazon MQ in the AWS Console
2. Click Create broker
3. Select RabbitMQ as the engine type
4. Configure broker settings as follows:

Setting	Value
Broker name	Choose a descriptive name
Broker instance type	mq.m5.large (production) or mq.t3.micro (dev/test)
Deployment mode	Single-instance broker (dev) or Cluster deployment (production)
RabbitMQ version	Latest stable version

5. Configure network and security:

   • For Public Internet Access: Enable "Public accessibility"
   • For VPN/Direct Connect: Select private subnets and disable public accessibility
   • Choose or create an appropriate security group

6. Configure user credentials with a strong password

7. Review settings and create the broker

Broker creation typically takes 10-15 minutes to complete.

Create Amazon MQ Broker via AWS CLI

Alternatively, use the AWS CLI to create your broker.

For Public Access:

aws mq create-broker \
  --broker-name <your-broker-name> \
  --engine-type RABBITMQ \
  --engine-version 3.11.20 \
  --host-instance-type mq.m5.large \
  --deployment-mode SINGLE_INSTANCE \
  --publicly-accessible true \
  --users Username=<your-username>,Password=<your-secure-password> \
  --security-groups <your-security-group-id>

For Private Access (via VPN/Direct Connect):

aws mq create-broker \
  --broker-name <your-broker-name> \
  --engine-type RABBITMQ \
  --engine-version 3.11.20 \
  --host-instance-type mq.m5.large \
  --deployment-mode SINGLE_INSTANCE \
  --publicly-accessible false \
  --users Username=<your-username>,Password=<your-secure-password> \
  --subnet-ids <your-subnet-id> \
  --security-groups <your-security-group-id>

Replace placeholder values with your specific configuration details.

Configure Security Group for Amazon MQ

Create or update the security group to allow MQTT traffic from your on-premise network.

For Public Access:

Port	Protocol	Source	Purpose
8883	TCP	Your on-premise public IP range	MQTT over TLS
15671	TCP	Your admin IP range	RabbitMQ Management Console

For Private Access (VPN/Direct Connect):

Port	Protocol	Source	Purpose
8883	TCP	On-premise CIDR range	MQTT over TLS
15671	TCP	On-premise CIDR range	RabbitMQ Management Console

Retrieve Broker Endpoints

After the broker is created, retrieve the MQTT endpoint:

1. Navigate to Amazon MQ > Brokers in the AWS Console
2. Select your broker
3. Under Connections, locate the MQTT endpoint

The endpoint format follows this pattern:

mqtts://<broker-id>.mq.<region>.amazonaws.com:8883

Amazon MQ for RabbitMQ only supports MQTT over TLS (port 8883). Non-TLS MQTT connections are not available, ensuring secure communication by default.

Verify MQTT Plugin Status

The MQTT plugin is enabled by default. To verify, access the RabbitMQ Management Console:

1. Navigate to https://<broker-endpoint>:15671
2. Login with your credentials
3. Navigate to Admin > Plugins
4. Confirm rabbitmq_mqtt appears as enabled

For more information about the MQTT plugin, see the RabbitMQ MQTT documentation.

---

Step 4: Configure On-Premise Firewall

Your on-premise firewall must allow outbound connectivity to Amazon MQ. This step is critical for establishing communication.

Required Firewall Rules

Configure the following outbound rules:

Direction	Source	Destination	Port	Protocol	Purpose
Outbound	Ignition Server	Amazon MQ Endpoint	8883	TCP	MQTT over TLS
Outbound	Ignition Server	Tulip Cloud	443	TCP	REST API (optional)

Test Connectivity

Before proceeding, verify connectivity from your Ignition server to Amazon MQ.

Windows (PowerShell):

Test-NetConnection -ComputerName <your-broker-endpoint> -Port 8883

Linux:

nc -zv <your-broker-endpoint> 8883

If the connection fails, verify the following:

• Firewall rules allow outbound traffic on port 8883
• DNS resolution is working correctly
• No proxy is interfering with the connection

---

Step 5: Install and Configure MQTT Modules in Ignition

With network connectivity established, configure Ignition to communicate with Amazon MQ.

Install Modules

The MQTT Transmission and MQTT Engine modules enable Ignition to publish and subscribe to MQTT messages. Download these modules from the Cirrus Link website.

To install:

1. Access Ignition Gateway at your server's address
2. Navigate to Config > System > Modules
3. Install both MQTT Transmission and MQTT Engine modules
4. Restart the Gateway if prompted

Configure MQTT Server Connection

Next, configure the connection to Amazon MQ:

1. Go to MQTT Transmission > Settings > Servers
2. Click Create new MQTT Server
3. Enter the following connection details:

Setting	Value
Name	A descriptive name for this connection
URL	ssl://<your-broker-endpoint>:8883
Username	Your Amazon MQ username
Password	Your Amazon MQ password
Server Set	Default Set

4. Click Create New MQTT Server
5. Repeat the same configuration for MQTT Engine > Settings > Servers

Configure TLS Settings

Amazon MQ uses AWS-managed certificates. Ignition's MQTT modules typically trust the AWS certificate chain by default.

If you encounter certificate errors, download the Amazon Root CA certificate from Amazon Trust Services. Then import it into Ignition's trust store via Config > Security > Certificates.

Configure JSON Namespace for Tulip

Tulip uses JSON payloads for MQTT messages. Configure Ignition to handle this format:

1. Go to MQTT Engine > Settings > Namespaces
2. Select the Custom tab
3. Click Create new Custom Namespace
4. Enter the following configuration:

Setting	Value
Name	Tulip
Topics	tulip_ignition/#

5. Click Save Changes

This configuration tells Ignition to process messages on topics matching the specified pattern as JSON.

Configure UNS Transmitter

The UNS Transmitter publishes tag data to MQTT:

1. Go to MQTT Transmission > Settings > UNS Transmitters
2. Click Create new Settings
3. Configure as follows:

Setting	Value
Name	TulipTransmitter
Tag Provider	default
Tag Path	Leave empty for all tags, or specify a path
Server Set	Default

4. Click Create New Settings

Verify Connection Status

Confirm the connection is working:

1. Go to MQTT Transmission > Settings > Servers
2. Check the Connected column displays a successful connection
3. Repeat verification for MQTT Engine > Settings > Servers

If the connection fails, review your firewall rules, security group configuration, and broker endpoint URL.

---

Step 6: Configure SSL/TLS for Tulip Embedding

To embed Tulip within Ignition Perspective, your Ignition server must be accessible via HTTPS. This section covers two approaches.

Option A: Using a Reverse Proxy

Deploying a reverse proxy in front of Ignition handles TLS termination. This approach offers flexibility and additional security features.

A sample NGINX configuration:

server {
    listen 443 ssl;
    server_name <your-ignition-hostname>;
    
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;
    
    location / {
        proxy_pass http://localhost:8088;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Replace placeholder values with your actual certificate paths and hostname.

Option B: Direct SSL on Ignition

Alternatively, configure SSL directly on Ignition:

1. Obtain an SSL certificate and private key for your server
2. Navigate to Config > Networking > Web Server
3. Upload the certificate and key
4. Enable HTTPS on your chosen port

DNS Configuration

Ensure your Ignition server has a DNS hostname that resolves correctly. For internal access only, use internal DNS. For external access, configure public DNS accordingly.

---

Step 7: Configure Tulip Integration

With Ignition configured, set up the Tulip side of the integration.

Add Ignition to Tulip Domain Allowlist

Tulip requires explicit permission to be embedded in external applications:

1. Login to your Tulip instance
2. Navigate to Settings > Domain Allowlist
3. Add your Ignition server URL (must use HTTPS)

If Ignition is only accessible internally, Tulip embedding will only work on the same network.

Configure MQTT Data Source in Tulip

Create an MQTT data source to receive messages from Ignition:

1. Navigate to Shop Floor > Machines > Data Sources
2. Click Create machine data source
3. Configure with your Amazon MQ endpoint:

Setting	Value
Name	A descriptive name
Runs on	Cloud
Type	MQTT
Broker URL	ssl://<your-broker-endpoint>:8883
Username	Your Amazon MQ username
Password	Your Amazon MQ password

4. Subscribe to relevant topics:

tulip_ignition/+/status
tulip_ignition/+/quantity_produced
tulip_ignition/+/warning
tulip_ignition/+/melt_temp
tulip_ignition/+/motor_load

5. Click Test to verify connectivity
6. Click Save

For more details on Tulip machine data sources, refer to the Tulip documentation.

Create Tulip API Token

For REST API integration from Ignition:

1. Navigate to Settings > API Tokens
2. Click Create API Token
3. Select required scopes:
   • attributes:write
   • tables:read
   • tables:write
4. Save the API Key and Secret securely

---

Step 8: Embed Tulip in Ignition Perspective

Creating a unified interface requires embedding Tulip within Ignition Perspective.

Add Inline Frame Component

Follow these steps in Ignition Designer:

1. Open Ignition Designer and connect to your Gateway
2. Open your Perspective project
3. Drag an Inline Frame component onto your view
4. Set the src property to your Tulip player URL:

https://<your-tulip-instance>.tulip.co/player?appId=<your-app-id>

To find the app ID, open the app in Tulip and examine the URL in your browser's address bar.

Register the Interface in Tulip

When the embedded player loads for the first time:

1. Login with Tulip credentials
2. Name the interface descriptively
3. Assign it to a station
4. Sign in with your Badge ID

This registration process links the embedded interface to a specific station in Tulip.

---

Step 9: Configure Data Exchange

Establishing bidirectional data exchange completes the integration. This section covers topic structure and implementation.

MQTT Topics Structure

Define a consistent topic structure for communication:

Root: tulip_ignition/<machine_id>/

Topics:
├── work_order          (Tulip → Ignition)
├── quantity_required   (Tulip → Ignition)
├── quantity_produced   (Ignition → Tulip)
├── status              (Ignition → Tulip)
├── inlet_pressure      (Ignition → Tulip)
├── outlet_pressure     (Ignition → Tulip)
├── melt_pressure       (Ignition → Tulip)
├── melt_temp           (Ignition → Tulip)
├── motor_load          (Ignition → Tulip)
├── screw_speed         (Ignition → Tulip)
├── warning             (Ignition → Tulip)
└── e_stop              (Ignition → Tulip)

This structure organizes messages by machine and data type, making subscriptions and filtering straightforward.

Publish from Ignition via Script

Enable scripting in MQTT Transmission:

1. Go to MQTT Transmission > Settings > Sets
2. Edit the Default set
3. Enable Show advanced properties
4. Check Enable/disable RPC Client
5. Save changes

Add a tag change script to publish data:

# On tag value change, publish to MQTT
system.cirruslink.transmission.publish(
    "<your-mqtt-server-name>",                    # MQTT server name
    "tulip_ignition/<machine_id>/melt_temp",      # Topic
    str(currentValue.value),                       # Payload as JSON string
    0,                                             # QoS level
    True                                           # Retained flag
)

Replace placeholder values with your specific configuration.

Call Tulip REST API from Ignition

Create a project library script for REST API calls:

# Project Library: Tulip

TULIP_URL = "https://<your-tulip-instance>.tulip.co/api/v3"
API_KEY = "<your-api-key>"
SECRET = "<your-api-secret>"

def reportMachineAttribute(machineId, attributeId, value):
    import base64
    
    data = {
        "attributes": [
            {
                "machineId": machineId,
                "attributeId": attributeId,
                "value": value
            }
        ]
    }
    
    url = TULIP_URL + "/attributes/report"
    credentials = base64.b64encode((API_KEY + ":" + SECRET).encode()).decode()
    headers = {"Authorization": "Basic " + credentials}
    
    response = system.net.httpPost(
        url=url,
        postData=system.util.jsonEncode(data),
        headerValues=headers,
        contentType="application/json"
    )
    
    return response

Usage example:

Tulip.reportMachineAttribute(
    "<machine-id>",      # Machine ID from Tulip
    "<attribute-id>",    # Attribute ID from Tulip
    currentValue.value   # Value to report
)

For API details, see the Tulip API documentation.

---

Step 10: Configure High Availability (Optional)

Production environments benefit from high availability configurations.

Amazon MQ Cluster Deployment

For message broker redundancy, deploy Amazon MQ in cluster mode:

aws mq create-broker \
  --broker-name <your-broker-name>-ha \
  --engine-type RABBITMQ \
  --engine-version 3.11.20 \
  --host-instance-type mq.m5.large \
  --deployment-mode CLUSTER_MULTI_AZ \
  --publicly-accessible true \
  --users Username=<your-username>,Password=<your-secure-password> \
  --security-groups <your-security-group-id>

This creates a three-node cluster across multiple Availability Zones. The cluster provides automatic failover and message replication.

On-Premise Ignition Redundancy

For high availability of your on-premise Ignition installation:

1. Deploy a secondary Ignition Gateway server
2. Configure Ignition Gateway Network for redundancy
3. Configure both gateways to connect to Amazon MQ independently
4. Enable automatic failover if the primary gateway fails

Refer to the Ignition redundancy documentation for detailed configuration steps.

---

Step 11: Monitoring and Observability

Effective monitoring ensures reliable operation of the integration.

Amazon MQ CloudWatch Metrics

Monitor your Amazon MQ broker using Amazon CloudWatch. Key metrics include:

Metric	Description	Suggested Alarm Threshold
MessageCount	Messages in queues	Greater than 10,000
ConsumerCount	Active consumers	Less than 1
PublishRate	Messages published per second	Significant deviation from baseline
SystemCpuUtilization	Broker CPU usage	Greater than 80%
RabbitMQMemUsed	Memory utilization	Greater than 80%

For more information on Amazon MQ metrics, see the Amazon MQ monitoring documentation.

Create CloudWatch Alarms

Set up alarms to notify you of potential issues:

aws cloudwatch put-metric-alarm \
  --alarm-name "AmazonMQ-HighMessageCount" \
  --metric-name MessageCount \
  --namespace AWS/AmazonMQ \
  --statistic Average \
  --period 300 \
  --threshold 10000 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=Broker,Value=<your-broker-name> \
  --evaluation-periods 2 \
  --alarm-actions <your-sns-topic-arn>

Monitor On-Premise Ignition

Monitor your on-premise Ignition server through these channels:

• Ignition Gateway Status Page: Check connection status to Amazon MQ
• MQTT Transmission Status: Verify messages are being published
• MQTT Engine Status: Verify subscriptions are active
• System Resources: Monitor CPU, memory, and disk utilization

---

Verification

Before going live, verify each component of the integration.

Test MQTT Connectivity

Use an MQTT client to verify message flow through Amazon MQ.

From On-Premise Server:

# Subscribe to topics
mosquitto_sub \
  -h <your-broker-endpoint> \
  -p 8883 \
  -t "tulip_ignition/#" \
  -u <your-username> \
  -P <your-password> \
  --capath /etc/ssl/certs/

# Publish test message
mosquitto_pub \
  -h <your-broker-endpoint> \
  -p 8883 \
  -t "tulip_ignition/test/status" \
  -m "RUNNING" \
  -u <your-username> \
  -P <your-password> \
  --capath /etc/ssl/certs/

Verify via RabbitMQ Management Console

Access the management console to confirm message flow:

1. Navigate to https://<broker-endpoint>:15671
2. Check the Queues tab for MQTT subscriptions
3. Review message rates under Overview

Test End-to-End Data Exchange

Complete verification with these tests:

1. Change a tag value in Ignition
2. Verify the value appears in Tulip machine data
3. Send a work order from Tulip
4. Verify Ignition receives it via MQTT

---

Troubleshooting

The following table addresses common issues:

Issue	Solution
Cannot connect to Amazon MQ from on-premise	Verify firewall allows outbound port 8883. Check security group rules. Test connectivity with mosquitto client.
Certificate errors	Download and install Amazon Root CA certificate in Ignition trust store.
Tulip won't load in iframe	Verify Ignition URL is in Tulip domain allowlist. Confirm HTTPS is configured correctly.
MQTT connection intermittent	Check network stability. Consider VPN or Direct Connect for more reliable connectivity.
Tags not appearing in Tulip	Confirm JSON namespace is configured. Check topic subscriptions match published topics.
REST API returns 401	Verify API key and secret. Check token scopes are correct.
High message latency	Consider upgrading Amazon MQ instance type. Evaluate network path.

---

Security Best Practices

Network Security

Follow these practices for secure communication:

Practice	Implementation
Use TLS for all connections	Amazon MQ enforces TLS on port 8883
Restrict security group access	Limit inbound rules to known IP ranges
Use VPN for sensitive data	Consider AWS Site-to-Site VPN or Direct Connect
Rotate credentials regularly	Update Amazon MQ and Tulip API credentials periodically

On-Premise Security

Protect your on-premise infrastructure:

Practice	Implementation
Configure firewall rules	Allow only required outbound traffic
Enable Ignition security	Configure authentication and authorization
Implement network segmentation	Isolate Ignition server from general network traffic
Enable audit logging	Log all connections for security review

---

Cost Considerations

Amazon MQ for RabbitMQ Pricing

Costs vary by instance type and deployment mode:

Instance Type	Use Case	Approximate Monthly Cost
mq.t3.micro	Development and testing	~$20
mq.m5.large	Production (single instance)	~$150
mq.m5.large (cluster)	Production (high availability)	~$450

Costs vary by AWS Region. Data transfer charges apply for data sent from AWS to on-premise systems. For current pricing, refer to the Amazon MQ pricing page.

Data Transfer Costs

Transfer Type	Cost
Data into AWS (on-premise to Amazon MQ)	Free
Data out of AWS (Amazon MQ to on-premise)	Approximately $0.09/GB (varies by Region)

Cost Optimization

Consider these strategies to manage costs:

Strategy	Potential Savings
Use mq.t3.micro for development	Up to 85% compared to production instances
Right-size based on CloudWatch metrics	20-40%
Single-instance for non-critical workloads	66% compared to cluster deployment
Optimize message payloads	Variable, reduces data transfer costs

---

Related Resources

• Amazon MQ for RabbitMQ Documentation
• RabbitMQ MQTT Plugin Documentation
• Inductive Automation Ignition Documentation
• Cirrus Link MQTT Modules
• Tulip API Documentation
• AWS Site-to-Site VPN
• AWS Direct Connect
• Amazon CloudWatch

---

Conclusion

This hybrid integration enables manufacturers to maintain their Ignition SCADA systems on-premise while leveraging AWS managed services for reliable messaging infrastructure. Amazon MQ for RabbitMQ provides a fully managed MQTT broker that bridges on-premise industrial systems and cloud-based platforms like Tulip.

The architecture delivers low-latency machine connectivity required for industrial control while enabling cloud-scale integration capabilities. By following this guide, organizations can create a unified interface that combines real-time machine data with intuitive frontline operations applications.

This approach reduces the complexity of managing messaging infrastructure while maintaining the security and reliability required for manufacturing environments.