Coder Legion - Recent posts tagged azurefunctions

Multi-Cloud Resilience: The Event-Driven Cellular Architecture Blueprint across AWS and Azure

Sat, 02 May 2026 12:42:02 +0000

1. Introduction

As enterprise systems reach massive scale, relying on a single cloud provider introduces systemic risk. Regional outages, vendor-specific API degradations, or severe misconfigurations can result in global downtime. Multi-cloud cellular architecture solves this by deploying isolated, self-contained failure domains (cells) across different cloud providers. In this tutorial, you will architect a unified, event-driven system where AWS and Azure serve as the physical hosts for identical logical cells.

Instead of building a "stretched" application that queries data across clouds—an anti-pattern that guarantees high latency and fragile dependencies—you will deploy complete, asynchronous processing pipelines on both AWS and Azure. A global, cloud-agnostic edge routing layer will inspect incoming traffic and forward it to either an AWS cell or an Azure cell based on a partition key (such as TenantId). By the end of this guide, you will understand how to orchestrate this ultimate fault-isolation boundary using Terraform, ensuring your application survives even a total cloud provider outage.

2. Prerequisites

To build a multi-cloud environment, your operational tooling must be strictly cloud-agnostic. You will need:

Active accounts on both Amazon Web Services (AWS) and Microsoft Azure with administrative privileges.
The AWS CLI and Azure CLI installed and authenticated on your local machine.
Terraform (version 1.3.0 or higher) installed. Terraform is crucial here, as it is the singular control plane capable of deploying resources to both clouds simultaneously.
Understanding of Global Server Load Balancing (GSLB) or Edge Compute platforms (like Cloudflare Workers or Fastly) to act as the multi-cloud router.
A Domain-Driven Design (DDD) approach to your data, ensuring that a specific tenant's data lives entirely within one cell and never needs to cross the multi-cloud boundary.

3. Step-by-Step

Step 1: Configuring Multi-Cloud Providers in Terraform

What to do: Create a root Terraform configuration that initializes providers for both AWS and Azure simultaneously.

Why do it: Infrastructure as Code (IaC) is the only sustainable way to manage multi-cloud environments. By declaring both providers in the same root module, you can orchestrate the deployment of AWS cells, Azure cells, and the DNS records that tie them together from a single pipeline, preventing configuration drift between your cloud environments.

Code Example (main.tf):

terraform {
  required_version = ">= 1.3.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

provider "azurerm" {
  features {}
}

Step 2: Deploying the AWS and Azure Data Plane Cells

What to do: Utilize the modular approach to instantiate independent cells on both clouds. The AWS cell utilizes DynamoDB, SNS, and SQS. The Azure cell utilizes Cosmos DB, Service Bus Topics, and Subscriptions. Both rely on serverless compute (Lambda and Azure Functions).

Why do it: While the underlying managed services differ, the architectural pattern is identical: an HTTP entry point writes to a NoSQL database, which triggers a change stream, which is fanned out via a message bus to consumer workers. Encapsulating these into Terraform modules abstracts the cloud-specific complexities, allowing you to treat "AWS" and "Azure" simply as deployment targets for your business logic.

Code Example (data_plane.tf):

# AWS Cell (East Coast)
module "cell_aws_alpha" {
  source  = "./modules/aws_event_cell"
  cell_id = "aws-alpha"
  region  = "us-east-1"
}

# Azure Cell (East Coast)
module "cell_azure_beta" {
  source   = "./modules/azure_event_cell"
  cell_id  = "azure-beta"
  location = "East US"
}

# Azure Cell (Europe)
module "cell_azure_gamma" {
  source   = "./modules/azure_event_cell"
  cell_id  = "azure-gamma"
  location = "North Europe"
}

Step 3: Implementing the Cloud-Agnostic Edge Router

What to do: Deploy a global routing layer that sits entirely outside of AWS and Azure. This is typically achieved using an Edge Compute platform like Cloudflare Workers. The Worker intercepts the HTTP request, reads the TenantId, checks a globally distributed Key-Value store to find the assigned cell's API endpoint, and forwards the payload.

Why do it: If your global router is hosted on AWS (e.g., using API Gateway), and AWS experiences an outage, your Azure cells become unreachable, defeating the purpose of multi-cloud. The routing layer must be cloud-agnostic. Cloudflare Workers execute at the edge, providing sub-millisecond lookups for the routing map and directing traffic to the respective AWS API Gateway or Azure Function HTTP trigger.

Conceptual Edge Router Logic (JavaScript for Edge Worker):

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const tenantId = request.headers.get("X-Tenant-ID");

    if (!tenantId) {
      return new Response("Missing Tenant ID", { status: 400 });
    }

    // Lookup cell assignment from global edge KV store
    const cellEndpoint = await env.ROUTING_MAP.get(tenantId);

    if (!cellEndpoint) {
      return new Response("Tenant mapping not found", { status: 404 });
    }

    // Proxy the request to the target cloud (AWS or Azure)
    const targetUrl = new URL(url.pathname, cellEndpoint);
    const modifiedRequest = new Request(targetUrl, request);
    
    return fetch(modifiedRequest);
  }
}

