Azure

VNet Integration, Private Endpoints, and Private DNS

Locking down an App Service or a Function App means two separate pieces of configuration, regional VNet integration and private endpoints, and the names do not make the difference obvious. Inbound and outbound are configured independently, so an application can reach a database over a private address while its own front door is still answering the public internet, or the reverse.

Creating a private endpoint adds a record in a private DNS zone such as privatelink.database.windows.net, and that record is what makes the resource's ordinary public hostname resolve to the private address from inside the virtual network. Clients outside that DNS scope keep resolving the public IP, which is why an identical connection string works from a VM in the VNet and times out from a laptop on VPN or from a server on-premises whose resolver never learned the zone. When something cannot connect, nslookup from the failing client is most of the diagnostic: a public IP in the answer is a DNS problem, a private IP with no connection is routing or a network security group.

• Regional VNet integration. Outbound only. It gives the application a route into your virtual network so it can reach private addresses, and it requires a subnet delegated to it rather than shared with other resources.
• Private endpoint. Inbound to a platform resource. A network interface in your subnet with a private IP, so traffic to that storage account, database, or key vault stays on the virtual network.
• Service endpoint. Also inbound control, but no private IP. The resource keeps its public endpoint and limits access to traffic originating in named subnets. Simpler to configure, and it does nothing for traffic arriving from on-premises.
• Access restrictions on the app itself. IP and service tag rules evaluated on inbound requests to App Service or Functions before your code runs. This is where public access to the application is closed, and the app can take a private endpoint of its own as well.

Deployment Slots and What a Swap Actually Does

Deployment slots are additional hostnames running on the same App Service plan, and that has an immediate consequence: the staging slot shares compute with production, so a load test against staging competes for the same CPU and memory as live traffic. The swap itself is a routing change rather than a deployment. The instance that ends up serving production is exactly the one that was already running in staging.

Application settings and connection strings follow the slot only when they are marked as slot settings. Anything not marked travels with the code during a swap, which is how a staging database connection string reaches production. The swap sequence also matters: Azure applies the target slot's settings to the source instance, restarts it, and waits for it to answer warmup requests, so the application boots once with production configuration while still in staging. Startup work that depends on configuration, such as running migrations or priming a cache, therefore executes against production before any traffic moves. Four other properties of slots decide whether they help or hurt.

• Certificates and custom domains bind to a slot. The staging slot has its own hostname and needs its own binding if you intend to test TLS there.
• The staging hostname is public unless you close it. It resolves on the internet like any other App Service hostname, so access restrictions or authentication belong on it too.
• Function triggers fire in staging. A timer or queue trigger starts running as soon as the slot is configured, so a staging slot pointed at production queues processes real work before any swap happens.
• Swapping back is also only a routing change. It restores which instance serves traffic and undoes nothing the new code already wrote to a database or a queue.

Zone Redundancy, Region Failure, and Backups Are Three Different Things

Availability zones are physically separate facilities within a single region, with independent power and cooling and low latency links between them. Zone redundancy is a property you opt into per resource: a zone-redundant App Service plan, a zone-redundant SQL database, a storage account created as ZRS. It covers the loss of one facility, it is invisible to your connection strings, and for several services it is set at creation, which means enabling it later is a redeployment rather than a setting change.

Backups answer a different question, the one where the infrastructure is healthy and something was deleted or corrupted. Azure SQL takes automatic backups and supports point-in-time restore within a retention window that defaults to seven days, with long-term retention as a separate setting. The restore produces a new database instead of overwriting the original, so the application still has to be pointed at it. Geo-redundant storage copies blobs to a paired region, which protects against losing the bytes and not against a deployment that overwrote them, unless soft delete or versioning is on.

A region failure is the case neither of those covers. Recovering from one means having somewhere else to run, which is a design decision with a standing cost attached rather than a switch to flip. Active-passive with a warm standby, active-active behind a global front end, and restoring from backup into another region after the fact are all defensible answers, but they carry different budgets and different recovery times, and describing all three as disaster recovery is how a plan gets approved without being real. Whichever one is chosen, a second region has to account for four things.

• The application itself. Compute in the second region, deployed by the same pipeline, or the standby drifts until the day it is needed.
• Secrets and certificates. Key Vault is a regional resource. TLS certificates, connection strings, and signing keys have to exist in the second region before the failure, not during it.
• Data and static content. Geo-replication for the database, and whatever the storage replication setting actually is rather than what it was assumed to be. Read access to a secondary copy is not automatic.
• Traffic steering. Front Door or Traffic Manager decides where requests land. Traffic Manager operates at the DNS layer, so client and resolver caching stretches the cutover well past the moment the health probe notices.

Managed Identity Failures and How to Tell Them Apart

A managed identity gets its token from a local endpoint on the host, the instance metadata service on a VM and an environment-provided endpoint on App Service and Functions, which means that code path only exists when the code runs in Azure. DefaultAzureCredential in the Azure SDKs walks a chain of sources and falls back to the developer's signed-in Azure CLI or IDE account, so the same code authenticates on a laptop and fails after deployment. Running the cloud path in a deployed environment early, rather than at release, is what keeps that from being discovered late.

The failures are easy to separate once you read the whole response instead of the status code. A 403 means a token was issued and the role assignment is missing or scoped elsewhere, most often assigned at the resource group when the resource needed it or assigned to a similarly named resource in another environment. A failure to acquire a token at all means the identity is not enabled on the host, or that several user-assigned identities are attached and no client ID was specified, leaving the runtime unable to choose. Assignments are not instant either: a new one takes time to propagate, and tokens already issued keep their old claims until they expire.

Key Vault adds one more branch. Access to a vault is governed either by its own access policies or by Azure RBAC, depending on how the vault was created, and a correctly scoped role assignment has no effect on a vault still running access policies. Checking which permission model the vault uses comes before debugging anything else.

Subscriptions, Resource Groups, and the Choices You Cannot Undo

Scope in Azure is a hierarchy: management group, subscription, resource group, resource. A role assigned at any level applies to everything beneath it, which is why an access review that only inspects assignments on a resource misses everyone holding Owner on the subscription. Quotas mostly sit at the subscription and region level, including vCPU counts per VM family, so a deployment can fail for capacity reasons that have nothing to do with the template being wrong.

A resource group is a deletion and deployment boundary, not a security perimeter on its own. Deleting one deletes everything inside it. Its location stores only its metadata, so it can hold resources in other regions. Moving resources between groups or subscriptions is supported for many resource types and not for all, and the types that cannot move have to be recreated at the destination.

Two decisions are effectively permanent. A resource's region is fixed at creation, so moving to another region means deploying new resources and migrating data rather than changing a setting. And several names are globally unique across all of Azure, including storage account names and the default azurewebsites.net hostname, which is why the naming convention is worth settling before the first environment exists rather than after three of them do.