Choose a file access strategy for Azure Functions

files = container_client.list_blobs(name_starts_with="reference/")
for blob in files:
    stream = container_client.download_blob(blob.name)

for file_path in Path("/mnt/reference").iterdir():
    with open(file_path, "rb") as f:

reference_data = container.query_items(
    query="SELECT * FROM reference WHERE id IN (...)"
)

Use case: You have 1,000 analysis tasks that all need to read from the same set of reference data files (for example, ML models, lookup tables, or corpus data).

The problem: Without mounts, you have two suboptimal options:

• Package the reference files with your function: This approach results in a huge deployment artifact, slow cold starts, and storage redundancy.
• Download from Blob Storage each time: This approach introduces network latency on every function invocation and wastes bandwidth.

The mount-based solution: All instances read from the mounted share directly. After mount initialization, there's no per-request network overhead and no redundant storage.

┌─────────────────────────┐
│  Function Instance 1    │
│  Function Instance 2    ├──→  /mnt/models/  ──→  Azure Files share
│  Function Instance 3    │     (shared mount)
└─────────────────────────┘

Implementation pattern: (Python)

import os
from pathlib import Path

MOUNT_PATH = "/mnt/models"

def analyze_data(item: str) -> dict:
    """Activity function: reads from shared mount."""
    model_path = Path(MOUNT_PATH) / "model.pkl"
    
    # Direct file I/O — no SDK call, no network overhead
    with open(model_path, "rb") as f:
        model = pickle.load(f)
    
    result = model.predict(item)
    return {"item": item, "score": result}

Key points:

• All instances of your function app see the same mount.
• File reads are POSIX-compliant. You use standard file system APIs.
• No need to authenticate per read (the mount is authenticated once at startup).
• Changes written by one instance are visible to others immediately.

Security considerations:

• Storage account key: Azure Files storage mounts on Flex Consumption authenticate by using a storage account access key configured in the function app's mount settings. Managed identity with Storage File Data SMB Share Contributor RBAC isn't supported for SMB mounts on Azure Functions. Keep the access key secure and rotate it periodically.
• Read-only option: If your workload doesn't need to write, restrict the mount to read-only.
• Quotas: Set Azure Files share quotas to prevent runaway costs if instances write large files.

Use case: You need to run a large third-party binary (500+ MB) on every instance, but you don't want to package it with your function code. Such binaries could include ffmpeg, ImageMagick, and others.

The problem:

• Without mounts:

  • Package binary in deployment artifact: 500+ MB per instance, slow deployment, wasted bandwidth.
  • Download from Blob on each invocation: Network call on every execution, slower than local access.

• Using mounted shares

  Upload the binary once to Azure Files. All instances access it from the mount.

  ┌─────────────────────────────────────────────────┐
  │  Deployment package: 10 MB (just your code)     │
  ├─────────────────────────────────────────────────┤
  │  Mount: /mnt/binaries/ffmpeg                    │
  │  (500 MB binary, shared across all instances)   │
  ├─────────────────────────────────────────────────┤
  │  Execution: your code calls the mounted binary  │
  └─────────────────────────────────────────────────┘
  

Implementation pattern: (Python)

import subprocess
from pathlib import Path

FFMPEG_PATH = "/mnt/binaries/ffmpeg"
TEMP_PATH = "/mnt/binaries/temp"

def process_video(video_file: str) -> str:
    """Activity function: calls ffmpeg from mount."""
    input_file = Path(TEMP_PATH) / video_file
    output_file = Path(TEMP_PATH) / f"{video_file}.mp4"
    
    result = subprocess.run(
        [FFMPEG_PATH, "-i", str(input_file), "-codec", "libx264", str(output_file)],
        capture_output=True,
        timeout=300
    )
    
    if result.returncode != 0:
        raise Exception(f"FFmpeg error: {result.stderr.decode()}")
    
    return str(output_file)

Key points:

• The binary is mounted, not packaged.
• The deployment artifact stays small.
• Cold starts are faster (less to unzip).
• All instances can call the same binary concurrently.

Performance implications:

• First execution: SMB mount initialization adds approximately 200-500 milliseconds.
• Subsequent executions: Direct file access with minimal overhead.
• Binary caching: The OS caches the binary in memory, reducing repeated disk reads.

Use case: You have App A (data producer) and App B (data consumer) running in the same region. App A writes processed data, and App B reads it.

The problem: Without mounts, you'd typically use Azure Blob Storage (decoupled, but with network overhead), Azure Queue Storage with message passing (eventual consistency), or Azure Cosmos DB (more complexity than simple file sharing needs).

The mount-based solution: Both apps mount the same Azure Files share. App A writes, and App B reads. No message passing, no eventual consistency.

┌──────────────────────┐
│  App A (Producer)    ├──write──┐
└──────────────────────┘         │
                           ┌─────┴─────────────────┐
                           │  /mnt/shared/         │
                           │  Azure Files share    │
                           │  (single source of    │
                           │   truth)              │
                           └─────┬─────────────────┘
┌──────────────────────┐         │
│  App B (Consumer)    ├──read───┘
└──────────────────────┘

Implementation pattern:

App A (Producer):

from pathlib import Path
import json

MOUNT_PATH = "/mnt/shared"

def write_results(data: dict) -> None:
    """Write results to shared mount."""
    output_file = Path(MOUNT_PATH) / "latest_results.json"
    with open(output_file, "w") as f:
        json.dump(data, f)

App B (Consumer):

from pathlib import Path
import json

MOUNT_PATH = "/mnt/shared"

def read_results() -> dict:
    """Read results from shared mount."""
    results_file = Path(MOUNT_PATH) / "latest_results.json"
    if not results_file.exists():
        return {}
    with open(results_file, "r") as f:
        return json.load(f)

Key points:

• Both apps need mount configuration referencing the same storage account and access key.
• Use file locks (for example, fcntl on Linux or equivalent locking APIs in your language) to prevent read/write race conditions.
• Azure Files supports concurrent reads; writes should be sequential or locked.