0Pricing
Cloud & IT Cert Prep · Lesson

Autoscaling and Custom Domains

Configure scale-out rules based on CPU and HTTP queue metrics, map a custom domain to your web app, and bind a free App Service Managed Certificate.

Autoscaling and Custom Domains is a free Cloud & IT Cert Prep lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cloud & IT Cert Prep learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Why Autoscaling Matters

Autoscaling automatically adjusts the number of App Service instances running your application based on real-time demand. Without autoscaling, you must provision for peak load and pay for idle capacity during off-peak hours. With autoscaling, Azure adds instances when load rises and removes them when it drops, optimising both performance and cost. Autoscaling requires Standard tier or above.

Scale-Out vs Scale-Up

Azure offers two scaling dimensions. Scale out (horizontal scaling) adds more identical instances of your app to share the load — this is what autoscaling primarily does. Scale up (vertical scaling) moves to a larger VM size with more CPU and RAM by changing the App Service plan SKU. Scale-out is preferred for resilience because multiple instances can survive individual failures; scale-up has hardware limits.

# Scale out to 5 instances manually
az appservice plan update \
  --name MyAppServicePlan \
  --resource-group MyRG \
  --number-of-workers 5

# Scale up: change the SKU tier
az appservice plan update \
  --name MyAppServicePlan \
  --resource-group MyRG \
  --sku P2V3

Autoscale Rules and Profiles

Autoscale in Azure is configured through autoscale settings attached to an App Service plan. An autoscale setting contains one or more profiles (regular, fixed-date, recurrence) each containing rules. A scale-out rule fires when a metric exceeds a threshold (e.g., CPU > 70%); a scale-in rule fires when it falls below a lower threshold (e.g., CPU < 30%). Always define both scale-out and scale-in rules to avoid runaway growth or excessive cost.

# Create an autoscale setting with CPU-based rules
az monitor autoscale create \
  --name MyAutoscale \
  --resource-group MyRG \
  --resource MyAppServicePlan \
  --resource-type Microsoft.Web/serverfarms \
  --min-count 2 \
  --max-count 10 \
  --count 2

# Add scale-out rule: CPU > 70% for 5 minutes
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale out 2 \
  --condition 'CpuPercentage > 70 avg 5m'

Schedule-Based Autoscaling

Schedule-based autoscaling (recurrence profiles) lets you pre-scale for predictable traffic patterns. For example, scale out to 10 instances every weekday at 08:00 and scale back to 2 at 18:00. Combining schedule-based and metric-based profiles gives you the best of both: pre-scaled capacity for known peaks and elastic response to unexpected spikes.

# Add a recurrence profile for weekday peak hours
az monitor autoscale profile create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --name 'WeekdayPeak' \
  --min-count 5 \
  --max-count 15 \
  --count 5 \
  --recurrence week mon tue wed thu fri \
  --start 08:00 \
  --end 18:00 \
  --timezone 'UTC'

Cooldown Periods

A cooldown period is a delay after a scaling action during which no further scaling occurs. It prevents thrashing — rapid repeated scale-out or scale-in triggered by transient metric spikes. The default cooldown is 5 minutes for scale-out and 5 minutes for scale-in. Set a longer cooldown for scale-in (e.g., 10-15 minutes) to give instances time to drain active connections before being removed.

# Scale-in rule with 10-minute cooldown
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale in 1 \
  --condition 'CpuPercentage < 30 avg 10m' \
  --cooldown 10

Configuring a Custom Domain

App Service apps get a default azurewebsites.net hostname. To use your own domain (e.g., www.contoso.com), add a custom domain in the App Service settings and create the corresponding DNS records at your domain registrar. You need to prove ownership by creating a CNAME or TXT record (called a verification record) in your DNS zone, and then create the actual routing CNAME or A record.

# DNS records at your registrar:
# CNAME  www           MyUniqueWebApp.azurewebsites.net
# TXT    asuid.www     <verification_id from Azure portal>

# After DNS propagation, add the custom domain in Azure
az webapp config hostname add \
  --webapp-name MyUniqueWebApp \
  --resource-group MyRG \
  --hostname www.contoso.com

TLS Certificates for Custom Domains

