az functionapp list --resource-group <resource-group> --output table
Compute
Serverless compute
Azure Functions
Azure Functions is Azure serverless compute for running code from triggers such as HTTP requests, queues, timers, events, and service integrations without managing servers.
Source: Microsoft Learn - Azure Functions overview Reviewed 2026-05-29
- Exam trap
- Treating queue processing as exactly-once and writing non-idempotent code that corrupts records after retries.
- Production check
- Verify the function app, hosting plan, storage account, Application Insights resource, and managed identity are the expected ones.
Article details and learning context
- Aliases
- Functions, Function App, serverless functions
- Difficulty
- intermediate
- CLI mappings
- 6
- Last verified
- 2026-05-29
- Article depth
- field-manual-complete
Learning paths
Learn
AZ-204 Azure Developer application path
Azure Functions
Understand the concept
In plain English
Azure Functions is a way to run focused pieces of code only when something happens. A request arrives, a queue message appears, a file lands in storage, or a timer fires, and Azure starts the function for that job. You do not manage virtual machines for the function runtime. You still design the code, triggers, permissions, hosting plan, retries, and logs. It is best when work is event-driven, bursty, or naturally split into small tasks.
Why it matters
Azure Functions matters because many production workflows do not need a full web server or always-on worker. They need reliable reaction to events: resize an image, process a message, enrich a document, run a scheduled cleanup, or connect two systems. Using the wrong compute model can leave teams paying for idle capacity or building fragile polling jobs. Functions gives architects a clean boundary for small units of work, but it also forces discipline around timeout, retry, idempotency, cold start, and dependency design. Learners should understand it as a workload shape, not merely a cheaper hosting option. It also clarifies when queues, durable orchestration, or a long-running worker should carry the load.
Official wording and source
Azure Functions is Azure’s serverless compute service for running small pieces of code from events such as HTTP requests, timers, queues, Event Grid notifications, or service messages. It lets teams build event-driven workloads without managing servers while still controlling triggers, bindings, hosting plan, identity, networking, and monitoring.
Technical context
Azure Functions sits in Azure compute and integration architecture as an event-driven runtime. A function app is the Azure resource, while individual functions bind to triggers and inputs such as HTTP, Blob Storage, queues, Event Grid, Event Hubs, Service Bus, Cosmos DB, or timers. Hosting can use Consumption, Flex Consumption, Premium, Dedicated, or container-based patterns. It touches control plane configuration, data plane events, managed identity, application settings, storage, networking, and Application Insights telemetry. That mix is why operators must trace both Azure settings and event payload paths.
Exam context
What to know
operator field manual with architecture, governance, CLI, and case-study depth
Compare with
Where it is used
Where you see it
- In the Azure portal, Azure Functions appears as a Function App with Functions, App keys, Configuration, Identity, Networking, Deployment Center, and Monitor blades for each environment.
- In Azure CLI output, operators see az functionapp list, show, function list, appsettings list, identity show, and restart commands for the exact app and slot.
- In Application Insights, it appears through request, dependency, trace, exception, execution count, duration, failure rate, and trigger-specific telemetry during live incidents and release reviews. weekly
Common situations
- Process queue or Service Bus messages without keeping a custom worker VM online all day.
- Run scheduled cleanup, reconciliation, or notification jobs where a timer trigger is simpler than a full scheduler platform.
- React to Blob Storage uploads by validating, transforming, indexing, or forwarding files immediately after arrival.
- Expose a narrow HTTP endpoint for webhook intake, lightweight APIs, or automation callbacks with managed scaling.
- Coordinate multi-step event workflows with Durable Functions when retries, checkpoints, and long-running orchestration matter.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 Claims intake removes fragile polling servers Scenario, objectives, solution, measured impact, and takeaway.
Scenario
A specialty insurance processor received claim PDFs from 1,200 brokers and used scheduled Windows services to poll a file share. Peak storm days created six-hour backlogs and little evidence about which files failed.
Goals
- Process 95 percent of claim uploads within two minutes.
- Remove three aging polling servers from the intake path.
- Capture failure evidence for every rejected document.
- Keep broker-facing upload behavior unchanged during migration.
Approach using Azure Functions
The team placed uploaded claim packages in Blob Storage and used Azure Functions with blob and queue triggers to validate file type, extract metadata, and push accepted records into Service Bus. Managed identity granted access to the storage account, Key Vault, and the downstream claims API. Application Insights tracked execution duration, dependency failures, and rejected-file reasons. Poison messages were routed to a support queue with the broker ID, blob URI, correlation ID, and validation failure. The old polling service stayed read-only for two weeks while the function app processed live uploads, allowing operators to compare counts before retiring the servers.
Potential outcomes
- Ninety-seven percent of uploads were processed within 84 seconds.
- The six-hour storm backlog fell to under eleven minutes at peak.
- Three polling servers and their patch windows were retired.
- Support could identify the rejected file and reason in under three minutes.
What to learn
Azure Functions is valuable when event intake needs fast reaction, repeatable retries, and clear failure evidence without running a permanent worker tier.
Scenario 02 Transit alerts move from overnight batches to live events Scenario, objectives, solution, measured impact, and takeaway.
Scenario
A city transportation agency collected bus sensor events but only generated maintenance alerts after an overnight batch. Brake-temperature spikes and door faults were often discovered after vehicles had completed full shifts.
Goals
- Generate high-priority maintenance alerts within one minute.
- Avoid adding a new always-on operations server.
- Route duplicate sensor events safely without duplicate work orders.
- Give dispatchers a simple dashboard for failed processing.
Approach using Azure Functions
Engineers used Event Hubs for incoming telemetry and Azure Functions to process partitioned event batches. The function checked each event against a maintenance threshold table in Azure SQL and wrote one idempotent work order per vehicle, fault type, and hour. Managed identity handled database access, and Application Insights captured lag, execution failures, and dependency latency. A dead-letter workflow stored malformed messages in Blob Storage for weekly review. The team tuned batch size and concurrency after load testing morning rollouts, then added a timer-triggered reconciliation function to catch missed alerts.
Potential outcomes
- Critical maintenance alerts arrived in a median of 37 seconds.
- Duplicate work orders dropped from 14 percent to below 1 percent.
- No additional Windows service hosts were added to operations.
- Dispatchers saw processing failures on the same dashboard as fleet alerts.
What to learn
Azure Functions works well when telemetry streams need targeted event handling, duplicate-safe writes, and operational visibility without a full application server.
Scenario 03 Media archive creates searchable assets on upload Scenario, objectives, solution, measured impact, and takeaway.
Scenario
A documentary studio had petabytes of archived video and still images, but editors waited days for new material to become searchable. The legacy workflow depended on a manual spreadsheet and a shared desktop encoding tool.
Goals
- Create searchable metadata within ten minutes of asset upload.
- Separate heavy media work from the upload portal.
- Track every failed thumbnail and transcript job.
- Reduce manual catalog updates by at least 70 percent.
Approach using Azure Functions
The platform team used Blob Storage events to start Azure Functions whenever new proxy files arrived. A queue-triggered function generated thumbnails, called approved media analysis services, and wrote metadata into Azure AI Search. Long-running transcode work was moved to a separate batch service, while Functions handled orchestration, validation, and catalog updates. Managed identity limited access to the archive container, search index, and Key Vault. Operators used Application Insights workbooks to track failed executions, average processing time, and dependency errors by asset type.
Potential outcomes
- Searchable records appeared in a median of 6.4 minutes.
- Manual spreadsheet catalog updates fell 82 percent.
- Failed thumbnail jobs were isolated and replayed without reuploading files.
- Editors recovered roughly 18 hours per week during production deadlines.
What to learn
Azure Functions is strongest when it glues storage events, queues, indexing, and diagnostics into a focused workflow that can be replayed safely.
Azure CLI
I use Azure CLI for Azure Functions because real environments usually have dozens of function apps, slots, identities, plans, settings, and trigger definitions spread across subscriptions. After ten years of Azure operations, I do not trust portal memory during an incident. CLI gives me repeatable inventory, JSON output, and commands that can be pasted into a pipeline or runbook. I can inspect hosting plan, runtime version, identity state, app settings, deployments, and function lists without clicking through blades. It also lets me restart, configure, or export evidence with a clear target scope and audit trail. That speed matters when triggers fail and customers are waiting.
Useful for
- Inventory all function apps in a resource group and export runtime, plan, region, and identity data for review.
- Inspect app settings, trigger lists, deployment slots, and Application Insights connection values before a release.
- Restart or scale the hosting plan from an approved runbook when failures, cold start, or stuck workers affect production.
Before you run a command
- Confirm tenant, subscription, resource group, function app name, slot, and whether the command changes runtime behavior.
- Check that you have least-privilege access; appsettings output can reveal secrets, connection strings, or endpoints.
- Know the hosting plan, region, storage account, and event source because a restart or configuration change can interrupt processing.
What the output tells you
- Runtime, state, host names, plan ID, identity, and site configuration show whether the app matches the approved design.
- Function lists and trigger metadata show which event handlers exist and whether the expected function was deployed.
- App settings, deployment timestamps, and logs help separate a code failure from missing configuration or dependency access.
Mapped commands
Azure Functions operations
directaz functionapp show --name <function-app> --resource-group <resource-group>az functionapp function list --name <function-app> --resource-group <resource-group>az functionapp config appsettings list --name <function-app> --resource-group <resource-group>az functionapp identity show --name <function-app> --resource-group <resource-group>az functionapp restart --name <function-app> --resource-group <resource-group>Architecture context
Architecturally, Azure Functions is best treated as a small event processor inside a larger system. It often belongs between storage, messaging, APIs, data services, and observability. The durable part of the design is usually the event source, queue, database, or workflow state, not the function instance itself. I care most about trigger semantics, retry behavior, poison handling, idempotent code, and identity permissions. For customer-facing HTTP functions, I also evaluate API Management, App Service, Container Apps, or AKS. For background events, Functions often wins when the unit of work is focused, stateless, measurable, and easy to replay safely. It should have explicit ownership, limits, and replay guidance.
- Security
- Security is direct because a function can run code, read events, call downstream services, and expose HTTP endpoints. Protect HTTP triggers with authentication, authorization, function keys, App Service authentication, API Management, or private networking where appropriate. Store secrets in Key Vault or use managed identity instead of raw connection strings when possible. Lock down storage accounts, queues, Service Bus namespaces, and databases to only the identities that need them. Be careful with app settings because they often contain sensitive values. Log enough for audit without writing tokens, customer data, or message payloads unnecessarily. Deployment identities also need review because code changes can alter data access paths.
- Cost
- Cost is tied to hosting plan, executions, memory, duration, storage transactions, telemetry, and downstream services. Consumption-style plans can be efficient for bursty event work, but expensive mistakes still happen when functions loop, retry bad messages, emit excessive logs, or call costly APIs repeatedly. Premium and Dedicated plans add predictable capacity and warm workers, but charge for allocated resources even during quiet periods. Application Insights ingestion can become a surprise line item if every payload is logged. FinOps reviews should compare event volume, execution duration, scale settings, telemetry retention, and whether a long-running worker would be cheaper. Tagging the function app and related resources keeps ownership visible during monthly reviews.
- Reliability
- Reliability depends on trigger behavior, timeout limits, retry policies, hosting plan, dependency health, and whether function code is idempotent. A queue-triggered function can process messages repeatedly after failures, so duplicate-safe writes are essential. HTTP functions need clear timeout and client retry expectations. Cold start can affect first requests unless the plan keeps workers warm. Durable Functions help with stateful orchestration, but they introduce their own storage and replay considerations. Operators should monitor failures, execution count, latency, dead-letter queues, storage health, and deployment changes. Reliability comes from designing for replay, not assuming every event runs once. Alert rules should distinguish platform failures from poison-message patterns and bad downstream dependencies.
- Performance
- Performance depends on cold start, hosting plan, language runtime, package size, dependency initialization, trigger batching, downstream latency, and concurrency settings. A function that starts quickly but waits on a slow database is still a slow workflow. Queue and Event Hub workloads need tuning around batch size, partitioning, retries, and poison handling. HTTP functions need attention to startup, connection reuse, and response time. Premium or always-ready patterns can reduce cold-start impact. Operators should measure execution duration, failures, dependency calls, memory use, and first-request latency after deployments instead of assuming serverless automatically means fast. These measurements make tuning concrete instead of relying on serverless assumptions.
- Operations
- Operators inspect Azure Functions through the function app resource, Application Insights, deployment history, app settings, identity configuration, networking, scale behavior, and trigger-specific queues or topics. Day-two work includes checking failed executions, restart history, runtime version, extension bundle behavior, storage dependencies, and recent deployments. CLI is useful for pulling app settings, listing functions, confirming managed identity, and restarting a stuck app after approval. Good runbooks name the event source, downstream dependency, retry policy, owner, and rollback path. Without those details, support teams waste time guessing whether the issue is code, trigger configuration, or platform scale. Teams should also record trigger names and sample correlation IDs for faster triage.
Common mistakes
- Treating queue processing as exactly-once and writing non-idempotent code that corrupts records after retries.
- Leaving secrets in app settings or ZIP packages instead of using managed identity and Key Vault references.
- Choosing a hosting plan without testing cold start, timeout limits, dependency latency, and expected burst volume.
Copied command