Step 4: Automating Disaster Recovery and Traffic Shifting

What to do: Establish a process to update the global routing map. If the AWS region hosting cell_aws_alpha goes offline, you update the Edge KV store to point those affected tenants to a standby cell on Azure.

Why do it: Cellular architecture drastically reduces the blast radius of an outage, but you still need a mechanism to restore service for the degraded cell. By decoupling the routing logic from the compute infrastructure, shifting traffic between clouds becomes a simple Key-Value update at the DNS/Edge layer, resulting in near-instantaneous failover.

4. Common Troubleshooting

The Multi-Cloud Data Split Brain: The biggest mistake in multi-cloud architecture is attempting synchronous database replication between AWS and Azure. This introduces severe latency and massive egress costs. Ensure strict cellular isolation: a tenant's data must live and be processed entirely within their assigned cell. Data should only cross clouds during a deliberate, asynchronous disaster recovery migration.
CI/CD Pipeline Complexity: Deploying to multiple clouds means your deployment pipelines must authenticate with two different IAM systems. Utilize OpenID Connect (OIDC) in platforms like GitHub Actions or GitLab CI. OIDC allows your pipelines to assume temporary, secure roles in both AWS (via IAM Identity Center) and Azure (via Microsoft Entra Workload ID) without storing long-lived, vulnerable access keys.
Observability Fragmentation: AWS logs live in CloudWatch; Azure logs live in Log Analytics. Troubleshooting a multi-cloud environment requires a unified view. You must export logs and metrics from both cloud providers into a centralized, agnostic observability platform (like Datadog, New Relic, or a self-hosted ELK stack) to effectively monitor the health of your global cells.

5. Conclusion

Building an event-driven cellular architecture across multiple clouds is the pinnacle of infrastructure resilience. By treating AWS and Azure as interchangeable hosts for isolated data planes, and governing them with a cloud-agnostic edge router and Terraform, you eliminate single points of failure at the vendor level. While this approach introduces operational complexity, it guarantees that a regional outage or provider degradation remains a contained incident rather than a business-ending catastrophe. As a next step, focus on standardizing your application packaging by utilizing containers (ECS on AWS, Container Apps on Azure) to ensure your worker code executes identically regardless of the host cloud.

Your First Azure Function: HTTP Triggers Step-by-Step

Fri, 13 Feb 2026 07:31:47 +0000

Theory doesn't ship features. You learned the why in Part 1—when serverless makes sense, the economics, how it compares to App Service and Container Apps. Now let's build something.

In this second part of the Azure Functions for .NET Developers series, we'll create a project from scratch, understand every line of generated code, and build three HTTP trigger patterns that cover most real-world API scenarios. By the end, you'll have a working HTTP API running locally on your machine. No Azure subscription required.

