Azure Functions for AI: hosting, scaling, triggers, bindings, security, and MCP

radio_button_uncheckedshort_text1. Scenario and learning objectives

Imagine an intelligent document platform that receives an upload through an API, extracts text with an Azure AI service, classifies the content, and persists the result. Virtual machines sized for traffic peaks remain idle much of the day and still require patching and capacity management. Azure Functions replaces that fixed capacity with event-driven execution, automatic scaling, and billing tied to the selected plan.

• Expose a low-latency HTTP ingestion endpoint.
• Move long work to a queue-triggered processor.
• Use bindings for data movement and SDK clients where no binding exists.
• Protect configuration with Key Vault, App Configuration, and managed identity.
• Expose selected operations as MCP tools for agents.

Quick recap

The goal is a responsive, secure AI backend that pays for appropriate capacity and separates request acceptance from heavy processing.

radio_button_uncheckedshort_text2. Cold starts and why AI workloads magnify them

A cold start occurs when the platform allocates an instance, starts the Functions host and language worker, loads the application, and prepares dependencies before the first invocation. It can occur on any plan that scales to zero and is paid once per new instance—not on every request.

AI functions often import large SDKs, load model metadata, resolve configuration, obtain tokens, create network pools, or initialize inference libraries. Those steps make the first request slower than a lightweight handler. Initialize reusable clients at module scope, keep deployment packages lean, avoid unnecessary startup work, and measure startup separately from warm latency.

Quick recap

Cold start is per instance; dependency weight and initialization amplify it, while warm invocations reuse the prepared process.

radio_button_uncheckedshort_text3. Flex Consumption: the serverless default

Flex Consumption is the recommended Linux-based plan for new serverless function apps. It offers event-driven per-function scaling, virtual-network integration, configurable 512-MB, 2,048-MB, or 4,096-MB instances, and up to 1,000 on-demand instances. The 2,048-MB size is the general starting point; 4,096 MB provides more CPU and memory for heavier workloads, while 512 MB suits light processors.

Always-ready instances keep selected functions or scale groups warm. They reduce cold-start risk but create a baseline charge, so apply them to latency-sensitive endpoints rather than every background function. On-demand instances still expand beyond that floor.

Quick recap

Choose Flex Consumption for event-driven economics and per-function scale; add always-ready capacity only where first-request latency justifies it.

radio_button_uncheckedshort_text4. Premium and the remaining hosting choices

Quick recap

Premium trades a warm baseline for predictable startup and larger/custom workers; Dedicated and Container Apps serve specialized capacity or container requirements.

radio_button_uncheckedshort_text5. Per-function scaling, concurrency, and memory

In Flex Consumption, all HTTP triggers scale as one HTTP group, Event Grid-based blob triggers form a blob group, and Durable Functions share a durable group. Most other triggers—such as Service Bus, queues, and timers—scale independently. A document queue surge therefore does not have to consume the instances serving the HTTP front door.

Concurrency controls parallel executions per instance. Lower concurrency spreads expensive AI calls across more instances and gives each invocation more CPU and memory; higher concurrency reduces instance count but increases resource contention. Tune with load tests, downstream quotas, memory profiles, and end-to-end latency—not throughput alone.

Quick recap

Scale groups determine which functions share instances, while concurrency and instance memory decide how much work each instance accepts.

radio_button_uncheckedshort_text6. Long-running work and async request-reply

An HTTP-triggered function has about 230 seconds to return a response because of the Azure Load Balancer, regardless of a longer functionTimeout. Flex Consumption and Premium can run non-HTTP executions without a configured maximum, but scale-in and platform-update grace periods still apply.

1. Validate the request and create a job identifier.
2. Write the work item to Service Bus.
3. Return 202 Accepted with a status URL.
4. Process the message in a separate function.
5. Persist status and results for polling or notification.

import azure.functions as func
import json, uuid

app = func.FunctionApp()

@app.route(route="documents", methods=["POST"], auth_level=func.AuthLevel.FUNCTION)
@app.service_bus_queue_output(
    arg_name="job", queue_name="document-jobs", connection="ServiceBusConnection")
def accept_document(req: func.HttpRequest, job: func.Out[str]) -> func.HttpResponse:
    payload = req.get_json()
    job_id = str(uuid.uuid4())
    job.set(json.dumps({"jobId": job_id, "url": payload["documentUrl"]}))
    return func.HttpResponse(
        json.dumps({"jobId": job_id, "statusUrl": f"/api/jobs/{job_id}"}),
        status_code=202, mimetype="application/json")

Quick recap

A 202 response plus a queue decouples request latency from long AI processing and lets ingestion and workers scale separately.

radio_button_uncheckedshort_text7. Local tools and project creation

Azure Functions Core Tools v4 supplies the generally available local host and the func command. Azure Functions CLI v5 is currently preview. The Azure Functions extension for Visual Studio Code adds templates, F5 debugging, deployment, and settings synchronization. Start a project from the command palette or with func init, add a trigger with func new, and run it with func start.

