Microsoft Azure Services and Architecture Questions

Direct answer

The query below finds the top 5 resources by Error-level log count in the AzureDiagnostics table over the last 24 hours, with each resource's count and its percentage of the total error volume in that window. Grouping is done by the _ResourceId column (the resource's full ARM ID), which is the column that actually uniquely identifies a specific resource in this table; the more commonly guessed ResourceId is not the real column name.

Structured elaboration: approach and query

let window = 24h;
let errors = AzureDiagnostics
    | where TimeGenerated >= ago(window)
    | where Level == "Error";
let totalErrors = toscalar(errors | count);
errors
| summarize ErrorCount = count() by _ResourceId
| top 5 by ErrorCount desc
| extend PercentOfTotal = round(100.0 * ErrorCount / totalErrors, 2)
| project _ResourceId, ErrorCount, PercentOfTotal

Key points. The query computes totalErrors once with toscalar() over the whole 24-hour error set before grouping, so the percentage column is a true share of all errors in the window, not a share of just the top 5's combined count (a subtle but common mistake: computing the denominator only from the already-filtered top-5 rows instead of the full population). Level == "Error" is the correct filter for AzureDiagnostics because AzureDiagnostics is a shared table across many resource types that use "Azure Diagnostics mode" (Key Vault, Application Gateway, Azure Firewall, and others among them) and Level is one of the common columns present across that shared schema.

