How to Create a Serverless Function with Azure Functions (Step-by-Step)

Last updated January 17, 2026 ~26 min read 20 views
serverless azure azure functions function app http trigger timer trigger event-driven identity managed identity app settings deployment azure cli powershell bicep terraform application insights monitoring security networking devops
How to Create a Serverless Function with Azure Functions (Step-by-Step)

Azure Functions is Microsoft’s serverless compute service for running event-driven code without managing servers. For IT administrators and system engineers, the value is practical: you can attach automation to operational events (HTTP webhooks, schedules, storage events, queues, and more), deploy quickly, and scale without building a dedicated app tier.

This how-to focuses on creating a “serverless function” that is not just a Hello World demo, but something you can run in a production Azure estate: you will choose a hosting model, create a Function App, develop locally, deploy, secure it with least privilege and managed identity, connect to downstream services safely, and instrument it for monitoring and cost control. Along the way, you’ll see multiple real-world scenarios (scheduled maintenance automation, webhook ingestion, and event-driven file processing) to anchor decisions in operational reality.

The guide assumes you have access to an Azure subscription and basic familiarity with Azure Resource Manager concepts (resource groups, regions) and command-line tooling. Examples use Azure CLI and Functions Core Tools; where configuration is sensitive, the approach favors managed identity and Key Vault over embedding secrets.

Understand what you’re building: Function, Function App, triggers, and bindings

In Azure Functions terminology, a function is a unit of code that runs in response to an event. That event is provided by a trigger (for example, an HTTP request, a timer schedule, or a message arriving on a queue). A Function App is the Azure resource that hosts one or more functions and provides the runtime, configuration, scaling, and integration points.

Functions also support bindings, which are declarative connectors that let you read from or write to services (Storage, Service Bus, Cosmos DB, etc.) without writing boilerplate connection code. Triggers are a kind of binding that initiates execution; output bindings are a convenient way to emit results.

A production mindset starts here: most operational failures in serverless aren’t “code bugs” as much as misaligned trigger choice, incorrect hosting plan, weak configuration hygiene, or missing observability. As you design the first function, keep in mind how it will be deployed, configured, secured, and monitored.

Choose a hosting plan and runtime settings that fit operations

Before writing code, choose the hosting model because it affects scaling behavior, cold starts, networking options, and cost predictability.

Azure Functions supports multiple hosting plans. The two most commonly used are Consumption (including Flex Consumption in newer offerings) and Premium. There is also Dedicated/App Service plan (Functions running on an App Service plan), which can be appropriate if you already have reserved capacity.

Consumption plans are pay-per-execution and scale automatically, which is great for spiky workloads and cost control. The trade-off is cold start behavior and some networking limitations depending on the specific SKU and region features.

Premium plans provide pre-warmed instances, more predictable performance, and advanced networking features. They cost more, but they’re often the right answer for line-of-business automation where latency and VNet integration matter.

Another early decision is the runtime stack (for example, .NET, Node.js, Python, Java, PowerShell) and the execution model. For .NET, you will often see two approaches: in-process and isolated worker. The isolated worker model separates your function from the host process and gives more control over dependencies; it is frequently favored for newer development because it reduces host coupling. Your organization’s standardization and support model should influence the choice.

Finally, consider the runtime version and operating system (Linux vs Windows) for the Function App. Linux hosting is common for container-friendly, cross-platform deployments; Windows hosting may be used for certain legacy dependencies. In most greenfield cases, Linux plus a modern runtime version is a solid default.

These choices will show up later when you configure identity, networking, and deployment. It’s worth aligning them with your broader platform standards early.

Plan the operational footprint: resource group, region, storage, and logging

A Function App is not a standalone resource. It typically depends on:

  1. A Storage account used by the Functions runtime for host state and triggers (for example, tracking timer schedules and managing scale). This storage account is not optional for most plans and triggers.
  2. A log/telemetry destination, commonly Application Insights (part of Azure Monitor). This is essential for production operations: you want execution traces, failures, dependencies, and end-to-end correlation.
  3. Optional integrations such as Key Vault, Service Bus, Event Grid, SQL, or external APIs.

