1. Serverless Principles

  • Event-driven execution — code runs in response to triggers, not continuously polling.
  • Pay-per-execution — billed per invocation + GB-s of memory used. Zero traffic = zero cost.
  • Auto-scale to zero — no idle compute. Scales out automatically under load (up to 200 instances on Consumption).
  • Stateless by default — each invocation is independent. Use Durable Functions for stateful orchestration.
🎯 Exam Tip: AZ-305 loves asking when Consumption plan is not appropriate — look for requirements like VNet integration, predictable latency, or execution >10 minutes.

2. Hosting Plans Compared

FeatureConsumptionPremium (EP)Dedicated (ASP)Container Apps
Scale to zero❌ (min 1)
Max timeout10 min60 min+Unlimited30 min
VNet integration✅ (Std+)
Always-ready instances
Max scale-out20010010–30300
BillingPer executionPer vCPU-s + pre-warmedFixed ASP costPer vCPU-s
Cold startSignificantMinimal (pre-warmed)NoneModerate

3. Triggers & Bindings

Triggers invoke the function; bindings connect to data sources declaratively (no SDK boilerplate).

  • Queue → Cosmos DB: Process orders from Service Bus, write to Cosmos.
  • Blob → Queue: Image uploaded triggers resize, output message for next step.
  • Event Grid → Blob + SignalR: React to resource events, notify connected clients.
  • HTTP → Table Storage: Lightweight CRUD APIs without ORM overhead.

4. Durable Functions Patterns

Key Patterns

  • Function chaining: A1 → A2 → A3 sequentially. Each activity can retry independently.
  • Fan-out/Fan-in: Spawn N parallel activities, wait for all to complete. E.g., process 100 images concurrently.
  • Human interaction: Orchestrator pauses, sends approval request, waits for external event (with timeout).
  • Monitor: Polling loop with configurable interval — replaces timer-triggered functions for long-running checks.
  • Eternal orchestrations: Infinite loops with ContinueAsNew() to prevent history growth.

5. Cold Start & Mitigation

Cold start = time to allocate a worker, load the runtime, and initialize your app. Ranges from 1–10+ seconds depending on language and dependencies.

Mitigation Strategies

  • Premium plan always-ready: Pre-warmed instances eliminate cold start entirely. Set minimum instance count.
  • Smaller packages: Trim dependencies; use .funcignore to exclude dev files.
  • Language choice: C# (in-process) and JavaScript start faster than Java. .NET isolated has slightly longer starts.
  • Avoid heavy constructors: Lazy-load connections; use dependency injection singletons.
  • HTTP warmup triggers: Configure health-check pings in Premium to keep instances hot.

6. Networking & Security

  • VNet integration (Premium/Dedicated): Outbound traffic routes through your VNet — access private databases, storage via service/private endpoints.
  • Private endpoints: Inbound traffic restricted to VNet. No public IP exposed.
  • Service endpoints: Lock down storage/Cosmos to VNet traffic only.
  • NAT gateway: Fixed outbound IP for firewall allowlisting (attach to integration subnet).
🎯 Exam Tip: Consumption plan does NOT support VNet integration. If the scenario requires private connectivity, the answer is Premium or Dedicated — never Consumption.

7. When NOT to Use Functions

  • Long-running processes >10 min (use Durable Functions or Container Apps instead).
  • Stateful real-time connections (WebSockets) — use App Service or SignalR Service.
  • High-throughput, constant-load APIs — Dedicated compute is cheaper at 100% utilization.
  • Complex multi-container apps — use AKS or Container Apps.
  • Workloads needing GPU/specialized hardware.

8. Real-World: Event-Driven Order Processing Pipeline

📋 Scenario

An e-commerce platform processes 50K orders/day with spikes to 5K/min during flash sales. Orders must be validated, payment charged, inventory updated, and shipping initiated — all within 30 seconds.

✅ Solution Architecture

  1. HTTP-triggered Function (Premium EP1): Receives order, validates schema, drops message to Service Bus queue.
  2. Durable Orchestrator: Queue-triggered, runs chained activities: validate inventory → charge payment → reserve stock → create shipment.
  3. Fan-out: Parallel notifications — email confirmation, SMS, push notification, analytics event.
  4. Dead-letter handling: Separate function monitors DLQ, raises alerts, retries with exponential backoff.

Why Premium?

  • VNet integration to reach private payment gateway and inventory database.
  • Always-ready instances (min 3) eliminate cold start during flash sales.
  • Scales to 100 instances for burst capacity.
  • 60-minute timeout for complex orchestrations with human approval (high-value orders).

Summary

  • Consumption: Best for sporadic, short-lived workloads. No VNet, 10-min timeout, cold starts.
  • Premium: Enterprise choice — VNet, pre-warmed, 60-min timeout. Still event-driven billing (partially).
  • Durable Functions: Stateful orchestration without managing state infrastructure. Use for chaining, fan-out, and human-in-the-loop.
  • Triggers + bindings: Declarative I/O reduces boilerplate. One function, one trigger, many bindings.
  • Networking: VNet integration = outbound private access. Private endpoints = inbound restriction. Both require Premium+.

Knowledge Check