Pricing plans

When you buy a subscription to IBM® App Connect Enterprise as a Service in the AWS Marketplace, you can choose between two pricing plans, which are based either on flow runs or VPC hours.

If you choose the Resource Unit (Flow Run) plan, you are charged for the number of flow runs that are triggered. If you choose the Runtime Compute Capacity plan (VPC hours), you are charged for the amount of resources that are allocated to process your integrations.

With both pricing plans, you need to buy premium connector packs for the number of connectors that you use in your deployed flows. For more information, see Connectors.

You can use the IBM SaaS console to view billing and usage information. If your usage exceeds your purchased allowance, charges might apply. You can still access product features. However, if your subscription continues to exceed your allowed usage, product features might be disabled. You might lose access to the Designer and Dashboard interfaces and the Public API, and your running flows might be stopped. For more information, see Managing subscriptions, instances, and users.

For more information about costs for different subscription durations, see the pricing information on the AWS Marketplace.

Flow runs plan

When you buy a subscription and choose the Resource Unit (Flow Run) plan, you pay for the number of flow runs that you expect to use in the next 12 months. All flow runs for a deployed flow are counted, whether the flow is run for testing or in production. (The testing feature in the flow editor before you deploy your flow is not charged.) You pay for multiples of 100,000 flow runs. The following definitions of resource unit, flow, and flow run are taken from the IBM App Connect Enterprise as a Service service description.
  • A "Resource Unit" is an independent measure of a resource managed by, processed by, or related to the use of the Cloud Service. For the purpose of this Cloud Service, the Resource is a Flow Run.
  • A “Flow” is an integration artifact that includes one or more steps (nodes) that may automate movement of data between a source and target.
  • A “Flow Run” occurs when an event triggers a Flow to execute any one or more nodes in the flow.