Edge cases. Not every resource that logs to AzureDiagnostics populates Level consistently; some resource types express severity differently (for example through a ResultType or a resource-specific status column instead), so this query only sees error volume for resource types that do populate Level, and a resource type that logs errors under a different column would silently show zero here rather than erroring out, which is worth checking with a quick AzureDiagnostics | where isnotempty(Level) | distinct ResourceType before relying on this query for a resource type you have not already confirmed uses Level. Also note that many Azure resource types have since moved to "resource-specific" diagnostic log tables instead of the shared AzureDiagnostics table (Microsoft's newer, recommended collection mode); a resource on resource-specific mode will not appear in AzureDiagnostics at all, so this query is scoped to whichever resources are still configured for Azure Diagnostics mode.

Worked example: converting this into an alert rule

1. Create a scheduled query rule (Microsoft.Insights/scheduledQueryRules) using this query (or a variant without the top 5, since an alert usually should not silently cap itself to 5 resources and miss a 6th one also spiking).
2. Set the evaluation frequency and lookback window much shorter than 24 hours for an alert (e.g. evaluate every 15 minutes over a 15-minute window), since a 24-hour rolling window is good for a daily report but far too slow to catch an emerging problem for paging purposes; keep the 24-hour version as a scheduled report/Workbook, not the live alert.
3. Configure the rule with "split by dimension" on _ResourceId so one rule definition fires a separate alert instance per resource that crosses the threshold, rather than one alert for "some resource somewhere is over threshold" that then requires a human to go re-run the query to find out which one.
4. Set the threshold as a count comparison, for example "number of rows with ErrorCount greater than a defined threshold, per resource, is greater than 0," and route the resulting alert to an action group scoped by resource type or owning team so the right people get paged.
5. Add a suppression window or a slightly higher threshold for any resource type known to log a noisy-but-harmless error pattern periodically, to avoid the alert becoming background noise the team starts ignoring.

Trade-offs and pitfalls

Because AzureDiagnostics is a shared, wide table across many resource types, a naive count() grouped only by _ResourceId conflates very different kinds of "errors" (a Key Vault access-denied event and an Application Gateway backend-health error look completely different in severity) into one ranked list; for anything beyond a first-pass triage view, also group by ResourceType or Category so the top-5 list distinguishes "many low-severity Key Vault throttling events" from "a handful of serious Application Gateway backend failures" rather than ranking them purely by raw count.

Direct answer

Reduce alert fatigue by making most alerts adaptive and grouped instead of static per-metric thresholds, reserving immediate, ungrouped, high-severity paging for the small set of signals that truly mean "a human must act right now." Concretely: use dynamic thresholds instead of hardcoded numbers wherever the metric has a predictable pattern, group related alerts so one incident produces one notification instead of twenty, assign a real severity scale and route only the top severities to paging, add suppression windows around known noisy periods (deploys, scheduled batch jobs), and attach an automated runbook to the alerts that have a known, safe first response so a human is only paged after automation has already tried the obvious fix.

Structured elaboration

Severity levels. Azure Monitor alerts carry a Sev0-Sev4 severity (0 = critical, 4 = verbose). The discipline that actually prevents fatigue is deciding, in advance and in writing, what each severity means operationally: Sev0/Sev1 pages a human immediately (production down, data loss risk); Sev2 opens a ticket and can wait for business hours; Sev3/Sev4 are dashboard-only or feed a weekly review. The failure mode this discipline avoids is a team that assigns everything Sev1 "to be safe," which is functionally identical to no severity scheme at all.

Dynamic thresholds. For metrics with daily/weekly seasonality (request rate, queue depth, checkout volume), a static "alert if over 1000/min" either fires constantly during normal peak traffic or misses a real anomaly during a normal trough. Azure Monitor's dynamic threshold alert type learns the metric's normal pattern over a rolling window and alerts on statistically significant deviation from that pattern, which tracks the metric's own seasonality automatically instead of requiring a human to keep tuning a fixed number every time traffic grows.

Alert grouping. A single root cause (a downstream dependency outage, a bad deploy) commonly trips many independent alert rules at once (elevated latency, elevated 5xx rate, elevated queue depth, a health-probe failure) which, ungrouped, is 4+ separate pages for one incident. Configure action group-level or alert-processing-rule grouping so correlated alerts within a short window collapse into one notification, and prefer designing alerts around symptoms a human would act on (elevated customer-facing error rate) over every internal signal that could theoretically indicate a problem.

Suppression windows. Alert processing rules can suppress notifications for a defined window (a deployment, a planned maintenance activity, a known-noisy nightly batch job) without disabling the underlying alert rule, so you keep the historical signal (useful for post-incident review) without paging anyone for a change you already know is happening.

Action groups and escalation. An action group should route by severity and by time (business hours vs. on-call), not send every alert to every channel; a Sev1 goes to the on-call phone/SMS/Teams incident channel, a Sev3 goes to a ticket queue nobody's phone buzzes for.

Automated runbook playbooks. For alerts with a known, safe, scriptable first response (restart an unhealthy instance, scale out a queue-backed worker pool, clear a specific cache), wire the alert's action group to an Azure Automation runbook or a Logic App that performs that response automatically and only escalates to a human if the automated remediation does not resolve the condition within a defined window. This converts a class of pages from "wake someone up" to "self-heals, and only pages if self-healing failed," which is the single biggest lever for reducing 3am pages for a well-understood, recurring problem.

Related scenario: multi-resource alert routing across AKS (Azure Kubernetes Service), SQL, and Storage. In a real environment with dozens of resources across several resource types, avoid one alert rule per resource; instead scope alert rules to a resource group or a subscription with dimension splitting (alert per Resource or ResourceId dimension from a single rule definition) so adding a new AKS node pool, database, or storage account is covered automatically rather than requiring someone to remember to clone another alert rule. Route by resource type and severity into distinct action groups (a SQL deadlock spike and an AKS pod crash-loop rarely need the same responder), but keep the escalation and suppression policy consistent across resource types so the on-call experience does not depend on which resource happened to break.

Worked example

A checkout API's 5xx rate normally sits under 0.5% except during two known nightly batch windows where it briefly spikes to 2% due to a maintenance job pausing a downstream cache. Static threshold "alert if 5xx rate > 1%" pages the on-call every night for a known, harmless spike. Fix: a dynamic-threshold alert on 5xx rate (learns the nightly pattern as normal), a suppression window during the documented maintenance job for the one static alert that must remain (a hard SLA, or service-level agreement, breach threshold at, say, 10%, which should still fire even during maintenance because a 10% breach is not "known noise"), and an automated runbook attached to the queue-depth alert for that same cache that pre-warms it before the maintenance job starts, addressing the root cause rather than just muting the symptom.

Trade-offs and pitfalls

Dynamic thresholds need a few weeks of representative history to learn a pattern; applying them to a brand-new resource or right after a major traffic-pattern change (a new marketing campaign, a new customer segment) produces worse alerting than a static threshold until the model relearns, so pin a temporary static threshold during that window rather than trusting a dynamic threshold with no real history. Over-aggressive suppression is the opposite failure: a suppression window broad enough to cover "any time we might be deploying" can hide a real incident that happens to coincide with a routine deploy; keep suppression windows as narrow and specific as the known-noisy event actually is. Automated runbooks that retry or restart without a cap can mask a worsening problem (a service that needs restarting every 10 minutes and never escalates because the runbook always "fixes" it) so every automated remediation needs an escalation trigger if it has fired more than N times in a period, not just a success/failure branch.

Direct answer

Azure Monitor is Azure's umbrella observability platform, and it is built from a small set of pieces that fit together: metrics (lightweight numeric time series, collected automatically for most resources), logs stored in a Log Analytics workspace (structured, queryable event and telemetry data), Application Insights (the application-performance-monitoring layer, which is really just a specialized way of writing into a Log Analytics workspace), Alerts (rules that fire on a metric threshold or a log query result), Autoscale (rules that resize compute based on a metric), Diagnostic Settings (the plumbing that routes a resource's platform logs and metrics into a workspace, storage account, or Event Hub), and Workbooks (interactive, shareable report canvases built on top of the other pieces). For a .NET or Java web API, you get end-to-end request/dependency/exception tracing largely for free by adding the Application Insights SDK (or, increasingly, the vendor-neutral OpenTelemetry SDK exporting to Azure Monitor) and letting it auto-instrument HTTP calls, database calls, and unhandled exceptions, correlated across services by a shared operation ID.

