--- title: Configure Elastic Cloud Forwarder for Azure description: Configure the Elastic Cloud Forwarder for Azure Bicep template parameters. url: https://www.elastic.co/docs/reference/opentelemetry/edot-cloud-forwarder/azure/configure products: - Elastic Cloud Forwarder - Elastic Cloud Forwarder for Azure - Elastic Cloud Serverless - Elastic Observability applies_to: - Serverless Observability projects: Preview - Serverless Security projects: Preview - Elastic Cloud Forwarder for Azure: Preview since 0.7 --- # Configure Elastic Cloud Forwarder for Azure Before deploying Elastic Cloud Forwarder for Azure, configure the Bicep template parameters based on your specific requirements. The template uses the following settings to deploy and configure the Elastic Cloud Forwarder for Azure Function App. To provide the required parameters, you can either: - Use the `--parameters` flag when deploying the template. - Configure the parameters in the Azure portal when deploying the template. ## Parameters reference These parameters are available in the Bicep template. Configure them using the `--parameters` flag when deploying the template. ### Required parameters | Parameter | Description | |-----------------|---------------------------------------------------------------------------------------| | `otlpEndpoint` | OTLP service endpoint obtained from Elastic Cloud Serverless or Elastic Cloud Hosted. | | `elasticApiKey` | Elasticsearch API key for authentication. | ### Optional parameters The following parameters are optional and can be configured to customize the deployment. #### Per-signal encoding Encoding parameters control how each telemetry signal is transformed before being forwarded to Elasticsearch. Refer to the relevant signal page for details and examples. | Signal | Parameter | Default | Description | Available options | |---------|-------------------------|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------| | Logs | `logsEncodingExtension` | `azure_encoding` | Encoding extension for logs. Use `azure_encoding` for OTel Native format, or `beats_encoding` for ECS format. Refer to [Logs](/docs/reference/opentelemetry/edot-cloud-forwarder/azure/signals/logs#encoding). | `azure_encoding`, `beats_encoding` | | Metrics | _(none)_ | — | Metrics use a single OTel Native encoding. Refer to [Metrics](/docs/reference/opentelemetry/edot-cloud-forwarder/azure/signals/metrics#encoding). | — | #### Infrastructure parameters | Parameter | Default | Description | Available options | |-----------------------------------|----------------|----------------------------------------------------------------------------------------------------------------|--------------------------------------------------------| | `eventHubPartitionCount` | `4` | Number of partitions in the event hubs. | | | `eventHubMessageRetentionInDays` | `1` | Number of days for the event hub data retention. | | | `functionAppAlwaysReadyInstances` | `0` | Number of always-ready instances for function app. Refer to [Always-ready instances](#always-ready-instances). | `0` or more | | `version` | (see template) | Elastic Cloud Forwarder (ECF) for Azure version to deploy. | The `ecf.bicep` contains the latest version available. | ### Always-ready instances Always Ready is an optional number of instances that can be configured to be always enabled and assigned to different triggers and functions of the app. These instances stay pre-warmed so Event Hub–triggered functions can process messages as soon as they arrive, reducing cold start latency and helping ensure predictable processing when traffic arrives. - **Parameter**: `functionAppAlwaysReadyInstances` (both `infra/ecf.bicep` and `infra/ecf-flex-consumption-vnet.bicep`). - **Default**: `0` (no always-ready instances). #### Trade-offs | Setting | Pros | Cons | |---------------|-------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------| | `0` (default) | Lower cost; you pay only for execution time. | Cold starts can add latency when the first messages arrive or when scaling from zero. | | `1` or more | Lower latency; messages can be processed immediately. More predictable behavior under variable or bursty traffic. | Higher cost; refer to the Billing section. | #### Billing You are billed for the total amount of memory provisioned for the baseline while each always-ready instance is idle. For the total amount of memory provisioned for the execution time, each always-ready instance is executing functions, as well as for the total number of executions. Use always-ready instances when you need better latency or more predictable processing and are willing to pay for pre-warmed capacity. For cost-sensitive or low-traffic scenarios, keep the default of `0`. ## Resource group resources The Bicep template creates the following resources to process telemetry data: | Resource name | Type | Description | |-----------------------|-------------------------------------------|-----------------------------------------------------------------------------------------------------------| | `eventHubNamespace` | `Microsoft.EventHub/namespaces` | Event Hubs namespace to host the event hubs to stream logs and metrics. | | `logsEventHub` | `Microsoft.EventHub/namespaces/eventhubs` | Event hub for the logs. | | `metricsEventHub` | `Microsoft.EventHub/namespaces/eventhubs` | Event hub for the metrics. | | `storageAccount` | `Microsoft.Storage/storageAccounts` | Storage Account container to store the Event Hubs trigger checkpoint information and the failed messages. | | `hostingPlan` | `Microsoft.Web/serverfarms` | Hosting plan that runs the function app. | | `functionApp` | `Microsoft.Web/sites` | The function app that runs the ECF for Azure. | | `applicationInsights` | `Microsoft.Insights/components` | Application Insights instance to monitor the application. | Note the following: - The `eventHubNamespace` hosts the two event hubs responsible for receiving logs and metrics from Azure services. - The `storageAccount` stores the checkpoint information for the Event Hub triggers, and it also hosts the failed logs and metrics in the `logs-error-container` and `metrics-error-container` containers. - The `functionApp` is the core component responsible for running the OTel collector inside the Azure Function.