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
| Feature | Consumption | Premium (EP) | Dedicated (ASP) | Container Apps |
|---|---|---|---|---|
| Scale to zero | ✅ | ❌ (min 1) | ❌ | ✅ |
| Max timeout | 10 min | 60 min+ | Unlimited | 30 min |
| VNet integration | ❌ | ✅ | ✅ (Std+) | ✅ |
| Always-ready instances | ❌ | ✅ | ✅ | ❌ |
| Max scale-out | 200 | 100 | 10–30 | 300 |
| Billing | Per execution | Per vCPU-s + pre-warmed | Fixed ASP cost | Per vCPU-s |
| Cold start | Significant | Minimal (pre-warmed) | None | Moderate |
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
.funcignoreto 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
- HTTP-triggered Function (Premium EP1): Receives order, validates schema, drops message to Service Bus queue.
- Durable Orchestrator: Queue-triggered, runs chained activities: validate inventory → charge payment → reserve stock → create shipment.
- Fan-out: Parallel notifications — email confirmation, SMS, push notification, analytics event.
- 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+.