[Cheat Sheet] 2026 Serverless Pricing & Quotas: AWS vs GCP vs Azure

As we move through 2026, the serverless landscape has evolved beyond simple event-driven functions into a sophisticated ecosystem of container-native execution and AI-optimized runtimes. Architects are no longer just choosing a provider based on language support, but on granular pricing tiers, cold-start latency mitigation, and global distribution quotas. This cheat sheet provides a high-fidelity comparison of the 'Big Three' providers, focusing on the latest 2026 pricing models and resource limitations to help you optimize your infrastructure spend.

Pricing Comparison Matrix (2026)

Understanding the unit costs is only the first step. The real complexity lies in how vCPU and Memory are coupled across different providers.

*Unless using Lambda Runtime Extensions or specific async patterns.

Execution & Resource Quotas

Quotas define the architectural boundaries of your application. Pushing these limits often requires moving to provisioned capacity or dedicated instances.

• Maximum Execution Timeout:
  • AWS Lambda: 15 minutes (Hard limit).
  • GCP Cloud Run: 60 minutes (Configurable up to 3600s).
  • Azure Functions: 10 minutes (Consumption), Unlimited (Premium/App Service).
• Memory Limits:
  • AWS Lambda: 128MB to 10,240MB (Allocates vCPU proportionally).
  • GCP Cloud Run: 512MB to 32GB (Can decouple vCPU from Memory).
  • Azure Functions: Up to 4GB (Consumption), much higher on Flex/Premium.
• Payload Limits: Standardized across most providers at 6MB for synchronous invocations and 256KB for asynchronous events. When processing larger datasets, always use signed URLs with S3 or GCS to avoid payload bottlenecks. For security-sensitive data processing, consider utilizing a Data Masking Tool before logging or storing serverless payloads.

CLI Quick Reference

Commands grouped by common management tasks for the 2026 toolsets.

Resource Inspection

# AWS: Check concurrency limits for a specific region
aws lambda get-account-settings --region us-east-1

# GCP: List Cloud Run services with resource usage
gcloud run services list --format="table(name,status.address,spec.template.spec.containers[0].resources.limits)"

# Azure: Get function app settings
az functionapp config show --name my-app --resource-group my-group

Cost-Optimized Deployment Flags

# Deploy AWS Lambda on ARM64 (Graviton3) for 20% better price/perf
aws lambda create-function --function-name my-func \
    --architectures arm64 --runtime nodejs20.x

# Set GCP Cloud Run concurrency to maximize resource density
gcloud run deploy my-service --concurrency 80 --cpu-boost

Advanced Scaling Config

In 2026, the 'Cold Start' problem is largely solved by three specific features you should be configuring in your serverless.yml or terraform files:

1. Provisioned Concurrency (AWS): Keeps a specified number of functions 'warm'. Use Scheduled Scaling to turn this down at night.
2. Startup CPU Boost (GCP): Temporarily allocates more CPU during container startup to decrease initialization time by up to 50%.
3. Always-on Instances (Azure): Part of the Premium/Flex plans to ensure zero latency for mission-critical endpoints.

Cost Optimization Strategies

• Right-sizing Memory: Use tools like AWS Lambda Power Tuning to find the 'Goldilocks' zone. Doubling memory often halves execution time, resulting in the same cost but better performance.
• Log Retention: By default, CloudWatch and Cloud Logging retain logs forever. Set a 7-day retention policy to avoid 'hidden' storage costs that can exceed execution costs.
• VPC Cold Starts: Ensure you are using the latest ENI-per-VPC (AWS) or Serverless VPC Access (GCP) configurations to avoid the 10-second networking penalty of older architectures.