← All articles

Stop Over‑Provisioning Serverless: Fine‑Tune Lambda, Functions & Cloud Run

Why Serverless Over‑Provisioning Sneaks Into Your Bill

Serverless platforms promise pay‑as‑you‑go, but most teams add safety nets—provisioned concurrency, pre‑warmed instances, or max‑instance caps—without measuring actual demand. Those safety nets are billed whether they run or sit idle, and the cost can equal or exceed the workload itself. The trick is to treat these settings as capacity that needs the same rightsizing discipline as EC2 or RDS.

1. Audit Provisioned Concurrency on AWS Lambda

What to Look For

• Functions with provisioned-concurrency > 0 that see < 10% utilization over the last 30 days.
• Versions or aliases that are never invoked but still have allocated concurrency.

CLI Steps

# List all functions with provisioned concurrency
aws lambda list-functions --query "Functions[?ProvisionedConcurrencyConfig != null].FunctionName" --output text

# For each function, get detailed usage metrics
aws cloudwatch get-metric-statistics \
  --namespace AWS/Lambda \
  --metric-name ProvisionedConcurrencyUtilization \
  --dimensions Name=FunctionName,Value=my-func Name=Qualifier,Value=prod \
  --statistics Average \
  --period 86400 --start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Actionable Adjustments

• If average utilization < 20 %, reduce --provisioned-concurrent-executions to the 90th‑percentile of actual concurrent invocations.
• For functions that rarely spike, consider on‑demand only and delete the provisioned setting:

aws lambda delete-provisioned-concurrency-config \
  --function-name my-func --qualifier prod

• Use Lambda SnapStart (if supported) as an alternative to keep cold‑start latency low without paying for concurrency.

2. Trim Azure Functions Premium Plan Instances

What to Look For

• Premium plan apps with pre-warmed instance count set high while FunctionExecutionCount remains low.
• Apps that never exceed the maxBurst threshold.

Azure CLI Steps

# List all Premium plan apps and their pre‑warmed instance count
az functionapp plan list --query "[?sku.tier=='Premium'].{Name:name, PreWarmedInstances:properties.preWarmedInstanceCount}" -o table

# Pull execution metrics for the last 30 days
az monitor metrics list \
  --resource /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Web/sites/<app> \
  --metric "FunctionExecutionCount" \
  --interval PT1H \
  --aggregation Average \
  --start-time $(date -d '-30 days' -u +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Actionable Adjustments

• Reduce preWarmedInstanceCount to the 95th‑percentile of concurrent executions. Update via:

az functionapp config set \
  --resource-group <rg> \
  --name <app> \
  --set properties.preWarmedInstanceCount=2

• If the app never exceeds the maxBurst limit, switch to the Consumption plan and delete the Premium plan.
• Enable Azure Functions Premium Auto‑Scale (preview) to let the platform adjust pre‑warmed instances based on real traffic.

3. Control Max‑Instance Settings in GCP Cloud Run

What to Look For

• Services with --max-instances set to a high static value (e.g., 1000) while actual traffic peaks at < 50.
• Services that use --cpu and --memory over‑provisioned together with a high max‑instance cap.

gcloud Commands

# List services and their max‑instance settings
for svc in $(gcloud run services list --platform managed --format "value(metadata.name)"); do
  echo "Service: $svc"
  gcloud run services describe $svc --platform managed --format "value(spec.template.metadata.annotations[run.googleapis.com/max-instances])"
done

# Pull request count metrics for the last 30 days
gcloud monitoring time-series list \
  --filter='metric.type="run.googleapis.com/request_count"' \
  --project=my-project \
  --interval='30d' \
  --format='json'

Actionable Adjustments

• Set --max-instances to the 99th‑percentile of observed concurrent requests:

gcloud run services update $svc \
  --max-instances 75 \
  --platform managed

• If the service rarely exceeds 10 concurrent requests, consider fully managed Cloud Run (no max‑instance limit) and let the platform scale to zero.
• Combine with CPU‑Bursting (--cpu=1) and lower memory to shrink per‑instance cost.

4. Automate the Rightsizing Loop

1. Collect Metrics – Pull CloudWatch, Azure Monitor, and Cloud Monitoring data on a nightly basis.
2. Calculate Utilization – Compute the average and 95‑percentile utilization for each serverless capacity knob.
3. Apply Thresholds – If utilization < 20 % for > 7 days, flag for reduction.
4. Execute Safe Updates – Use the CLI snippets above in a CI/CD job that runs --dry-run first, then applies changes after approval.
5. Monitor Impact – Track the dollar change via the provider’s cost explorer to verify savings.

5. Common Pitfalls & How to Avoid Them

• Cold‑Start Regression – After reducing provisioned concurrency, monitor latency spikes. If they breach SLA, incrementally raise the setting.
• Burst Traffic – For workloads with occasional spikes (e.g., nightly batch), keep a modest max‑instances buffer (10‑20 % above peak) instead of a static high ceiling.
• Multi‑Region Deployments – Each region has its own provisioned concurrency quota; audit per‑region to avoid hidden waste.
• Version Drift – Ensure you adjust the published version/alias, not just the $LATEST version, otherwise the change has no effect.

6. The Bottom Line

Serverless over‑provisioning is a silent cost leak that bypasses traditional rightsizing checks. By regularly auditing provisioned concurrency, pre‑warmed instances, and max‑instance caps—and adjusting them based on real utilization—you can reclaim a significant portion of your serverless spend without sacrificing performance.

How CloudBudgetMaster helps – Our platform continuously scans Lambda provisioned concurrency, Azure Functions Premium settings, and Cloud Run max‑instance configurations, flags under‑utilized capacity, and shows the exact dollar impact, so you can act fast and keep serverless costs in check.