AzureServerlessintermediate

API Management (APIM) Guide

Build and manage APIs with Azure API Management, covering tiers, policies, OAuth integration, rate limiting, developer portal, and versioning.

CloudToolStack Team24 min readPublished Feb 22, 2026

Prerequisites

Understanding of REST APIs and HTTP protocols
Familiarity with Azure Functions or App Service
Basic knowledge of OAuth 2.0 and API authentication

Azure API Management Overview

Azure API Management (APIM) is a fully managed service that enables organizations to publish, secure, transform, maintain, and monitor APIs at any scale. It acts as a gateway between API consumers (mobile apps, web apps, partner systems) and your backend services (Azure Functions, App Service, AKS, on-premises APIs), providing a consistent facade regardless of where or how the backend is implemented.

APIM solves several critical challenges in modern API-driven architectures: how to enforce consistent authentication and authorization across all APIs, how to apply rate limiting and throttling to protect backend services, how to version and evolve APIs without breaking existing consumers, how to provide developer documentation and self-service onboarding, and how to monitor API usage and performance. Without a centralized API management layer, these concerns are typically implemented inconsistently across individual services, leading to security gaps, operational complexity, and poor developer experience.

This guide covers APIM from initial setup through advanced policy configuration, covering all the concepts you need to design and operate a production-grade API management platform on Azure.

APIM Deployment Time

Creating an Azure API Management instance in the Developer or Premium tiers can take 30–60 minutes because APIM provisions dedicated infrastructure including a virtual IP address, internal load balancers, and a managed gateway. The Consumption and Basic v2 tiers provision much faster (minutes). Plan your initial deployment accordingly and use infrastructure-as-code to make the provisioning repeatable.

APIM Tiers & Architecture

Azure API Management offers several pricing tiers, each designed for different use cases, scale requirements, and feature needs. Choosing the right tier is one of the most important decisions because it affects cost, performance, SLA, and available features.

Tier	SLA	Scale Units	VNet Support	Dev Portal	Price (approx.)
Consumption	99.95%	Auto-scale	No	No	Pay per call (~$3.50/million)
Developer	No SLA	1 (no scaling)	External only	Yes	~$50/month
Basic v2	99.95%	0–2	No	Yes	~$160/month
Standard v2	99.95%	0–10	VNet integration	Yes	~$330/month
Premium	99.95–99.99%	1–12 per region	External + Internal	Yes	~$2,800/month per unit

Architecture Components

An APIM instance consists of three main components: the API Gateway (which processes API requests, applies policies, and forwards requests to backends), theManagement Plane (used by administrators to configure APIs, policies, products, and users), and the Developer Portal (a customizable website where API consumers discover, test, and subscribe to APIs).

Terminal: Create an API Management instance

# Create an APIM instance (Developer tier for testing)
az apim create \
  --resource-group rg-api-platform \
  --name apim-myorg-dev \
  --location eastus \
  --publisher-name "My Organization" \
  --publisher-email "api-team@myorg.com" \
  --sku-name Developer \
  --sku-capacity 1 \
  --tags project=api-platform environment=dev

# This takes 30-60 minutes for Developer/Premium tiers
# For quick testing, use Consumption tier:
az apim create \
  --resource-group rg-api-platform \
  --name apim-myorg-consumption \
  --location eastus \
  --publisher-name "My Organization" \
  --publisher-email "api-team@myorg.com" \
  --sku-name Consumption

# Verify the instance is ready
az apim show \
  --resource-group rg-api-platform \
  --name apim-myorg-dev \
  --query '{Name:name, Tier:sku.name, GatewayUrl:gatewayUrl, PortalUrl:developerPortalUrl, State:provisioningState}' \
  --output table

Publishing Your First API

Adding an API to APIM involves defining the API surface (operations, request/response schemas) and configuring the backend service that handles requests. APIM supports importing APIs from OpenAPI specifications (Swagger), WSDL files, Azure Functions, Logic Apps, or manual definition. The OpenAPI import is the most common approach because it automatically creates all operations with correct schemas.

Terminal: Import an API from OpenAPI specification

