Build a Secure Azure Functions API with Flex Consumption, Node.js v4, Entra ID and Durable Functions

Building a modern serverless API on Azure today means throwing out outdated assumptions about fixed memory limits, plaintext application settings, and folder-per-function project structures. A recent 12-step technical walkthrough published by Shattered outlines how to stand up a prototype Order Status API in roughly 75 minutes using the current Azure Functions stack: the Flex Consumption hosting plan, the Node.js v4 programming model, Durable Functions orchestration, Microsoft Entra ID authentication, Key Vault secret references, Application Insights telemetry, and GitHub Actions automation.

While that blueprint covers the right architectural pillars, deploying it safely into a real-world enterprise environment requires reconciling several command-line flags, Node.js runtime versions, and security realities against Microsoft Learn's official documentation. Here is the complete, verified guide to building, securing, and deploying a modern Azure Functions API—along with the critical configuration corrections you need so your prototype does not turn into a production headache.

The 2026 Azure Functions Landscape: Why Old Guides Break​

Why are so many older Azure Functions scripts and deployment pipelines suddenly failing or throwing deprecation warnings? According to Microsoft Learn's runtime comparison and hosting documentation, three major infrastructure and runtime shifts have reshaped the platform:

• Runtime 4.x is the lone survivor: Azure Functions runtime version 4.x is now the only host version with full production support across all languages. Versions 2.x and 3.x are already out of support, and support for the ancient 1.x runtime officially ended on September 14, 2026. Even more urgently, function apps still running the end-of-life v3 runtime on the Linux Consumption plan stopped running entirely after September 30, 2026. (For.NET shops still clinging to the in-process model on v4, note that official support for in-process execution ends on November 10, 2026, making the isolated worker model mandatory for moving forward.)
• Flex Consumption is the new serverless default: Microsoft now steers new serverless workloads toward the Linux-based Flex Consumption plan rather than the classic Consumption plan. Flex Consumption retains pay-as-you-go scale-to-zero billing, but adds native virtual network (VNet) integration, configurable instance memory sizes (512 MB, 2,048 MB, and 4,096 MB), and optional "always-ready" instances to mitigate cold starts. Meanwhile, the legacy Linux Consumption hosting plan is scheduled for full retirement on September 30, 2028, and receives no new language versions. (Windows Consumption apps are not currently subject to that 2028 retirement date, though they lack Flex Consumption's features.)
• Expanded language boundaries and strict version ceilings: Modern workloads have broader language choices, including Python 3.13 across Flex Consumption, Premium, and Dedicated plans, and public preview support for Go—which runs exclusively on the Flex Consumption plan. Conversely, if you are stuck on legacy Linux Consumption, Microsoft has frozen language upgrades at Node.js 22, Python 3.12, Java 21,.NET 9, and PowerShell 7.4.

Section Summary: If you are starting a new serverless project in late 2026, targeting Functions Runtime 4.x on the Flex Consumption plan is the standard path forward. Legacy Linux Consumption v3 apps have already hit their September 30, 2026 cutoff, and the entire Linux Consumption tier retires in 2028.

Prerequisites and the Node.js Version Trap​

Before touching the Azure CLI, you need your local workstation wired up properly. Most botched deployments fail during local tooling validation rather than in the handler code itself. You will need:

1. An active Azure subscription with billing enabled.
2. Azure CLI (az), installed and authenticated against your tenant.
3. Azure Functions Core Tools v4 (specifically version 4.0.5382 or later to support the Node.js v4 programming model; 4.0.5530+ if you plan to use HTTP streams).
4. Node.js and npm: Here is your first major reality check. While Shattered's tutorial specifies Node.js 20.x LTS, Microsoft Learn's current Azure Functions Node.js developer reference lists Node.js 22.x and 24.x as the supported versions for the v4 model. Always install a currently supported LTS release—such as Node.js 22.x—so your local environment matches what Azure's Flex Consumption provisioning commands actually accept.
5. Azure Developer CLI (azd) (optional, for streamlined infrastructure-as-code workflows) and a command-line HTTP client like curl.

Verify your local setup in a terminal before proceeding:

az --version
az account show
func --version
node --version

If az account show throws an authentication error, run az login first so your terminal session has a valid token for resource provisioning.

Step-by-Step: Building and Deploying the Prototype API​

This 12-step architecture builds an Order Status API prototype containing an HTTP status route, a 15-minute background cleanup timer, and a stateful Durable Functions checkout workflow, all backed by Key Vault, Entra ID, and Application Insights.

Step 1: Provision the Resource Group and Storage Backend​

Every Function App relies on an Azure Storage account to manage internal host metadata (AzureWebJobsStorage), coordinate timer triggers, and store deployment packages. In Flex Consumption, deployments package your code into a .zip archive hosted in a Blob storage container.

az group create \
  --name rg-order-status-api \
  --location eastus2

az storage account create \
  --name stgorderstatusapi \
  --resource-group rg-order-status-api \
  --location eastus2 \
  --sku Standard_LRS \
  --allow-blob-public-access false

Note: Storage account names must be globally unique across Azure, between 3 and 24 characters long, using only lowercase letters and numbers. Append random digits if stgorderstatusapi is taken. Adding --allow-blob-public-access false aligns the storage account with Microsoft's baseline security recommendations from day one. While Standard_LRS (locally redundant storage) keeps dev/test costs minimal, production workloads should use zone-redundant (Standard_ZRS) or geo-redundant storage.

Step 2: Scaffold the Local Project with the Node.js v4 Model​

Initialize a new project using the Node.js v4 programming model:

func init order-status-api --javascript --model V4
cd order-status-api
npm install [USER=77929]@Azure[/USER]/functions

It is easy to confuse the Functions Runtime v4 with the Node.js Programming Model v4—the matching version number is purely coincidental. The runtime governs the underlying Azure host across all languages, whereas the Node.js v4 programming model (tied to the @azure/functions 4.x npm package) replaces the old folder-per-function and function.json configuration layout.

In the v4 model, your project only requires host.json and package.json at the root. How does the runtime find your functions? It checks the main field in your package.json—which defaults to a glob pattern like src/functions/*.js—and executes those files to register triggers directly in code via app.http() or app.timer(). Keep in mind that you cannot mix v3 (function.json) and v4 code-registered functions in the same app; as soon as one v4 function registers, any legacy v3 functions are ignored.

Step 3: Write the HTTP-Triggered Order Status Endpoint​

Create src/functions/getOrderStatus.js to handle GET requests for a specific order ID. Notice that in the v4 programming model, request is the first argument passed to the handler and context is the second (the exact opposite of the v3 model), and HTTP types follow the standard fetch specification via Node's undici package:

const { app } = require('[USER=77929]@Azure[/USER]/functions');

app.http('getOrderStatus', {
  methods: ['GET'],
  authLevel: 'anonymous',
  route: 'orders/{orderId}/status',
  handler: async (request, context) => {
    const orderId = request.params.orderId;
    context.log(`Checking status for order ${orderId}`);

    return {
      status: 200,
      jsonBody: {
        orderId,
        status: 'processing',
        checkedAt: new Date().toISOString()
      }
    };
  }
});

Setting authLevel: 'anonymous' makes local smoke testing straightforward before cloud identity controls exist. Test it locally by running func start and querying the local endpoint in a second terminal:

curl [url]http://localhost:7071/api/orders/A1001/status[/url]

Step 4: Add a Timer-Triggered Cleanup Job​

To scan for abandoned or stale orders every 15 minutes without maintaining a dedicated cron server, create src/functions/cleanupStaleOrders.js:

const { app } = require('[USER=77929]@Azure[/USER]/functions');

app.timer('cleanupStaleOrders', {
  schedule: '0 */15 * * * *',
  handler: async (myTimer, context) => {
    context.log('Timer triggered: scanning for stale orders');
    // Database query and state cleanup logic goes here
    context.log('Cleanup pass complete');
  }
});