From an administrator’s perspective, build these into a repeatable pattern. Decide naming conventions, tagging, RBAC boundaries, and whether the Function App must be reachable only privately (VNet integration, private endpoints) or can be public with strong authentication.

To make the rest of this guide concrete, the examples will create:

  • One resource group
  • One Storage account
  • One Function App
  • One Application Insights instance (workspace-based Application Insights is the modern default)

If your organization mandates infrastructure as code (IaC), you can still follow the CLI walkthrough to understand the mechanics, and then translate to Bicep or Terraform. Later, an IaC example is included.

Set up your workstation: Azure CLI and Functions Core Tools

For local development and testing, you typically need:

  • Azure CLI (az) to create resources and deploy.
  • Azure Functions Core Tools (func) to run the Functions host locally.
  • A runtime SDK depending on your language (for .NET, the .NET SDK).

Install Azure CLI following Microsoft documentation for your OS. After installation, sign in:

az login
az account set --subscription "<SUBSCRIPTION_ID_OR_NAME>"

Install Functions Core Tools (example shown for macOS with Homebrew; use the appropriate package manager for your platform):

bash
brew tap azure/functions
brew install azure-functions-core-tools@4

Verify:

bash
az --version
func --version

Core Tools version 4 aligns with current supported Azure Functions runtimes. Keeping this consistent across engineer workstations and build agents reduces “works on my machine” drift.

Create the Azure resources with Azure CLI

This section creates an initial, functional baseline using Azure CLI. You can later re-create the same layout with IaC for repeatability.

Set variables (Bash syntax shown):

bash
LOCATION="eastus"
RG="rg-func-demo-01"
STORAGE="stfuncdemo$RANDOM" 

# must be globally unique, lowercase

APP="func-demo-$RANDOM"     

# Function App name must be globally unique

AI="ai-func-demo-01"
WORKSPACE="log-func-demo-01"

Create the resource group:

bash
az group create -n "$RG" -l "$LOCATION"

Create a Storage account. The Functions runtime requires general-purpose v2 storage:

bash
az storage account create \
  -g "$RG" -n "$STORAGE" -l "$LOCATION" \
  --sku Standard_LRS \
  --kind StorageV2 \
  --allow-blob-public-access false \
  --min-tls-version TLS1_2

Create a Log Analytics workspace and Application Insights (workspace-based). Workspace-based Application Insights sends telemetry into Log Analytics, enabling Kusto queries and centralized retention control:

bash
az monitor log-analytics workspace create \
  -g "$RG" -n "$WORKSPACE" -l "$LOCATION"

WORKSPACE_ID=$(az monitor log-analytics workspace show -g "$RG" -n "$WORKSPACE" --query id -o tsv)

az monitor app-insights component create \
  -g "$RG" -l "$LOCATION" -a "$AI" \
  --workspace "$WORKSPACE_ID" \
  --application-type web

Now create the Function App. The exact parameters vary by OS, runtime, and plan. The following creates a Consumption plan Function App on Linux with a modern runtime (example: Node.js). If you prefer .NET isolated, the creation differs mostly in how you initialize code and deploy.

bash
az functionapp create \
  -g "$RG" -n "$APP" \
  --storage-account "$STORAGE" \
  --consumption-plan-location "$LOCATION" \
  --os-type Linux \
  --runtime node \
  --runtime-version 20 \
  --functions-version 4

Link Application Insights to the Function App by setting app settings. Retrieve the connection string from Application Insights:

bash
AI_CONN=$(az monitor app-insights component show -g "$RG" -a "$AI" --query connectionString -o tsv)

az functionapp config appsettings set \
  -g "$RG" -n "$APP" \
  --settings "APPLICATIONINSIGHTS_CONNECTION_STRING=$AI_CONN"

At this point you have a hosting container, storage, and telemetry. Next you’ll create a function project locally and deploy it.

Create a local Azure Functions project (Node.js HTTP trigger)

A minimal but useful starting point for many operational workflows is an HTTP-triggered function that receives a request, validates it, and performs an action (or enqueues work for later). HTTP triggers are also the easiest to test.

Create a new project directory:

bash
mkdir func-http-demo
cd func-http-demo

Initialize a Functions project:

bash
func init --worker-runtime node --language javascript

Create an HTTP-triggered function:

bash
func new --template "HTTP trigger" --name WebhookHandler