# Import an API from an OpenAPI (Swagger) specification URL
az apim api import \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id orders-api \
  --path orders \
  --specification-format OpenApiJson \
  --specification-url "https://mybackend.azurewebsites.net/swagger/v1/swagger.json" \
  --display-name "Orders API" \
  --service-url "https://mybackend.azurewebsites.net" \
  --protocols https \
  --api-type http \
  --subscription-required true

# Import from a local OpenAPI file
az apim api import \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id products-api \
  --path products \
  --specification-format OpenApi \
  --specification-path ./openapi.yaml \
  --display-name "Products API" \
  --service-url "https://func-products.azurewebsites.net/api"

# List all APIs in the APIM instance
az apim api list \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --query "[].{Name:displayName, Path:path, Id:name}" \
  --output table

# Import an Azure Function App as an API
az apim api import \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id func-api \
  --path functions \
  --specification-format OpenApiJson \
  --specification-url "https://func-myapp.azurewebsites.net/api/openapi/v3.json" \
  --display-name "Functions API"

Products & Subscriptions

In APIM, a Product is a grouping of APIs that can be offered to developers with specific terms of use, rate limits, and approval workflows. ASubscription is what a developer obtains to access a product, and it provides subscription keys (API keys) that must be included in API requests. This model gives you fine-grained control over who can access which APIs and under what conditions.

Terminal: Create products and manage subscriptions

# Create a product that bundles the Orders and Products APIs
az apim product create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --product-id partner-access \
  --display-name "Partner Access" \
  --description "Access to Orders and Products APIs for partner integrations" \
  --subscription-required true \
  --approval-required true \
  --subscriptions-limit 5 \
  --state published

# Add APIs to the product
az apim product api add \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --product-id partner-access \
  --api-id orders-api

az apim product api add \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --product-id partner-access \
  --api-id products-api

# Create a subscription for a specific consumer
az rest --method PUT \
  --url "https://management.azure.com/subscriptions/<sub-id>/resourceGroups/rg-api-platform/providers/Microsoft.ApiManagement/service/apim-myorg-dev/subscriptions/partner-acme?api-version=2022-08-01" \
  --body '{
    "properties": {
      "displayName": "ACME Corp Subscription",
      "scope": "/products/partner-access",
      "state": "active"
    }
  }'

Policies & Transformations

Policies are the most powerful feature of Azure API Management. They are XML-based rules that execute during the request/response pipeline and can modify requests, responses, enforce security, implement caching, transform payloads, and much more. Policies can be applied at four scopes: global (all APIs), product, API, and operation, with policies at narrower scopes inheriting from broader ones.

Policy Execution Pipeline

Section	When It Runs	Common Uses
inbound	Before the request reaches the backend	Authentication, rate limiting, request transformation, caching lookup
backend	When forwarding to the backend service	Backend URL routing, retry policies, circuit breaking
outbound	After the backend response is received	Response transformation, header manipulation, caching store
on-error	When an error occurs in any section	Error formatting, logging, fallback responses

policy.xml: Comprehensive API policy example

