Azure App Service Plans Explained: DNS, HTTPS Bindings, Slots, and Scaling Rules

Blog Draft: Managing Azure App Service Plans (Custom Domains, TLS, Slots, Scaling) for AZ-104

What you’ll learn

By the end of this guide, you’ll be able to:

• Map a custom domain to an Azure Web App using the right DNS records
• Add HTTPS using either a managed certificate or your own certificate
• Use deployment slots to release updates safely with swap
• Scale your app correctly using scale up and scale out (manual, autoscale rules, and App Service automatic scaling)

---

Prerequisites

What you need

• An existing App Service (Web App) running in Azure
• A domain you control (example: contoso.com)
• Access to the domain’s DNS provider (could be Azure DNS, Cloudflare, GoDaddy, etc.)
• An App Service Plan tier that supports the features you want:
  • Custom domains: generally available
  • TLS/SSL binding: requires Basic or higher in most cases
  • Deployment slots: requires Standard or higher
  • Autoscale: depends on SKU and configuration approach

[Screenshot: App Service Overview blade showing URL, resource group, and App Service Plan]

---

1) Add a Custom Domain (DNS + Validation)

Why this matters

Your web app starts with a default hostname like:

• https://<appname>.azurewebsites.net

A custom domain gives you:

• Branding and trust: https://www.contoso.com
• Cleaner URL structure for end users

Portal path

Azure portal → App Services → your app → Custom domains → Add custom domain

Step 1: Choose the hostname you want

Common choices:

• www.contoso.com (subdomain)
• contoso.com (apex / root domain)

Step 2: Add DNS records at your DNS provider

Azure will show you exactly what it expects. In most real deployments, you’ll add:

• A mapping record (A or CNAME)
• A verification TXT record (asuid...)

Option A: Map www.contoso.com (recommended starting point)

Use a CNAME for www.

Example:

• CNAME
  • Name: www
  • Value: <appname>.azurewebsites.net
• TXT
  • Name: asuid.www
  • Value: <verification-id-from-azure>

Option B: Map the apex domain contoso.com

Apex domains typically require an A record.

Example:

• A
  • Name: @
  • Value: <app-ip-from-azure>
• TXT
  • Name: asuid
  • Value: <verification-id-from-azure>

Step 3: Validate and add

Back in Azure:

1. Select Validate
2. Wait for green checks (DNS propagation may take time)
3. Select Add

[Screenshot: Validation results showing green checkmarks]

Quick verification

• Browse to your new hostname (HTTP first is fine)
• Confirm it loads the correct app

---

2) Secure the Domain with HTTPS (TLS/SSL Binding)

What you’ll see after adding the domain

Often, Azure shows a warning like:

• “One or more domains are not secured”
• Binding status: No binding

That means your custom domain is mapped, but HTTPS is not configured.

Portal path

App Services → your app → Custom domains → select hostname → Add binding

[Screenshot: Hostname list showing “No binding”]

Option 1: App Service Managed Certificate (simple)

Best for most labs and many production scenarios where limitations are acceptable.

Steps:

1. Add binding
2. TLS/SSL type: SNI SSL
3. Certificate: Create App Service Managed Certificate
4. Add

[Screenshot: Add binding dialog with SNI and managed certificate selected]

Notes you should remember for AZ-104-style scenarios

• Managed cert is convenient, but not universal.
• If issuance stalls, check DNS correctness and potential CAA restrictions at your DNS provider.

Option 2: Bring your own certificate (PFX) or Key Vault

Use this when you need:

• A specific CA
• A wildcard cert
• Centralized cert lifecycle via Key Vault

Steps (high-level):

1. Upload/import certificate in Certificates
2. Return to Custom domains
3. Add binding using your certificate

Validate HTTPS end-to-end

• Open https://www.contoso.com
• Confirm certificate details in the browser
• Optional hardening: configure HTTPS-only and redirect HTTP → HTTPS in app code or configuration

---

3) Deployment Slots (Staging → Test → Swap)

Why slots matter

Slots let you deploy a new version safely without breaking production. You test changes in a staging URL like:

• https://<appname>-staging.azurewebsites.net

Then you swap staging into production.

Portal path

App Services → your app → Deployment slots → Add Slot

Step 1: Create a staging slot

• Slot name: staging
• Clone settings from: production (recommended)