Start the function locally:

bash
func start

You should see output indicating the local host and a URL such as:

  • http://localhost:7071/api/WebhookHandler

Test it with curl:

bash
curl -i "http://localhost:7071/api/WebhookHandler?name=Ops"

This local loop is important even for admins who primarily deploy infrastructure. It’s how you validate trigger behavior, request/response handling, and logging before the Azure deployment step adds variables like networking and identity.

Add structured logging and input validation early

A common anti-pattern is leaving the default template code unchanged, then trying to retrofit validation and logging later. For operational reliability, add explicit validation from the first iteration.

Open WebhookHandler/index.js and adjust it to validate JSON input and log consistently:

javascript
module.exports = async function (context, req) {
  context.log('WebhookHandler invoked', {
    method: req.method,
    hasBody: !!req.body,
  });

  const name = (req.query && req.query.name) || (req.body && req.body.name);
  if (!name) {
    context.log.warn('Missing required parameter: name');
    context.res = {
      status: 400,
      headers: { 'Content-Type': 'application/json' },
      body: { error: 'Missing required parameter: name' }
    };
    return;
  }

  context.res = {
    status: 200,
    headers: { 'Content-Type': 'application/json' },
    body: { message: `Hello, ${name}.` }
  };
};

Even in this simple example, notice that logging includes context about the request and uses warn for validation failures. These logs will show up in Application Insights once deployed, making it easier to distinguish “client sent bad data” from “function is broken.”

Deploy the function code to Azure

For many teams, a CI/CD pipeline deploys Functions. Still, it’s helpful to understand how deployment works end-to-end from a workstation because it clarifies which settings live where and how the host loads your code.

For a quick deployment from your local folder, use the Azure Functions Core Tools publish command:

bash
func azure functionapp publish "$APP"

This packages your function project and deploys it to the Function App. After deployment completes, list functions:

bash
az functionapp function list -g "$RG" -n "$APP" -o table

Retrieve the default hostname:

bash
HOST=$(az functionapp show -g "$RG" -n "$APP" --query defaultHostName -o tsv)
echo "$HOST"

Call the function. By default, HTTP-triggered functions can require an access key depending on the authorization level configured in function.json. The template often uses function auth level, which requires a function key.

List function keys and invoke securely:

bash
KEY=$(az functionapp function keys list \
  -g "$RG" -n "$APP" \
  --function-name WebhookHandler \
  --query default -o tsv)

curl -i "https://$HOST/api/WebhookHandler?name=Ops&code=$KEY"

In production, you typically avoid passing keys on URLs for user-facing access. Instead, you front the function with API Management, use Azure AD authentication, or use a signed mechanism (depending on the client). You’ll address authentication patterns after you’ve established basic deployment.

Real-world scenario 1: Scheduled maintenance automation with a Timer trigger

HTTP triggers are interactive, but operations often requires time-based automation: rotate logs, check certificate expirations, validate backups, or reconcile inventory. Timer triggers are a good fit because they are simple, reliable, and do not require external schedulers.

Add a timer function to the same app so you can operate multiple functions under one Function App (a common pattern when functions share configuration and lifecycle).

Create a timer-trigger function:

bash
func new --template "Timer trigger" --name NightlyInventory

Open NightlyInventory/function.json and set a CRON schedule. Azure Functions uses NCRONTAB format. For example, to run daily at 01:30 UTC:

json
{
  "bindings": [
    {
      "name": "myTimer",
      "type": "timerTrigger",
      "direction": "in",
      "schedule": "0 30 1 * * *"
    }
  ]
}

Then implement the logic in NightlyInventory/index.js. For a practical operations example, imagine you need to query a REST endpoint (internal CMDB or inventory API) and write results to a storage blob or a log stream. In a first iteration, focus on idempotent behavior (safe to run multiple times) and observable output.

javascript
module.exports = async function (context, myTimer) {
  const utcTimestamp = new Date().toISOString();

  if (myTimer.isPastDue) {
    context.log.warn('NightlyInventory timer is running late', { utcTimestamp });
  }

  context.log('NightlyInventory started', { utcTimestamp });

  // Placeholder for real work: query inventory, reconcile, emit metrics.
  // Keep the first version deterministic and heavily logged.

  context.log('NightlyInventory completed', { utcTimestamp });
};