Structured elaboration

Metrics are near-real-time (typically one-minute granularity), pre-aggregated numbers like CPU percent or request count. They are cheap to query and good for dashboards and fast-firing alerts, but they carry no per-request detail.

Logs and Log Analytics store structured records (platform diagnostic logs, custom application traces, security events) that you query with Kusto Query Language (KQL). This is where request-level detail, exceptions, and dependency calls end up, and where cross-resource correlation happens, because everything in one workspace is queryable together.

Application Insights is the application-focused front end for logs: its SDK (or an OpenTelemetry exporter) captures requests, dependencies (outbound HTTP, SQL, calls to other Azure services), exceptions, custom events, and performance counters, and writes them into resource-specific tables (AppRequests, AppDependencies, AppExceptions, AppTraces) inside a Log Analytics workspace when the resource is workspace-based, which is the current default and recommended mode (the older "classic" Application Insights resource with its own isolated store is legacy).

Alerts evaluate either a metric (fast, cheap, good for "CPU over 90% for 5 minutes") or a log query on a schedule (flexible, good for "more than N exceptions of a specific type in 15 minutes"), and route to Action Groups (email, SMS, webhook, Azure Function, ITSM ticket, and so on).

Autoscale reacts to a metric (commonly CPU percent or a custom queue-length metric) by adding or removing instances of a VM Scale Set, App Service plan, or similar; it is the same metric pipeline as Alerts wired to a scale action instead of a notification.

Diagnostic Settings are per-resource configuration that says "send these log categories and these metrics to this destination." Nothing flows into a Log Analytics workspace automatically for most Azure PaaS resources until a diagnostic setting says so; forgetting this step is the single most common reason "the logs just aren't there" for a newly deployed resource.

Workbooks compose queries, metrics, parameters, and markdown into a single interactive report, useful for a team's shared "here is the health of this service" page that is friendlier to a non-KQL-fluent stakeholder than raw Log Analytics.

