Azure FunctionsAuthorCloudBrum editorial teamLast reviewed22 Oct 2026Reading time~12 minLevelBeginner to advanced

• Triggers and bindingsA trigger starts the function and bindings read or write data, so a queue-to-database job needs little glue code.
• Several hosting plansFlex Consumption, Premium and Dedicated plans, plus the older Consumption plan, trade price against start-up speed, networking and limits.
• Many languagesWrite in C#, JavaScript, TypeScript, Python, Java or PowerShell, or bring your own runtime with a custom handler.
• Scale to zero and outApps scale out as events arrive and, on serverless plans, back to zero when there is nothing to do.
• Always ready instancesOn Flex Consumption and Premium you can keep warm instances ready to cut the start-up delay.
• Durable FunctionsWrite long-running, stateful workflows in code, with fan-out, waiting for people or events, and automatic checkpoints.
• Identity-first securityManaged identities, Microsoft Entra sign-in, Key Vault references and private networking keep keys out of your code.
• Built-in monitoringApplication Insights collects logs, traces, failures and live metrics for each function.

Function app

The deployable unit. It holds one or more functions that share a hosting plan, settings, identity and scaling.

Function

One piece of code with exactly one trigger. A function app can contain many of them.

Trigger

What starts a function: an HTTP request, a timer, a queue message, a blob upload, an event and so on.

Binding

A declared connection to data. An input binding reads data for the function, and an output binding writes the result somewhere.

Hosting plan

The compute model for the app: Flex Consumption, Premium, Dedicated (App Service) or the older Consumption plan.

Flex Consumption

The newer serverless plan with per-function scaling, selectable instance memory, virtual network support and optional always ready instances.

Always ready instance

An instance kept running so that the first request does not wait for a new one to start. It is billed for as long as it is kept ready.

Isolated worker model

For .NET, your code runs in its own process, separate from the Functions host. It is the model that continues to be supported and updated.

Host storage account

A storage account the Functions host uses for internal state, such as trigger coordination and, on some plans, the deployment package.

Managed identity

An identity for the function app in Microsoft Entra ID, used to reach other Azure services without stored secrets.

Authorization level

For HTTP triggers: anonymous, function or admin. Non-anonymous levels require an access key.

Extension bundle

A versioned set of binding extensions that the host loads, so non-.NET apps get triggers and bindings without extra installs.

Set up a function app in the Azure portal

1. Start a new Function AppIn the Azure portal search for Function App and choose Create. Pick the subscription and a resource group.
2. Choose a hosting optionFor a new serverless app, start with Flex Consumption. Choose Premium if you need constant warm capacity with full networking, or a Dedicated plan if you already run an App Service plan.
3. Name it and pick the runtimeThe name must be unique across Azure, because it becomes the web address. Choose the region, the language stack and the version.
4. Choose instance size and scale limitsOn Flex Consumption set the instance memory and the maximum number of instances. A cap protects downstream systems from a flood of parallel runs.
5. Set up storageCreate or choose a storage account for the host. Keep it private and use identity-based access where you can.
6. Decide on networkingLeave public access on for a first test, or use virtual network integration and private endpoints for production.
7. Turn on monitoringEnable Application Insights so failures and slow runs show up. Plan sampling to keep log volume, and cost, under control.
8. Give the app an identityEnable a system-assigned managed identity and grant it only the roles your code needs, such as a queue or table role on one storage account.
9. Write and deploy the codeDevelop locally with Azure Functions Core Tools or Visual Studio Code, then deploy from the command line, a pipeline or the editor.
10. Test, watch and tuneRun the function, open the Failures and Live metrics views in Application Insights, and adjust concurrency, batch size and always ready settings.

• Create clients once. Reuse HTTP, storage and database clients across executions instead of building them per call.
• Pick the plan for the latency you need. Flex Consumption with always ready instances, or Premium, avoids most cold-start waits.
• Right-size instance memory on Flex Consumption: too small slows runs, too big wastes money.
• Keep HTTP calls short. Answer quickly, queue slow work and let the client check back.
• Tune batch and concurrency settings for queue and event triggers so you process quickly without flooding a database.
• Keep the package lean and use the current runtime, language worker and extension bundle versions.
• Run in the same Region as the storage, database and other services the function calls.
• Use Durable Functions for fan-out and long workflows instead of holding one function open.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Azure Functions.