[Screenshot: Add slot dialog with “Clone settings from production”]

Step 2: Deploy to the staging slot

Common patterns:

• GitHub Actions pipeline targets the slot
• Zip deploy
• Azure DevOps release pipeline

Key concept: the slot has its own URL, so you can test safely.

Step 3: Swap

When staging is validated:

1. Go to Deployment slots
2. Select Swap
3. Source: staging
4. Target: production
5. Start swap

Slot settings (sticky settings) you must understand

Some settings should not swap (common examples):

• Connection strings (staging DB vs prod DB)
• Feature flags
• API keys that differ per environment

Mark them as Deployment slot setting so they stay with the slot.

---

4) Scaling the App Service Plan

First, learn the two scaling directions

Scale up

Scale up changes the plan tier/size:

• More CPU and RAM
• More features (depending on tier)

Think: “bigger machine”

Scale out

Scale out changes instance count:

• More instances behind the same app URL

Think: “more machines”

Where scaling happens

You can scale from:

• The App Service Plan (affects all apps in that plan)
• The App itself (still changes the underlying plan behavior)

[Screenshot: App Service Plan blade showing apps sharing the plan]

Scale out modes you’ll see

A) Manual

You set instance count yourself.

• Good for predictable events (product launch, scheduled promotion)

B) Autoscale rules (metric-based or schedule-based)

This is the exam-friendly model:

• Add instances when a metric is high
• Remove instances when a metric is low
• Optionally scale on a schedule

Example rule set

• If CPU > 70% for 10 minutes: +1 instance
• If CPU < 20% for 15 minutes: -1 instance
• Minimum instances: 1
• Maximum instances: 5

Implementation notes

• Always configure both scale out and scale in rules.
• Use sensible cool-down periods to avoid “thrashing.”

C) App Service Automatic scaling (HTTP-based)

Some configurations provide an “Automatic” option that scales based on incoming HTTP traffic characteristics.

• Useful for simple apps when you do not want to tune metrics
• Still requires you to define ceilings and readiness levels

---

Common Troubleshooting (Fast Fixes)

Custom domain validation fails

Check:

• TXT record name is correct (asuid or asuid.<subdomain>)
• CNAME points to <appname>.azurewebsites.net (not your vanity name)
• A record points to the IP Azure provided
• DNS propagation has completed

Custom domain works but HTTPS shows “No binding”

Check:

• You actually created and attached a certificate binding to that hostname
• The plan tier supports TLS binding
• The certificate issuance is complete (managed cert can take time)

Swap completed but production looks wrong

Check:

• App settings and connection strings that were not marked as slot settings
• Any environment-specific values overwritten by the swap

Autoscale not triggering

Check:

• Metric time range and aggregation settings
• Cooldown too long
• Thresholds unrealistic (CPU rarely hits configured values)
• Minimum/maximum instance limits blocking action

---

AZ-104 Exam Notes to Memorize

• Custom domain mapping requires correct DNS plus verification TXT in many scenarios.
• TLS binding is a separate step from adding the domain.
• Deployment slots are a Standard+ feature and provide a clean staging URL.
• Swap exchanges slot content and most settings unless marked as slot-specific.
• Scale up changes SKU/size. Scale out changes instance count.

---

Mini-Quiz (AZ-104 Style)

Questions

1. You mapped www.contoso.com to an App Service. Which DNS record is most common for www?
2. After adding a custom domain, Azure shows “No binding.” What is missing?
3. Your team needs a staging environment with a separate URL and a zero-downtime cutover. What feature should you use?
4. You want to ensure staging uses a test database and production uses the real database even after swap. What must you configure?
5. Which scaling option increases CPU/RAM per instance?
6. Which scaling option increases the number of instances?
7. You configured autoscale to add instances when CPU > 70%. What rule should you add next for stability?
8. Multiple web apps share the same App Service Plan. If you scale out the plan, what happens?

Answer key

1. CNAME pointing www → <appname>.azurewebsites.net
2. TLS/SSL binding is missing (certificate not bound to the hostname)
3. Deployment slots (staging slot + swap into production)
4. Mark the DB connection string or setting as a deployment slot setting (sticky setting)
5. Scale up
6. Scale out
7. Add a scale-in rule (example: CPU < 20% then remove 1 instance) plus cooldown
8. The plan scales out, so all apps in that plan benefit from added instances (shared compute pool)

---