All code from this article is available in the azure-functions-samples repository.

Prerequisites

You need four tools installed before we start. Here's what to check and where to get them:

Tool	Verify	Expected
.NET 10 SDK	`dotnet --version`	10.x
Azure Functions Core Tools	`func --version`	4.x
VS Code + Azure Functions extension	—	Latest
Azurite	`npx azurite --version`	Any

.NET 10 SDK is required to build and run our function app. It's an LTS release, supported through November 2028. Grab it from dot.net/download if you don't have it.

Azure Functions Core Tools v4 lets you create, run, and debug functions locally. Install via npm, Homebrew, or Chocolatey:

# npm (any OS)
npm install -g azure-functions-core-tools@4

# Homebrew (macOS)
brew tap azure/functions
brew install azure-functions-core-tools@4

# Chocolatey (Windows)
choco install azure-functions-core-tools-4

VS Code with the Azure Functions extension gives you project templates, debugging, and deployment in one place. Visual Studio and Rider work too—use whatever you're comfortable with. The CLI commands in this article work regardless of editor.

Azurite emulates Azure Storage locally. The Functions runtime needs a storage connection even for HTTP triggers (it uses storage internally for features like function key management and, in production, for coordinating across instances). Install it globally or run it on demand:

# Install globally
npm install -g azurite

# Or run on demand without installing
npx azurite

If the verification commands all return version numbers and you have VS Code with the Azure Functions extension installed, you're ready.

Creating Your First Project

With your tools in place, open a terminal and scaffold a new function app:

func init HttpTriggerDemo --worker-runtime dotnet-isolated --target-framework net10.0
cd HttpTriggerDemo
func new --template "HTTP trigger" --name Hello

The first command creates the project. --worker-runtime dotnet-isolated selects the isolated worker model (the modern default—we'll explain what "isolated" means in Part 5). --target-framework net10.0 targets .NET 10.

Once inside the project directory, func new adds an HTTP-triggered function called Hello from a built-in template.

Your project now looks like this:

HttpTriggerDemo/
├── Hello.cs              # Your function code
├── Program.cs            # Application entry point
├── HttpTriggerDemo.csproj # Project file
├── host.json             # Runtime configuration
└── local.settings.json   # Local environment variables

The Project File

Open HttpTriggerDemo.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <OutputType>Exe</OutputType>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="2.51.0" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.7" />
    <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="2.1.0" />
  </ItemGroup>
</Project>

A few things to note:

OutputType: Exe — the isolated worker model runs as a standalone executable, not a class library loaded into the Functions host. This is what gives you full control over the process.
FrameworkReference: Microsoft.AspNetCore.App — brings in ASP.NET Core types like HttpRequest and IActionResult. Without this, you'd use the lower-level HttpRequestData API.
Extensions.Http.AspNetCore — the bridge that maps ASP.NET Core's HTTP abstractions to the Functions runtime. This is what makes the developer experience feel like writing a regular web API.
ImplicitUsings: enable — the compiler automatically includes common using statements (System, System.Collections.Generic, System.Linq, System.Threading.Tasks, and others). That's why our code files don't start with a block of using directives.
Nullable: enable — turns on nullable reference types. The compiler warns you when code might dereference null without checking. You'll see this in action when we read query string values—req.Query["name"] returns string?, not string.

The Entry Point

Program.cs is minimal:

using Microsoft.Azure.Functions.Worker.Builder;

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Build().Run();

ConfigureFunctionsWebApplication() is the key line. It enables ASP.NET Core integration—without it, you'd need to use HttpRequestData and HttpResponseData instead of the familiar HttpRequest and IActionResult. For HTTP-triggered functions, this is almost always what you want.

FunctionsApplication.CreateBuilder(args) is a convenience factory introduced in Worker SDK 2.0. It returns a pre-configured IHostApplicationBuilder with Functions defaults already wired up—logging, JSON serializer options, and middleware. The key using to remember is Microsoft.Azure.Functions.Worker.Builder, which brings the factory method into scope. You may also see an older pattern that starts with new HostBuilder() and calls .ConfigureFunctionsWorkerDefaults()—it still works, but requires more manual setup (for example, explicit ConfigureAppConfiguration() calls to load appsettings.json). func init scaffolds FunctionsApplication.CreateBuilder by default, so stick with it for new projects.

This is also where you'd register services for dependency injection, add middleware, or configure logging. We'll keep it simple for now.

Understanding the Generated Code

With the project structure in place, let's look at the function itself. The func new command created a file called Hello.cs with a complete working function. Before we run it, let's understand what each part does. Open Hello.cs:

public class Hello(ILogger<Hello> logger)
{
    [Function("Hello")]
    public IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req)
    {
        logger.LogInformation("C# HTTP trigger function processed a request.");
        return new OkObjectResult("Welcome to Azure Functions!");
    }
}

