- Manage Billing
StreamNative Cloud Billing
StreamNative Cloud bills are based on the consumption of resources within your cloud organization. This includes, but is not limited to, the compute units, storage units, and the total amount of data transferred in and out of your cluster.
Billing for each StreamNative Cloud component accrues at hourly intervals. Any usage of less than an hour is billed for the entire hour. All billing computations are conducted in Coordinated Universal Time (UTC).
Note
Billing accrues hourly, with a monthly-in-arrears invoicing cycle. If you de-provision resources that have accrued billed usage during the current month, billing will no longer accrue for these resources, but the billed usage accrued so far in the invoicing cycle will appear on your next invoice.
Subscription plan
A subscription is an agreement between you and StreamNative to pay for service on a particular schedule. In the current release, when you create an instance and a cluster on the StreamNative Cloud Console, you are automatically enrolled in the default Pay-As-You-Go subscription plan. For customers who have legacy clusters, submit a ticket to get assistance with moving your cluster to the updated subscription plan.
If you want to provision a cluster with snctl instead of on StreamNative Cloud Console, you'll need to first create a subscription with snctl. For more information about snctl, see the StreamNative CLI (snctl).
For more information about viewing your invoices, what resources are included on your invoice, how to update your payment information, and more, see the billing documentation page.
Billing dimensions
StreamNative Cloud offers multiple cluster types. The billing dimensions vary by cluster type.
Important
StreamNative storage and throughput are calculated in binary gigabytes (GB), where 1 GB is 2^30 bytes. This unit of measurement is also known as a gibibyte (GiB).
Serverless clusters
Public Preview
Serverless Clusters are currently in Public Preview. During this phase, we're actively gathering feedback and refining the service. Pricing structure is subject to change.
Serverless clusters adopt a throughput-based pricing model. The following table summarizes the billing dimensions for serverless clusters.
| Dimension | Unit of measure |
|---|---|
| Elastic Throughput Unit (ETU) | Cost per ETU per hour |
| Ingress (Data In) | Cost per GB |
| Egress (Data Out) | Cost per GB |
| Storage (Data Stored) | Cost per GB stored per hour |
Dedicated clusters
Dedicated clusters adopt a resource-based pricing model. The following table summarizes the billing dimensions for dedicated clusters.
| Dimension | Unit of measure |
|---|---|
| Compute Unit (CU) | Cost per CU per hour |
| Storage Unit (SU) | Cost per SU per hour |
| Ingress (Data in) | Cost per GB |
| Egress (Data out) | Cost per GB |
| Storage (Data stored) | Cost per GB stored per hour |
Classic-Engine BYOC & BYOC Pro clusters
Classic-Engine BYOC & BYOC Pro clusters adopt a resource-based pricing model. The following table summarizes the billing dimensions for Classic-Engine BYOC & BYOC Pro clusters.
| Dimension | Unit of measure |
|---|---|
| Compute Unit (CU) | Cost per CU per hour |
| Storage Unit (SU) | Cost per SU per hour |
Ursa-Engine BYOC & BYOC Pro clusters
Public Preview
Ursa Engine is currently in Public Preview. During this phase, we're actively gathering feedback and refining the service. Pricing structure is subject to change.
Ursa-Engine BYOC & BYOC Pro clusters adopt a throughput-based pricing model. The following table summarizes the billing dimensions for Ursa-Engine BYOC & BYOC Pro clusters.
| Dimension | Unit of measure |
|---|---|
| Elastic Throughput Unit (ETU) | Cost per ETU per hour |
Elastic Throughput Unit (ETU)
Elastic Throughput Units (ETUs) are the basis for billing clusters that adopt a throughput-based pricing model, including Serverless clusters and Ursa-Engine BYOC (and BYOC Pro) clusters in StreamNative Cloud. ETUs provide a flexible, scalable approach to resource allocation and pricing.
How ETUs Work
Clusters adopting ETUs are elastic and have a minimum number of ETUs. They can automatically scale up to a maximum capacity based on your workload. The minimum ETUs define the baseline capacity of your cluster, which is the minimum amount you are billed for even when the cluster is idle. The maximum capacity is defined in terms of ETUs and governs the peak resources your StreamNative cluster can use. However, you are only billed for the actual capacity used in a given hour, up to this maximum.
To determine the number of ETUs used in a given hour, the billing system monitors the actual consumption across several dimensions:
Ingress (Data In): This dimension measures the volume of data being written to your cluster. It is calculated as the total amount of data (in bytes) ingested into the cluster per second.
Egress (Data Out): This dimension measures the volume of data being read from your cluster. It is calculated as the total amount of data (in bytes) retrieved from the cluster per second.
Data Entries: This dimension counts the number of entries processed by the cluster per second. An entry represents a collection of messages batched together by either Pulsar or Kafka client. It includes both produce and consume operations.
If your cluster has zero consumption across all these dimensions, you will be billed for the minimum ETUs. This occurs when your cluster has no partitions, no topics have been created (or all topics have been deleted), and there is no capacity usage from any ETU-eligible dimension.
Serverless ETU Capacity and Limits
Each Serverless ETU represents a certain capacity across different dimensions. Here's a breakdown of what one Serverless ETU provides:
| Dimension | ETU Capacity |
|---|---|
| Ingress (Data In) | 5 megabytes per second (MBps) |
| Egress (Data Out) | 15 megabytes per second (MBps) |
| Data Entries | 500 entries per second |
The maximum capacity for a Serverless cluster is currently set at 20 ETUs, which translates to the following limits:
| Dimension | Maximum Capacity |
|---|---|
| Ingress (Data In) | 100 MBps |
| Egress (Data Out) | 300 MBps |
| Data Entries | 10,000 per second |
There is no minimum ETUs for a Serverless cluster.
BYOC ETU Capacity and Limits
Each BYOC ETU represents a certain capacity across different dimensions for Ursa-Engine BYOC & BYOC Pro clusters. Here's a breakdown of what one BYOC ETU provides:
| Dimension | ETU Capacity |
|---|---|
| Ingress (Data In) | 25 megabytes per second (MBps) |
| Egress (Data Out) | 75 megabytes per second (MBps) |
| Data Entries | 2500 entries per second |
The maximum capacity for a Ursa-Engine BYOC (or BYOC Pro) cluster is unlimited. Your actual throughput is capped by the resources you use for running brokers.
The minimum ETUs for a Ursa-Engine BYOC or BYOC Pro cluster is 1 ETU.
Determining ETU Usage
To estimate your ETU usage, you can monitor your cluster's performance across the three dimensions mentioned above. Your ETU consumption for a given hour will be based on the highest usage across these dimensions, relative to the capacity provided by one ETU.
For example, if in one hour your Serverless cluster uses:
- 20 MBps ingress (4 ETUs worth)
- 45 MBps egress (3 ETUs worth)
- 1,500 data entries per second (3 ETUs worth)
Your usage for that hour would be billed as 4 ETUs, based on the highest consumption dimension (ingress in this case).
Another example is if your Ursa-Engine BYOC cluster uses:
- 100 MBps ingress (4 ETUs worth)
- 100 MBps egress (1 ETUs worth)
- 12,500 data entries per second (5 ETUs worth)
Your usage for that hour would be billed as 5 ETUs, based on the highest consumption dimension (data entries in this case).
By understanding and monitoring these metrics, you can effectively optimize your resource usage and control costs in StreamNative Cloud.
CU and SU
Dedicated (formerly Hosted) and BYOC (including BYOC Pro) clusters are scaled using Compute Units (CUs) and Storage Units (SUs). These units provide a standardized way to allocate and manage resources for your StreamNative clusters.
Compute Units (CUs)
- Definition: One CU represents a unit of compute resources, specifically 2 CPUs and 8 GB RAM.
- Usage: CUs are used to scale all stateless components in your cluster, primarily the brokers.
- Scaling: You can adjust the number of CUs to increase or decrease the processing power of your cluster.
Storage Units (SUs)
- Definition: One SU represents a unit of storage resources, specifically 2 CPUs, 8 GB RAM, and 256 GB disk.
- Usage: SUs are used to scale all stateful components in your cluster, including BookKeeper and ZooKeeper.
- Scaling: Adjusting the number of SUs allows you to manage the storage capacity and performance of your cluster.
Billing and Resource Allocation
The number of CUs and SUs used by a StreamNative cluster determines the total resources allocated. Charges for CUs and SUs accrue each hour based on the allocated resources. You can expand or shrink your cluster by adding or removing CUs and SUs. When you modify the cluster capacity, you are billed for the new resource allocation starting from the next hour following the change.
Limits per CU and SU
CUs and SUs determine the capacity of a StreamNative cluster. For a StreamNative Cloud cluster, the expected performance for any given workload is dependent on a variety of dimensions, such as message size and number of partitions.
Use the following guidelines to determine the minimum number of CUs and SUs to use for a given workload, how to monitor a dimension, and suggestions to reduce your use of a particular dimension.
Important
These dimensions provide guidelines for capacity planning. The ability to fully utilize these dimensions depends on the workload and utilization of other dimensions.
Recommended guideline for a broker CU
| Dimension | Guideline per CU | Details |
|---|---|---|
| Ingress | 50 MBps | Number of bytes that can be produced to the cluster in one second. To reduce usage on this dimension, you can compress your messages. lz4 is recommended for compression. |
| Egress | 150 MBps | Number of bytes that can be consumed from the cluster in one second. To reduce usage on this dimension, you can compress your messages and ensure each consumer is only consuming from the topics it requires. lz4 is recommended for compression. |
| Requests (aka Data Entries) | 10,000 per second | Number of data entries (each entry is a batch of messages batched at the client side) that can be produced to and consumed from the cluster in one second. To reduce usage on this dimension, you can adjust producer batching configurations and shut down otherwise inactive clients. |
Recommended guideline for a bookie SU
A SU can support a maximum post-replication write throughput of 125 MBps. However, the actual throughput varies based on different factors including data entry size, data entry rate, etc. To attain the peak post-replication write throughput of 125 MBps, clients must efficiently batch their requests.
ETU vs CU/SU
ETU and CU/SU are similar billing metrics for different StreamNative cluster types. Both metrics quantify the pre-allocated resources across various capacity dimensions. The difference between them is how you are billed. With Dedicated, BYOC, and BYOC Pro clusters, you are billed based on the number of CUs and SUs you use for your cluster. If your cluster uses less capacity than what you set, you still pay the same.
By contrast, Serverless clusters are elastic. You purchase a cluster with a fixed maximum, but you are only obligated to pay for a minimum amount of capacity if there is any dimensional consumption. Your cost can only go as high as the fixed maximum. If you're at zero capacity, you don't pay for anything.
Dedicated and BYOC clusters
You determine the capacity of your cluster at creation by specifying the number of brokers and bookies, and the number of CPUs and RAM for each. You pay for whatever number you purchase.
Serverless clusters
Your cluster comes with a fixed maximum capacity. You pay nothing if there is no dimensional consumption (your cluster is at zero capacity). With consumption, you pay the minimum plus whatever you use over the minimum up to the maximum.
Ingress and Egress
StreamNative Cloud charges for data transfer in two directions:
- Ingress: Data transferred into your Serverless and Dedicated clusters.
- Egress: Data transferred out of your Serverless and Dedicated clusters.
These charges apply to all network traffic, including:
- Data produced to topics
- Data consumed from topics
- Replication traffic between clusters
- Admin operations (e.g., topic creation, subscription creation)
Billing for ingress and egress is based on the total volume of data transferred, measured in gigabytes (GB). The rates may differ for ingress and egress, so it's important to monitor both metrics separately.
To optimize your costs:
- Use compression for message payloads
- Implement efficient batching strategies
- Minimize unnecessary data transfers
Important
For BYOC (Bring Your Own Cloud) clusters, StreamNative Cloud does not charge for data transfers. These resources are hosted and billed directly by your cloud provider, so you'll need to refer to your provider's pricing for these costs.
Storage
StreamNative Cloud charges for the total volume of data stored in your Serverless and Dedicated clusters. Here are key points to understand about storage billing:
Pre-replication volume: Billing is based on the pre-replication volume of data. This means you're charged for the actual data you store, not the replicated copies.
Replication factor: StreamNative Cloud uses a built-in replication factor of 3 for high availability. While this triples the actual storage used, you're only billed for the pre-replication volume.
Billing calculation: Storage is billed based on the average volume of data stored over each hour, measured in gigabytes (GB).
Retention policy: To optimize storage costs, you can configure retention policies for your topics. These policies can automatically delete data after a specified period or when certain size limits are reached.
Compaction: For topics that only need to retain the latest value for each key, you can use compaction to reduce storage usage while preserving the most recent updates.
BYOC clusters
For Bring Your Own Cloud (BYOC) clusters, StreamNative Cloud does not charge for data storage. These resources are hosted and billed directly by your cloud provider.
To monitor and manage your storage usage, use the StreamNative Cloud Console or API to track storage metrics and adjust your data retention strategies as needed.
Functions and Connectors
StreamNative Cloud charges for functions and connectors based on the Function Processing Units (FPUs) they consume. This pricing model applies to all Pulsar cluster types: Serverless, Dedicated, and BYOC (including BYOC Pro).
An FPU represents a unit of compute resources, specifically 2 CPUs and 8 GB of RAM, dedicated to running functions or connectors. The charge for functions and connectors is based on the number of FPUs allocated and the duration of their usage.
Key points about function and connector billing:
Consistent across cluster types: The FPU-based billing model is uniform across all Pulsar cluster types, ensuring consistency in how you're charged for these components.
Resource allocation: When you deploy a function or connector, you specify the resources it requires. StreamNative Cloud then allocates the appropriate number of FPUs based on this specification.
Usage-based billing: You are billed for the FPUs allocated to your functions and connectors for as long as they are running. This means you only pay for the resources you use.
Scalability: If your functions or connectors auto-scale, the billing automatically adjusts to reflect the increased or decreased FPU usage.
Monitoring and optimization: You can monitor your function and connector usage in the StreamNative Cloud Console to optimize your resource allocation and manage costs effectively.
By using this FPU-based model, StreamNative Cloud provides a flexible and transparent way to charge for function and connector usage, regardless of the underlying Pulsar cluster type you're using.
Consumption Units and Support Units
All StreamNative Cloud billing dimensions are calculated in StreamNative Consumption Units. Your overall charge for StreamNative Cloud usage will be equal to the total number of Consumption Units multiplied by the cost of that unit.
The support plan purchased from StreamNative is also based on the Support Units. Your overall support cost will be the total number of Support Units multiplied by the cost of that unit.
| Unit | Price | Description |
|---|---|---|
| StreamNative Consumption Unit | $0.1 | A Consumption Unit captures your StreamNative Cloud usage based on underlying metrics such as Compute Units (CUs), Storage Units (SUs), data stored, data in, and data out. |
| StreamNative Support Unit | $0.1 | A Support Unit captures your StreamNative Support costs based on your support plan. The support plan is a separate and optional purchase item. |
Pricing dimensions
This section describes pricing dimensions for Serverless, Dedicated (formerly Hosted), and BYOC clusters and provides a pricing example.
Pricing dimensions for Serverless clusters
The following table outlines the prices for usage dimensions for Serverless clusters.
| Dimension | Consumption Units | Price |
|---|---|---|
| Elastic Throughput Unit (ETU) ($/hour) | 1 ETU/hour = 1 Consumption Unit | $0.10 |
| Ingress (Data In) ($/GB) | 1 GB = 1.3 Consumption Units | $0.13 |
| Egress (Data Out) ($/GB) | 1 GB = 0.4 Consumption Unit | $0.04 |
| Storage (Data Stored) ($/GB-Month) | 1 GB-Month = 0.9 Consumption Unit | $0.09 |
Pricing dimensions for Dedicated clusters
The following table outlines the prices for usage dimensions for Dedicated (formerly Hosted) clusters.
| Dimension | Consumption Units | Price |
|---|---|---|
| Compute Unit (CU) ($/hour) | 1 CU/hour = 2.4 Consumption Units | $0.24 |
| Storage Unit (SU) ($/hour) | 1 SU/hour = 3 Consumption Units | $0.30 |
| Ingress (Data In) ($/GB) | 1 GB = 1.3 Consumption Units | $0.13 |
| Egress (Data Out) ($/GB) | 1 GB = 0.4 Consumption Unit | $0.04 |
| Storage (Data Stored) ($/GB-Month) | 1 GB-Month = 0.9 Consumption Unit | $0.09 |
Pricing dimensions for Classic-Engine BYOC clusters
The following table outlines the prices for usage dimensions for Classic-Engine BYOC clusters.
| Dimension | Consumption Units | Price |
|---|---|---|
| Compute Unit (CU) ($/hour) | 1 CU/hour = 2 Consumption Units | $0.20 |
| Storage Unit (SU) ($/hour) | 1 SU/hour = 3 Consumption Units | $0.30 |
You can contact StreamNative sales to get a quote for BYOC Pro clusters.
Pricing dimensions for Ursa-Engine BYOC clusters
The following table outlines the prices for usage dimensions for Ursa-Engine BYOC clusters.
| Dimension | Consumption Units | Price |
|---|---|---|
| Elastic Throughput Unit (ETU) ($/hour) | 1 ETU/hour = 5 Consumption Unit | $0.50 |
You can contact StreamNative sales to get a quote for BYOC Pro clusters.
Pricing dimensions for Functions and Connectors
The following table outlines the prices for usage dimensions for Functions and Connectors.
| Dimension | Consumption Units | Price |
|---|---|---|
| Functions (FPU) ($/hour) | 1 FPU/hour = 1 Consumption Unit | $0.10 |
Pricing models
You can either pay as you go or make an annual commitment. Discounts based on usage are available with annual commitments.
Annual commitments
StreamNative Cloud offers the ability to make a commitment to a minimum amount of spend over a specified time period. This commitment gives you access to discounts and allows you to use this commitment across the entire StreamNative Cloud stack, including any StreamNative cluster type, connectors, functions, and support.
If you use more than your committed amount, you can continue using StreamNative Cloud without interruption. You will be charged at the on-demand price for usage beyond the committed amount until the end of your commitment term. Commitments are minimums, and there is no negative impact to exceeding your committed usage. If you exceed this minimum, overage charges will be billed to the payment method set for your organization.
Contact StreamNative to learn more about annual commitments, or review these topics.
- Get Started with StreamNative Cloud on the AWS Marketplace with Commitments
- Get Started with StreamNative Cloud on the Google Cloud Marketplace with Commitments
Pay-As-You-Go
With the Pay-As-You-Go pricing model, you can sign up and pay monthly in arrears. If you sign up for StreamNative Cloud directly through StreamNative, your organization will be on the Pay-As-You-Go billing model by default.
The Pay As You Go billing model is also available on the Cloud Marketplace channels. For more information on the cloud provider Marketplace integrations, see:
- Get Started with StreamNative Cloud on the AWS Marketplace with Pay-As-You-Go
- Get Started with StreamNative Cloud on the Google Cloud Marketplace with Pay-As-You-Go
Pay-As-You-Go billing schedule
This section describes the billing schedule for the Pay-As-You-Go pricing model.
Monthly, billed by StreamNative
When you sign up for StreamNative Cloud service by adding your credit card details in the StreamNative Cloud Console, you are billed monthly.
At each billing cycle, on the first day of each month, all usage for the previous month is aggregated, invoiced, and charged in arrears on the credit card used to sign up for the service.
All usage is expressed and charged in US dollars only.
Monthly, billed through Marketplace
Note
- Typically, marketplaces invoice you in arrears on the first day of each month. However, there are exceptions, such as in the case of the Google Cloud billing cycle.
- AWS marketplace only accepts integer usage. If your usage is smaller than the billing unit, the user is still charged at the billing unit price.
You can sign up for StreamNative Cloud service through Cloud Marketplace channels. In this case, all usage is reported hourly to the marketplace.
At the marketplace's billing cycle, all usage is aggregated and charged as part of your cloud provider bill.
StreamNative Cloud service usage is a single invoice line with the total amount charged.
Pricing examples
This section provides pricing examples for Pulsar clusters, Pulsar functions, and connectors.
Note
The examples below estimate service costs based on a normalized monthly time frame. It assumes there are 730 hours in a month ((365 days * 24 hours) / 12 months in a year). The actual hours in a given billing period will vary slightly.
Pricing example for a Dedicated cluster
Note
On StreamNative Cloud, a minimum Dedicated cluster consists of 2 brokers and 3 bookies. Each broker consumes 0.5 compute units per month and each bookie consumes 0.5 storage units per month. Therefore, the minimum cost for a Dedicated cluster is about $505 per month.
Suppose you have a Dedicated cluster on StreamNative Cloud, running an entire month, with the following details:
3 brokers, each with 2 CUs
3 bookies, each with 2 SUs
200 GB data in
200 GB data out
200 GB data retained
CU: The total Consumption Units are
6 CUs x 2.4 Consumption Units / CU-hour x 730 hours = 10,512 Consumption UnitsSU: The total Consumption Units are
6 SUs x 3 Consumption Units / SU-hour x 730 hours = 13140 Consumption UnitsData in: The total Consumption Units are
200 GB x 1.3 Consumption Units / GB = 260 Consumption UnitsData out: The total Consumption Units are
200 GB x 0.4 Consumption Unit / GB = 80 Consumption UnitsData stored: The total Consumption Units are
200 GB-Month x 0.9 Consumption Unit / GB-Month = 180 Consumption Units
Therefore, the total cost of this cluster will be 24,172 Consumption Units x $0.10 per Consumption Unit = $2417.2.
Pricing example for a Serverless cluster
Note
Serverless clusters are billed based on actual usage of resources, without the need to provision specific compute or storage units upfront.
Suppose you have a Serverless cluster on StreamNative Cloud, running for an entire month, with the following usage:
- Average write throughput (Ingress): 1 MBps
- Average read throughput (Egress): 3 MBps
- Average entry size (batch size at the client side): 64 KB
- Retention: 7 days
So:
- the total Data-Stored for 7-days retention is
1 MBps x 60 x 60 x 24 x 7 = 604,800 MB = 604,800 / 1024 = 590.625 GB. - the total Data-In in a month is
1 MBps x 60 x 60 x 730 = 2,628,000 MB = 2,628,000 / 1024 = 2,566.21 GB. - the total Data-Out in a month is
3 MBps x 60 x 60 x 730 = 7,884,000 MB = 7,884,000 / 1024 = 7,699.22 GB.
Let's calculate the total ETUs used by this cluster.
- ETUs by ingress:
1 MBps / 5 MBps/ETU = 0.2 ETUs - ETUs by egress:
3 MBps / 15 MBps/ETU = 0.2 ETUs - ETUs by data entries:
(1 MBps + 3 MBps) / 64 KB/entry / 500 entries/ETU = 0.128 ETUs
So the total ETUs used by this cluster is max(0.2, 0.2, 0.128) = 0.2 ETUs.
Let's calculate the total consumption units used by this cluster.
- ETU: The total Consumption Units are
0.2 ETUs x 1 Consumption Unit / ETU-hour x 730 hours = 146 Consumption Units - Data in: The total Consumption Units are
2,566.21 GB x 1.3 Consumption Units / GB = 3,336.073 Consumption Units - Data out: The total Consumption Units are
7,699.22 GB x 0.4 Consumption Unit / GB = 3,079.688 Consumption Units - Data stored: The total Consumption Units are
590.625 GB x 0.9 Consumption Unit / GB = 531.5625 Consumption Units
Therefore, the total cost of this cluster will be 146 + 3,336.073 + 3,079.688 + 531.5625 = 7,093.3235 Consumption Units x $0.10 per Consumption Unit = $709.33.
Pricing example for a Ursa-Engine BYOC cluster
Note
Ursa-Engine BYOC clusters are billing on actual throughput.
Suppose you have a Ursa-Engine BYOC cluster on StreamNative Cloud, running for an entire month, with the following usage:
- Average write throughput (Ingress): 50 MBps
- Average read throughput (Egress): 150 MBps
- Average entry size (batch size at the client side): 64 KB
- Retention: 7 days
Let's calculate the total ETUs used by this cluster.
- ETUs by ingress:
50 MBps / 25 MBps/ETU = 2 ETUs - ETUs by egress:
150 MBps / 75 MBps/ETU = 2 ETUs - ETUs by data entries:
(50 MBps + 150 MBps) / 64 KB/entry / 2500 entries/ETU = 1.28 ETUs
So the total ETUs used by this cluster is max(2, 2, 1.28) = 2 ETUs.
Let's calculate the total consumption units used by this cluster.
- ETU: The total Consumption Units are
2 ETUs x 5 Consumption Unit / ETU-hour x 730 hours = 7300 Consumption Units
Therefore, the total cost of this cluster will be 7300 Consumption Units x $0.10 per Consumption Unit = $730.
Pricing Example for Pulsar Functions and Connectors
Pulsar functions and connectors are billed based on the Function Processing Unit (FPU). You can convert the CPU and memory usage of your functions and connectors to FPUs based on the following formula:
max((CPU / 2),(Mem (in GB) / 8))
For example, if you specify 1 CPU and 1 GB memory for a function, the total FPU for this function is max(1 / 2,1 / 8) = 0.5 CU.
If you have a Dedicated cluster on StreamNative Cloud, running an entire month, with
- 32 functions, each with 0.5 CPU and 1 GB memory
- 20 connectors, each with 1 CPU and 1 GB memory
The total FPUs used by these functions and connectors are 32 x max((0.5 / 2), (1 / 8) ) + 20 x max((1 / 2),(1 / 8)) = 18 FPUs.
The total Consumption Units used by these functions and connectors are 18 FPUs x 1.8 Consumption Unit / CU-hour x 730 hours = 23652 Consumption Units.
Therefore, the total cost of these functions and connectors will be 23652 Consumption Units x $0.10 per Consumption Unit = $2365.20.