Back to skills
SKILL.md
Azure Compute
ASecuritySelect and implement the right Azure compute platform for a workload. Decision tree guides choice based on workload characteristics, scaling needs, and operational maturity. Covers serverless, PaaS, containers, Kubernetes, and IaaS patterns.
- 16 stars
- 0 votes
- 0 copies
- 3 views
- Added September 12, 2026
Works with
Security analysis
100/100npx -y skills add manu14357/zskills --skill azure-compute --agent claude-codeAre you the author of Azure Compute?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/manu14357-azure-compute)---
name: azure-compute
description: >
Select and implement the right Azure compute platform for a workload.
Decision tree guides choice based on workload characteristics, scaling needs, and operational maturity.
Covers serverless, PaaS, containers, Kubernetes, and IaaS patterns.
compatibility:
models: [any-llm]
cloud: azure
frameworks: [well-architected]
platforms: [functions, app-service, container-apps, aks, vm]
---
# Azure Compute
Choose the compute option with the lowest operational burden that meets your workload's functional and non-functional requirements.
Managed services first; IaaS only when control is mandatory.
## Use This Skill When
- The user asks which Azure compute service to use (Functions vs. App Service vs. AKS)
- A workload must move from on-premises or another cloud to Azure
- The user needs trade-off analysis: cost, scaling, latency, compliance
- The user needs operational readiness assessment
## Context: Compute Maturity Spectrum
```
Serverless (Least ops):
Azure Functions
└─ Pro: Zero infrastructure, auto-scale, pay-per-exec
└─ Con: Cold starts, max 10-min timeout, limited languages
PaaS (Low ops):
App Service
└─ Pro: Built-in scaling, diagnostics, deployment slots
└─ Con: Single-region, limited customization
Container Apps
└─ Pro: Container-native, auto-scaling, event-driven
└─ Con: Smaller ecosystem, newer service
Containers + Orchestration:
Azure Kubernetes Service (AKS)
└─ Pro: Full Kubernetes control, multi-region, custom scaling
└─ Con: Requires Kubernetes expertise, higher operational burden
IaaS (Most control, Most ops):
Virtual Machines / VMSS
└─ Pro: OS-level control, custom binaries, legacy support
└─ Con: Requires manual patching, scaling, monitoring
```
## Required Inputs
- **Workload type**: Web API, background job, ML training, legacy app, real-time analytics
- **Traffic pattern**: Constant, bursty, seasonal, event-driven
- **Latency requirement**: Sub-100ms, <500ms, or flexible
- **Availability**: 99%, 99.9%, 99.95%?
- **Scaling needs**: Min/max instances, target response time
- **Compliance**: On-premises only, specific regions, data residency
- **Team skills**: DevOps, Kubernetes expertise, vendor lock-in tolerance
- **Budget**: TCO vs. OpEx preference
## Decision Tree
```
Is this a background job triggered by an event (file upload, message queue, timer)?
├─ Yes → Azure Functions (lowest cost, auto-scale, easy)
│ But if: Job runs >10 min → Container Apps or App Service
└─ No → Continue
Is this a stateless HTTP API or web app?
├─ Yes → App Service (built-in scaling, diagnostics)
│ Or: Container Apps (if containerized, multi-region)
├─ Needs Kubernetes → AKS
└─ No → Continue
Does this need OS-level control (custom packages, specific kernel version)?
├─ Yes → Virtual Machines or VMSS
└─ No → One of above managed options
Is latency critical (< 100ms p99)?
├─ Yes → Consider colocating compute with data store (same region/AZ)
│ Evaluate: App Service Plan, VMSS, or Container Apps with CPU optimization
└─ No → Standard deployment acceptable
Do you need to orchestrate multiple microservices?
├─ Yes → AKS (service mesh, traffic mgmt, multi-region)
│ Or: App Service + API Management (simpler, less overhead)
└─ No → Single-service option (Functions, App Service)
```
## Workflow
### Phase 1: Characterize Workload
1. **Inventory current state**:
- Runtime: Node.js, Python, .NET, Java, Go, etc.
- Concurrency: Single-threaded, multi-threaded, async?
- State: Stateless, session affinity, distributed cache?
- Dependencies: Database, message queue, cache, external APIs?
- Constraints: Max execution time, memory, disk I/O?
2. **Predict load profile**:
- Baseline (off-peak): 10 req/sec
- Average (peak): 100 req/sec
- Spike (flash sale, viral event): 500 req/sec
- Duration of spikes: Seconds or hours?
3. **Define SLA**:
- Availability: 99% (5.2 hours downtime/month) vs. 99.95% (21 minutes/month)
- Response time p99: Must be <500ms? <100ms?
- Cost sensitivity: $500/month budget or flexible?
### Phase 2: Evaluate Candidates
**Candidate 1: Azure Functions**
```
✓ Event-driven, API-triggered, timer-based workloads
✓ Zero infrastructure, auto-scale to thousands
✓ Pay only for execution time
✗ Cold starts (first invocation 1-5 sec)
✗ Max 10-minute execution timeout
✗ Limited to 1.5 GB memory per invocation
✗ Not suitable for stateful or long-running tasks
Cost estimate: 1M invocations/month × $0.20/1M = $0.20 + compute duration charges
```
**Candidate 2: App Service**
```
✓ Web APIs, web apps, long-running services
✓ Instant startup (no cold start)
✓ Built-in auto-scale, deployment slots
✓ Integrated diagnostics, backups
✗ Single region (unless you manage multi-region)
✗ Always-on instances (minimum cost even at 0 traffic)
Cost estimate: P1V2 plan (1 core, 1.75 GB) = $74/month × 2 instances = $148/month
```
**Candidate 3: Container Apps**
```
✓ Containerized microservices, event-scale
✓ Auto-scale to zero (similar to Functions)
✓ Multi-region deployment
✗ Newer service, smaller ecosystem
✗ Kubernetes learning curve
Cost estimate: 0.5 vCPU, 1 GB memory, auto-scale = ~$30-50/month
```
**Candidate 4: AKS**
```
✓ Complex microservices orchestration
✓ Service mesh, traffic mgmt, canary deployments
✓ Multi-region, high availability
✓ Kubernetes portability
✗ Requires Kubernetes expertise
✗ Significant operational overhead
✗ Higher minimum cost (node pool)
Cost estimate: 3-node cluster (B2S VMs) = $30/month × 3 + storage + egress = $100-200/month+
```
**Candidate 5: Virtual Machines**
```
✓ Legacy app, custom OS packages, GPL software
✓ OS-level control
✗ Manual scaling, patching, monitoring
✗ Highest operational burden
✗ Highest minimum cost
Cost estimate: D2s_v3 VM = $97/month × 2 (HA) = $194/month minimum
```
### Phase 3: Size and Scale
1. **Baseline sizing** (off-peak):
- Functions: $5-10/month (very low)
- App Service: 1 instance × plan cost (~$50/month)
- Container Apps: 0.25 vCPU (~$10/month)
- AKS: 2-3 node minimum (~$100-150/month)
- VMs: 2 instances (HA) (~$200/month)
2. **Scaling policy**:
- **Functions**: Auto, no configuration needed
- **App Service**: Auto-scale rule: 50-80 CPU%, scale out when >80%, scale in when <30%
- **Container Apps**: CPU 70%, memory 80%
- **AKS**: Kubernetes HPA: target CPU 70%
- **VMs/VMSS**: Scale set: CPU 70%, add 2 instances at a time
3. **Cost impact of scaling**:
- Functions: $0.20 per 1M invocations + duration
- App Service: +$74/month per standard instance
- Container Apps: +$30-50/month per scaled instance
- AKS: +$30/month per node
## Output Contract
1. **Recommended Compute Option**
- Why this option is best for your workload
- Confidence level (80%, 95%, etc.)
2. **Justification & Trade-Offs**
- Operational burden vs. cost vs. flexibility
- Why alternatives were rejected
3. **Sizing & Scaling**
- Baseline instance count, VM size
- Auto-scale rules (CPU/memory thresholds)
- Peak capacity and estimated cost
4. **Cold Start & Latency Impact**
- If Functions: ~1-5 sec cold start time, 100 ms warm
- Mitigation: Keep-alive, premium plan, container warm-up
5. **Operational Checklist**
- Monitoring (Application Insights)
- Logging (Log Analytics)
- Backup/DR strategy
- CI/CD pipeline type
6. **Migration Readiness**
- Dependency adjustments (connection strings, auth)
- Testing strategy (smoke, integration, load)
- Rollback plan (old platform stays active until validated)
## Practical Examples
### Example 1: Bursty Event-Driven Workload
**Workload**: Image resize triggered on file upload to blob storage
- Traffic: 10 images/day (steady), 1000 images/day on marketing campaign (spiky)
- Latency: <30 sec acceptable (async)
- **Recommendation**: Azure Functions (Premium Plan for concurrency control)
- **Cost**: ~$40/month steady + $0.20 per 1M invocations
### Example 2: Steady HTTP API
**Workload**: REST API for mobile app
- Traffic: 100 req/sec average, 500 req/sec peak
- Latency: <100ms p99 (critical)
- Availability: 99.95%
- **Recommendation**: App Service P1V2 (2+ instances) + CDN for static assets
- **Cost**: $148/month (2 instances) + egress
### Example 3: Microservices Architecture
**Workload**: 5 services: API gateway, auth, billing, inventory, notifications
- Need service-to-service communication, canary deployments
- Team: Kubernetes-experienced DevOps team
- **Recommendation**: AKS with Helm charts, Istio service mesh
- **Cost**: $100-150/month (3-node cluster) + storage, egress
## Guardrails
- **Avoid over-engineering**: Use Functions for simple tasks; don't add AKS until you need it.
- **Be honest about operational burden**: AKS requires dedicated DevOps; App Service works with dev teams.
- **Consider lock-in**: App Service is Azure-only; AKS is portable (but requires Kubernetes skills).
- **Latency matters**: Functions cold starts may violate SLA; test realistic load.
- **Monitor from day one**: Set up alerts before go-live (CPU, memory, errors, latency).
- **Plan for growth**: Today's App Service might become tomorrow's AKS; design for portability.
Attribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.