Let's break this apart.

public class Hello(ILogger<Hello> logger) uses a C# 12 primary constructor. The ILogger<Hello> parameter is injected by the dependency injection container automatically—no need to write a separate constructor or field assignment. The logger is available throughout the class.

[Function("Hello")] registers this method with the Functions runtime. The string "Hello" becomes the function's name and appears in the URL path: http://localhost:7071/api/Hello. If you rename the class but keep the attribute string the same, the URL stays the same.

[HttpTrigger(AuthorizationLevel.Function, "get", "post")] is where the behavior is defined:

AuthorizationLevel.Function means callers need a function-specific API key to invoke this endpoint. Other options are Anonymous (no key required) and Admin (requires the master host key). When running locally, authorization is bypassed regardless of the level you set.
"get", "post" lists the allowed HTTP methods. Requests using other methods receive a 405 Method Not Allowed.

HttpRequest req is the full ASP.NET Core request object. Query strings, headers, body, route values—it's all there. If you've written ASP.NET Core controllers or minimal APIs, this is the same type.

IActionResult is the return type. OkObjectResult maps to a 200 response. The runtime serializes the object to JSON (or returns it as plain text for strings) and sends it back to the caller. All the familiar result types work: BadRequestResult, NotFoundResult, CreatedResult, and so on.

Run It

Before we modify anything, let's see this function in action. Start Azurite in a separate terminal (or in the background):

npx azurite --silent --location /tmp/azurite &

Then start the Functions runtime from your project directory:

func start

You should see output listing your function's URL:

Functions:

        Hello: [GET,POST] http://localhost:7071/api/Hello

Test it in another terminal:

curl http://localhost:7071/api/Hello
# → Welcome to Azure Functions!

That's a working HTTP endpoint, running locally, no Azure subscription needed. Keep func start running—we'll build on this function next.

HTTP Trigger Deep Dive

With a running function under your belt, let's build three patterns that cover the majority of real-world HTTP function scenarios. After each change, stop func start with Ctrl+C and restart it to pick up the new code.

Pattern 1: GET with Query String

The simplest pattern—read a value from the URL and return a response:

public class HelloFunction(ILogger<HelloFunction> logger)
{
    [Function("Hello")]
    public IActionResult Run(
        [HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
    {
        logger.LogInformation("Hello function triggered");

        string? name = req.Query["name"];
        return new OkObjectResult($"Hello, {name ?? "world"}!");
    }
}

req.Query["name"] reads the name parameter from the query string. If it's missing, the value is null, so we fall back to "world" with the null-coalescing operator. Note the string? — the query collection returns a nullable type, and with <Nullable>enable</Nullable> in the project file, the compiler enforces this.

Test it:

curl "http://localhost:7071/api/Hello?name=Azure"
# → Hello, Azure!

curl "http://localhost:7071/api/Hello"
# → Hello, world!

This pattern works well for simple lookups—search queries, filtering lists, or any GET request where the parameters are short and cacheable.

Pattern 2: POST with JSON Body

For creating or updating resources, you'll typically accept a JSON request body. C# records and ASP.NET Core model binding make this clean:

using FromBodyAttribute = Microsoft.Azure.Functions.Worker.Http.FromBodyAttribute;

public record CreateOrderRequest(string ProductId, int Quantity);

public class OrderFunction(ILogger<OrderFunction> logger)
{
    [Function("CreateOrder")]
    public IActionResult CreateOrder(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "orders")] HttpRequest req,
        [FromBody] CreateOrderRequest order)
    {
        logger.LogInformation("Order for {ProductId} x{Quantity}", order.ProductId, order.Quantity);
        return new CreatedResult($"/orders/{Guid.NewGuid()}", order);
    }
}

