Connecting IBM i to the Cloud: Azure, AWS, Power Virtual Server, and Hybrid Integration Patterns That Actually Work

By /

The previous post covered observability — knowing what is happening inside IBM i. This post covers the other direction: connecting IBM i to the cloud services and platforms that now surround it in almost every enterprise environment.

IBM i sitting in isolation from cloud infrastructure is a design choice, not a technical constraint. The same PASE tooling that runs Node.js and Git also runs HTTP clients, message queue SDKs, and cloud CLI tools. The same DB2 replication mechanisms that mirror data between IBM i partitions can replicate to cloud databases. The question is not whether IBM i can connect to Azure or AWS — it can — but which integration pattern fits the problem.

This post covers the patterns that actually get used in production hybrid architectures.

The hybrid IBM i reality

Most IBM i shops are not choosing between IBM i and the cloud. They are operating both, and the challenge is making them work together without building a fragile web of custom integrations.

The common scenarios:

  • IBM i holds the transactional record of truth; cloud-hosted applications need read access to that data
  • Cloud-hosted APIs need to trigger IBM i business logic — order creation, inventory updates, shipment processing
  • IBM i batch processes need to consume data or trigger workflows in cloud services (Azure Service Bus, AWS SQS, Salesforce)
  • IBM i data needs to flow into cloud analytics platforms (Azure Synapse, AWS Redshift, Snowflake)
  • The IBM i workload itself needs to move to cloud-hosted Power infrastructure (IBM Power Virtual Server)

Each scenario has a different integration pattern. Choosing the wrong one for the scenario creates maintenance problems that outlast the initial implementation.

Pattern 1: REST API layer (IBM i as a service)

The cleanest pattern for cloud applications needing IBM i data or logic is the REST API layer covered in Post 15. IBM i exposes a versioned REST API via Node.js in PASE; cloud applications call it over HTTPS exactly as they would call any other service.

This pattern is architecture-agnostic from the cloud side. An Azure Function, an AWS Lambda, a containerised microservice, or a Salesforce integration all consume the same HTTP endpoint. IBM i internals — the RPG programs, the DB2 schema, the library structure — are invisible to the consumer.

What cloud-side consumption looks like:

# Azure Function calling IBM i REST API
import requests
import os

def get_open_orders(customer_id: str) -> dict:
    response = requests.get(
        f"{os.environ['IBMI_API_BASE']}/api/v1/orders/open",
        params={"customerId": customer_id},
        headers={"Authorization": f"Bearer {get_api_token()}"},
        timeout=10
    )
    response.raise_for_status()
    return response.json()

The IBM i REST API layer is the right first choice when:

  • Cloud applications need to call IBM i logic synchronously
  • The integration is request/response in nature
  • You want IBM i to own the interface definition and the business logic

Pattern 2: Message queue integration

For asynchronous integrations — IBM i triggering cloud workflows, or cloud events driving IBM i processing — message queues provide decoupling that survives temporary unavailability on either side.

Azure Service Bus from IBM i (Node.js in PASE):

const { ServiceBusClient } = require('@azure/service-bus');

const sbClient = new ServiceBusClient(process.env.AZURE_SERVICEBUS_CONN_STRING);
const sender = sbClient.createSender('ibmi-order-events');

async function publishOrderCreated(orderNumber, customerNumber, amount) {
  await sender.sendMessages({
    body: {
      eventType: 'order.created',
      orderNumber,
      customerNumber,
      amount,
      timestamp: new Date().toISOString(),
      source: 'ibmi'
    },
    contentType: 'application/json',
    subject: 'order.created'
  });
}

module.exports = { publishOrderCreated };

This runs in PASE alongside your existing Node.js API. When an RPG program creates an order, it calls the Node.js layer (via a stored procedure or direct HTTP call to localhost), which publishes to Service Bus. Azure Functions or Logic Apps consume the event.

AWS SQS from IBM i:

