---
title: Sizing and performance tuning for EDOT Cloud Forwarder for Azure
description: Size EDOT Cloud Forwarder for Azure and tune scaling parameters for your workload.
url: https://docs-v3-preview.elastic.dev/elastic/edot-cloud-forwarder-azure/tree/main/reference/edot-cf-azure/sizing-performance-tuning-cost
products:
  - EDOT Cloud Forwarder
  - EDOT Cloud Forwarder for Azure
  - Elastic Cloud Serverless
  - Elastic Observability
applies_to:
  - Serverless Observability projects: Preview
  - Elastic Distribution of OpenTelemetry Cloud Forwarder for Azure: Preview since 0.7
---

# Sizing and performance tuning for EDOT Cloud Forwarder for Azure
EDOT Cloud Forwarder for Azure runs as an Azure Function on the Flex Consumption plan. The following guidance helps you size and tune your workload.

## Tuning parameters

The default settings work well for most workloads. Adjust them only if you observe timeouts, high latency, or consistently high instance counts in Application Insights.

| Service      | Parameter                  | Default       | Range                    | Description                                                                                                         |
|--------------|----------------------------|---------------|--------------------------|---------------------------------------------------------------------------------------------------------------------|
| Function App | **Instance memory**        | 512 MB        | 512, 2048, 4096 MB       | Memory allocated per function instance. Higher memory can reduce processing time, but increases cost.               |
| Function App | **Maximum instance count** | 40            | 40-1000                  | Upper bound on concurrent instances that the Flex Consumption plan can scale to.                                    |
| Function App | **Always Ready instances** | 0 (On-Demand) | 0+                       | Number of pre-warmed instances kept running. This reduces cold-start latency, but adds idle cost.                   |
| Event Hub    | **Tier**                   | Standard      | Basic, Standard, Premium | Tier of the Event Hubs namespace. Higher tiers support more throughput units and features such as capture.          |
| Event Hub    | **Capacity**               | 1             | 1-40 (Standard)          | Number of throughput units. Each unit provides 1 MB/s ingress and 2 MB/s egress. Scale up for higher event volumes. |
| Event Hub    | **Partition count**        | 4             | 2-32                     | Number of partitions per event hub. More partitions enable higher parallelism and throughput.                       |

<note>
  **Event Hubs** is the name of the Azure service. An **Event Hubs namespace** is a regional container for messaging resources. An **event hub** is the entity where events are produced and consumed (similar to a Kafka topic). The following table refers to settings that apply to the namespace or to each event hub, depending on the parameter.
</note>


## Sizing

The default configuration of 512 MB instance memory and 4 Event Hub partitions handles most workloads. For higher event volumes, increase the number of partitions before increasing memory.

| Event volume           | Instance memory  | Partitions  | Note                                                  |
|------------------------|------------------|-------------|-------------------------------------------------------|
| **Low** (< 5 MB/s)     | 512 MB (default) | 4 (default) | No changes needed.                                    |
| **Medium** (5-10 MB/s) | 512 MB           | 8           | Increase partitions first.                            |
| **High** (> 10 MB/s)   | 512 MB           | 16          | Increase partitions first, then consider more memory. |

<tip>
  Monitor execution duration in Application Insights. If average duration approaches the function timeout, increase the number of partitions to raise concurrency.
</tip>


## Monitoring

Track these metrics in **Application Insights** to detect performance issues early.

| Metric               | What to look for                                                                                                          |
|----------------------|---------------------------------------------------------------------------------------------------------------------------|
| **Execution count**  | Sustained high values can indicate the need for more instances.                                                           |
| **Average duration** | Rising values with event volume are expected. If duration approaches the timeout, add partitions to increase concurrency. |
| **Failures**         | Should remain at 0. Investigate any non-zero values in Application Insights logs.                                         |
| **Instance count**   | Should not consistently reach your configured maximum instance count. The default maximum is 40.                          |

Use this KQL query in Application Insights to measure current execution volume and duration:
```kql
requests
| where timestamp >= startofmonth(now())
| where cloud_RoleName == "<your-function-app-name>"
| summarize
    executions = count(),
    avgDurationSec = avg(duration) / 1000.0
```


## Cost model

The following sections describe the cost model for EDOT Cloud Forwarder for Azure.

### Flex Consumption billing

EDOT Cloud Forwarder for Azure uses the Flex Consumption plan, which supports two billing modes:
**On-Demand (default)**:
- Instances scale automatically based on incoming events.
- Billing occurs only during execution.
- Charges are based on the number of executions, plus memory in GB multiplied by duration in seconds.
- There is no idle Function App cost.

**Always Ready**:
- A fixed number of instances remain always ready.
- This reduces cold-start latency.
- Billing applies to provisioned memory while idle, as well as memory during execution and execution count.
- This creates a baseline monthly cost even with zero traffic.


### Monthly free grant

Azure provides a [monthly free grant](https://azure.microsoft.com/en-us/pricing/details/functions/) per subscription under pay-as-you-go pricing:
- **250,000** executions per month.
- **100,000** GB-seconds per month.

These limits are independent. Exceeding either one triggers charges for that dimension.

### Calculating GB-seconds

Function App execution cost is driven by GB-seconds:
```text
GB-seconds = executions × duration (seconds) × memory (GB)
```

For example, with the following measured values:

| Metric           | Value          |
|------------------|----------------|
| Executions       | 1,186,012      |
| Average duration | 6.414 seconds  |
| Instance memory  | 2048 MB (2 GB) |

The calculation is:
```text
1,186,012 x 6.414 x 2 GB ~= 15,214,161 GB-seconds
```


### Idle baseline cost

With no incoming logs, the main cost contributor is the Event Hubs namespace in the Standard tier. The Function App itself does not incur charges when idle in On-Demand mode.

| Resource                 | Idle cost | Notes                                                      |
|--------------------------|-----------|------------------------------------------------------------|
| Event Hubs namespace     | Low       | Standard tier. Scale throughput units down to reduce cost. |
| Function App (On-Demand) | None      | No charge when not executing.                              |
| Storage account          | Minimal   | Used for function state.                                   |
| Application Insights     | Varies    | Depends on ingested data volume.                           |


### Cost estimation

Use the [Azure Pricing Calculator](https://azure.microsoft.com/en-us/pricing/calculator/) to forecast costs for your workload. Configure the following:
- **Azure Functions** for memory, execution volume, and hosting mode.
- **Event Hubs** for throughput units based on expected log volume.
- **Storage** for completeness, even though cost is usually minimal.