Azure Functions Cost Optimisation

Hosting Plan Cost Comparison

Azure Functions offers three hosting plans with fundamentally different billing models:

Consumption Plan Pricing in Detail

The Consumption plan has two charge dimensions:

• Execution count: $0.20 per million executions. First 1 million/month are free.
• Execution time (GB-seconds): $0.000016 per GB-second. First 400,000 GB-seconds/month are free.

Calculating cost for a typical workload

An HTTP-triggered function that processes 5 million requests/month, each taking 200ms with 256 MB memory:

• Executions: 5 million — 1 million free = 4 million billable × $0.20/million = $0.80
• GB-seconds: 5,000,000 × 0.2s × 0.25 GB = 250,000 GB-s — all within the 400,000 free tier = $0
• Total: $0.80/month — serverless is genuinely cheap at this scale

Now consider a data processing function that runs 10 million times/month, each taking 5 seconds with 1 GB memory:

• Executions: 9 million billable × $0.20/million = $1.80
• GB-seconds: 10,000,000 × 5s × 1 GB = 50,000,000 GB-s — minus 400,000 free = 49,600,000 billable × $0.000016 = $793.60
• Total: $795.40/month

This shows why execution time and memory allocation are the dominant cost factors — not execution count.

Premium Plan: When It’s Cheaper Than Consumption

The Premium plan charges continuously for at least one pre-warmed instance. An EP1 instance (1 vCPU, 3.5 GB RAM) costs approximately $0.173/hour = ~$126/month.

At the data processing workload above ($795/month on Consumption), switching to a Premium EP2 (2 vCPU, 7 GB RAM, ~$252/month) would require processing roughly 3x the work within the same time window to justify the switch. But if the workload is that heavy and predictable, Premium becomes cheaper AND provides better performance characteristics (no cold starts, faster scale, VNET integration).

Code-Level Optimisations That Reduce Cost

Because Consumption billing depends on execution time × memory, every inefficiency in your function code translates directly to money.

1. Reduce memory allocation

Azure Functions on Consumption allocates memory dynamically based on actual usage, but avoidable allocations still count. Keep memory usage down by:

• Processing data in streams rather than loading entire payloads into memory
• Disposing of large objects promptly in .NET functions
• Avoiding loading large configuration files or models inside the function handler (load them at startup)

2. Reduce execution time

Execution time is billed from when the function handler starts to when it completes. Common time wasters include:

• Creating new HTTP clients or database connections on every invocation — use static/singleton clients instead
• Making sequential database calls that could be parallelised with Promise.all() or Task.WhenAll()
• Fetching configuration from Key Vault on every invocation — cache it with a TTL
• Using synchronous SDK calls where async equivalents are available

// EXPENSIVE: creates a new database connection on every invocation
module.exports = async function (context, req) {
  const client = new MongoClient(process.env.MONGODB_URI);
  await client.connect();
  // ... work ...
  await client.close();
};

// OPTIMISED: connection created once at module load, reused across invocations
const { MongoClient } = require('mongodb');
let cachedClient = null;

async function getClient() {
  if (!cachedClient) {
    cachedClient = new MongoClient(process.env.MONGODB_URI);
    await cachedClient.connect();
  }
  return cachedClient;
}

module.exports = async function (context, req) {
  const client = await getClient();
  // ... work ...
  // Do NOT close the client here
};

3. Use durable functions for long-running work

The Consumption plan has a maximum execution timeout of 10 minutes. Workflows that would exceed this are often split into chained functions with intermediate storage, incurring multiple executions. Durable Functions orchestrations pause during waits and are only billed for active execution, making them more efficient for multi-step workflows than polling loops.

Trigger-Level Optimisations

The trigger type affects how often your function executes and therefore its cost:

• Timer triggers: review whether polling frequency matches business need. A function checking for new records every 60 seconds runs 43,800 times/month. If the check can happen every 10 minutes, that drops to 4,320 executions — a 90% reduction.
• Queue triggers: use batching where possible. Processing 10 messages per execution costs the same as processing 1, but reduces execution count by 10x.
• HTTP triggers: implement request coalescing at the Application Gateway layer to batch small requests before they reach your function.
• Event Grid / Service Bus triggers: increase the batch size configuration to process more events per invocation.

// host.json: increase batch size for Service Bus triggers
{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "prefetchCount": 100,
      "messageHandlerOptions": {
        "maxConcurrentCalls": 16,
        "maxAutoRenewDuration": "00:05:00"
      },
      "batchOptions": {
        "maxMessageCount": 1000,
        "operationTimeout": "00:01:00",
        "autoComplete": true
      }
    }
  }
}

Azure Savings Plans for Functions

Azure Savings Plans apply to Azure Functions Premium plan compute. If you have a predictable Functions Premium workload, committing to a savings plan can reduce the per-vCPU-hour cost by 17–20% compared to on-demand Premium pricing.

Savings Plans do not apply to Consumption plan Functions — there is nothing to commit to since there is no continuous compute reservation.