• Start with Flex Consumption for new serverless apps. You pay for executions and memory-time, and a free monthly grant applies per subscription.
• Choose instance memory carefully; it sets the cost of each second a function runs.
• Use always ready sparingly. Warm instances are billed even when idle, so keep them to latency-critical functions.
• Cap maximum instances to limit both cost and pressure on dependencies.
• Batch and filter. Fewer executions for the same work means a smaller bill.
• Control monitoring cost. Sampling, log levels, retention and daily caps often matter more than compute.
• Do not forget the storage account. It is outside the free grant and is billed for operations and capacity.
• Pick Premium only when it pays off, for steady load, long runs or full network features; otherwise a serverless plan is usually cheaper.
• Delete unused apps and slots, and tag apps by team and product with budgets and alerts.
• Compare plans with real numbers in the Azure pricing calculator before committing to one.

• Use managed identities and identity-based connections for storage, queues, databases and Key Vault instead of connection strings.
• Keep remaining secrets in Azure Key Vault and reference them from app settings.
• Protect HTTP triggers with Microsoft Entra sign-in (built-in authentication) or API Management. Function keys are for service callers, not end users.
• Prefer private endpoints and virtual network integration, and restrict inbound access to known networks.
• Require HTTPS only and a modern minimum TLS version.
• Validate all input, treat trigger data as untrusted and avoid building queries or commands from it.
• Give each app least-privilege roles and review them regularly.
• Keep runtimes and packages current, and move .NET apps to the isolated worker model.
• Turn on Microsoft Defender for Cloud recommendations and review alerts.
• Send logs to Application Insights and Azure Monitor, and alert on failures, throttling and unusual call volumes.

Policy names change over time, so search the built-in definitions for the current ones. For audits, use the Azure Activity log for who-changed-what, Microsoft Defender for Cloud for the regulatory compliance view and the Service Trust Portal for compliance reports. Microsoft’s attestations for Azure Functions cover the platform; your code, identities, data and app settings are yours to secure and to demonstrate.

• Rely on idle scale-down. On serverless plans an app with no work consumes no compute.
• Keep always ready instances to a minimum, since warm instances keep resources reserved.
• Shorten each run. A function that finishes sooner, on less memory, uses less energy.
• Batch and filter events so the app wakes up only when there is real work.
• Prefer cleaner Regions where latency and data residency leave you room.
• Trim logging. Less data collected and stored saves energy and money.
• Measure it. The carbon optimization feature in the Azure portal and Microsoft’s emissions reporting estimate your impact; check which tool is current for your tenant.

Purchase options

What you actually pay for

• Executions and memory-time (GB-seconds) on serverless plans, or vCPU and memory time on Premium
• Always ready instance baseline, if used
• The host storage account (capacity and operations)
• Application Insights and Log Analytics data ingestion
• Networking: private endpoints, NAT or virtual network gateways, and data transfer out

A small queue-triggered function that saves each order to Azure Table Storage with an upsert, so a repeated message does no harm. A bad message raises an error, is retried, and finally moves to the poison queue. The CLI and Terraform tabs create a Flex Consumption app; the Python and C# tabs hold the function. Replace the placeholder names with your own.

# Resource group and the storage account the function app uses
az group create --name rg-func-dev --location centralindia

az storage account create \
  --name stfuncorders001 \
  --resource-group rg-func-dev \
  --location centralindia \
  --sku Standard_LRS \
  --allow-blob-public-access false \
  --min-tls-version TLS1_2

# A Flex Consumption function app running Python
az functionapp create \
  --resource-group rg-func-dev \
  --name func-orders-demo-001 \
  --storage-account stfuncorders001 \
  --flexconsumption-location centralindia \
  --runtime python \
  --runtime-version 3.12 \
  --instance-memory 2048 \
  --maximum-instance-count 40

# Identity-based connections: no connection strings in the settings
az functionapp identity assign --resource-group rg-func-dev --name func-orders-demo-001
PRINCIPAL_ID=$(az functionapp identity show --resource-group rg-func-dev --name func-orders-demo-001 --query principalId --output tsv)
STORAGE_ID=$(az storage account show --name stfuncorders001 --resource-group rg-func-dev --query id --output tsv)

az role assignment create --assignee-object-id "$PRINCIPAL_ID" --assignee-principal-type ServicePrincipal \
  --role "Storage Queue Data Message Processor" --scope "$STORAGE_ID"
az role assignment create --assignee-object-id "$PRINCIPAL_ID" --assignee-principal-type ServicePrincipal \
  --role "Storage Table Data Contributor" --scope "$STORAGE_ID"

az functionapp config appsettings set --resource-group rg-func-dev --name func-orders-demo-001 --settings \
  "QueueConnection__queueServiceUri=https://stfuncorders001.queue.core.windows.net" \
  "TABLE_ENDPOINT=https://stfuncorders001.table.core.windows.net"

# Deploy the code from the folder that holds function_app.py (Azure Functions Core Tools)
func azure functionapp publish func-orders-demo-001