const { SQSClient, SendMessageCommand } = require('@aws-sdk/client-sqs');

const sqs = new SQSClient({
  region: process.env.AWS_REGION,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
  }
});

async function enqueueShipmentEvent(shipmentData) {
  await sqs.send(new SendMessageCommand({
    QueueUrl: process.env.SQS_SHIPMENT_QUEUE_URL,
    MessageBody: JSON.stringify(shipmentData),
    MessageGroupId: shipmentData.warehouseId  // for FIFO queues
  }));
}

Consuming cloud queue messages on IBM i:

A Node.js consumer process running in PASE polls Azure Service Bus or AWS SQS and calls the appropriate IBM i stored procedure or RPG program for each message:

const receiver = sbClient.createReceiver('cloud-to-ibmi-commands');

async function processIncoming() {
  const messages = await receiver.receiveMessages(10, { maxWaitTimeInMs: 5000 });

  for (const msg of messages) {
    try {
      await dispatchToRPG(msg.body);
      await receiver.completeMessage(msg);
    } catch (err) {
      logger.error({ msg: msg.body, error: err.message }, 'message processing failed');
      await receiver.abandonMessage(msg);
    }
  }
}

setInterval(processIncoming, 5000);

Message queue integration is the right choice when:

  • IBM i batch processes need to trigger downstream cloud workflows
  • Cloud events need to drive IBM i processing without a synchronous call
  • Either side may be temporarily unavailable and you need guaranteed delivery
  • You need to decouple IBM i release cycles from cloud service release cycles

Pattern 3: Data replication to cloud databases

For analytics, reporting, and ML workloads that need IBM i data without querying IBM i directly, replication is the right pattern. IBM i DB2 journal-based replication can feed cloud databases continuously.

IBM InfoSphere Data Replication (IIDR) — IBM’s enterprise replication product. Reads DB2 for i journals and replicates changes to Azure SQL, AWS RDS, Snowflake, Kafka topics, and other targets. Near-real-time CDC (change data capture). High reliability, IBM support, enterprise cost.

Striim — cloud-native CDC platform with IBM i source support. Similar capability to IIDR, different licensing and deployment model. Strong Azure and AWS integration.

Debezium + Kafka — open-source CDC stack. Debezium has an IBM i connector that reads DB2 journals and publishes change events to Kafka topics. Kafka Connect sinks carry the data to the destination. More operational complexity than IIDR, no licensing cost.

Custom journal reader approach (lower cost, lower reliability):

-- Query DB2 journal for changes since last run
SELECT JOURNAL_CODE, ENTRY_TYPE, OBJECT_NAME,
       SEQUENCE_NUMBER, ENTRY_TIMESTAMP,
       BEFORE_IMAGE, AFTER_IMAGE
FROM TABLE(QSYS2.DISPLAY_JOURNAL(
    JOURNAL_LIBRARY  => 'ORDLIB',
    JOURNAL_NAME     => 'ORDJRN',
    JOURNAL_ENTRY_TYPES => 'PT,UP,DL',
    STARTING_SEQUENCE_NUMBER => :lastProcessedSeq
)) AS T
ORDER BY SEQUENCE_NUMBER

A Node.js process in PASE reads this query on an interval, transforms the rows into the target schema, and bulk-inserts to the cloud database. Simpler than IIDR, suitable for lower-volume replication needs, requires custom maintenance.

Azure Data Factory with ODBC: Azure Data Factory has an ODBC connector that can query IBM i DB2 via a self-hosted integration runtime on a Windows server with the IBM i Access ODBC driver installed. This works for scheduled batch replication (not CDC) and fits organisations already using Data Factory for other ETL.

Pattern 4: IBM Power Virtual Server (cloud-hosted IBM i)

IBM Power Virtual Server (PowerVS) is IBM Cloud’s infrastructure-as-a-service offering for Power hardware — including IBM i. Instead of running IBM i on on-premises hardware, you run it on IBM-managed Power servers in IBM Cloud data centres.