Worked example: end-to-end tracing for a .NET or Java API

1. Add the instrumentation: for .NET, Microsoft.ApplicationInsights.AspNetCore (or the OpenTelemetry Azure.Monitor.OpenTelemetry.AspNetCore package, the direction Microsoft is now steering toward); for Java, attach the Application Insights Java agent as a JVM argument (-javaagent:applicationinsights-agent-x.y.z.jar), which needs no code changes at all.
2. Point it at an Application Insights resource via its connection string (not the older instrumentation key alone, which Microsoft has deprecated in favor of the connection string format that also carries the ingestion endpoint).
3. The SDK/agent auto-instruments inbound HTTP requests, outbound HTTP calls, and common database clients (SQL, Cosmos DB, Redis), recording each as a request or dependency telemetry item.
4. Correlation across services happens via the W3C Trace Context standard: every inbound request gets (or receives, if propagated from an upstream caller) a traceparent header carrying a trace ID and a span ID; when Service A calls Service B over HTTP, the SDK automatically forwards that header, so Service B's request telemetry links back to Service A's dependency call for the same operation.
5. In Log Analytics, AppRequests, AppDependencies, and AppExceptions all share an OperationId column for a given end-to-end operation, so a query like AppRequests | where OperationId == "<id>" | union AppDependencies, AppExceptions (joined on the same ID) reconstructs the full call graph for one user request across every instrumented service, which is the payoff of correlation: you go from "service B threw an exception" to "which specific inbound request from service A caused it" without manually stitching logs together by timestamp.
6. Application Insights' own "Application Map" and "Transaction Search" views in the portal render this automatically from the same correlated data, which is usually faster for a first look than hand-writing KQL.

Trade-offs and pitfalls

Auto-instrumentation covers the common cases (HTTP, common DB clients) but will not capture a custom message-queue consumer or a background job's logical operation unless you either propagate the trace context manually or wrap the work in a custom Activity/span, so a fully async, queue-driven pipeline needs a small amount of manual correlation code, not zero. Sampling is the other common surprise: to control cost, Application Insights applies adaptive sampling by default, which can drop some percentage of telemetry under load, meaning "I don't see this exception in Application Insights" sometimes means "it was sampled out," not "it didn't happen"; for anything you must never lose (like all exceptions above a severity), configure sampling exclusions explicitly rather than assuming 100% capture. Finally, every diagnostic setting and every ingested GB into Log Analytics has a real per-GB cost, so "instrument everything at full fidelity forever" is a cost decision, not a free one: set a workspace retention period that matches what debugging and compliance actually require (many teams land on 30-90 days of interactive retention for verbose application logs, with a cheaper archive or Basic tier for anything kept longer), and treat sampling rate and diagnostic-setting scope as the two levers that control ingestion volume, rather than assuming the only fix for a high bill is a bigger budget.

Direct answer

For 100,000 events/second with per-partition ordering and at-least-once delivery, Event Hubs is the right ingestion service: it is purpose-built for high-throughput streaming ingestion, its partitioning model gives ordering within a partition natively, and at-least-once is its default delivery semantic (a consumer that crashes before checkpointing simply reprocesses from its last checkpoint). Service Bus is the wrong tool at this throughput (it is built for reliable, often ordered, message processing with per-message features like sessions and dead-lettering, at a throughput ceiling far below Event Hubs) and Event Grid is the wrong tool for a raw high-volume event stream (it is built for reactive, discrete resource-state-change notifications, not sustained bulk telemetry ingestion).

flowchart LR
  Producers[Producers] --> EH[Event Hubs: 32 partitions]
  EH --> CG1[Consumer group: stream-processing]
  EH --> CG2[Consumer group: cold-storage]
  CG1 --> ASA[Stream Analytics / Functions]
  ASA --> Checkpoint[(Checkpoint store: Blob)]
  ASA --> Sink[Downstream DB / Cosmos DB]
  CG2 --> Capture[Event Hubs Capture]
  Capture --> ADLS[(ADLS Gen2)]

