One customer's App Service environment
An App Service Environment (ASE v3) is a single-tenant deployment of the App Service platform in a dedicated subnet of your virtual network. You still create App Service plans and apps, but the environment is reserved for your organization. Single-tenant service does not automatically mean physical-host isolation: if a requirement calls for dedicated physical hosts, choose and price the separate dedicated-host ASE option.
ASE apps can reach resources on their VNet without regular App Service's separate outbound VNet integration setup. Inbound access depends on the ASE configuration: an internal VIP gives an internal address, while an external VIP has a public-facing address. Merely choosing an ASE does not make the app unreachable from the internet. Select and test the inbound model that matches the requirement.1
What ASE v3 actually buys — and what it costs
An ASE can meet a requirement for a single-tenant platform, VNet-level control, or high scale. Microsoft documents up to 100 instances for one Isolated v2 plan and up to 200 across an ASE v3. Those are ceilings to verify against the current service limits, not goals for a small app. Dedicated physical hosts are available when that exact requirement exists.
Cost is different too. Isolated v2 plan instances are paid capacity. Even an empty standard ASE v3 has a minimum charge equivalent to one Windows I1v2 instance. A dedicated-host ASE starts with a separate host-based charge. Estimate the chosen deployment type and region before creating one; the empty environment does not scale its bill to zero.
Name the isolation requirement before choosing the environment.
The cheaper answer that usually wins
Many teams need private connections, not a single-tenant environment. On ordinary App Service, VNet integration handles outbound calls from the app to private resources. A private endpoint gives clients a private inbound path to the app. To require private-only inbound access, also verify that public network access is disabled and that private DNS resolves correctly.2 These features do not provide a single-tenant platform or dedicated physical hosts.
Work through the direction of travel first. If the app calls a private database, examine outbound VNet integration and the database's private endpoint and DNS. If users must reach the app privately, examine an inbound private endpoint, public-access setting, and DNS. If a written requirement calls for a single-tenant App Service platform, ASE-scale limits, or physical dedicated hosts, compare ASE options. Each requirement points to a different feature; do not buy a whole environment merely because someone says “private.”
| Approach | Hosting model | Gives you | Reach for it when |
|---|---|---|---|
| App Service + VNet integration | Multitenant platform | Outbound path to private resources, when routing and DNS work | The app must call a private database or system |
| App Service + Private Endpoint | Multitenant platform | Private inbound when public access is disabled and DNS works | Clients must reach the app privately |
| App Service Environment (ASE v3) | Single-tenant platform; optional dedicated hosts | VNet deployment and higher scale; internal or external inbound choice | A named platform, network-control, or scale requirement warrants it |
Play it through
Three minutes. Separate outbound database access from private-only inbound admin access, then compare an ASE with the smaller network changes. It pauses for your decisions.
When an ASE is genuinely the right call
An ASE is a reasonable answer when a documented requirement calls for a single-tenant App Service platform, its specific network controls, or scale beyond an ordinary plan. If the document requires physical-host isolation, price the dedicated-host deployment specifically; a standard ASE should not be described as equivalent. If inbound access must be private, select an internal VIP and verify DNS and routes.
Write the exact requirement and the feature that satisfies it. “The app must call a private database” is an outbound connectivity requirement. “The app must not accept public requests” is an inbound access requirement. “The platform must be single tenant” is a hosting requirement. Those are different decisions, and naming them prevents an expensive category error.
Campux asks for an ASE, and you talk them out of it
A security consultant tells Campux the storefront "should be on dedicated infrastructure for the payment flow," and someone forwards you a quote for an App Service Environment. You do not just say no; you ask what the requirement actually is. It turns out to be two concrete things: the app must reach the order database, which has no public endpoint, and the admin interface must not be reachable from the public internet. Neither of those needs dedicated hardware.
On the Standard storefront, outbound VNet integration can let the app reach a database private endpoint when routing and DNS are set correctly. For the admin app, configure its own private endpoint, disable public network access, and verify access from both inside and outside the network. This satisfies the stated connectivity goals on ordinary App Service. If a later control requires a single-tenant platform or dedicated physical hosts, revisit the matching ASE deployment. The read-only ASE Bicep lab shows how to inspect the template without creating billable resources.
Holding the whole App Service picture
Part A sized the App Service plan. Part B put apps on it and covered deployment slots, HTTPS, and settings. This part asks a different question: what kind of isolation does the app need? A private database connection is outbound networking. A private-only admin app is inbound networking. A single-tenant platform is a hosting choice. Write down which one is required before changing the platform.
Parts 11d and 11e move to virtual machines, where your team controls more of the operating system and also maintains more of it. Part 11f compares the options using written requirements. Carry this habit forward: explain what each feature solves, then test that it actually solves it.
Reading the quote before you sign it
A consultant recommends an ASE for “isolation.” You ask which traffic must be private. The storefront needs outbound VNet integration, plus the database's private endpoint and DNS. The admin app needs its own inbound private endpoint, public network access disabled, and private DNS. Test both paths. Keep the ASE quote for a written single-tenant or ASE-specific requirement; ask separately whether physical dedicated hosts are required.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. An ASE v3 is single-tenant App Service deployed into your VNet. Apps still use plans and slots. Physical dedicated hosts require the separate dedicated-host deployment choice. An ordinary ASE can also have an external public-facing inbound address, so decide inbound access separately.
B. The private endpoint supplies the inbound private address. Disable public network access and verify DNS to enforce private-only reachability. A standard ASE is not automatically private inbound: an external-VIP deployment is public-facing. Premium sizing and HTTPS Only do not answer this network-access requirement.
Isolated v2 capacity, networking options without ASE, and a single-tenant platform in your VNet are true. The dedicated-host choice is separate. ASE does not discard the App Service model: plans, apps, and slots still apply. A small private app can often use ordinary App Service with an inbound private endpoint and public access disabled.
DESIGN MEMO — why an ASE
1. A written control requires a single-tenant App Service platform.
2. We need the app to reach a private database with no public endpoint.
3. We expect to run well over a hundred instances at peak.
4. We accept Isolated v2 rates around the clock for this workload.
Line two. Ordinary App Service can use outbound VNet integration to reach a private database endpoint when routing and DNS are configured. Line one names a single-tenant platform requirement; line three needs comparison against current scale limits; line four is a budget note, not a technical requirement. If the control instead demanded physical-host isolation, price the dedicated-host ASE option specifically.
Consider the consequence. If line two is allowed to stand as a justification, it quietly does the persuading — a reviewer skims four plausible reasons and approves the ASE, when really only the mandate and the scale numbers carry it, and a much smaller app could have ridden VNet integration on a Standard plan. Being able to strike the reason that does not require the tool is how you stop a good tool from being oversold into the wrong job.
Concede the seriousness before you complicate it. The stakeholder is right that payment workloads deserve stronger isolation than a throwaway app, and treating them carefully is exactly correct. Do not answer as if their caution is silly; answer as if their caution is right and the ASE is one of several ways to honour it. That keeps the conversation about the requirement rather than about who is more security-minded.
Turn “secure” into testable requirements. For private inbound access, configure a private endpoint, disable public access, and verify DNS. For outbound access to a private database, configure VNet integration and the database's private path. A single-tenant platform requirement points toward ASE; a physical-host requirement points to its dedicated-host option. Check the actual payment controls with the security and compliance owners.
Price the chosen design. An ASE may be justified, but no one feature makes a payment application compliant by itself. Compare the exact control, hosting option, network paths, operating cost, and evidence you can present to an auditor.
Grant that it works, then reframe the question. "It works fine" is true — an ASE will happily run a small reporting app. But working is not the bar; a plain VM would also run it, and so would a Standard plan. The real question your manager is asking is whether the ASE's cost is buying anything this workload needs, and for a few dozen internal users a day, the honest answer is almost certainly no.
Check what is being paid for. Isolated v2 workers and an empty-environment minimum can create a standing charge even at low traffic. Do not assume it bought physical-host isolation or private inbound access; inspect the deployment type and internal/external VIP.
Compare before migrating. Confirm written controls, current costs, networking, DNS, data dependencies, and required scale. If ordinary App Service plus private networking meets them, plan a tested migration and retire the ASE only after the replacement works. If a single-tenant or dedicated-host requirement remains, keep or adjust the ASE accordingly.
Five things worth carrying out of Part C
- ASE v3 is a single-tenant App Service platform in your VNet; physical dedicated hosts are a separate deployment choice.
- Internal and external VIPs have different inbound exposure. An empty ASE also has a minimum charge; Isolated v2 instances do not scale to zero.
- Most of the private-networking benefit is available on ordinary App Service through VNet integration (outbound) and Private Endpoints (inbound).
- Use an ASE when a documented platform, scale, or network-control need warrants it; choose dedicated hosts only if physical isolation is required.
- For private-only ordinary App Service inbound, pair the private endpoint with a verified public-access setting and DNS.
- Microsoft's ASE overview distinguishes its single-tenant platform from optional dedicated physical hosts and internal from external VIPs. Its pricing section describes the empty standard ASE v3 minimum and dedicated-host charges. ↩
- VNet integration is outbound from an ordinary App Service app. An inbound private endpoint needs the public-access setting and DNS checked to establish private-only access. ↩
Distinguish an ASE's single-tenant platform from dedicated hosts and private networking on ordinary App Service.
Play the lesson above to stamp this class.