An application is deployed to Azure App Service and responds at its default azurewebsites.net address, but the public custom hostname still returns a certificate warning. A team fixes DNS and then discovers that its private database is unreachable. Later, someone restores an App Service backup and expects the custom domain, managed identity, and monitoring alerts to reappear automatically. These failures are related to the same application but belong to different configuration boundaries.

Configuring App Service safely requires separating the public hostname and TLS binding, the inbound client path, the outbound connection from the app, and the recoverable application content. These are not synonyms for deploying code or creating an App Service plan. They also involve independent permissions, network routes, DNS ownership, certificates, backup stores, and acceptance tests.

Map the App Service dependencies before changing them

Microsoft’s current Microsoft AZ-104 compute objectives include App Service plans, scaling, TLS certificates, existing custom DNS names, backups, networking settings, and deployment slots. The related App Service release and scaling workflow covers deployment slots and rollback. An administrator securing and recovering a live application must additionally know which independently controlled settings can break user traffic.

Before a production change, record the App Service plan tier, hostname inventory, certificate and DNS ownership, current networking configuration, deployment slots, linked external databases, managed identities, and backup state. A configuration can look complete in one blade while a necessary downstream dependency remains inaccessible.

Map a custom hostname with the correct DNS records

App Service gives a new app a default hostname, but an organization’s domain requires control of its public DNS and a separate hostname mapping. Microsoft’s current custom-domain guide distinguishes a root domain, typically mapped with an A record, from a subdomain, commonly mapped through CNAME to the default App Service hostname. The recommended record type is not a substitute for validating the actual requested domain.

For a company-owned www.example.org site, the operations team should be able to edit the zone’s records and follow the App Service custom-domain validation workflow. The portal also provides a TXT verification record: Microsoft strongly recommends retaining it to reduce domain or subdomain takeover risk. DNS ownership should be verified before traffic is cut over from an old hosting provider, not after an application outage.

Custom domains require an App Service plan tier that supports that feature; the current Microsoft tutorial uses an eligible paid tier. The automatic default azurewebsites.net certificate does not cover every organization’s custom domain. A successful CNAME lookup does not, by itself, establish valid HTTPS, and a certificate bound to the wrong hostname will still fail client name checks.

Bind the right TLS certificate to the right hostname

Once domain mapping and ownership validation are correct, establish the TLS binding for the custom hostname. App Service supports managed certificates and several certificate-import options, each with tier, domain, and renewal limitations. An App Service managed certificate may simplify an eligible basic hostname scenario; a certificate from Key Vault or an externally issued certificate can be appropriate when its key-management and renewal requirements are understood.

Microsoft documents changes to App Service Managed Certificates effective July 28, 2025. The current certificate issuance and renewal restrictions must therefore be checked before choosing a supposedly automatic model. Never publish a procedure based solely on the statement that “Azure always renews it.” Record the responsible person, supported name coverage, expiration, intended binding, renewal procedure and monitoring trigger.

With SNI-based TLS, a hosting endpoint can serve certificates for multiple domains where the App Service tier supports the configuration. IP-based SSL has different plan restrictions. After binding, test the exact hostname with a real HTTPS client, verify subject name coverage and issuer validity, and make sure the expected certificate is served after any DNS changes or slot operations.

Enabling HTTPS Only redirects incoming HTTP requests to HTTPS; it is not the same as creating a valid certificate binding. An application might correctly redirect to HTTPS and still serve an expired or mismatched certificate. Conversely, a certificate can be bound while the application remains publicly available through unwanted hostnames or network access paths.

Distinguish public inbound access from private inbound access

App Service’s default entry point is publicly addressable in common multitenant hosting scenarios. Access restrictions filter incoming requests through that default endpoint. Depending on the service and tier, a private endpoint offers a different entry point through an IP address in the consumer VNet. The Private Endpoint versus service endpoint distinction matters because DNS and the path clients actually use determine which restrictions are evaluated.

Microsoft explicitly documents that App Service access restrictions apply to the default inbound endpoint, not to traffic entering through a private endpoint. Setting an IP rule on the default hostname does not create the same control for the private endpoint path. Private endpoint access requires the right private DNS answer, subnet and route design, and permitted clients. When the requirement is private-only access, review the public network access setting as well.

App Service access restrictions can use allowed or denied IP ranges, Azure service tags, and supported virtual-network service endpoint rules. Their default behavior can change when an allow or deny rule is added. Confirm the unmatched-rule action explicitly instead of assuming that adding a single approved corporate IP restriction left all prior clients unaffected.

For inbound validation, test at least one permitted source and one intentionally unapproved source, and capture which hostname, DNS answer, and path each used. A test from an administrator laptop may reach the public endpoint while the intended app consumer uses a private endpoint. Both paths matter if the design allows them.

Virtual network integration is primarily an outbound feature

Azure App Service virtual network integration lets a running app make outbound calls to resources reachable through a designated virtual network. It does not make the app’s inbound endpoint private. Microsoft documents using a private endpoint for inbound private client access and virtual network integration for reaching private databases, internal APIs and services from the app. These capabilities use different networking paths and have different subnet requirements.

The VNet integration subnet must be in the same region as the App Service, dedicated to the integration scenario and large enough for App Service scale requirements. Microsoft’s current setup documentation sets /28 as a minimum and recommends a /26 or larger for headroom. Plan address capacity before the application scales to additional instances, and confirm tier support rather than copying a sample subnet size from a small test app.

