CH08-03: Managed Web Hosting with App Service and Container Apps

Goal

The previous section explained how traffic enters the application. Now the request has reached the application layer. The next decision is where the web code or API code should run.

For many Azure web applications, the first managed hosting choices to consider are Azure App Service and Azure Container Apps. Both can run web-facing workloads. They are not the same operating model.

The durable idea is:

The web hosting layer should match the deployment shape and operating responsibility of the application.

The Short Version

The hosting layer runs the application code that receives requests and returns responses. It may host a web UI, an API, a backend-for-frontend, a small service, or a containerized component.

Azure App Service is a managed platform for hosting web applications and APIs. It is often a strong fit when the team wants to deploy application code or containers to a web hosting platform with built-in features such as custom domains, TLS, scaling, deployment slots, health checks, authentication integrations, and platform-managed infrastructure.

Azure Container Apps is a managed container application platform. It is often a strong fit when the team packages the workload as containers and wants features such as container revisions, ingress, service-to-service communication, event-driven scaling, jobs, and managed platform abstraction without operating Kubernetes directly.

The practical question is not:

Which service is newer?

The better question is:

Does this workload want managed web hosting, managed container hosting, or a deeper platform control model?

The Runtime Decision

Start with the shape of the application component:

flowchart TD
    A["What is the runtime shape?"]
    B["Static files only?<br/><small>HTML, CSS, JS, images</small>"]
    C["Managed web app or API?<br/><small>Framework app, web process, standard deployment</small>"]
    D["Containerized service?<br/><small>Image-based deployment, container dependencies</small>"]
    E["Kubernetes platform needed?<br/><small>Kubernetes APIs, ecosystem, cluster control</small>"]
    F["Static hosting option"]
    G["App Service"]
    H["Container Apps"]
    I["AKS"]

    A --> B --> F
    A --> C --> G
    A --> D --> H
    D --> E --> I

This is a starting model. Real decisions include networking, deployment, scaling, governance, team skills, and reliability needs. But it prevents a common mistake: treating every web workload as if it needs the same runtime platform.

App Service as Managed Web Hosting

App Service is often the natural starting point for conventional web applications and APIs.

It fits well when:

• The application is a web app or API built with a common framework.

• The team wants managed hosting without managing servers or Kubernetes.

• Deployment slots would help with safer releases.

• Built-in custom domain, TLS, scaling, backup, health check, and monitoring integrations are useful.

• The team wants a platform that is familiar to application developers and operations teams.

App Service can be used for serious production applications. Do not dismiss it because it feels simpler than Kubernetes. Simpler is often the correct architecture when the workload does not need cluster-level control.

The team still owns important decisions: runtime configuration, identity, networking, secrets, deployment pipeline, scaling settings, logs, alerts, dependency health, and cost. Managed hosting reduces infrastructure work. It does not remove architecture work.

Container Apps as Managed Container Hosting

Container Apps is often a strong fit when containers are part of the application model, but Kubernetes itself is not the goal.

It fits well when:

• The team already builds container images.

• The application has one or more containerized APIs, web services, workers, or jobs.

• Scaling may depend on HTTP traffic, events, CPU, memory, or queue-like signals.

• Revisions and traffic splitting help release new versions safely.

• The team wants service-to-service communication patterns without managing a Kubernetes cluster.

• The organization is not ready to operate AKS for this workload, or does not need to.

Container Apps uses Kubernetes-based technology behind the scenes, but it intentionally hides direct Kubernetes operations. That abstraction is part of the value. If the team needs Kubernetes APIs, custom controllers, cluster-level policy, node pools, service mesh standards, or a shared Kubernetes platform, AKS may be the better fit.

App Service and Container Apps Compared

This comparison is not about which service is better. It is about which operating boundary matches the workload.

Where AKS Fits

AKS can host web applications too, but it should usually enter the conversation because Kubernetes control is required, not merely because the application is containerized.

AKS may fit when:

• The organization has a platform team that runs Kubernetes as a shared product.

• Teams need Kubernetes APIs, Helm charts, operators, service mesh patterns, or cluster-level policy.

• Workloads require scheduling, networking, security, or ecosystem capabilities that App Service or Container Apps do not provide.

• Portability across Kubernetes environments is a real requirement.

AKS adds power and responsibility. Someone must own clusters, upgrades, node capacity, ingress, network policy, secrets integration, observability, workload identity, and platform governance. For a single web app or small API, that may be more platform than the team needs.

Example: Web Portal and Containerized API

Imagine a team building a customer portal. The main portal is a .NET web application that deploys cleanly as a standard web app. The account API is already packaged as a container because it shares a container build pipeline with other services.

A reasonable first-pass design might be:

Front Door with WAF
  -> App Service: customer web portal
  -> Container Apps: account API container
  -> Azure SQL and Blob Storage dependencies

This is not inconsistent. One application architecture can use more than one runtime when components have different shapes. The important thing is that the team can explain why each runtime exists.

If the API does not need container packaging, App Service might be simpler. If the API is one of many Kubernetes-standard services run by a platform team, AKS might be justified. If the portal becomes a static single-page app with a separate API, the front end might move to static hosting while the API remains on App Service or Container Apps.

Common Mistakes

• Choosing containers only because containers sound more modern.

• Assuming App Service is too simple for serious applications.

• Moving to AKS before the team needs Kubernetes control.

• Treating the hosting service as the whole architecture.

• Forgetting that runtime choice affects networking, identity, deployment, observability, scaling, and cost.

• Forcing every component into one hosting model even when the components have different jobs.

If Someone Asks You

How do you choose between App Service and Container Apps for a web workload?

A good answer is:

I choose App Service when the workload is a conventional web app or API that fits managed web hosting and benefits from platform features such as deployment slots, custom domains, scaling settings, and integrated operations. I choose Container Apps when the workload is naturally containerized and the team wants managed container hosting, revisions, traffic splitting, and event-based scaling without operating Kubernetes directly. I move toward AKS only when Kubernetes control is part of the requirement.

What You Should Remember

Choose web hosting by deployment shape, runtime needs, scaling behavior, and operating responsibility.

Questions to Check Your Understanding

1. What does App Service manage for a team?

2. What does Container Apps add for containerized workloads?

3. Why is Kubernetes not automatically required for web containers?

4. Why might one web architecture use more than one runtime option?