Several things happening here:

record CreateOrderRequest defines an immutable data type. Records are ideal for request and response DTOs—they give you value equality, a clean ToString(), and immutability out of the box. No need to write a class with properties and a constructor.

[FromBody] CreateOrderRequest order tells the ASP.NET Core model binder to deserialize the JSON request body into a CreateOrderRequest instance. If the JSON doesn't match (missing required fields, wrong types), the runtime returns a 400 Bad Request automatically. One gotcha: with ASP.NET Core integration enabled, FromBody exists in two namespaces—Microsoft.Azure.Functions.Worker.Http and Microsoft.AspNetCore.Mvc. You need the Functions Worker version. The using alias at the top of the file resolves the ambiguity so you can use [FromBody] without a fully qualified name.

Route = "orders" overrides the default route. Without it, the URL would be /api/CreateOrder (derived from the function name). With it, the URL becomes /api/orders—cleaner and more RESTful.

CreatedResult returns HTTP 201 with a Location header pointing to the new resource. Standard REST semantics.

Test it:

curl -X POST http://localhost:7071/api/orders \
  -H "Content-Type: application/json" \
  -d '{"productId":"SKU-001","quantity":3}'
# → {"productId":"SKU-001","quantity":3}
# (with 201 status and Location header)

The Content-Type: application/json header is required. Without it, model binding won't kick in and you'll get a deserialization error.

Pattern 3: Route Parameters

For resource-oriented APIs, you'll want parameters embedded in the URL path rather than the query string:

public class ProductFunction(ILogger<ProductFunction> logger)
{
    [Function("GetProduct")]
    public IActionResult GetProduct(
        [HttpTrigger(AuthorizationLevel.Function, "get",
            Route = "products/{category:alpha}/{id:int?}")] HttpRequest req,
        string category, int? id)
    {
        logger.LogInformation("Looking up {Category}, id={Id}", category, id);
        return new OkObjectResult(new { category, id });
    }
}

Route parameters are defined in curly braces inside the Route string and captured as method parameters matched by name. The runtime extracts category and id from the URL and passes them directly to your method.

Route constraints validate parameters before your code runs:

Constraint	Meaning	Example
`:alpha`	Letters only	`electronics` matches, `123` doesn't
`:int`	Integer	`42` matches, `abc` doesn't
`:int?`	Optional integer	Parameter can be omitted
`:guid`	GUID format	`{id:guid}`
`:length(5)`	Exact string length	`{code:length(5)}`
`:min(1)`	Minimum integer value	`{page:min(1)}`

If a constraint fails, the runtime returns a 404—your function never executes.

Test it:

curl http://localhost:7071/api/products/electronics/42
# → {"category":"electronics","id":42}

curl http://localhost:7071/api/products/electronics
# → {"category":"electronics","id":null}

curl http://localhost:7071/api/products/123/42
# → 404 (constraint :alpha rejects "123")

You now have three working patterns that cover most real-world HTTP function scenarios.

Running and Testing Locally

Restart func start now that all three functions are in place. You should see all of them listed:

Azure Functions Core Tools
Core Tools Version: 4.6.0

Functions:

        CreateOrder: [POST] http://localhost:7071/api/orders

        GetProduct: [GET] http://localhost:7071/api/products/{category:alpha}/{id:int?}

        Hello: [GET] http://localhost:7071/api/Hello