Redeploy:

bash
func azure functionapp publish "$APP"

Operationally, timer triggers raise two questions you should answer early:

First, where does “time” live? The schedule is interpreted in UTC. If your operations are time-zone-specific (for example, local business hours), encode the conversion explicitly or standardize on UTC and document it.

Second, what happens during outages? The runtime tracks timer state using the storage account. If the app is down, Functions can mark the timer as past due and run when it resumes. That behavior is useful, but it means your job must be safe to run after a delay. For example, if the job performs patch orchestration, you might need additional safeguards (state checks, feature flags, or “do not run after X hours” logic).

This timer scenario also sets up a later discussion on managed identity: scheduled functions often need privileged access (for example, to query Azure resources or update a database). Avoid storing credentials in app settings and use identity-based access.

Configuration management: app settings, connection strings, and deployment slots

Azure Functions uses application settings (also referred to as “app settings”) for configuration. They are stored as environment variables in the runtime environment. For many teams, this is the primary configuration mechanism because it integrates with ARM/Bicep/Terraform and supports slot settings.

A few practices matter in production:

Treat app settings as part of the deployment contract. If a function requires TARGET_API_URL, document it in code and ensure the deployment pipeline sets it.

Avoid storing secrets directly in app settings when possible. Prefer Key Vault references or managed identity with identity-based connections.

Use deployment slots where supported by the plan (typically Premium or Dedicated) to stage changes. Slots let you deploy to a non-production slot, warm it up, validate, then swap. This reduces risk for HTTP-triggered workloads.

To set an app setting:

bash
az functionapp config appsettings set \
  -g "$RG" -n "$APP" \
  --settings "TARGET_API_URL=https://example.internal/api"

Read the setting from code as an environment variable. In Node.js:

javascript
const targetUrl = process.env.TARGET_API_URL;

This becomes more important when you introduce identity and downstream dependencies.

Identity and access: use managed identity and least privilege

A Function App can have a managed identity, which is an Azure AD identity managed by Azure. There are two types: system-assigned and user-assigned. System-assigned is tied to the lifecycle of the Function App; user-assigned is a standalone resource that can be attached to multiple apps.

For many operational functions, system-assigned identity is a good default because it avoids extra resources. Enable it:

bash
az functionapp identity assign -g "$RG" -n "$APP"

PRINCIPAL_ID=$(az functionapp identity show -g "$RG" -n "$APP" --query principalId -o tsv)
echo "$PRINCIPAL_ID"

Now you can grant the function access to Azure resources using RBAC. For example, if the timer function needs to list VMs or read resource tags, assign the minimal role at the correct scope.

Example: grant Reader access to the resource group (adjust scope as needed):

bash
RG_ID=$(az group show -n "$RG" --query id -o tsv)

az role assignment create \
  --assignee-object-id "$PRINCIPAL_ID" \
  --assignee-principal-type ServicePrincipal \
  --role Reader \
  --scope "$RG_ID"

In real operations, you should narrow the scope further whenever feasible (subscription sub-scope, specific resource, or a custom role). The important shift is conceptual: instead of storing an Azure service principal secret, you let Azure issue tokens to the Function App identity at runtime.

Using managed identity from code (example: Azure SDK default credentials)

If you later add Azure SDK calls (for example, to query resources, write to Storage, or send to Service Bus with Entra ID), standardize on default credentials. In many SDKs, DefaultAzureCredential automatically uses managed identity when running in Azure.

Even if you don’t add SDK usage in the first iteration, designing around managed identity now prevents a costly redesign when security reviews happen.

Secure an HTTP-triggered function for real clients

By default, an HTTP trigger with authLevel set to function uses function keys. Keys can work for internal automation but are often insufficient for enterprise authentication requirements because they are shared secrets, difficult to rotate safely without coordination, and typically passed by clients.

In practice, you usually choose one of these models:

If the function is internal-only, you can keep key-based authorization but restrict network access (private endpoint, or IP restrictions) so only internal systems can reach it.

If the function is accessed by users or multiple systems, consider putting it behind API Management or using built-in authentication via App Service Authentication/Authorization (often called “Easy Auth”) with Microsoft Entra ID. The function then receives validated tokens and user claims.