<policies>
  <inbound>
    <base />

    <!-- Set CORS for browser-based clients -->
    <cors allow-credentials="true">
      <allowed-origins>
        <origin>https://myapp.com</origin>
        <origin>https://partner-portal.com</origin>
      </allowed-origins>
      <allowed-methods preflight-result-max-age="300">
        <method>GET</method>
        <method>POST</method>
        <method>PUT</method>
        <method>DELETE</method>
      </allowed-methods>
      <allowed-headers>
        <header>Content-Type</header>
        <header>Authorization</header>
        <header>X-Request-ID</header>
      </allowed-headers>
    </cors>

    <!-- Add a correlation ID if not present -->
    <set-header name="X-Correlation-ID" exists-action="skip">
      <value>@(context.RequestId.ToString())</value>
    </set-header>

    <!-- Validate JWT token from Azure AD -->
    <validate-jwt header-name="Authorization" require-scheme="Bearer">
      <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
      <required-claims>
        <claim name="aud" match="all">
          <value>{api-client-id}</value>
        </claim>
        <claim name="scp" match="any">
          <value>Orders.Read</value>
          <value>Orders.Write</value>
        </claim>
      </required-claims>
    </validate-jwt>

    <!-- Rate limiting: 100 calls per minute per subscription -->
    <rate-limit-by-key calls="100" renewal-period="60"
      counter-key="@(context.Subscription.Id)" />

    <!-- Rewrite the request path for the backend -->
    <rewrite-uri template="/api/v2{request.path}" />
  </inbound>

  <backend>
    <forward-request timeout="30" follow-redirects="false" />
  </backend>

  <outbound>
    <base />

    <!-- Remove internal headers from the response -->
    <set-header name="X-Powered-By" exists-action="delete" />
    <set-header name="X-AspNet-Version" exists-action="delete" />

    <!-- Add response headers -->
    <set-header name="X-Request-ID" exists-action="override">
      <value>@(context.RequestId.ToString())</value>
    </set-header>

    <!-- Cache successful GET responses for 5 minutes -->
    <cache-store duration="300" />
  </outbound>

  <on-error>
    <base />
    <!-- Return a standardized error response -->
    <return-response>
      <set-status code="500" reason="Internal Server Error" />
      <set-header name="Content-Type" exists-action="override">
        <value>application/json</value>
      </set-header>
      <set-body>@{
        return new JObject(
          new JProperty("error", new JObject(
            new JProperty("code", context.Response.StatusCode),
            new JProperty("message", "An internal error occurred"),
            new JProperty("requestId", context.RequestId.ToString())
          ))
        ).ToString();
      }</set-body>
    </return-response>
  </on-error>
</policies>

Policy Expressions

Policy expressions (the @(...) syntax) allow you to write C# code inline within policies. You have access to the context object which provides request details, subscription info, user identity, and variables. Policy expressions are evaluated at runtime and enable dynamic behavior like conditional routing, payload transformation, and computed header values. Use them to build sophisticated gateway logic without modifying backend code.

Authentication & OAuth Integration

APIM supports multiple authentication mechanisms for securing API access. The most common approach for production APIs is OAuth 2.0 with Azure AD (Microsoft Entra ID), which provides token-based authentication, fine-grained scopes, and integration with Azure's identity platform. APIM can validate JWT tokens, extract claims, and make authorization decisions without any backend code changes.

Authentication Methods

Method	Use Case	Security Level
Subscription Keys	Simple API key authentication	Basic (key rotation required, no granular scopes)
OAuth 2.0 / JWT	Azure AD or any OIDC provider	High (token-based, scoped, time-limited)
Client Certificates	Mutual TLS (mTLS) for service-to-service	High (certificate-based identity)
Managed Identity	APIM authenticating to backend services	High (no credentials in config)

policy.xml: OAuth 2.0 with backend credential forwarding

<inbound>
  <base />

  <!-- Validate the consumer's JWT token -->
  <validate-jwt header-name="Authorization" require-scheme="Bearer"
    output-token-variable-name="jwt">
    <openid-config url="https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration" />
    <audiences>
      <audience>{apim-app-client-id}</audience>
    </audiences>
    <issuers>
      <issuer>https://login.microsoftonline.com/{tenant-id}/v2.0</issuer>
    </issuers>
  </validate-jwt>

  <!-- Extract user info from the validated token -->
  <set-header name="X-User-Id" exists-action="override">
    <value>@(((Jwt)context.Variables["jwt"]).Claims.GetValueOrDefault("oid", "unknown"))</value>
  </set-header>
  <set-header name="X-User-Email" exists-action="override">
    <value>@(((Jwt)context.Variables["jwt"]).Claims.GetValueOrDefault("preferred_username", "unknown"))</value>
  </set-header>

  <!-- Authenticate to the backend using APIM's managed identity -->
  <authentication-managed-identity resource="{backend-app-client-id}" />
</inbound>

Rate Limiting & Throttling

Rate limiting protects your backend services from being overwhelmed by too many requests, whether from legitimate high traffic, misbehaving clients, or denial-of-service attacks. APIM provides two throttling policies: rate-limit (fixed window, per subscription) and rate-limit-by-key (flexible key-based, supports custom dimensions like IP address, user ID, or any header value).