A flow run occurs whenever part of a flow is triggered. For example, in the following flow, a Salesforce "New case" event triggers the flow to complete three actions. Each time a new case is created in Salesforce, it triggers the flow to complete one or more of its actions, which counts as one flow run.
A Designer flow that contains a Salesforce "New case" event that triggers three actions.
In the following flow, a Scheduler event node triggers the flow to complete two actions every hour. In this example, you are charged for one flow run each hour that the Scheduler node triggers the flow.
A Designer flow that contains a Scheduler node that triggers two actions every hour.
A trigger is anything that causes the flow to begin processing and includes (but isn't limited to) the following situations.
  • An event in an external system that causes the flow to run either through an event connector in an App Connect Designer flow or an input node in an IBM App Connect Enterprise Toolkit flow. (Input nodes include nodes that are suffixed with "input" and the FileExists node.)
  • A request from an external system to an API in the flow, including an HTTP or REST API, a raw TCP/IP input node, or a callable flow.
  • A response from an external call during asynchronous processing. In this situation, a request flow completes and a new flow run is started when the response arrives. Asynchronous flows use asynchronous HTTP request nodes, callable flow nodes, and IBM MQ nodes and connectors where request queue and response queue processing are done asynchronously.
  • One invocation of a batch processing node. When an event triggers a flow that contains a batch node, batch processing occurs within a single flow run, regardless of the number of records that are processed. For example, a batch node in a flow might process ten records, but the flow is triggered once and therefore counts as one flow run.

    However, each record from an external file that is processed by using record detection triggers part of the flow. Therefore, one flow run occurs for each record that is contained in the file.

  • An event that an event-driven architecture (EDA) node or connector generates. These events are generated either by scheduling or by the combination of events that other flow runs generate. Whenever an EDA node or connector generates a new event, it triggers a flow run. These flow runs are in addition to the triggering events that cause them. A Scheduler node in App Connect Designer or a Timer node in the Toolkit can cause this type of event to occur at user-defined times. Collector, Resequence, Aggregation, and Group nodes can also produce this type of event as a result of input from other flow runs.
Note: If an error occurs in a flow after one or more nodes are triggered, and the error causes the flow to end, that counts as one flow run.

The following examples show how flow runs are counted in more complex Toolkit scenarios.

Example of how different Toolkit input nodes affect the number of flow runs

Screenshot that shows a Toolkit flow with MQInput, TimeoutNotification, HTTPInput, and HTTPAsyncResponse nodes. The TimeoutNotification, HTTPInput, and HTTPAsyncResponse nodes are connected to Compute nodes. The MQInput node and the TimeoutNotification node's Compute node are connected to an MQOutput node. The HTTPInput node's Compute node is connected to an HTTPAsyncRequest node. The HTTPAsyncResponse nodes's Compute node is connected to an HTTPReply node.
This example shows how input nodes in a Toolkit flow with different behaviors affect the number of flow runs that you're charged for. The example includes three different input node behaviors: triggering a flow to send a single synchronous message, triggering a flow on a schedule, and triggering request and response flows to process a message asynchronously. Each of these triggers counts as one flow run.
  • An MQInput node triggers a flow run when a message is put on a queue. The MQInput node propagates the message to an MQOutput node, which then puts the message on a queue. The flow run completes and you're charged for one flow run.
  • A TimeoutNotification node is configured to trigger a flow run every second. Each second, the TimeoutNotification node propagates a message to a Compute node, which then propagates the message to an MQOutput node. The flow run completes, but repeats every second. Therefore, you're charged for one flow run per second.
  • An HTTPInput node triggers a flow run when an HTTP request is made to the integration runtime. The HTTPInput node propagates the message to a Compute node, which then propagates the message to an HTTPAsyncRequest node. An HTTP request is started but because the operation is asynchronous, the flow run completes before the response is returned. When a response is received, the HTTPAsyncResponse node triggers a new flow run that propagates the message to a Compute node, which sends an HTTP response to the original HTTP request. The second flow run completes. You're charged for two flow runs: one for the request and one for the asynchronous response.

Example of how actions in a single Toolkit flow affect the number of flow runs

Screenshot that shows a Toolkit flow with an SAPInput and a SiebelInput node. The SAPInput node is connected to a Resequence node. The SiebelInput and Resequence nodes are connected to a Collector node. The Collector node is connected to an MQOutput node.
This example shows that actions in a single Toolkit flow can trigger multiple flow runs. In this example, SAPInput and SiebelInput nodes receive events from SAP and Siebel systems. A Collector node combines them into one message, which is then placed on a queue. Each time an input message is received, or a Resequence node sends a stored event, or a Collector node sends a combined message counts as one flow run. The process is described in more detail in the following steps.
  1. An SAPInput node receives an event and propagates it to a Resequence node, which stores the event. The flow run completes and you're charged for one flow run.
  2. The Resequence node processes stored events when it receives the next event in the sequence that it's monitoring. The node then triggers a flow run that propagates the events to a Collector node, which stores the event. The flow run completes and you're charged for one flow run. The Collector node doesn't process the events until it has a full collection.
  3. A SiebelInput node then triggers a flow run and propagates an event to the Collector node, which stores the event. The flow run completes and you're charged for one flow run.
  4. When the Collector node has a complete collection, it builds a combined event that contains both SAP and Siebel data. The Collector node then propagates the combined event to the MQOutput node, which puts the message on a queue. The flow run completes and you're charged for one flow run.

Therefore, in the simplest version of this scenario where you receive two input messages, you're charged for four flow runs to produce one output message.

Monitoring your use of flow runs

Use the IBM SaaS Console to see how much of your entitlement you used and how much remains. Click the Current period usage value to view how many flow runs you used for each month. For more information, see Getting started with the IBM Automation management console.

You receive reminders by email when you reach specific thresholds of your allowance. If you need to buy more flow runs, contact IBM.

Deploying your flows on the flow runs plan

When you pay for the number of flow runs that you need, you don't need to configure the size of the integration runtime that runs your flows. You deploy your flows and view deployed flows on the Manage page of App Connect Designer.

You can have a maximum of 50 deployed flows or BAR files at a time. To provide high availability when you deploy BAR files, multiple copies of the BAR file run on different servers. For more information, see Deploying integrations on the flow runs plan.

VPC hours plan

A virtual processor core (VPC) is a unit of measurement that is used to determine the licensing cost of IBM products. A VPC hour represents each hour that a VPC is available to App Connect Enterprise as a Service. When you choose VPC-hour pricing, you pay for the number of hours that each VPC is available to each instance of App Connect Enterprise as a Service for the next 12 months.

You're charged for the resources that are used by the flows that are deployed to an integration runtime. The App Connect Designer authoring environment isn't charged because it supports the development and testing of flows only.

VPC usage is sampled several times an hour, and the peak usage determines the usage of the VPC. For example, if you use two VPCs between 1 AM and 2 AM, then disable them, you're billed for two VPCs for the day. If you use three VPCs for one minute between 1 AM and 2 AM, then use two VPCs for the rest of the hour, you're billed for three VPCs for that hour.

Deploying your flows on the VPC hours plan

When you deploy your workload to the App Connect Dashboard, you create an integration runtime of an appropriate size to run your flows. You can see how much VPC capacity is associated with each choice so that you can choose the appropriate size for your integration. Billing is based on the size of the integration runtime that you create and not the amount of resources that your integration runtime uses.
Screenshot that shows the Size tab of the Deploy integrations page.

When you create an integration runtime, you set appropriate amounts of CPU and memory. The ratio of CPU to memory is limited to 1:2. For example, if you assign 0.5 CPU cores to your runtime, the maximum amount of memory that you can assign is 1 GB. Similarly, if you assign one CPU core, the memory limit is 2 GB. If the deployed BAR files don't match the size of the integration runtime, the VPC cost might be affected.

In addition to choosing the size of the integration runtime, you can also create replicas of an integration runtime to allow for better availability of your solutions. Increasing the number of replicas proportionally increases the resource requirements of the integration.

For more information, see Creating an integration runtime.

Monitoring your use of VPC hours

Use the IBM SaaS Console to see how much of your entitlement you used and how much remains. Click the Current period usage value to view how many VPC hours you used for each month. For more information, see Getting started with the IBM Automation management console.

You receive reminders by email when you reach specific thresholds of your allowance. If you need to buy more VPC hours, contact IBM.