If the function is a webhook endpoint from a third-party SaaS, you may need a shared secret signature validation (for example, HMAC signature in headers). In that case, store the secret in Key Vault and validate the signature in code. This is common for ITSM tools, alerting platforms, and CI systems.

Because authentication architecture can become its own project, the key operational advice is: don’t leave a production HTTP endpoint with anonymous access unless you have a deliberate reason and compensating controls.

Real-world scenario 2: Webhook ingestion that queues work (decouple with Storage Queue)

A common systems-engineering pattern is: accept inbound webhooks quickly, validate them, and then queue work so downstream processing is reliable and independent of HTTP response latency. This pattern avoids timeouts and makes retries easier.

One lightweight option is an Azure Storage Queue. You can implement this with code (using an SDK) or with bindings. Here, use bindings to keep it clear.

Add a new function that accepts HTTP, validates payload, and writes a message to a queue via output binding.

Create a new function:

bash
func new --template "HTTP trigger" --name WebhookToQueue

Edit WebhookToQueue/function.json to add an output binding to a Storage Queue. The queue name is ops-events, and the connection setting is AzureWebJobsStorage (the default storage connection used by the host).

json
{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["post"],
      "route": "webhook/toqueue"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "res"
    },
    {
      "type": "queue",
      "direction": "out",
      "name": "outputQueueItem",
      "queueName": "ops-events",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Then implement the handler in WebhookToQueue/index.js:

javascript
module.exports = async function (context, req) {
  // Basic schema guard: require an eventType and correlationId.
  const body = req.body;
  if (!body || typeof body !== 'object') {
    context.res = { status: 400, body: { error: 'Expected JSON body' } };
    return;
  }

  const { eventType, correlationId } = body;
  if (!eventType || !correlationId) {
    context.res = {
      status: 400,
      body: { error: 'Missing eventType or correlationId' }
    };
    return;
  }

  // Output binding: assign a string or object (runtime will serialize).
  context.bindings.outputQueueItem = JSON.stringify({
    eventType,
    correlationId,
    receivedAt: new Date().toISOString(),
    payload: body
  });

  context.log('Enqueued ops event', { eventType, correlationId });

  context.res = {
    status: 202,
    body: { status: 'accepted', correlationId }
  };
};

Now add a queue-triggered function to process messages asynchronously:

bash
func new --template "Queue trigger" --name ProcessOpsEvent

Implement minimal processing in ProcessOpsEvent/index.js:

javascript
module.exports = async function (context, myQueueItem) {
  let msg;
  try {
    msg = typeof myQueueItem === 'string' ? JSON.parse(myQueueItem) : myQueueItem;
  } catch (e) {
    context.log.error('Invalid queue message JSON', e);
    return;
  }

  context.log('Processing ops event', {
    eventType: msg.eventType,
    correlationId: msg.correlationId
  });

  // Placeholder for real actions: open a ticket, call an automation API, update CMDB.
  // Ensure actions are idempotent using correlationId.

  context.log('Processed ops event', { correlationId: msg.correlationId });
};

This scenario reflects a realistic workflow: a monitoring system posts alerts to your function, your function validates and quickly acknowledges, then a background worker processes the event. In operations, the decoupling is often more valuable than raw performance because it improves reliability and allows you to add retries and poison-message handling.

Redeploy the app again:

bash
func azure functionapp publish "$APP"

Then invoke the webhook-to-queue endpoint (with function key):

bash
KEY=$(az functionapp function keys list -g "$RG" -n "$APP" --function-name WebhookToQueue --query default -o tsv)

curl -i -X POST "https://$HOST/api/webhook/toqueue?code=$KEY" \
  -H "Content-Type: application/json" \
  -d '{"eventType":"alert","correlationId":"abc-123","severity":"high"}'

As messages arrive, the queue trigger fires and you should see logs in Application Insights. This is a strong baseline architecture for serverless automation because it avoids coupling external systems to your processing time.

Observability: Application Insights, log correlation, and metrics

Once you have multiple functions and triggers, operational visibility becomes the difference between a maintainable automation platform and an opaque black box.

Application Insights captures request telemetry (for HTTP triggers), traces (context.log output), and dependency calls (some dependencies are tracked automatically depending on runtime). For event-driven triggers like queues and timers, you still get traces and failures but not “HTTP request” telemetry. That’s normal; you should rely on custom logs and, where appropriate, custom metrics.

Two practical techniques improve operational clarity:

First, use a correlation identifier. In the queue scenario you already included a correlationId. Ensure you log it consistently at each stage so you can search logs and reconstruct event flow.

Second, log structured data rather than only strings. In Node.js, passing objects to context.log allows richer fields that are easier to query later.

To query logs in the Log Analytics workspace, you can use Kusto Query Language (KQL). For example, to find traces for a specific correlationId:

kusto
traces
| where message has "correlationId" or tostring(customDimensions) has "correlationId"
| where tostring(customDimensions.correlationId) == "abc-123"
| order by timestamp desc

You can also look at failures:

kusto
exceptions
| order by timestamp desc
| take 50

Administrators should also configure alerting: failed executions above a threshold, unusually high duration, or spikes in queue length. The exact alert rules depend on triggers and workload, but the key is to treat a Function App like any other production service: you need error budgets, paging signals, and dashboards.

Deployment approaches: zip deploy, run-from-package, and CI/CD

The func azure functionapp publish workflow is convenient, but most organizations shift to CI/CD for consistency and separation of duties.

Under the hood, Azure Functions supports common deployment approaches:

Zip deploy packages your app into a zip file and deploys it to the Function App.

Run-from-package runs your app directly from a deployed package, improving consistency because the app content is immutable. Many pipelines use this model.

Container-based deployment runs Functions in a custom container image (more common on Kubernetes or containerized App Service). This is useful if you need OS-level dependencies.

For many IT automation functions, zip deploy or run-from-package is enough. The operational advice is to standardize on one method per platform team and document how configuration is handled separately from code.

If you want a simple zip deploy example with Azure CLI, you can build a zip and deploy it:

bash
zip -r app.zip .

az functionapp deployment source config-zip \
  -g "$RG" -n "$APP" \
  --src app.zip

In CI/CD, you’d generate the zip as an artifact and deploy from an agent. Keep environment-specific settings in app settings (or slot settings), not in the package.

Infrastructure as code example (Bicep): repeatable provisioning

If your goal is to publish a function once, CLI provisioning is fine. If your goal is to operate multiple Function Apps across environments, IaC is the operationally correct approach.

The following Bicep sketch shows the core resources: storage, Function App, and Application Insights workspace-based setup. Treat it as a starting point; production templates usually include tags, diagnostic settings, private endpoints (if needed), and role assignments.

bicep
param location string = resourceGroup().location
param functionAppName string
param storageAccountName string
param workspaceName string
param appInsightsName string

resource storage 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    allowBlobPublicAccess: false
    minimumTlsVersion: 'TLS1_2'
  }
}