Rate Limiting Strategies

Effective rate limiting requires a layered approach. Apply broad limits at the product level to protect the overall platform, and apply stricter per-operation limits on expensive endpoints like search or bulk operations.

policy.xml: Layered rate limiting

<inbound>
  <base />

  <!-- Global rate limit: 1000 calls/minute per subscription -->
  <rate-limit calls="1000" renewal-period="60" />

  <!-- Per-IP rate limit: 50 calls/minute to prevent abuse -->
  <rate-limit-by-key calls="50" renewal-period="60"
    counter-key="@(context.Request.IpAddress)" />

  <!-- Quota: 10,000 calls/day per subscription -->
  <quota calls="10000" renewal-period="86400" />

  <!-- Conditional stricter limits for anonymous/free tier -->
  <choose>
    <when condition="@(context.Product.Name == "Free Tier")">
      <rate-limit-by-key calls="10" renewal-period="60"
        counter-key="@(context.Subscription.Id)"
        increment-condition="@(context.Response.StatusCode >= 200 && context.Response.StatusCode < 300)" />
    </when>
  </choose>
</inbound>

<outbound>
  <base />
  <!-- Include rate limit headers in the response -->
  <set-header name="X-RateLimit-Limit" exists-action="override">
    <value>1000</value>
  </set-header>
  <set-header name="X-RateLimit-Remaining" exists-action="override">
    <value>@(context.Variables.GetValueOrDefault<string>("remainingCallsPerSubscription", "unknown"))</value>
  </set-header>
</outbound>

Caching & Performance

APIM includes a built-in response cache that can dramatically reduce backend load and improve API response times. By caching responses at the gateway level, subsequent requests for the same resource can be served directly from the APIM cache without reaching the backend at all. APIM supports both an internal cache (included with the service) and an external Redis cache for larger caching needs.

policy.xml: Caching policies

<inbound>
  <base />

  <!-- Look up cached response -->
  <cache-lookup vary-by-developer="false"
                vary-by-developer-groups="false"
                allow-private-response-caching="false"
                must-revalidate="true"
                downstream-caching-type="none">
    <!-- Vary cache by query parameters -->
    <vary-by-query-parameter>page</vary-by-query-parameter>
    <vary-by-query-parameter>pageSize</vary-by-query-parameter>
    <vary-by-query-parameter>filter</vary-by-query-parameter>
    <!-- Vary by custom header (e.g., Accept-Language) -->
    <vary-by-header>Accept-Language</vary-by-header>
  </cache-lookup>
</inbound>

<outbound>
  <base />

  <!-- Store response in cache (only for successful responses) -->
  <cache-store duration="300" />

  <!-- Cache individual values for use in other policies -->
  <cache-store-value key="@("user-profile-" + context.Request.Headers.GetValueOrDefault("X-User-Id", ""))"
                     value="@(context.Response.Body.As<string>())"
                     duration="600" />
</outbound>

Cache Invalidation

Remember the old adage: "There are only two hard things in computer science: cache invalidation and naming things." When using APIM caching, ensure your cache duration is appropriate for the data's freshness requirements. For frequently changing data, use shorter durations (30–60 seconds). For reference data, longer durations (5–30 minutes) are appropriate. Implement cache invalidation in your write operations by using the cache-remove-value policy to clear specific cached entries when the underlying data changes.

Developer Portal Configuration

The APIM Developer Portal is a fully customizable, auto-generated website where API consumers can discover your APIs, read documentation, try API operations interactively, and manage their subscriptions. A well-configured developer portal significantly reduces the support burden on your API team by enabling self-service onboarding and providing comprehensive, always-up-to-date documentation.

Developer Portal Features

API catalog: Browse all published APIs with operation details, schemas, and examples
Interactive console: Test API operations directly from the browser with auto-populated authentication
Subscription management: Request, view, and regenerate subscription keys
User profiles: Self-service registration with email verification or Azure AD SSO
Custom pages: Add getting started guides, change logs, and support information
Branding: Customize colors, logos, fonts, and layouts to match your organization

Terminal: Manage the developer portal