For quick reference, here are all three test commands together:

# Pattern 1: GET with query string
curl "http://localhost:7071/api/Hello?name=Azure"

# Pattern 2: POST with JSON body
curl -X POST http://localhost:7071/api/orders \
  -H "Content-Type: application/json" \
  -d '{"productId":"SKU-001","quantity":3}'

# Pattern 3: Route parameters
curl http://localhost:7071/api/products/electronics/42

You can also use Postman, the REST Client extension for VS Code, or HTTPie—whatever fits your workflow.

A note on authorization: when running locally, AuthorizationLevel.Function is bypassed. You don't need to pass a function key. This makes local development frictionless. Once deployed, clients will need to include the key as a query parameter (?code=<key>) or in the x-functions-key header.

Troubleshooting

If things don't work on the first try, check these common issues:

"Can't determine project language" or "No job functions found"

The .csproj file is missing required settings. Verify it targets net10.0, has <AzureFunctionsVersion>v4</AzureFunctionsVersion>, and includes the Worker SDK packages. Run dotnet build separately to check for compilation errors.

Port 7071 already in use

Another Functions host (or another process) is using the default port. Either kill it or start on a different port:

func start --port 7072

"Value cannot be null: provider" or storage connection errors

Azurite isn't running. The Functions runtime needs a storage emulator even for HTTP triggers. Start Azurite, or verify that local.settings.json contains:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

UseDevelopmentStorage=true tells the SDK to connect to Azurite on its default ports.

JSON deserialization errors on POST requests

Two common causes: missing the Content-Type: application/json header, or property name mismatches between your JSON and your C# record. By default, the serializer is case-insensitive, so productId and ProductId both work. But the property names must exist on the target type.

"The listener for function X was unable to start"

Usually a runtime version mismatch. Confirm func --version returns 4.x and your .csproj has <AzureFunctionsVersion>v4</AzureFunctionsVersion>. If you recently upgraded the Core Tools, also run dotnet clean and rebuild.

Conclusion

We went from an empty directory to a running HTTP API with three production patterns:

Query strings for simple reads (GET /api/Hello?name=Azure)
JSON bodies for mutations (POST /api/orders)
Route parameters for resource-oriented endpoints (GET /api/products/electronics/42)

All running locally, no Azure subscription needed.

The isolated worker model with ASP.NET Core integration gives you familiar types—HttpRequest, IActionResult, [FromBody]—so writing Azure Functions feels like writing any other .NET web API. The main difference is that Azure handles the hosting, scaling, and infrastructure.

The code samples in this article are deliberately simple. In a real project, you'd add input validation, error handling, and probably connect to a database or external service. But the patterns are the same—the [HttpTrigger] attribute, the route configuration, the model binding. Once you understand these building blocks, everything else is regular C#.

All code from this article is available in the azure-functions-samples repository—clone it, run func start, and experiment.

What's Next in This Series

Part 3: Beyond HTTP Triggers (coming soon) covers timer triggers for scheduled jobs, queue triggers for message processing, and blob triggers for reacting to file uploads. Same project structure, new event sources.

Part 4: Local Development Setup (coming soon) digs into the day-to-day workflow—debugging in VS Code, hot reload, and productivity tips.

Part 5: Understanding the Isolated Worker Model (coming soon) explains what "isolated" means, why Microsoft created this model, how it differs from the legacy in-process model, and what it means for your code.

And yes—we'll cover deploying to Azure with CI/CD via GitHub Actions later in the series, so everything you're building locally will make it to the cloud.

Why Azure Functions? Serverless for .NET Developers

Wed, 11 Feb 2026 07:29:29 +0000

You've just finished building a webhook handler. Maybe fifty lines of code—parse some JSON, hit a database, return a response. Now comes the fun part: provisioning a VM, configuring IIS, setting up SSL certificates, writing health checks, and figuring out how to scale when traffic spikes at 3 AM. Sound familiar?