resource workspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: workspaceName
  location: location
  properties: {
    retentionInDays: 30
    sku: { name: 'PerGB2018' }
  }
}

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: workspace.id
  }
}

resource plan 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: '${functionAppName}-plan'
  location: location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
  }
}

resource functionApp 'Microsoft.Web/sites@2022-09-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: plan.id
    siteConfig: {
      linuxFxVersion: 'Node|20'
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storage.name};AccountKey=${listKeys(storage.id, storage.apiVersion).keys[0].value};EndpointSuffix=${environment().suffixes.storage}'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
      ]
    }
    httpsOnly: true
  }
}

This Bicep uses a storage account key for AzureWebJobsStorage. That is common and required for host storage in many cases, but as you design more secure systems you should separate “host storage” from “application data storage,” and you should minimize where keys appear. For application data access, prefer identity-based access where supported (for example, Entra ID with Storage, Service Bus, and other services).

Also note the httpsOnly: true setting, which is a baseline hardening move for HTTP triggers.

Networking considerations: public endpoints, access restrictions, and private connectivity

Functions can be used for both public webhooks and internal automation endpoints. The networking posture should match the use case.

If you are receiving third-party webhooks (for example, an external SaaS), you may need a public endpoint. In that case, consider at least IP restrictions if the provider publishes stable source IP ranges, and always enforce strong authentication/signature validation.