# Uses the AzureRM 4.x provider. Assumes azurerm_resource_group.demo is defined elsewhere.
# Key-based access to the deployment container is shown for brevity: prefer identity-based access where your provider version supports it.
resource "azurerm_storage_account" "func" {
  name                            = "stfuncorders001"
  resource_group_name             = azurerm_resource_group.demo.name
  location                        = azurerm_resource_group.demo.location
  account_tier                    = "Standard"
  account_replication_type        = "LRS"
  allow_nested_items_to_be_public = false
  min_tls_version                 = "TLS1_2"
}

resource "azurerm_storage_container" "package" {
  name                  = "app-package"
  storage_account_name  = azurerm_storage_account.func.name
  container_access_type = "private"
}

resource "azurerm_service_plan" "flex" {
  name                = "plan-func-orders"
  resource_group_name = azurerm_resource_group.demo.name
  location            = azurerm_resource_group.demo.location
  os_type             = "Linux"
  sku_name            = "FC1"
}

resource "azurerm_function_app_flex_consumption" "orders" {
  name                = "func-orders-demo-001"
  resource_group_name = azurerm_resource_group.demo.name
  location            = azurerm_resource_group.demo.location
  service_plan_id     = azurerm_service_plan.flex.id

  storage_container_type      = "blobContainer"
  storage_container_endpoint  = "${azurerm_storage_account.func.primary_blob_endpoint}${azurerm_storage_container.package.name}"
  storage_authentication_type = "StorageAccountConnectionString"
  storage_access_key          = azurerm_storage_account.func.primary_access_key

  runtime_name           = "python"
  runtime_version        = "3.12"
  instance_memory_in_mb  = 2048
  maximum_instance_count = 40

  identity {
    type = "SystemAssigned"
  }

  app_settings = {
    QueueConnection__queueServiceUri = azurerm_storage_account.func.primary_queue_endpoint
    TABLE_ENDPOINT                   = azurerm_storage_account.func.primary_table_endpoint
  }

  site_config {}

  tags = {
    Env   = "dev"
    Owner = "platform-team"
  }
}

# function_app.py (requirements.txt: azure-functions, azure-data-tables, azure-identity)
import json
import logging
import os

import azure.functions as func
from azure.data.tables import TableServiceClient, UpdateMode
from azure.identity import DefaultAzureCredential

app = func.FunctionApp()

# Created once per worker process and reused by later executions
service = TableServiceClient(endpoint=os.environ["TABLE_ENDPOINT"], credential=DefaultAzureCredential())
orders = service.get_table_client("orders")


@app.queue_trigger(arg_name="msg", queue_name="orders", connection="QueueConnection")
def process_order(msg: func.QueueMessage) -> None:
    # A bad message raises here, is retried, and finally lands in the "orders-poison" queue
    order = json.loads(msg.get_body().decode("utf-8"))
    entity = {"PartitionKey": "orders", "RowKey": str(order["order_id"]), "Total": order.get("total", 0)}
    orders.upsert_entity(entity, mode=UpdateMode.REPLACE)  # an upsert makes a repeated message harmless
    logging.info("saved order %s", order["order_id"])

// dotnet add package Microsoft.Azure.Functions.Worker
// dotnet add package Microsoft.Azure.Functions.Worker.Sdk
// dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues
// dotnet add package Azure.Data.Tables
// dotnet add package Azure.Identity
using System.Text.Json;
using Azure.Data.Tables;
using Azure.Identity;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices(services =>
    {
        // One client for the whole process
        services.AddSingleton(_ => new TableServiceClient(
            new Uri(Environment.GetEnvironmentVariable("TABLE_ENDPOINT")!), new DefaultAzureCredential()));
    })
    .Build();
host.Run();

public class ProcessOrder
{
    private readonly TableClient _orders;
    private readonly ILogger<ProcessOrder> _logger;

    public ProcessOrder(TableServiceClient service, ILogger<ProcessOrder> logger)
    {
        _orders = service.GetTableClient("orders");
        _logger = logger;
    }

    [Function("ProcessOrder")]
    public async Task Run([QueueTrigger("orders", Connection = "QueueConnection")] string message)
    {
        // A bad message throws here, is retried, and finally lands in the "orders-poison" queue
        using var doc = JsonDocument.Parse(message);
        var orderId = doc.RootElement.GetProperty("order_id").GetString()!;
        await _orders.UpsertEntityAsync(new TableEntity("orders", orderId) { ["Body"] = message }, TableUpdateMode.Replace);
        _logger.LogInformation("saved order {OrderId}", orderId);
    }
}

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

Not sure a function is the right size? Compare with Azure Virtual Machines for servers you control, Azure Container Apps for containers that scale on events, Azure App Service for web apps with steady traffic, and Azure Logic Apps for low-code integration workflows.