This is the problem serverless computing solves. Instead of managing infrastructure, you write the code that matters—your business logic—and let the platform handle everything else. In 2026, with cloud costs under constant scrutiny, the pay-per-execution model makes even more sense: why pay for idle servers when you can pay only for the milliseconds your code actually runs?

For .NET developers, Azure Functions has matured into a first-class serverless platform. The isolated worker model, combined with .NET 10's performance improvements, means you get the full power of modern .NET without compromise.

Every major cloud provider offers a serverless compute platform—AWS has Lambda, Google Cloud has Cloud Functions. For .NET developers, Azure Functions is the most natural choice: first-class support in the .NET SDK, seamless integration with Visual Studio and Rider, and deep ties to the broader Azure ecosystem you're likely already using. If your team runs on .NET, you won't fight the tooling here.

In this series, we'll explore Azure Functions from the ground up—when to use them, how they work, and the patterns that make serverless development practical. Let's start with the fundamentals.

What Azure Functions Actually Is

Azure Functions is Microsoft's event-driven serverless compute service. Instead of managing servers or worrying about infrastructure, you write small, focused pieces of code that run in response to events. Azure handles scaling, patching, and availability automatically.

Triggers: What Starts Your Code

A trigger defines what event causes your function to execute. Common triggers include:

HTTP Trigger - Respond to web requests (APIs, webhooks)
Timer Trigger - Run on a schedule (cron expressions)
Service Bus Trigger - Process messages from queues or topics
Cosmos DB Trigger - React to document changes in your database
Blob Trigger - Execute when files are uploaded to storage

Bindings: Declaring Inputs and Outputs

Bindings connect your function to other Azure services declaratively. Instead of writing SDK code to read from a queue or write to a database, you declare the connection through attributes—and Azure Functions handles the plumbing.

There are two types:

Input bindings - Read data when your function executes (e.g., fetch a document from Cosmos DB, read a blob from storage)
Output bindings - Write data after your function completes (e.g., add a message to a queue, insert a row into Table Storage)

Your function's return value can serve as an output binding directly. Return an object, and Azure Functions writes it to the configured destination—no explicit SDK calls needed.

Your First Function

Here's a minimal HTTP-triggered function using the .NET 10 isolated worker model:

public class HelloFunction(ILogger<HelloFunction> logger)
{
    [Function("Hello")]
    public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
    {
        logger.LogInformation("Processing request");
        return new OkObjectResult("Hello from Azure Functions!");
    }
}

