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.

Flow runs are subject to the following limits.
  • A single flow can run for a maximum of 10 minutes.

    The running time of the flow is measured from when the flow is triggered until the last action completes for that trigger. This limit doesn't include batch processes that run asynchronously to the flow but that are counted as part of the flow.

  • The maximum size of the data that can trigger the flow is 100 MB.

    This limit includes the event, request, or the total size of a batch. 100 MB is the overall limit, but the limit might be lower for some connectors or nodes. Individual limits are documented in the how-to guides.

  • A maximum of 1000 actions (or nodes) can be completed in one flow run.

    This limit is not for the number of steps in a flow but the number of times an action is completed during one flow run.

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 create a maximum of 100 draft flows in your App Connect Enterprise as a Service instance and you can have a maximum of 100 BAR files. To provide high availability when you deploy BAR files, multiple copies of the BAR file run on different runtimes. 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 your running integration runtimes, even if no integrations are deployed to them. To stop a running integration runtime so that it doesn't use any resources, you can either delete it or set the number of replicas to zero. You can then increase the number of replicas again when you're ready to run the integration runtime. You're not charged for the resources that are used when you test flows in the App Connect Designer flow editor.

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 hoursplan

When you deploy your workload on the VPC hours plan, 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.
Figure 1. Integration runtime templates for creating a runtime in the App Connect Dashboard
Integration runtime templates for creating a runtime in the App Connect Dashboard
Figure 2. Integration runtime templates for creating a runtime in App Connect Designer
Integration runtime templates for creating a runtime on the Manage 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 integrations don't match the size of the integration runtime, the VPC cost might be affected. 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.

If you're deploying an integration that you developed in the IBM App Connect Enterprise Toolkit, you export it from the Toolkit as a BAR file, then import it into App Connect Enterprise as a Service. If you're using the App Connect Dashboard to deploy flows that you created in App Connect Designer, you also export those flows as BAR files. If you're deploying Designer flows on the Manage page, those flows are automatically added to a BAR file when you deploy them. This type of BAR file is identified on the BAR files page in the App Connect Dashboard as a system-generated BAR file.
Note: You can have up to 100 BAR files on the BAR files page for your App Connect Enterprise as a Service instance. System-generated BAR files contribute towards the limit of 100 BAR files.

For more information, see Deploying integrations on the VPC plan.

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 can also see CPU and memory usage data for your integration runtimes on the Monitoring page The icon that represents the Monitoring page of App Connect Designer. For more information, see Monitoring resources.
Note: Billing and monitoring data originate from the same source but are presented differently. Monitoring data is aggregated so that you can assess performance and identify issues. Therefore, it's normal for monitoring data to appear different from billing data. To view billing and usage data, use the IBM SaaS Console.
Flows on the VPC hours plan are subject to the following limits.
  • A single flow can run for a maximum of 10 minutes.

    The running time of the flow is measured from when the flow is triggered until the last action completes for that trigger. This limit doesn't include batch processes that run asynchronously to the flow but that are counted as part of the flow.

  • The maximum size of the data that can trigger the flow is 100 MB.

    This limit includes the event, request, or the total size of a batch. 100 MB is the overall limit, but the limit might be lower for some connectors or nodes. Individual limits are documented in the how-to guides.

  • A maximum of 1000 actions (or nodes) can be completed in one flow run.

    This limit is not for the number of steps in a flow but the number of times an action is completed during one flow run.

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