Once a custom domain is mapped, you need a TLS certificate to enable HTTPS. App Service offers three options: App Service Managed Certificate (free, auto-renewing, limited to standard domains), App Service Certificate (purchased through Azure, stored in Key Vault), or third-party certificate upload (your own cert from Let's Encrypt or a CA). HTTPS-only mode redirects all HTTP traffic to HTTPS automatically.

# Create a free App Service Managed Certificate
az webapp config ssl create \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --hostname www.contoso.com

# Bind the certificate to enforce HTTPS
az webapp config ssl bind \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --certificate-thumbprint <THUMBPRINT> \
  --ssl-type SNI

# Enforce HTTPS only
az webapp update \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --https-only true

HTTP Queue Metrics for Autoscaling

While CPU is a common autoscale metric, HTTP queue length is often a better signal for web applications. When the queue length is high, new requests are waiting because instances are fully occupied. Scaling based on HttpQueueLength detects overload faster than CPU, since CPU can fluctuate without necessarily indicating user-facing latency. Use both metrics together for robust autoscale behaviour.

# Scale out when HTTP queue length exceeds 100
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale out 2 \
  --condition 'HttpQueueLength > 100 avg 1m' \
  --cooldown 5

# Scale in when queue drops below 10
az monitor autoscale rule create \
  --autoscale-name MyAutoscale \
  --resource-group MyRG \
  --scale in 1 \
  --condition 'HttpQueueLength < 10 avg 10m' \
  --cooldown 10

Autoscale Notifications

Configure autoscale notifications to receive email or webhook alerts when scaling events occur. This helps teams understand traffic patterns and verify that autoscale is behaving as expected. Notifications are configured in the autoscale setting's notification section and can target multiple email addresses and webhook endpoints (for integration with Slack, PagerDuty, or custom tools).

# Add email notification to autoscale setting
az monitor autoscale update \
  --name MyAutoscale \
  --resource-group MyRG \
  --add-condition '{"email": {"sendToSubscriptionAdministrator": true, "customEmails": ["ops@contoso.com"]}, "webhooks": []}'

Apex Domains and Traffic Manager

Mapping an apex domain (e.g., contoso.com without www) to App Service requires an A record pointing to the App Service IP address, plus a TXT verification record. Because App Service IPs can change, Microsoft recommends using Azure Traffic Manager or Azure Front Door as an intermediary — the apex domain CNAME-equivalent (ALIAS/ANAME record) points to the Traffic Manager profile, which routes to App Service.

# Get the App Service inbound IP (for A record)
az webapp show \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --query 'inboundIpAddress' -o tsv

# DNS at registrar (apex domain with A record approach)
# A      contoso.com     <inboundIpAddress>
# TXT    asuid           <verification_id>

Testing Autoscale Behaviour

After configuring autoscale, test that it works correctly by generating artificial load. Use tools like Apache JMeter, k6, or Azure Load Testing to simulate concurrent users. Watch the App Service plan's Instance count metric in Azure Monitor to confirm instances increase when load rises and decrease when it subsides. Document the observed RPS (requests per second) per instance to validate your scale thresholds.

# Run a quick load test with curl (basic)
for i in {1..100}; do curl -o /dev/null -s https://www.contoso.com/health & done
wait

# Monitor current instance count
az monitor metrics list \
  --resource '/subscriptions/.../providers/Microsoft.Web/serverfarms/MyAppServicePlan' \
  --metric 'InstanceCount' \
  --interval PT1M

Quick Check

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

Lesson Recap

In this lesson you learned: autoscale rules on App Service plans add or remove instances based on CPU, HTTP queue, or schedule triggers, custom domains require DNS CNAME/A records plus a TXT verification record in your DNS zone, and TLS certificates (including free managed certificates) enable HTTPS on custom domains. Next up we explore App Service authentication and networking.

Frequently asked questions

Is the “Autoscaling and Custom Domains” lesson free?

Yes — the full text of “Autoscaling and Custom Domains” is free to read here on the web, and the Cloud & IT Cert Prep course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cloud & IT Cert Prep course, upgrade to CoddyKit PRO.

What will I learn in “Autoscaling and Custom Domains”?

Configure scale-out rules based on CPU and HTTP queue metrics, map a custom domain to your web app, and bind a free App Service Managed Certificate. You practise Cloud & IT Cert Prep with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cloud & IT Cert Prep?

No prior experience is required. Cloud & IT Cert Prep on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Autoscaling and Custom Domains” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cloud & IT Cert Prep lesson?

Yes. Every Cloud & IT Cert Prep lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Creating an App Service Plan and Web App
  2. Deployment Slots and Swap
  3. Autoscaling and Custom Domains
  4. App Service Authentication and Networking
← Back to Cloud & IT Cert Prep