What PowerVS gives you:

  • IBM i running on the same Power10 hardware as on-premises, in IBM Cloud
  • Elastic scaling — resize CPU and memory without a hardware procurement cycle
  • Pay-as-you-go or reserved pricing
  • Direct connectivity to IBM Cloud services (Object Storage, Db2 on Cloud, Kubernetes)
  • ExpressRoute-equivalent private connectivity to Azure or AWS via IBM Cloud Direct Link
  • Managed backup and snapshot capabilities

Network connectivity to Azure / AWS from PowerVS:

IBM Cloud Direct Link connects a PowerVS environment to Azure or AWS via private BGP peering — no traffic over the public internet. This is the IBM i equivalent of Azure ExpressRoute or AWS Direct Connect, and it makes PowerVS IBM i appear as a private network peer to Azure VNets or AWS VPCs.

# Conceptual network topology

IBM Power Virtual Server (IBM Cloud)
  └── IBM Cloud Direct Link (private BGP)
        ├── Azure VNet (via Azure ExpressRoute Gateway)
        │     ├── Azure App Service (web tier)
        │     ├── Azure Service Bus
        │     └── Azure SQL Database
        └── AWS VPC (via AWS Direct Connect)
              ├── AWS Lambda
              └── AWS RDS

PowerVS is the right choice when:

  • On-premises hardware refresh is approaching
  • Disaster recovery or secondary partition is needed without second data centre costs
  • The organisation has a cloud-first policy that applies to infrastructure procurement
  • Elastic capacity is needed for seasonal IBM i workloads

Pattern 5: Calling cloud APIs from IBM i

The integration need is sometimes reversed — IBM i processes need to call external cloud services. An order confirmation email via SendGrid, a document stored in Azure Blob Storage, a record created in Salesforce, a notification sent through Teams.

IBM i can make outbound HTTPS calls from PASE (Node.js, Python, or curl) and from ILE programs via the QHTTP APIs or the open-source libcurl port.

Calling an external REST API from RPG via a Node.js sidecar:

The cleanest pattern is a local HTTP service in PASE that RPG programs call via a stored procedure. The stored procedure calls the Node.js service; Node.js makes the external API call and returns the result.

-- SQL stored procedure wrapping the Node.js sidecar call
CREATE OR REPLACE PROCEDURE ORDLIB.SEND_CONFIRMATION_EMAIL(
    IN  ORDER_NUMBER   VARCHAR(20),
    IN  CUSTOMER_EMAIL VARCHAR(100),
    OUT STATUS_CODE    INTEGER,
    OUT STATUS_MSG     VARCHAR(200)
)
LANGUAGE SQL
BEGIN
  DECLARE HTTP_RESULT VARCHAR(1000);

  SET HTTP_RESULT = SYSTOOLS.HTTPPOSTCLOB(
    'http://localhost:3001/internal/send-email',
    'Content-Type: application/json',
    '{"orderNumber":"' || ORDER_NUMBER || '","email":"' || CUSTOMER_EMAIL || '"}'
  );

  SET STATUS_CODE = 200;
  SET STATUS_MSG = HTTP_RESULT;
END;

SYSTOOLS.HTTPPOSTCLOB is a built-in IBM i SQL function that makes HTTP calls. It is available on IBM i 7.3+ and supports HTTPS. For simple outbound calls this eliminates the need for a Node.js sidecar entirely.

Directly from SQL (no RPG required):

-- Store a document in Azure Blob Storage from SQL
VALUES SYSTOOLS.HTTPPUTCLOB(
  'https://yourstorage.blob.core.windows.net/orders/ORD00143.json',
  'x-ms-blob-type: BlockBlob
Content-Type: application/json
Authorization: SharedKey yourstorage:SIGNATURE',
  (SELECT JSON_OBJECT(
    'orderNumber': ORDNO,
    'customerNumber': CUSNO,
    'amount': ORDAMT
  ) FROM ORDHDR WHERE ORDNO = 'ORD00143')
)