Structured elaboration

Why Event Hubs over Service Bus or Event Grid here. Event Hubs is built around a partitioned log model (conceptually similar to Kafka): events append to one of N partitions and consumers read each partition sequentially, which is exactly what "ordering per partition" needs and is also what lets Event Hubs scale horizontally to very high aggregate throughput, since partitions can be consumed in parallel by different consumer instances. Service Bus's ordering guarantee (sessions) and its richer per-message feature set (dead-lettering, scheduled delivery, transactions) come at meaningfully lower throughput ceilings per entity; it is the right choice when you need those per-message semantics at moderate volume, not at 100k events/sec of raw ingestion. Event Grid is a push-based, discrete-event pub/sub system for reacting to state changes (a blob was created, a resource was deployed) with no concept of an ordered, replayable partition log; it complements this pipeline for control-plane/alerting fan-out, not for the ingestion path itself.

Partitioning strategy. Choose a partition key that groups events needing relative ordering together (a device ID, a tenant ID, a user session ID) while keeping the key space wide enough to avoid hot partitions: if one key (say, a single very active tenant) generates a disproportionate share of the 100k events/sec, that tenant's traffic funnels into one partition and becomes the actual system bottleneck regardless of how many partitions exist overall. Size the partition count for your target aggregate throughput divided by realistic per-partition throughput (Event Hubs' throughput units/processing units gate ingress and egress per unit, and partition count is fixed at Event Hub creation time and cannot be changed later without recreating the entity), so undershoot risk (too few partitions, capping achievable parallelism) matters more than the modest coordination overhead of a few extra partitions.

Downstream processing. Azure Stream Analytics suits SQL-like windowed aggregation directly over the stream (rolling counts, simple joins, anomaly thresholds) with minimal code; Azure Functions (Event Hubs trigger) suits custom per-event or micro-batched processing logic where the transformation is easier to express in code than in a windowed SQL query; a custom consumer (using the Event Hubs SDK directly, or Kafka clients via Event Hubs' Kafka-compatible endpoint) suits the most demanding or specialized processing. Beyond those, at genuinely high volume with complex stateful processing (windowed joins across multiple streams, exactly-once sink semantics the consumer must guarantee itself), Apache Flink (an open-source distributed stream-processing engine, not a database or a library, available as a managed option on HDInsight, Azure's managed Hadoop/Spark/Kafka service, or self-hosted on AKS, Azure Kubernetes Service, and increasingly offered as a first-class managed service) or Databricks Structured Streaming reading directly from the Event Hubs Kafka-compatible endpoint are both stronger fits than Stream Analytics or Functions for that specific complexity, at the cost of a heavier compute footprint and, for Databricks, its own per-DBU charge (DBU = Databricks Unit, a billing unit Databricks charges in addition to the underlying VM cost). None of this beyond-Stream-Analytics-and-Functions tier is needed to answer what the question asked; treat it as depth for a narrower set of real-world variants, not as a default recommendation. All of these consumer options can run against independent consumer groups on the same Event Hub simultaneously (each consumer group gets its own view of the stream with its own checkpoint position), which is how a single ingestion pipeline commonly feeds both a real-time processing path and a separate, independent path that just archives everything (Event Hubs Capture, writing raw events straight to Blob or ADLS Gen2 (Azure Data Lake Storage Gen2) with zero custom code) without either path affecting the other's throughput or checkpoint progress.

A device-telemetry-specific variant: Azure IoT Hub instead of raw Event Hubs. If the 100,000 events/second originate from field devices (industrial sensors, connected vehicles, retail edge hardware) rather than from your own backend services, IoT Hub is usually the better front door than Event Hubs directly: it adds device identity and per-device authentication, device-to-cloud and cloud-to-device messaging, device twin state, and device provisioning, none of which Event Hubs itself provides, while still exposing a built-in Event Hubs-compatible endpoint underneath for exactly the same partitioned-consumer pattern described above. Choosing between them is really "do I need to manage untrusted or fleet-scale device identity and provisioning" (IoT Hub) versus "do I control both ends of the pipe and just need a high-throughput partitioned log" (Event Hubs directly), not a throughput decision, since both scale to this volume.