If the function is internal-only, you can reduce exposure by limiting inbound access. Azure App Service (which hosts Functions) supports access restrictions. You can also integrate with a VNet for outbound traffic to reach private resources.

For environments with strict network controls, you might combine:

  • Inbound: private endpoint (so the function is reachable only inside your network)
  • Outbound: VNet integration (so the function reaches private backends)

The exact steps depend on plan/SKU and enterprise architecture. The operational takeaway is that serverless does not mean “no networking design.” You still need to decide where the endpoint lives and how traffic reaches dependencies.

Real-world scenario 3: Event-driven file processing with Blob triggers (pattern and caveats)

A frequent systems engineering requirement is to react to files arriving in storage: ingest logs, process exports from SaaS systems, or validate configuration snapshots. Azure Functions supports a Blob trigger for this.

The high-level pattern is:

  • A system writes a file into a blob container.
  • A function triggers, reads the file, and processes it.
  • The function writes output (transformed file, extracted metadata, status record) to another location.

This is operationally attractive because it avoids running a poller VM or scheduled job. However, file-triggered automation must be designed carefully for retries and idempotency because blob events can be delivered more than once, and processing may fail mid-stream.

Create a blob-trigger function:

bash
func new --template "Blob trigger" --name ProcessIncomingBlob

In ProcessIncomingBlob/function.json, you will see a path like samples-workitems/{name} in templates. Change it to an incoming container.