Azure Functions uses a six-field NCRONTAB syntax ({second} {minute} {hour} {day} {month} {day-of-week}), unlike standard five-field Linux crontabs. The leading 0 represents seconds, ensuring 0 */15 * * * * fires cleanly on the 15-minute mark. Because each file in src/functions/*.js is loaded via package.json, keeping each trigger in its own module prevents duplicate registration collisions.

Step 5: Provision the Flex Consumption Function App in Azure​

To create a Flex Consumption app via the Azure CLI, you pass --flexconsumption-location rather than assigning an old App Service plan. Using a currently supported runtime version (22 for Node.js), run:

az functionapp create \
  --resource-group rg-order-status-api \
  --name order-status-api-func \
  --storage-account stgorderstatusapi \
  --flexconsumption-location eastus2 \
  --runtime node \
  --runtime-version 22 \
  --instance-memory 2048

A crucial technical correction to common assumptions: Flex Consumption defaults to a 2,048 MB instance size, not 512 MB. The plan supports three memory tiers—512 MB, 2,048 MB, and 4,096 MB (plus an unbilled 272 MB platform buffer per instance for host processes)—and can scale out up to 1,000 instances per function group, subject to your regional subscription memory quota (which defaults to 250 cores / 512,000 MB across a region for standard paid subscriptions, or 15 cores for Free Trial/Student accounts). You can explicitly set --instance-memory at creation time or adjust it later.

Step 6: Publish the Prototype Code to Azure​

Package and push your local project using Azure Functions Core Tools:

func azure functionapp publish order-status-api-func

Once deployment completes, query the remote invocation URL via the CLI and verify the live response:

az functionapp function show \
  --resource-group rg-order-status-api \
  --name order-status-api-func \
  --function-name getOrderStatus \
  --query "invokeUrlTemplate" -o tsv

curl [url]https://order-status-api-func.azurewebsites.net/api/orders/A1001/status[/url]

Step 7: Secure Secrets with Managed Identity and Azure Key Vault​

Pasting raw database connection strings into Function App settings exposes credentials to anyone with read access to the resource configuration. Instead, Microsoft recommends either connecting to backing services directly via Managed Identity (when the target database supports Entra authentication) or storing secrets in Azure Key Vault and resolving them at runtime through Key Vault references.

First, assign a system-managed identity to your Function App and create a Key Vault:

az functionapp identity assign \
  --name order-status-api-func \
  --resource-group rg-order-status-api

az keyvault create \
  --name kv-order-status-api \
  --resource-group rg-order-status-api \
  --location eastus2

PRINCIPAL_ID=$(az functionapp identity show \
  --name order-status-api-func \
  --resource-group rg-order-status-api \
  --query principalId -o tsv)

Next, authorize that PRINCIPAL_ID to read secrets. How you do this depends on your vault's permission model. Newer Key Vaults default to Azure RBAC, where you assign the Key Vault Secrets User role to the managed identity. If your vault is configured to use legacy Vault Access Policies, you grant get and list permissions via set-policy:

# If using Vault Access Policies:
az keyvault set-policy \
  --name kv-order-status-api \
  --object-id $PRINCIPAL_ID \
  --secret-permissions get list

# Store your actual connection string securely (replace placeholder with a real secret):
az keyvault secret set \
  --vault-name kv-order-status-api \
  --name OrdersDbConnectionString \
  --value "<YOUR_ACTUAL_DB_CONNECTION_STRING>"

# Wire the Key Vault reference into Function App settings:
az functionapp config appsettings set \
  --name order-status-api-func \
  --resource-group rg-order-status-api \
  --settings OrdersDbConnectionString="@Microsoft.KeyVault(SecretUri=[url]https://kv-order-status-api.vault.azure.net/secrets/OrdersDbConnectionString[/url])"

Never pass a blank string (" ") to --value expecting it to work; supply a real connection string from a secure variable. At runtime, your code reads process.env.OrdersDbConnectionString normally, while the platform fetches and caches the secret behind the scenes (refreshing rotated unversioned secrets automatically within 24 hours, or immediately upon an app restart).

Step 8: Gate Endpoints with Microsoft Entra ID Authentication​

Leaving an order API open to anonymous traffic is an obvious non-starter. Built-in App Service Authentication (often called Easy Auth) lets you require a valid Microsoft Entra ID token before a request ever reaches your Node.js worker.

Before running the CLI commands, you must create an App Registration in the Microsoft Entra admin center, expose an API scope (such as api://<client-id>), and record your Application (client) ID, Tenant ID, and either a Client Secret or a federated Managed Identity credential. Then apply the configuration:

az functionapp auth microsoft update \
  --name order-status-api-func \
  --resource-group rg-order-status-api \
  --client-id <YOUR_ENTRA_CLIENT_ID> \
  --client-secret <YOUR_ENTRA_CLIENT_SECRET> \
  --issuer [Redirecting](https://login.microsoftonline.com/)<YOUR_TENANT_ID>/v2.0

az functionapp auth update \
  --name order-status-api-func \
  --resource-group rg-order-status-api \
  --enabled true \
  --action LoginWithAzureActiveDirectory

Critical Security Distinction: Enabling platform-level Entra ID authentication verifies who the caller is (authentication), blocking unauthenticated traffic at the gateway. However, authentication is not object-level authorization. If User A presents a valid Entra token and requests /api/orders/B9999/status (which belongs to User B), Easy Auth will let the request through unless your handler code inspects the caller's claims—injected by the platform via the Base64-encoded x-ms-client-principal header—and verifies that the caller actually owns order B9999. Furthermore, for production workforce tenants, Microsoft Learn notes you can avoid managing expiring client secrets entirely by configuring your app registration to trust a user-assigned managed identity as a federated credential.

Step 9: Orchestrate Multi-Step Workflows with Durable Functions​

Real-world checkout pipelines must validate inventory, charge a card, and schedule shipping—and if the shipping API times out, you certainly do not want to double-charge the customer's credit card on retry. Durable Functions solves this by checkpointing execution state into a storage backend (either Azure Storage or the Durable Task Scheduler on Flex Consumption) after every step.

Install the package (npm install durable-functions) and create src/functions/processOrder.js:

const { app } = require('[USER=77929]@Azure[/USER]/functions');
const df = require('durable-functions');

df.app.orchestration('processOrderOrchestrator', function* (context) {
  const order = context.df.getInput();
  const validated = yield context.df.callActivity('validateOrder', order);
  const charged = yield context.df.callActivity('chargePayment', validated);
  const shipped = yield context.df.callActivity('scheduleShipment', charged);
  return shipped;
});

df.app.activity('validateOrder', {
  handler: async (order) => ({...order, validated: true })
});

df.app.activity('chargePayment', {
  handler: async (order) => ({...order, charged: true })
});

df.app.activity('scheduleShipment', {
  handler: async (order) => ({...order, shipped: true })
});

app.http('startOrderProcessing', {
  methods: ['POST'],
  authLevel: 'function',
  route: 'orders/process',
  extraInputs: [df.input.durableClient()],
  handler: async (request, context) => {
    const client = df.getClient(context);
    const body = await request.json();
    const instanceId = await client.startNew('processOrderOrchestrator', { input: body });
    context.log(`Started orchestration with ID = ${instanceId}`);
    return client.createCheckStatusResponse(request, instanceId);
  }
});

Keep in mind that these three activity handlers are illustrative scaffolding that simply append boolean flags to an in-memory JSON payload; in a real build, you will replace them with actual database and payment gateway SDK calls, wrapped in explicit retry policies (callActivityWithRetry). Once redeployed, sending a POST request with a valid token/key returns a statusQueryGetUri webhook that you can poll to watch the workflow transition from Running to Completed.

Step 10: Wire Up Application Insights Telemetry​

While Durable Functions persists orchestration state in your storage provider regardless of logging, debugging a stalled multi-step workflow without telemetry is like flying blindfolded. Provision an Application Insights instance and pass its connection string to the Function App:

az monitor app-insights component create \
  --app order-status-api-insights \
  --location eastus2 \
  --resource-group rg-order-status-api

APPINSIGHTS_CONN_STRING=$(az monitor app-insights component show \
  --app order-status-api-insights \
  --resource-group rg-order-status-api \
  --query connectionString -o tsv)

az functionapp config appsettings set \
  --name order-status-api-func \
  --resource-group rg-order-status-api \
  --settings APPLICATIONINSIGHTS_CONNECTION_STRING="$APPINSIGHTS_CONN_STRING"

Note: If you created your Function App via az functionapp create in Step 5, Azure CLI often auto-provisions an Application Insights instance unless told otherwise, so check your resource group first if you prefer not to create a second one. Also note that Microsoft recommends configuring APPLICATIONINSIGHTS_CONNECTION_STRING directly as a regular app setting rather than a Key Vault reference so the Azure Portal can render integrated telemetry blades seamlessly. For distributed tracing in the Node.js v4 model, consider adding the @azure/functions-opentelemetry-instrumentation package.

Step 11: Automate CI/CD Releases with GitHub Actions​

Manual CLI publishing does not belong in a team workflow. Create .github/workflows/deploy.yml to deploy automatically on pushes to main, making sure the node-version matches your Azure runtime (22):

name: Deploy Azure Function
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
      - name: Install dependencies
        run: npm ci
      - name: Deploy to Azure Functions
        uses: azure/functions-action@v1
        with:
          app-name: order-status-api-func
          package: '.'
          publish-profile: ${{ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE }}

You can retrieve the publishing profile via az functionapp deployment list-publishing-profiles and store it in your GitHub repository secrets as AZURE_FUNCTIONAPP_PUBLISH_PROFILE. However, treat publish-profile secrets as a basic starting point: for hardened production CI/CD pipelines, verify the latest azure/functions-action documentation and strongly consider authenticating via OpenID Connect (OIDC) federated credentials (azure/login) rather than long-lived publish profiles. Also, remember that Flex Consumption defaults to the Recreate site update strategy, which terminates active invocations during deployment; switch your app's site update strategy to RollingUpdate (currently in public preview) if you need zero-downtime deployments.

Step 12: Smoke-Test, Load-Test, and Right-Size Memory​

How does Flex Consumption billing actually work under load? According to Microsoft Learn's Flex Consumption documentation, on-demand instances are billed only while actively executing code, measured in GB-seconds of provisioned memory plus total execution count (after exhausting the monthly per-subscription free grant of 100,000 GB-seconds and 250,000 executions). For Flex Consumption specifically, Microsoft documents a 1,000 ms (1 second) minimum billable execution period for both on-demand and always-ready modes, rounding up to the nearest 100 ms thereafter (which differs from the 100 ms minimum used on legacy Consumption plans). Be aware that while the Functions compute layer has a generous monthly free grant, auxiliary resources in this tutorial—such as Key Vault, Storage, and Application Insights beyond its free ingestion cap—can still incur small charges depending on your subscription tier.

To fire a quick 50-request burst test from your terminal (include a valid Authorization: Bearer <TOKEN> header if Step 8 is enabled):

for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
    -H "Authorization: Bearer <YOUR_ENTRA_TOKEN>" \
    [url]https://order-status-api-func.azurewebsites.net/api/orders/A1001/status[/url] &
done
wait

Treat a 50-request curl loop for what it is: a quick concurrency smoke test, not a scientific load benchmark. For real capacity planning, use a dedicated load generator like k6 or Azure Load Testing. Cross-reference execution durations and memory pressure in Application Insights. Because Flex Consumption defaults to 2,048 MB, if your lightweight JSON handler barely touches 150 MB of RAM, you can cut your per-second memory billing rate by 75% by scaling down to 512 MB using the official CLI command:

az functionapp scale config set \
  --resource-group rg-order-status-api \
  --name order-status-api-func \
  --instance-memory 512

Conversely, if you have a heavy data-processing function that needs more headroom, bump --instance-memory to 4096.

Section Summary: By combining the Node.js v4 model on Node 22 with Flex Consumption, Key Vault references, Entra ID authentication, and Durable Functions, you get an event-driven architecture that avoids legacy runtime dead ends. Always validate caller claims inside your code and right-size your instance memory with az functionapp scale config set.

Architectural Comparisons: Hosting Plans and Cloud Rivals​

Choosing the right Azure Functions tier—or deciding between Azure, AWS, and Google Cloud—comes down to how much infrastructure plumbing you want to manage yourself.

Azure Functions Hosting Plans Compared​

One standout architectural advantage of Flex Consumption over the Premium plan is IP multiplexing during VNet integration. Where a Premium plan consumes one subnet IP address per scaled instance, Flex Consumption routes traffic through a shared pool of platform-managed network gateways. As a result, a tiny /27 subnet (27 usable IPs) can comfortably support a single Flex Consumption app scaling all the way to 1,000 instances.

How Flex Consumption Stacks Up Against AWS Lambda and Cloud Run​

For enterprise teams already invested in Microsoft Entra ID and Azure, keeping HTTP endpoints, cron timers, and stateful saga orchestrations inside a single codebase and deployment artifact reduces operational sprawl compared to stitching together separate scheduler and state-machine services.

Troubleshooting Common Deployment Failures​

Even veteran cloud engineers hit snags when wiring up identities and serverless bindings. Keep this checklist handy when a step misbehaves:

• Key Vault reference fails to resolve in the portal: If your app fails to connect to the database, check Application Settings in the Azure Portal. When a Key Vault reference cannot be resolved—usually due to missing RBAC/access policy permissions on the managed identity or a typo in the SecretUri—Azure passes the literal @Microsoft.KeyVault(...) string to your app instead of the secret. Open Diagnose and solve problems > Key Vault Application Settings Diagnostics in the portal to pinpoint the exact permission error.
• func: command not found or v4 model functions ignored: Verify func --version is at least 4.0.5382. If your HTTP and timer functions do not show up when running func start, check that your package.json includes a valid "main": "src/functions/*.js" entry point and that no leftover function.json files exist in the project.
• Host initialization System.TimeoutException (gRPC timeout): Flex Consumption enforces a strict, non-configurable 30-second timeout for host initialization. If heavy startup dependencies delay initialization beyond 30 seconds, the host logs a gRPC timeout. Move heavy initialization out of the global startup path or use always-ready instances.
• Time zone settings (WEBSITE_TIME_ZONE / TZ) do not change timer schedules: Be aware that WEBSITE_TIME_ZONE and TZ application settings are not currently supported on the Flex Consumption plan. Design your NCRONTAB schedules in UTC.
• Clean Teardown: When you finish testing this prototype, avoid lingering charges from Key Vault or Log Analytics/Application Insights by deleting the entire resource group in a single command: az group delete --name rg-order-status-api --yes --no-wait. If your Key Vault has purge protection enabled, purge it explicitly if you do not plan to reuse the vault name.