Azure Services Catalog: Production Decision & Implementation Guide¶
The Four Highest-Leverage Decision Clusters¶
1. Compute — the Four-Way Decision¶
Microsoft's own Azure Architecture Center guidance establishes a clear preference order:
- Azure Container Apps (ACA) — the modern default for container workloads. Built on Kubernetes + KEDA + Dapr but hides the control plane; scale-to-zero, event-driven scaling, no node-pool management. Key constraint: single top-level security boundary (the Container Apps environment) with unrestricted intra-environment communication and a shared Log Analytics workspace — if you need granular multi-workload isolation, use AKS or multiple ACA environments.
- AKS — only when you need direct Kubernetes API access, custom service mesh, node-level control, or strict multi-workload isolation.
- Azure Functions (Flex Consumption) — event-driven spiky workloads. Flex Consumption is now the recommended default (GA November 2024): scale from zero to 1,000 instances, no cold start with Always Ready, VNet integration, per-function scaling, configurable instance memory, Linux-only.
- App Service — straightforward HTTP services and web apps. Deployment slots enable zero-downtime blue-green via slot swap.
Anti-pattern to avoid: every additional service is operational surface area and on-call burden — resist the Swiss Army knife.
Compute Details¶
Virtual Machines — series selection: - B: burstable, dev/test - D: general purpose - E: memory-optimized (databases/caches) - F: compute-optimized - L: storage-optimized - N: GPU - H: HPC - Use Availability Zones over Availability Sets for new production workloads; VMSS for scale - Managed disks: Standard HDD (dev/backup) → Standard SSD (light production) → Premium SSD (production) → Ultra Disk/Premium SSD v2 (highest IOPS, databases)
AKS networking models (decision is fixed at cluster creation): - kubenet: UDR-based, ~400-node limit, IP-efficient but limited - Azure CNI: pods get VNet IPs, direct connectivity but IP-hungry - Azure CNI Overlay: pods get IPs from a private CIDR, fixed /24 per node (~250 pods), scales to 5,000 nodes, comparable throughput to host networking — now the recommended default - Azure CNI Powered by Cilium: eBPF dataplane, no kube-proxy, built-in network policy + observability, Linux-only - Identity: AAD Pod Identity is deprecated — migrate to Workload Identity - Standard/Premium tier supports up to 5,000 nodes
ACA 2024–2025 additions: - Dynamic Sessions (GA): Hyper-V-isolated sandboxes for running untrusted/LLM-generated code - Jobs: event-driven/scheduled/manual batch - Serverless GPU (preview) - Native Azure Functions hosting - Free managed TLS certificates
App Service tiers: Free/Shared/Basic/Standard/Premium/Isolated - App Service Environment (ASE) v3: only justified for network isolation/compliance at scale (max 200 instances vs 30 on Premium)
Functions — Flex Consumption vs alternatives: - Flex Consumption: Linux-only, VNet, per-function scaling, ~zero cold starts with Always Ready - Classic Consumption: caps at 10-minute execution, 200 instances, no VNet; cold starts 1–3s (.NET/JS/Python), 3–7s (Java) - Premium (~$150–170/month minimum for EP1): eliminates cold starts via always-ready + prewarmed; worth it if not on Flex
2. Messaging — the Most-Confused Cluster¶
The canonical distinction: an event is a lightweight notification of a state change; a message is actionable data with delivery expectations.
| Service | Use For | Key Features |
|---|---|---|
| Service Bus | Transactional messages, orders, financial | FIFO via sessions, transactions, dead-lettering, duplicate detection, scheduled messages |
| Event Hubs | Telemetry streams, IoT, logs, clickstreams | Millions of events/sec, Kafka-compatible endpoint, Capture to Blob/ADLS |
| Event Grid | Reactive pub/sub ("react when X happens") | HTTP + MQTT, Event Grid Namespaces (MQTT broker, pull delivery); does NOT guarantee ordering |
| Storage Queue | Basic decoupling, cheap queuing | Simple REST-based; no sessions, transactions, or duplicate detection |
These are complementary. The canonical example: e-commerce uses Service Bus for orders, Event Hubs for telemetry, and Event Grid for shipment notifications.
3. Networking — Hub-Spoke vs Virtual WAN¶
Hub-and-spoke: full routing control, lower cost at small scale, supports specific third-party NVAs.
Virtual WAN: Microsoft-managed hub with native transitive routing and "routing intent" (auto-route all spoke traffic through Azure Firewall).
Crossover point: ~2–3 active regions or ~30 spokes, or when branch/SD-WAN connectivity at scale is needed.
vWAN gotchas: - NAT Gateway is not supported in a vWAN hub - Long-lived TCP flows through shared Azure Firewall drop on idle timeouts/instance recycling — workloads need bidirectional TCP keep-alives
Private Endpoint vs Service Endpoint:
| Service Endpoint | Private Endpoint | |
|---|---|---|
| Cost | Free | ~$7–8/month + data processing |
| On-premises access | No | Yes (via ExpressRoute/VPN) |
| DNS resolution | Public DNS | Private DNS (must configure) |
| Third-party support | No | Yes (Snowflake, etc.) |
| When required | Never (legacy) | SQL MI, ASE, AKS private API server, on-prem access |
4. Databases — the Three-Way Decision¶
Azure SQL Database: relational, DTU or vCore model, serverless tier (auto-pause), Hyperscale for large DBs, elastic pools for multi-tenant SaaS.
- SQL Managed Instance: near-full SQL Server compatibility; requires private endpoints (not service endpoints)
Cosmos DB: globally distributed NoSQL. The #1 performance lever is partition key selection — choose high cardinality, even RU/storage distribution, and a key that appears in query filters. - Five consistency levels: Strong → Bounded Staleness → Session (default) → Consistent Prefix → Eventual - Session consistency tokens must be passed explicitly between microservices or read-your-writes breaks - Hierarchical partition keys and partition-level auto-failover (new 2025–2026) ease scaling - Warning: "Scale failures are almost always design failures" — invest in partition-key design before launch; Cosmos DB is expensive and unforgiving when misused - Reserve for genuine global-distribution or flexible-schema needs
PostgreSQL: - Flexible Server: zone-redundant HA, burstable tiers, read replicas — use for migrating/modernizing existing PostgreSQL or Oracle apps - Cosmos DB for PostgreSQL (Citus): for new cloud-native apps needing horizontal sharding - Single Server is the deprecated path — do not use
Storage Redundancy Decision Matrix¶
| Tier | Durability | Notes |
|---|---|---|
| LRS | 11 nines | Dev/test only; lowest cost |
| ZRS | 12 nines | Production minimum; ~25% premium over LRS |
| GRS/GZRS | ~16 nines | Geo-redundant backup |
| RA-GZRS | 16 nines | Business-critical; adds read access to secondary |
Critical: archive tier is not supported on ZRS, GZRS, or RA-GZRS — only LRS/GRS/RA-GRS.
Access tiers: Hot → Cool (30-day min) → Cold (90-day min) → Archive (180-day min, hours to rehydrate)
Action: set lifecycle management policies to auto-tier aging data from day one — this is the primary cost lever.
AI & Microsoft Foundry¶
Platform History and Current State¶
- Azure AI Studio → Azure AI Foundry (Ignite 2024) → Microsoft Foundry (Ignite 2025, now GA)
- 1,900+ models from OpenAI, Meta, and more (11,000+ including community models per Microsoft marketing)
Two Project Models (Not at Full Feature Parity)¶
- Hub-based projects: built on Azure ML (
Microsoft.MachineLearningServices); legacy path - Foundry projects: built on Cognitive Services (
Microsoft.CognitiveServices/account); all new generative-AI investment goes here — new model-centric features available only here - An existing Azure OpenAI resource can be upgraded to a Foundry resource preserving endpoint and keys
Agent Capabilities¶
- Foundry Agent Service (GA May 2025): connected agents for multi-agent orchestration without external orchestrators
- Workflows (visual + YAML, preview from Ignite 2025): coordinate multiple agents
- Agent types: managed no-code Prompt agents (GA) and Hosted agents (preview), both behind the Responses API
- Tools: Code Interpreter, Logic Apps (1,400+ connectors), Functions, OpenAPI, MCP, Deep Research, Agent2Agent (A2A)
Microsoft Agent Framework¶
- Open-source successor to both Semantic Kernel and AutoGen (now in maintenance mode)
- Public preview October 1, 2025; 1.0 GA April 2026
- Five stable orchestration patterns: sequential, concurrent, handoff, group chat, Magentic
- Native MCP and A2A support
Deployment Options¶
| Option | When to Use |
|---|---|
| Standard deployment (preferred) | Foundry resource, no hub required, regional/data-zone/global processing |
| Serverless API endpoints (MaaS) | Pay-per-token, OpenAI/partner models, hub required |
| Managed compute | Hugging Face/NVIDIA NIM/custom models, billed per compute-hour |
PTU vs Pay-as-You-Go¶
- Pay-as-you-go (standard/token-based): variable, experimental, or low-volume workloads
- PTU (Provisioned Throughput Units): production with predictable traffic needing guaranteed latency; billed hourly per PTU regardless of usage
- Critical: quota does not guarantee capacity — deploy the model first, then buy the matching reservation
- Spillover routes PTU overflow (429s) to a standard deployment
When to Choose What¶
- Microsoft Foundry: end-to-end generative-AI/agent apps and the broad catalog — the default
- Raw Azure OpenAI: only when you need OpenAI models alone (upgrade path to Foundry recommended)
- Azure Machine Learning: custom model training, full MLOps, and the model registry
Vector Search for RAG¶
- Azure AI Search: default for Azure-native teams — hybrid (BM25 + vector) search, built-in semantic ranker, security trimming, indexer-managed ingestion
- pgvector: cheaper for small corpora already on PostgreSQL
- Cosmos DB vector search: globally distributed apps already on Cosmos
- At ≤100k vectors, all options are fast enough — decision driver is features, cost model, and operational ownership
APIM as AI Gateway¶
A major 2024–2026 pattern:
- azure-openai-token-limit policy for TPM throttling per subscription key
- Backend pool load balancing (round-robin/weighted/priority) and circuit breakers honoring Retry-After
- Route to PTU first, spill over to pay-as-you-go across regions on 429s
- azure-openai-emit-token-metric → Application Insights for per-team showback
- APIM is integrated into Microsoft Foundry; not a separate offering
- Azure-Samples/AI-Gateway repo provides 30+ deployable Bicep/policy labs
Cost Optimization¶
Layered commitment strategy:
| Tool | Discount | Best For |
|---|---|---|
| Reservations | Up to 72% vs pay-as-you-go | Stable steady-state compute; locked to VM family + region |
| Savings Plans | Up to 65% vs pay-as-you-go | Evolving compute; $/hour commitment flexible across families/regions/services |
| Spot VMs | Up to 90% vs pay-as-you-go | Fault-tolerant/batch; no SLA, ~30-second eviction notice |
- Reservations apply before Savings Plans when both match
- Stack Azure Hybrid Benefit for Windows/SQL licensing on top of Reservations
- Start with 30–60 days of usage data, then use Azure Cost Management recommendations
IaC: Bicep vs Terraform¶
Consensus: both are production-ready; standardize on one for new projects.
| Bicep | Terraform | |
|---|---|---|
| Best for | Azure-only teams | Multi-cloud or heavy third-party integration |
| State file | No | Yes (management overhead) |
| Azure day-0 support | Yes | Delayed (provider maturity) |
| Provider ecosystem | Azure-only | Mature, broad |
| CI/CD | Azure CLI native | State management required |
Migration between them is rarely worth it — standardize on one and let old projects attrit.
Identity & Zero Trust¶
- Managed Identities: always preferred over service principals for Azure-to-Azure auth — no secret management, no credential rotation
- Zero Trust stack: Entra ID + Conditional Access + PIM (just-in-time role activation) + Defender for Cloud
- Use Azure RBAC built-in roles at the narrowest scope — avoid Owner/Contributor at subscription/management-group scope
- Key Vault references: let App Service/Functions/AKS consume secrets without storing them in config
- Distinguish Azure RBAC (resource-plane) from Entra ID roles (directory/tenant-plane)
Service Retirements — Act Now¶
| Service | Status | Action Required |
|---|---|---|
| Log Analytics agent (MMA) | Retired November 2024 | Migrate to Azure Monitor Agent (AMA) with Data Collection Rules |
| Azure AD B2C | No new sales May 1, 2025; P2 discontinues March 15, 2026; support "until at least May 2030" | Migrate to Microsoft Entra External ID (GA Sept 2024); plan 3–9 months for migration |
| AzureAD/MSOnline PowerShell | Deprecated March 2024, retiring through 2025 | Migrate to Microsoft Graph PowerShell; Azure AD Graph API blocked for new apps |
| Prompt Flow | Retires April 20, 2027 | Migrate to Microsoft Agent Framework |
Entra External ID migration note: B2C custom policies don't port directly; Entra External ID still has gaps (OTP-only MFA, tenant-level branding) — validate feature parity before committing.
Production Staging Roadmap¶
Stage 1 — Foundation (landing zone first)¶
- Cloud Adoption Framework landing zone with management-group hierarchy
- Hub-spoke networking with Azure Firewall; ZRS storage defaults
- Managed identities everywhere
- Azure Policy guardrails (Audit/Deny/DeployIfNotExists)
- Bicep or Terraform IaC
- Trigger to migrate to Virtual WAN: exceed 2–3 active regions or ~30 spokes, or need branch/SD-WAN at scale
Stage 2 — Compute by workload¶
- Default container workloads → Container Apps
- Escalate to AKS only for: Kubernetes API access, custom service mesh, multi-workload isolation, node-level control
- Functions Flex Consumption for event-driven; App Service for web apps
Stage 3 — Data and messaging¶
- Map each integration to the right messaging service (don't standardize on one)
- Relational default: Azure SQL or PostgreSQL Flexible Server
- Reserve Cosmos DB for genuine global-distribution or flexible-schema needs
Stage 4 — AI¶
- Build on Microsoft Foundry (Foundry projects) for new generative-AI/agent work
- Start on pay-as-you-go → move to PTU once traffic is predictable (deploy first, reserve second)
- Front all AI traffic with APIM as an AI gateway
- RAG: default to Azure AI Search
Stage 5 — Cost¶
- After 30–60 days of data: Reservations on steady-state + Savings Plans on variable + Spot on fault-tolerant
- Stack Azure Hybrid Benefit
- Target high Effective Savings Rate (coverage × utilization), not maximum headline discount
Stage 6 — Govern and observe¶
- Mandatory tags via Policy
- Defender for Cloud for posture
- Azure Monitor with AMA + Data Collection Rules (MMA is gone)
- Track retirements against the Azure Retirement Workbook
Plugin: azure-cloud-infra · View SKILL.md on GitHub