# Publish the developer portal (makes it publicly accessible)
# This must be done from the Azure portal: APIM > Developer Portal > Publish

# Or use the REST API to trigger publishing
az rest --method POST \
  --url "https://management.azure.com/subscriptions/<sub-id>/resourceGroups/rg-api-platform/providers/Microsoft.ApiManagement/service/apim-myorg-dev/portalRevisions/publish-$(date +%Y%m%d)?api-version=2022-08-01" \
  --body '{
    "properties": {
      "description": "Portal update - Added new API documentation",
      "isCurrent": true
    }
  }'

# Configure custom domain for the developer portal
az apim update \
  --resource-group rg-api-platform \
  --name apim-myorg-dev \
  --set hostnameConfigurations[1].hostName=developers.myorg.com \
        hostnameConfigurations[1].type=DeveloperPortal \
        hostnameConfigurations[1].certificateSource=ManagedServiceIdentity

# Enable Azure AD sign-in for the developer portal
# Navigate to: APIM > Developer Portal > Identities > Add Azure Active Directory
# Configure: Client ID, Client Secret, Signin Tenant, Signup Policy

Versioning & Revisions

API versioning and revisions are two related but distinct concepts in APIM. Versionsrepresent breaking changes that require consumers to update their code (like changing the request/response schema). Revisions represent non-breaking changes that can be tested before going live (like adding a new optional field or tweaking a policy). APIM supports both concepts natively.

Versioning Schemes

Scheme	Example	Pros	Cons
URL Path	`/v1/orders`, `/v2/orders`	Clear, easy to understand, works with all tools	URL changes between versions
Query Parameter	`/orders?api-version=2024-01-01`	URL path stays the same	Easy to miss, harder to enforce
Header	`Api-Version: 2024-01-01`	Clean URLs, semantic	Not visible in browser, harder to test

Terminal: Create API versions and revisions

# Create a version set (groups related API versions together)
az apim api versionset create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --version-set-id orders-version-set \
  --display-name "Orders API Versions" \
  --versioning-scheme "Segment"

# Create v1 of the Orders API
az apim api create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id orders-api-v1 \
  --display-name "Orders API" \
  --path orders \
  --api-version v1 \
  --api-version-set-id orders-version-set \
  --service-url "https://backend-v1.azurewebsites.net" \
  --protocols https

# Create v2 of the Orders API
az apim api create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id orders-api-v2 \
  --display-name "Orders API" \
  --path orders \
  --api-version v2 \
  --api-version-set-id orders-version-set \
  --service-url "https://backend-v2.azurewebsites.net" \
  --protocols https

# Create a revision for testing changes before going live
az apim api revision create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id orders-api-v2 \
  --api-revision 2 \
  --api-revision-description "Added pagination support to list operations"

# Test the revision using the revision URL:
# https://apim-myorg-dev.azure-api.net/orders/v2;rev=2/list

# Make the revision current (goes live)
az apim api release create \
  --resource-group rg-api-platform \
  --service-name apim-myorg-dev \
  --api-id orders-api-v2 \
  --release-id release-pagination \
  --api-revision 2 \
  --notes "Released pagination support for list operations"

Monitoring & Best Practices

Monitoring your API Management instance is essential for understanding API usage patterns, detecting issues early, and making data-driven decisions about capacity planning and API evolution. APIM integrates with Azure Monitor to provide metrics, diagnostic logs, and Application Insights telemetry.

Key Metrics to Monitor

Total Requests: Overall API traffic volume and trends
Failed Requests: 4xx and 5xx response rates indicating client or server errors
Backend Response Time: How long backend services take to respond
Overall Duration: End-to-end request processing time (gateway + backend)
Cache Hit Ratio: Effectiveness of caching policies
Capacity: APIM gateway utilization (critical for scaling decisions)

Terminal: Configure APIM diagnostics and monitoring

# Enable Application Insights integration
az apim update \
  --resource-group rg-api-platform \
  --name apim-myorg-dev \
  --set properties.customProperties."Microsoft.WindowsAzure.ApiManagement.Gateway.Reporting.Enabled"="true"