Network connectivity options

The integration patterns above assume IBM i can reach cloud endpoints. How that connectivity is established depends on where IBM i lives.

On-premises IBM i to Azure:

  • Azure VPN Gateway (site-to-site IPSec) — Terminate the VPN on the IBM i network perimeter firewall. Azure VNet appears as a private subnet. Latency is typically 5–20ms depending on geography. Suitable for API calls and message queue integration.
  • Azure ExpressRoute — Private BGP peering via a colocation provider. No public internet. Required for high-throughput data replication or latency-sensitive integrations.

On-premises IBM i to AWS:

  • AWS Site-to-Site VPN — IPSec tunnel from network perimeter to AWS Virtual Private Gateway. AWS VPC resources appear as private network peers.
  • AWS Direct Connect — Private dedicated connection via a colocation provider or Direct Connect partner. Equivalent to ExpressRoute.

IBM i to SaaS (Salesforce, ServiceNow, Teams, SendGrid): Outbound HTTPS over existing internet connectivity. No special network configuration needed — just outbound port 443 from IBM i.

Authentication for cloud integrations

Each cloud platform has its own authentication model. The IBM i integration layer needs to handle these securely:

Azure: Use a managed identity (for PowerVS) or a service principal with client credentials. Store the client secret in Azure Key Vault; retrieve it at startup in the Node.js layer. Do not hard-code credentials in PASE files.

AWS: IAM role (for PowerVS running in IBM Cloud with AWS Direct Connect) or IAM user with access keys. Store access keys as encrypted IFS files owned by the service profile, not in environment variables that show up in process listings.

Generic API keys: Store in DB2 (encrypted), retrieved by the Node.js layer at runtime. Rotate without code changes.

-- Store API credentials in DB2 (encrypted at rest via DB2 field procedure or AS/400 encryption)
CREATE TABLE ORDLIB.API_CREDENTIALS (
  SERVICE_NAME   VARCHAR(50)  NOT NULL,
  CREDENTIAL_KEY VARCHAR(100) NOT NULL,
  CREATED_AT     TIMESTAMP    NOT NULL DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT PK_APICRED PRIMARY KEY (SERVICE_NAME)
);

-- Retrieve in Node.js at startup
const creds = await db.query(
  "SELECT CREDENTIAL_KEY FROM ORDLIB.API_CREDENTIALS WHERE SERVICE_NAME = ?",
  ['azure-servicebus']
);

Choosing the right pattern

A practical decision guide:

Cloud app needs IBM i data or logic synchronously: REST API layer (Node.js in PASE with Express). Post 15 covers this in detail.

IBM i event needs to trigger cloud workflow asynchronously: Message queue (Azure Service Bus or AWS SQS) published from Node.js in PASE.

Cloud analytics needs IBM i DB2 data continuously: CDC replication via IIDR, Striim, or Debezium/Kafka to the cloud database of choice.

IBM i needs to call external cloud services: SYSTOOLS.HTTPPOSTCLOB for simple calls; Node.js in PASE for calls requiring SDK features or complex authentication.

IBM i hardware refresh coming or DR needed: IBM Power Virtual Server with Direct Link connectivity to Azure or AWS.

Multiple patterns needed: API layer for synchronous access + message queue for events + replication for analytics is a common and stable combination. Each serves a different access pattern without overlap.

The cloud does not replace IBM i in any of these scenarios. It changes the boundary — IBM i remains the system of record and the execution engine for business logic; cloud services handle the new concerns that sit around it: user interfaces, analytics, workflow orchestration, and the integrations to other platforms that the business now depends on.

Next post: CL in 2026 — what Control Language is actually for on a modern IBM i, ILE CL patterns, error handling with MONMSG, and how CL fits into automated pipelines alongside RPG and SQL.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top