• Core Tools v4 or a supported Functions CLI workflow
• Visual Studio Code plus the Azure Functions extension
• A supported Python interpreter and isolated virtual environment
• Azurite for local host storage
• curl, an .http client, or another request tool

Quick recap

The local host executes the same trigger and binding model used in Azure, shortening the edit-test-debug loop before deployment.

radio_button_uncheckedshort_text8. Python v2 project structure

Keep functions stateless, split large applications into blueprints, and commit the debug configuration but not local.settings.json. A smaller deployment package also reduces initialization work.

Quick recap

function_app.py and blueprints define behavior; host.json defines shared runtime behavior; local settings and dependency files define the environment.

radio_button_uncheckedshort_text9. AzureWebJobsStorage, Azurite, and local dependencies

AzureWebJobsStorage is not merely application storage. The host uses it for coordination, timer state, and function access keys. Missing or invalid configuration can leave non-HTTP triggers inactive. Locally, UseDevelopmentStorage=true points the host and supported Storage bindings to Azurite implementations of Blob, Queue, and Table storage.

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "python",
    "ServiceBusConnection__fullyQualifiedNamespace": "<namespace>.servicebus.windows.net"
  }
}

Use the Azure Cosmos DB emulator where appropriate, local PostgreSQL or Redis containers for compatible protocols, and isolated development values. Before release, test with real Azure services and never deploy UseDevelopmentStorage=true.

Quick recap

Azurite satisfies the local host-storage requirement; emulators speed development but do not replace final tests against managed services.

radio_button_uncheckedshort_text10. HTTP triggers and endpoint authorization

Every function has exactly one trigger. An HTTP trigger receives methods, headers, query parameters, and a request body, then returns an HttpResponse. Use anonymous only for intentionally public endpoints or health checks, function for a basic production barrier, and admin only for operations that genuinely require the master key.

Function keys are not caller identity. Put internet-facing APIs behind API Management or App Service Authentication when you need Microsoft Entra ID, OAuth 2.0 validation, quotas, transformations, or rate limits.

Quick recap

HTTP triggers create synchronous APIs; authorization levels select a key requirement but an identity-aware gateway provides real caller authentication.

radio_button_uncheckedshort_text11. Service Bus triggers, locks, retries, and dead-lettering

A Service Bus queue trigger receives work in PeekLock mode. Successful execution completes the message; failure abandons it for redelivery unless settlement is handled manually. maxConcurrentCalls controls parallel callbacks per instance, while maxAutoRenewDuration must cover the expected processing window so a long AI call does not lose its lock.

{
  "version": "2.0",
  "extensions": {
    "serviceBus": {
      "maxConcurrentCalls": 1,
      "maxAutoRenewDuration": "00:10:00",
      "autoCompleteMessages": true
    }
  }
}

After maxDeliveryCount on the queue is exceeded, Service Bus moves the poison message to its built-in dead-letter subqueue with diagnostic metadata. Monitor and reprocess it deliberately. For the most accurate target-based scale decisions, also grant the management read permission described by the Service Bus binding documentation.

Quick recap

Set concurrency to match resource cost, renew locks long enough, and operate the dead-letter queue as part of the production workflow.

radio_button_uncheckedshort_text12. Input/output bindings and direct SDK clients

The trigger is also an input binding. Additional input bindings read data and output bindings write it without repetitive connection and serialization code. Blob Storage suits processed files, Azure Cosmos DB suits structured results, and Service Bus suits fan-out. Use SDK clients when the service has no suitable binding or when you need its complete API.

@app.service_bus_queue_trigger(
    arg_name="msg", queue_name="document-jobs", connection="ServiceBusConnection")
@app.cosmos_db_output(
    arg_name="result", database_name="ai-results",
    container_name="classifications", connection="CosmosDBConnection")
def classify(msg: func.ServiceBusMessage, result: func.Out[func.Document]) -> None:
    job = json.loads(msg.get_body().decode("utf-8"))
    answer = run_document_pipeline(job["url"])
    result.set(func.Document.from_dict({"id": job["jobId"], **answer}))

Create expensive credential and SDK client objects at module level so warm invocations reuse connection pools and token caches. Keep the handler focused on validation, orchestration, and business logic.

Quick recap

Bindings remove infrastructure boilerplate; SDK clients preserve full service control and should be initialized once per warm process.

radio_button_uncheckedshort_text13. Application settings and environment separation

Function app settings are encrypted at rest and injected as environment variables. Store endpoints, deployment names, thresholds, concurrency limits, and feature flags as focused key-value pairs. Python can use os.environ for required values and os.getenv for explicit defaults.

Keep development, staging, and production values separate. Manage production settings through infrastructure as code or controlled CLI workflows; fetching remote settings into local.settings.json can expose secrets and uploading local values can break production.