The [HttpTrigger] attribute defines this as an HTTP GET endpoint with function-level authentication (we'll cover authentication levels in the next article). The OkObjectResult you return becomes the HTTP response sent back to the caller—Azure Functions maps ASP.NET Core's familiar result types to actual HTTP responses for you. That's all you need to deploy a working API endpoint.

When to Use Azure Functions (and When Not To)

Azure Functions excels in specific scenarios, but it's not a universal solution. Here's an honest breakdown to help you choose wisely.

Where Functions Shine

APIs with unpredictable traffic. If your endpoint gets 100 requests one hour and 10,000 the next, you pay only for what you use. No idle VMs burning budget overnight.

Event-driven workloads. Processing messages from Service Bus, reacting to blob uploads, or handling Event Grid notifications—Functions integrates natively with Azure's eventing ecosystem. A few lines of code and you're processing events at scale.

Scheduled jobs. Timer triggers replace fragile cron servers. Need to clean up stale data every night or send weekly reports? Functions handles the scheduling infrastructure for you.

Glue code between services. Moving data from one system to another, transforming payloads, or orchestrating simple workflows—Functions keeps these small integrations from becoming maintenance burdens.

Prototypes and MVPs. When validating an idea quickly, Functions lets you ship without configuring infrastructure. You can always migrate to containers later.

When to Look Elsewhere

Latency-critical paths. Cold starts on the Consumption plan can add seconds of delay. If you need consistent sub-10ms response times, consider App Service or Container Apps with always-on instances.

Long-running processes. The 10-minute timeout (or 230 seconds on HTTP triggers) won't work for heavy batch processing. Look at Durable Functions for orchestration or Container Apps Jobs for extended compute.

Heavy, sustained compute. If you're running CPU-intensive workloads continuously, reserved container instances often cost less than millions of function executions.

Stateful applications. WebSocket connections, in-memory caches, or persistent sessions don't fit the ephemeral Functions model.

A Note on Cost Protection

Pay-per-execution pricing has a flip side: you pay for every request, including malicious ones. A DDoS attack against an unprotected Function endpoint means you're footing the bill for traffic you never wanted.

For public-facing APIs, consider these safeguards:

Azure API Management — rate limiting, throttling, and request quotas
Azure Front Door or Application Gateway — WAF rules and DDoS protection
Function authorization levels — AuthorizationLevel.Function or AuthorizationLevel.Admin require keys, blocking anonymous traffic

The Consumption plan's cost model works best when you control who can call your endpoints. For truly public APIs expecting untrusted traffic, budget for a protection layer—or consider the Premium plan's predictable pricing.

Quick Comparison: Functions vs App Service vs Container Apps

Choosing the right Azure compute option can significantly impact your costs and application architecture. Here's how Azure Functions stacks up against the other popular choices for .NET workloads:

Feature	Azure Functions	App Service	Container Apps
Scale trigger	Events (HTTP, queue, timer)	CPU/memory rules	Events (KEDA), CPU/memory
Pricing	Pay-per-execution*	Fixed/reserved	Per-resource (vCPU/memory)
Cold starts	Yes (Consumption)	No	Configurable
Scale-out limit	200 (Consumption) / 1,000 (Flex)	Up to 30 instances	300–1,000 replicas
Best for	Event-driven, APIs	Web apps, APIs	Microservices

\Consumption plan. Premium and Dedicated plans use fixed or memory/CPU-based pricing, similar to Container Apps.*

Choose Azure Functions when you have event-driven workloads, sporadic traffic patterns, or want to minimize costs for low-volume APIs. Opt for App Service when you need predictable performance without cold starts for traditional web applications. Consider Container Apps when building microservices architectures that require more control over the runtime environment while still benefiting from managed scaling.

A Note on .NET 10

Throughout this series, we'll use .NET 10 with the isolated worker model—the recommended stack for new Azure Functions projects. It's an LTS release (supported through November 2028) and gives you full ASP.NET Core integration with familiar types like HttpRequest and IActionResult. We'll cover the setup in Part 2 and what "isolated worker model" means in detail in Part 5.

What's Next in This Series

This article covered the "why" of Azure Functions—now it's time for the "how." Over the next several parts, we'll build real-world skills you can apply immediately.

Part 2: Your First Azure Function — HTTP Triggers Step-by-Step (coming soon) walks through project creation, running locally, and testing with curl. You'll have a working HTTP endpoint in minutes.

Part 3: Beyond HTTP Triggers (coming soon) explores timer, queue, and blob triggers—the event-driven patterns that make Functions powerful.

Part 4: Local Development Setup (coming soon) covers the tools, debugging techniques, and productivity tips that make daily development smooth.

Part 5: Understanding the Isolated Worker Model (coming soon) explains the architecture behind modern Azure Functions—why Microsoft created it, how it works, and what it means for your code.

Part 6: Production Realities — When Serverless Stops Being Serverless (coming soon) covers what actually happens when enterprise requirements like VNet integration and private endpoints push you off the Consumption plan—and when to consider alternatives.

Conclusion

Azure Functions has become a practical choice for .NET developers who want to ship features without managing infrastructure. The isolated worker model with .NET 10 gives you modern language features, familiar patterns, and genuine pay-per-use economics.

Start small. Create an HTTP-triggered function, deploy it to Azure, and see how quickly you can go from code to production. The barrier to entry has never been lower.

Follow this series to build your serverless skills step by step. Next up: setting up your development environment and deploying your first function. Let's build something.