json
{
  "bindings": [
    {
      "name": "myBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "incoming/{name}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Implement processing in ProcessIncomingBlob/index.js. A realistic first step is to log metadata, validate size, and emit a marker for downstream systems.

javascript
module.exports = async function (context, myBlob) {
  const blobName = context.bindingData.name;
  const size = myBlob ? myBlob.length : 0;

  context.log('Blob received', { blobName, size });

  if (size === 0) {
    context.log.warn('Blob is empty', { blobName });
    return;
  }

  // For real parsing, ensure you handle encoding and size limits.
  // Large blobs should be processed via streaming in supported runtimes.

  // Example: treat content as text, count lines.
  const text = myBlob.toString('utf8');
  const lineCount = text.split(/\r?\n/).length;

  context.log('Blob processed', { blobName, lineCount });
};

Deploy again:

bash
func azure functionapp publish "$APP"

Now, upload a test file to the storage account used by the Function App. You can do this with Azure CLI. First, get a storage connection key and create the incoming container:

bash
STG_KEY=$(az storage account keys list -g "$RG" -n "$STORAGE" --query '[0].value' -o tsv)

az storage container create \
  --account-name "$STORAGE" \
  --account-key "$STG_KEY" \
  --name incoming

echo "one\ntwo\nthree" > sample.txt

az storage blob upload \
  --account-name "$STORAGE" \
  --account-key "$STG_KEY" \
  --container-name incoming \
  --file sample.txt \
  --name sample.txt

Within moments, the blob-trigger function should fire.

From an operations standpoint, this scenario introduces important design constraints. File processing must be idempotent: if the same blob triggers twice, you should avoid double-writing outputs or duplicating tickets. A simple approach is to write a status record keyed by blob name and ETag, or to move processed blobs to a different container, but moving blobs has its own race conditions if multiple workers attempt it.

It also introduces throughput planning: blob triggers can scale out under load, which is great, but you must ensure downstream dependencies can handle parallel processing. This is where queue-based buffering can be combined with blob events: on blob arrival, enqueue a message and let queue workers handle controlled concurrency.

Performance and scaling: timeouts, concurrency, and cold starts

After you have functions in place, the next operational question is performance under load.

On Consumption plans, instances scale based on trigger demand. This is convenient but can create variability in latency, especially for HTTP triggers, due to cold starts. Cold starts occur when the platform needs to start a new host instance, load your code, and initialize dependencies.

Premium plans mitigate cold starts with pre-warmed instances. Dedicated plans can also provide more consistent performance when capacity is reserved.

Within a given instance, concurrency depends on language runtime and trigger type. Queue triggers, for example, can process multiple messages in parallel depending on host configuration. HTTP triggers handle requests concurrently as well. For operational safety, start with conservative assumptions and use Application Insights to measure actual execution time and failure rates.

Avoid writing functions that do heavy CPU-bound processing or long-running workflows as a single execution. Instead, break work into smaller units, or use orchestration services (for example, Durable Functions) when you need stateful coordination. While orchestration is a broader topic, the guiding principle is simple: keep a single function execution bounded in time and resources to reduce retries, cost surprises, and error blast radius.

Secret handling: Key Vault references and environment isolation

Many functions need to call external APIs, database endpoints, or ITSM systems. Secrets are unavoidable, but secret storage is a choice.

For App Service-based workloads (including Functions), you can use Key Vault references in app settings so the Function App reads secrets at runtime without storing them in plaintext configuration. This typically pairs with managed identity to access Key Vault.

The typical flow is:

  • Create a Key Vault.
  • Grant the Function App’s managed identity access to read secrets.
  • Add an app setting whose value is a Key Vault reference.

The exact Key Vault reference syntax and required permissions should be validated against your organization’s Key Vault policies and Azure’s current documentation, but the operational objective is consistent: ensure the function can retrieve secrets without developers copying secrets into repo files or pipeline variables.

Even with Key Vault, isolate environments. Do not point dev/test/prod functions at the same Key Vault secrets. Environment-specific secrets reduce blast radius and make auditing cleaner.

Release engineering: versioning, slots, and safe rollouts

A Function App can contain multiple functions. That’s convenient, but it also means a deployment updates all functions in the app together. In operations, you should treat a Function App as a deployment unit.

If you have unrelated functions with different change cadences, you may prefer separate Function Apps. This reduces risk because a change to one function doesn’t redeploy others.

Where plan supports it, deployment slots are an effective risk reduction tool for HTTP endpoints and for functions with significant initialization time. You deploy to a staging slot, run smoke tests against the staging hostname, and then swap.

Even without slots, you can reduce risk through:

  • Feature flags (app settings that enable/disable behavior)
  • Gradual exposure (front with API Management and route a percentage)
  • Backward-compatible changes to payload schemas

In the webhook-to-queue scenario, schema evolution is particularly important. If clients send a new field, your function should ignore unknown fields. If you change required fields, consider versioning the route or supporting multiple schemas during transition.

Governance and operational hygiene: tags, locks, RBAC boundaries, and policy

Once a function proves useful, it tends to multiply. Governance prevents serverless sprawl from becoming an inventory and security problem.

Tags are simple but effective: owner, cost center, environment, data classification, and on-call team. Standard tags help in cost allocation and incident response.

Resource locks can prevent accidental deletion, especially for shared storage accounts and Function Apps. Apply locks carefully: they can interfere with automated changes if misused.

RBAC should be scoped appropriately. Engineers deploying code do not necessarily need the ability to delete resource groups. Many organizations separate roles into “deploy code” vs “manage infrastructure” vs “read-only operations.”

Azure Policy can enforce baseline controls such as HTTPS only, minimum TLS versions, and restrictions on public access. If your platform team maintains policy, align Function Apps with policy requirements early so you don’t discover non-compliance during an incident.

Putting it together: a cohesive build-and-operate workflow

At this point, you have a Function App hosting multiple functions:

  • WebhookHandler: an HTTP endpoint suitable for internal calls and simple integrations.
  • NightlyInventory: a timer-based automation placeholder.
  • WebhookToQueue and ProcessOpsEvent: a decoupled ingestion and processing pipeline.
  • ProcessIncomingBlob: a file-driven processor.

This combination mirrors what many IT and platform teams actually run: a small serverless automation platform that reacts to schedules, webhooks, and storage events.

The operational workflow that keeps it maintainable is consistent across these triggers:

You develop locally with Core Tools, using realistic sample payloads and structured logs.

You deploy in a repeatable way (preferably CI/CD) and keep environment configuration in app settings, with secrets in Key Vault.

You secure access via managed identity for outbound calls and a deliberate authentication model for inbound HTTP.

You monitor execution health with Application Insights, using correlation identifiers and alerting on failures and backlog signals.

You govern the footprint with IaC, tags, RBAC, and policy.

If you adopt these practices from the first function, Azure Functions becomes an operational asset rather than a collection of ad-hoc scripts. That’s the difference between “serverless as a demo” and “serverless as a maintainable part of your platform.”