# Create diagnostic settings to send logs to Log Analytics
az monitor diagnostic-settings create \
  --resource /subscriptions/<sub-id>/resourceGroups/rg-api-platform/providers/Microsoft.ApiManagement/service/apim-myorg-dev \
  --name apim-diagnostics \
  --workspace /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-central \
  --logs '[
    {"category": "GatewayLogs", "enabled": true, "retentionPolicy": {"enabled": true, "days": 30}},
    {"category": "WebSocketConnectionLogs", "enabled": true, "retentionPolicy": {"enabled": true, "days": 30}}
  ]' \
  --metrics '[
    {"category": "AllMetrics", "enabled": true, "retentionPolicy": {"enabled": true, "days": 30}}
  ]'

# Query APIM gateway logs using KQL
# Run in Log Analytics:
# ApiManagementGatewayLogs
# | where TimeGenerated > ago(24h)
# | summarize count() by ResponseCode, bin(TimeGenerated, 1h)
# | render timechart

Best Practices Summary

Use policies for cross-cutting concerns: Authentication, rate limiting, caching, CORS, and error handling belong in APIM policies, not in backend code. This keeps backends focused on business logic.
Version from day one: Even if you only have v1, set up versioning from the start. It is much harder to add versioning retroactively.
Use named values for secrets: Store policy configuration values (connection strings, keys, URLs) in APIM Named Values linked to Key Vault, not hard-coded in policy XML.
Implement health endpoints: Create a dedicated health API in APIM that checks backend connectivity, cache status, and policy execution. This enables monitoring and load balancer health probes.
Test policies in the portal: Use the APIM portal's test console to validate policy behavior before deploying. The trace feature shows exactly how each policy modifies the request and response.
Automate with Bicep or Terraform: Define your APIM configuration, APIs, products, and policies as code for repeatable deployments and disaster recovery.

Self-Hosted Gateway

For hybrid and multi-cloud scenarios, APIM offers a self-hosted gateway that runs as a Docker container in any Kubernetes cluster, whether on-premises, in other clouds, or at the edge. The self-hosted gateway connects back to your APIM instance for configuration and reporting but processes API traffic locally. This enables low-latency API access for on-premises consumers and satisfies data residency requirements where API traffic must not leave a specific region.

Azure Functions Hosting Plans Azure Front Door & CDN Guide

Key Takeaways

1APIM provides a unified API gateway with built-in policy engine, developer portal, and analytics.
2Consumption tier offers serverless pricing; Developer and Premium tiers suit different scales.
3Policies enable request/response transformation, rate limiting, caching, and authentication without backend changes.
4OAuth 2.0 and OpenID Connect integration secures APIs with industry-standard protocols.
5The built-in developer portal provides self-service API documentation and testing for consumers.
6API versioning and revisions enable safe API evolution without breaking existing consumers.

Frequently Asked Questions

Which APIM tier should I choose?

Consumption: serverless, pay-per-call, best for low-traffic APIs. Developer: for dev/test with no SLA. Basic/Standard: for production with SLA. Premium: multi-region, VNet integration, highest scale. Start with Consumption or Developer and upgrade as needed.

What are APIM policies?

Policies are XML-based rules applied to API requests and responses. They can transform payloads, add headers, validate JWT tokens, rate-limit calls, cache responses, rewrite URLs, and more. Policies run at inbound, backend, outbound, and on-error stages.

How does APIM differ from Azure Application Gateway?

APIM is an API management platform (API gateway + developer portal + analytics + policies). Application Gateway is a Layer 7 load balancer with WAF. Use APIM for API lifecycle management; use Application Gateway for web application load balancing and security.

Can I use APIM with non-Azure backends?

Yes. APIM can proxy to any HTTP endpoint, including Azure services, on-premises APIs, third-party services, and other cloud providers. You configure the backend URL in the API definition and apply policies for transformation and security.

How much does API Management cost?

Consumption tier: free for first 1 million calls/month, then $3.50/million. Developer: ~$49/month. Basic: ~$152/month. Standard: ~$678/month. Premium: ~$2,794/month per unit. Consumption tier is most cost-effective for low-to-moderate traffic.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.