A self-managed alternative: Kafka on AKS instead of Event Hubs. For a team already running Apache Kafka elsewhere (a hybrid or multi-cloud estate, or deep existing Kafka-specific tooling and operational expertise), running Kafka itself on AKS (via an operator such as Strimzi, a popular open-source Kubernetes operator that automates deploying and running Kafka) is a real alternative to Event Hubs rather than only using Event Hubs' Kafka-compatible endpoint. This trades Event Hubs' fully-managed operational model (no broker patching, no partition-rebalancing operations, no storage capacity planning for the log itself) for full control over Kafka-specific features Event Hubs' compatibility layer does not expose one-for-one (certain broker-level configurations, some newer Kafka protocol features) and for avoiding a managed-service cost in favor of AKS compute cost plus the real, ongoing engineering time to run Kafka well at this scale. For most teams without existing deep Kafka operational investment, that trade is not worth it at 100k events/sec, which Event Hubs handles natively; it becomes worth considering specifically when Kafka-specific operational expertise and tooling already exist and would otherwise sit unused.

Checkpointing and at-least-once delivery. A consumer processes a batch of events from its assigned partition(s), then writes its checkpoint (the offset/sequence number it has successfully processed up to) to a durable store (commonly Blob Storage, via the Event Hubs client library's built-in checkpoint store integration), after processing, not before. If the consumer crashes between processing an event and checkpointing, the next consumer to take over that partition resumes from the last successful checkpoint and reprocesses the events since then, which is exactly at-least-once semantics: a small window of events may be processed twice, never zero times. Achieving effective exactly-once behavior downstream, when needed, is the consumer's responsibility (make the write to the sink idempotent, e.g. an upsert keyed by an event ID rather than an append) rather than something the ingestion layer itself guarantees.

Backpressure handling. If downstream processing falls behind ingestion (a slow database sink, a temporary spike in event volume), Event Hubs itself absorbs the burst up to its retention window (commonly 1-7 days of retained events, configurable) rather than dropping data or blocking producers, which decouples producer-side throughput from consumer-side processing speed. The pattern that keeps consumers from being overwhelmed while still processing everything eventually is checkpointing per batch rather than per event (amortizing the checkpoint-write cost) and, for a Functions-based consumer, tuning the trigger's batch size and prefetch count so the function processes manageable batches rather than being handed the entire partition backlog at once after an outage.

Worked example: partition sizing arithmetic

At 100,000 events/sec sustained and an assumed average event size of 1 KB, aggregate ingress is 100,000 x 1 KB = 100,000 KB/s ≈ 100 MB/s ≈ 800 Mbps. Event Hubs' throughput unit (the Standard-tier scaling unit) guarantees roughly 1 MB/s or 1,000 events/sec ingress per unit (whichever limit is hit first), so sustaining 100 MB/s of ingress alone needs on the order of 100 throughput units as a starting capacity estimate (Premium/Dedicated tiers use a different, capacity-unit-based model better suited to this scale and worth evaluating directly at this throughput rather than scaling Standard tier this far). Partition count should be set high enough that 100 throughput units' worth of parallel consumers can actually be spread across partitions productively. Since partition count cannot be changed after creation, err toward provisioning more partitions than the day-one estimate requires (a common starting point at this scale is 32-100 partitions) rather than needing to recreate the Event Hub and coordinate a producer/consumer migration later purely to add partitions.

Trade-offs and pitfalls

The most consequential decision made early and hardest to undo is partition count, since it cannot be changed on an existing Event Hub; undersizing it caps achievable throughput regardless of how much you scale consumers or throughput units, while oversizing it has a much smaller cost (a bit more coordination overhead, negligible at this scale). A close second is choosing a partition key that looks reasonable in testing but has a highly skewed real-world distribution (a small number of very active tenants or devices), which silently caps throughput on those specific partitions even while the aggregate cluster-wide throughput number looks fine on a dashboard; monitor per-partition throughput, not only the aggregate, to catch this. Finally, "at-least-once" is a promise about the ingestion/consumption contract, not about the final state of your data: if idempotent writes are not actually implemented downstream, a reprocessed batch after a consumer crash silently double-counts events in whatever aggregate or database the pipeline feeds, which is a correctness bug that will not show up in a normal-operation load test, only during an actual consumer failure.

Direct answer

For a high-throughput, stateful order-processing pipeline with occasional spikes, recommend Azure Functions on the Flex Consumption plan, Microsoft's current recommended serverless hosting tier, orchestrated with Durable Functions for the stateful workflow parts, over running the same logic as custom microservices on Azure Kubernetes Service (AKS, Microsoft's managed platform for running Kubernetes, an open-source system that schedules and runs containerized applications across a cluster of machines). Flex Consumption directly resolves the two things that used to push teams toward the Premium plan or AKS instead of plain serverless: cold start, since you can pin a configurable number of always-ready instances, and private networking, while keeping the lower operational overhead and faster iteration speed that made Functions attractive in the first place. AKS is still the right call when the workload is not naturally event-triggered, needs full control over the runtime, or the organization already runs AKS at scale for other services.