Quick recap

Code remains environment-neutral when configuration comes from environment variables and each stage owns its values.

radio_button_uncheckedshort_text14. Key Vault references and secret rotation

A Key Vault reference lets an app setting resolve a secret without changing application code. Grant the app identity the Key Vault Secrets User role. A versionless reference follows the latest secret version within the platform cache window—currently up to 24 hours—while a versioned URI stays pinned. An app configuration change or explicit refresh can force re-resolution.

AI_SERVICE_KEY=@Microsoft.KeyVault(
  SecretUri=https://<vault>.vault.azure.net/secrets/AiServiceKey/)

from azure.appconfiguration.provider import load
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
config = load(
    endpoint=os.environ["AZURE_APPCONFIG_ENDPOINT"],
    credential=credential,
    keyvault_credential=credential)

Quick recap

Keep secrets in Key Vault, use versionless references for managed rotation, and grant only secret-read access to the function identity.

radio_button_uncheckedshort_text15. Azure App Configuration and feature management

Azure App Configuration centralizes non-secret values and feature flags shared by multiple function apps. Labels can select development, staging, or production configuration; the Python provider can refresh values and resolve Key Vault references through DefaultAzureCredential.

Use App Configuration for model routes, feature toggles, or thresholds; use Key Vault for credentials. This layered design offers one configuration surface without turning a configuration store into a secret vault.

Quick recap

App Configuration centralizes shared behavior and labels; Key Vault remains the source of sensitive values.

radio_button_uncheckedshort_text16. Managed identity and least-privilege connections

Identity-based connections replace connection strings with a named prefix and service endpoint. A system-assigned identity is the default; a user-assigned identity can be shared and prepared before deployment. The double-underscore settings form structured connection properties.

AzureWebJobsStorage__accountName=<storage-account>
ServiceBusConnection__fullyQualifiedNamespace=<namespace>.servicebus.windows.net
CosmosDBConnection__accountEndpoint=https://<account>.documents.azure.com:443/

# SDK client created once and reused on warm invocations
credential = DefaultAzureCredential()
client = DocumentIntelligenceClient(
    endpoint=os.environ["DOCUMENT_INTELLIGENCE_ENDPOINT"],
    credential=credential)

Quick recap

Managed identity removes stored credentials; each target still needs a narrowly scoped data-plane role and correct connection-property suffix.

radio_button_uncheckedshort_text17. Access keys, API protection, and the MCP lab

Function keys apply to one function, host keys can invoke every HTTP function in an app, system keys belong to extensions, and the master key unlocks administrative endpoints. Treat all as secrets. API Management adds policy and OAuth controls; App Service Authentication can enforce Microsoft Entra sign-in.

The Azure Functions MCP extension can expose tool, resource, and prompt triggers. Current clients should prefer Streamable HTTP at /runtime/webhooks/mcp; SSE exists for compatibility. In Azure, the endpoint normally requires the mcp_extension system key. Python needs azure-functions 1.24.0 or later and local MCP work requires Core Tools 4.0.7030 or later.

{
  "servers": {
    "local-functions-mcp": {
      "type": "http",
      "url": "http://localhost:7071/runtime/webhooks/mcp"
    },
    "remote-functions-mcp": {
      "type": "http",
      "url": "https://<app>.azurewebsites.net/runtime/webhooks/mcp",
      "headers": { "x-functions-key": "${input:mcp-extension-system-key}" }
    }
  }
}

1. Create a Functions project and an MCP Tool trigger.
2. Verify host.json uses extension bundle 4.x.
3. Implement a small tool in function_app.py and avoid destructive operations.
4. Run Azurite and func start, then connect an MCP client locally.
5. Deploy, retrieve the mcp_extension system key securely, and test Streamable HTTP.

Quick recap

Keys are scoped shared secrets; production APIs need identity-aware protection, and an MCP server should expose narrow tools over Streamable HTTP.

radio_button_uncheckedshort_text18. Assessment review, checklist, and references

Final design checklist

• Measure cold and warm latency.
• Choose the plan and instance memory from load tests.
• Queue work that can exceed the HTTP response limit.
• Tune concurrency, lock renewal, retry, and dead-letter operations.
• Keep local settings out of source control.
• Prefer managed identity and least privilege.
• Rotate unavoidable secrets through versionless Key Vault references.
• Monitor failures, scale decisions, dependency latency, and cost.
• Constrain MCP tools and protect remote endpoints.

1. Azure Functions scale and hosting
2. Flex Consumption plan
3. Develop Azure Functions locally
4. Azure Service Bus trigger for Azure Functions
5. Configure connections to remote services
6. Key Vault references for Azure Functions
7. MCP bindings for Azure Functions

Quick recap

The exam scenario joins hosting, scaling, local tooling, messaging, secure configuration, identity, and endpoint protection into one operational design.