When the app connects to a private SQL endpoint, verify its DNS resolver can return the endpoint’s private address, the integration route reaches that address, and the database’s identity/network rules allow the connection. An integration toggle can be enabled while the destination resolves publicly and the workload times out. The actual application’s connection test provides stronger evidence than a green networking settings pane.

Outbound routing controls affect which destinations leave through the virtual network. When all-traffic routing is enabled, even internet-bound traffic can be directed through the VNet; otherwise some traffic may take the platform’s default path. This influences SNAT, firewall rules, package retrieval, identity services and certificate revocation checks. An overly restrictive outbound policy can make an application appear to fail at startup despite its private backend being reachable.

Diagnose a broken custom domain in a fixed sequence

Imagine a new www.example.org mapping that produces intermittent failures. The operator should determine whether name resolution, hostname ownership validation, the TLS binding, or the running application is responsible. Changing all four controls simultaneously destroys evidence about the original cause and increases rollback risk.

1. Inspect the intended DNS records at the authoritative provider, and confirm that the current client can resolve the requested hostname.
2. Check the App Service custom-domain list and its TXT ownership validation record; do not mistake an unverified hostname for a fully accepted mapping.
3. Confirm the hostname’s TLS binding, selected certificate type, expiration, subject names, and any managed-certificate eligibility constraints.
4. Test HTTPS and the expected response from the app while recording redirects, host headers and whether the traffic entered through a public or private endpoint.
5. Check inbound access restrictions only after confirming the path: a rule affecting the default public endpoint may not affect traffic entering through a private endpoint.
6. Use a controlled rollback that restores the known-good DNS and TLS path without deleting unrelated domains or affecting deployment slots unnecessarily.

These are illustrative checks derived from Microsoft’s first-party procedures, not evidence that an actual company domain was migrated or tested for this article.

Back up the application, not just the deployment package

App Service provides automatic backups and user-configured custom backups for supported pricing tiers, but the two mechanisms are not interchangeable. Microsoft’s current backup guidance lists Basic, Standard, Premium and Isolated among supported automatic and custom backup tiers, while automatic backup retention and scheduling differ from custom backup retention and storage requirements. Verify the feature actually enabled for the plan instead of inferring a recovery point from a generic Backups navigation link.

A custom App Service backup can require a dedicated Azure Storage account/container and uses SAS-based authorization; the current Microsoft documentation states that managed-identity authorization to the storage account is not supported for App Service backup and restore. The backup’s size and service limits also depend on its type. An automatic backup can cover application content and configuration, but restoring one does not recreate everything the app needs in its surrounding Azure environment.

The current Microsoft service documentation states that custom backups will stop including linked databases from March 31, 2028, with earlier changes to the option for new linked-database backup configurations. For a SQL or PostgreSQL dependency, use the database service’s own current native backup and restore tools instead of relying on an App Service archive as proof of complete relational data recovery.

Some connected settings and resources are expressly outside App Service backups. Microsoft lists items such as managed identities, custom domains, TLS/SSL bindings, scale-out configuration, diagnostics and certain monitoring controls as not automatically restored through the backup. This makes an App Service restore different from restoring an integrated production environment. Link the recovery procedure to a broader recovery design and document what must be rebuilt independently.

Choose a meaningful restoration test

An on-demand backup can complete successfully while the recovery configuration remains incomplete. A reliable test selects a supported restore method, verifies the content and app settings that are actually backed up, and checks what happens to linked databases, identity, certificate bindings and network integrations. Restoring into a separate approved app or slot may support a safer test when the chosen tier and service workflow permit it.

A recovery exercise needs more than a backup timestamp. Record the target environment, identity and key requirements, connection strings, database recovery step, custom hostname restoration, certificate availability, and private endpoint or outbound VNet dependencies. The user-facing application should be tested from the right network as part of final acceptance.

If a private storage account or VNet-restricted path hosts custom backup data, Microsoft’s guidance describes additional network configuration for backups over a virtual network. An App Service integration subnet, storage firewall and applicable SAS-based access need to agree. A recent network hardening change can make future backups fail even when the application continues to serve traffic.

Use distinct failure signals to find the broken layer

Use Azure Monitor signals and logs to correlate failure timestamps with the change. HTTP error rates, backend dependency failures, private DNS errors, TLS renewal events and backup job failures can look like one application outage from the user’s perspective; their remedies belong to different owners and configuration resources.

Complete an App Service change with actual client-path evidence

Consider a business application that must serve an HTTPS hostname to customers while accessing a private database. A sufficient rollout plan would first establish domain ownership and the TLS certificate, then validate inbound access, configure outbound network integration and private DNS, and only afterward test backup recovery. It should include a known-good rollback for each step.

A change record should capture the destination hostname, DNS records, binding certificate, allowed client ranges, private endpoint use, integration subnet, outbound routing, database role, backup scope and on-call owner. The administrator should document the expected evidence: the correct certificate is presented to a browser, the app responds via the intended hostname, a private backend query succeeds from the app, an unauthorized inbound client is rejected as intended, and the recovery plan can restore meaningful service.

App Service administration is not complete when a deployment slot swaps successfully or the portal displays a green check beside a configuration setting. The task is to make hostname ownership, TLS, inbound controls, outbound dependencies and recoverable content agree with one another, and to demonstrate that agreement through a real user path whenever the organization’s test environment permits it.

• < Azure VM Encryption at Host and Resource Moves
• Microsoft AZ-104 Practical Lab: Secure and Recover an Azure Workload >