Structured elaboration

Cold-start and development-velocity framing. The reason Flex Consumption resolves this decision for most teams, rather than leaving it as an open trade-off, is that the two historical reasons to reach for Premium or AKS instead of plain Consumption, unacceptable cold-start latency and the lack of private networking, are both addressed directly without giving up the fast iteration and low operational overhead that made Functions attractive in the first place. A team's development velocity, how quickly a change can be written, tested, and deployed, is measurably higher on Functions than on a service that also requires maintaining Kubernetes manifests, Helm charts, and an upgrade cadence, and for a team not already running AKS for other reasons, that difference compounds every sprint.

When AKS is still the right call. A workload that is not naturally event-triggered, a long-running, stateful process that owns its own connections and does not fit a function-invocation model well; a requirement for full runtime control or a language Functions does not support well; or an organization already running AKS at scale, where one more workload on it is close to free incrementally rather than a first cluster stood up just for this.

Worked example

An order-processing pipeline receives an order event, validates inventory (a call to another service), reserves payment, and on success triggers fulfillment, a natural fit for a Durable Functions orchestration where each step is a discrete activity function and the orchestration's own state persists automatically between steps, so a mid-workflow failure resumes from the last completed step instead of restarting the whole order. Under a normal load of 50 orders per second, Flex Consumption with 2 always-ready instances handles the baseline with no cold start. During a flash-sale spike to 500 orders per second for 20 minutes, Flex Consumption's per-instance scale-out adds capacity within roughly the platform's documented scale-out latency, on the order of seconds per new instance. An equivalent AKS deployment facing the same spike needs the Horizontal Pod Autoscaler to notice the metric breach, schedule new pods, and, if the node pool is also at capacity, wait for the cluster autoscaler to provision new nodes first, a multi-step scaling chain with more moving parts and typically slower end-to-end reaction to a sudden spike unless the cluster was already over-provisioned with idle headroom.

Trade-offs and pitfalls

Choosing AKS by default because "we might need the flexibility later," with no concrete current requirement demanding it, pays an ongoing cluster-operations tax for optionality that may never get used. Sticking with older Consumption or Premium plans out of familiarity ignores that Flex Consumption directly resolves the two reasons that pushed teams toward Premium or AKS in the first place. And underestimating how much of "AKS gives more control" actually translates into "AKS gives more that has to be maintained" is a cost that shows up in on-call load and upgrade cycles, not in the architecture diagram.