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.
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. |
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.
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. |
Monitor execution duration in Application Insights. If average duration approaches the function timeout, increase the number of partitions to raise concurrency.
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:
requests
| where timestamp >= startofmonth(now())
| where cloud_RoleName == "<your-function-app-name>"
| summarize
executions = count(),
avgDurationSec = avg(duration) / 1000.0
The following sections describe the cost model for EDOT Cloud Forwarder for Azure.
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.
Azure provides a monthly free grant 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.
Function App execution cost is driven by GB-seconds:
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:
1,186,012 x 6.414 x 2 GB ~= 15,214,161 GB-seconds
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. |
Use the Azure 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.