CH08-06: Web Application Architecture Scenario

Goal

This section applies the Chapter 8 model to one realistic design. The goal is not to memorize one perfect diagram. The goal is to practice explaining why each layer exists and how the trade-offs fit together.

The scenario is a subscription-based education platform. It needs a public portal, an account API, document storage, relational subscription data, safe releases, private data access, WAF protection, monitoring, and clear support ownership. The team is small, so the design should avoid platform complexity unless the requirements justify it.

The durable idea is:

A strong web architecture can explain every layer from user entry to runtime, data dependency, protection, deployment, monitoring, and cost.

The Scenario

The product team is building an education platform for paying customers.

Users can:

• Visit the public portal.

• Sign in and manage subscriptions.

• Download course documents.

• Upload required forms.

• Call account and billing APIs through the web UI.

The business constraints are ordinary but important:

• The platform will start in one primary Azure region.

• Public traffic must use HTTPS and WAF protection.

• Subscription data should use a managed relational database.

• Documents should use object storage.

• Data dependencies should not be broadly exposed through public network paths.

• Releases should be safe enough for frequent product changes.

• A small platform team owns cloud operations, so AKS should not be the first answer unless Kubernetes is genuinely needed.

• Cost must stay understandable by workload and environment.

Step 1: Walk the Request Path

Start with the plain request path before naming every Azure service:

Customer browser
  -> Public HTTPS entry and WAF
  -> Web portal
  -> Account API
  -> Subscription database
  -> Document storage
  -> Logs, metrics, alerts, deployment controls, cost owners

This already reveals the main responsibilities. The design needs entry, protection, hosting, data, secure access, deployment, observability, and cost ownership.

Step 2: Choose a First-Pass Architecture

A reasonable first-pass Azure architecture could look like this:

flowchart LR
    U["Customers"]
    FD["Azure Front Door<br/><small>Custom domain, TLS, WAF, routing</small>"]
    WEB["App Service<br/><small>Customer portal</small>"]
    API["App Service or Container Apps<br/><small>Account API</small>"]
    ID["Managed identities"]
    KV["Key Vault<br/><small>Secrets and certificates</small>"]
    SQL["Azure SQL Database<br/><small>Subscription data</small>"]
    ST["Blob Storage<br/><small>Documents</small>"]
    PE["Private endpoints + private DNS"]
    MON["Azure Monitor + Application Insights<br/><small>Logs, metrics, traces, alerts</small>"]
    COST["Budgets, tags, owners"]

    U --> FD
    FD --> WEB
    FD --> API
    WEB --> ID
    API --> ID
    ID --> KV
    WEB --> PE
    API --> PE
    PE --> SQL
    PE --> ST
    WEB --> MON
    API --> MON
    SQL --> MON
    ST --> MON
    FD --> MON
    FD --> COST
    WEB --> COST
    API --> COST
    SQL --> COST
    ST --> COST

This diagram is still a teaching diagram. It does not show every subnet, private DNS zone, deployment pipeline, or alert rule. It shows the responsibility path well enough for a design conversation.

Why These Services Fit

The architecture is intentionally managed. It gives the product team a production-capable path without making Kubernetes the default operating model.

Step 3: Explain the Important Alternatives

The recommendation is not the only valid answer. A strong architecture explanation names alternatives and why they may or may not fit.

Front Door or Application Gateway

Front Door is a strong first-pass choice when the team wants global edge entry, WAF at the edge, TLS, and future room for health-based routing across regions or origins.

Application Gateway may be a better fit if the application is primarily regional, must sit behind a regional gateway inside a virtual network pattern, or must follow an enterprise standard for private backend delivery.

Some mature designs use both:

Users
  -> Front Door for global edge and WAF
  -> Application Gateway for regional private routing
  -> Web/API runtime

That can be valid, but it adds cost and operational work. The team should be able to explain why both layers are needed.

App Service or Container Apps

For the web portal, App Service is a strong starting point because the application is a standard web workload and the team wants managed hosting.

For the account API, the decision depends on deployment shape:

• If the API deploys as a normal application package and needs straightforward managed web hosting, App Service keeps the model simple.

• If the API is already containerized, needs revision traffic splitting, or will sit beside other containerized services and workers, Container Apps may fit better.

• If the organization has a Kubernetes platform team and the API must use Kubernetes APIs, policies, or ecosystem tools, AKS may become appropriate.

The small platform team is an important signal. AKS is powerful, but it would add cluster operations before this scenario clearly needs them.

Blob Storage or Application Runtime for Static Content

If much of the portal is static content, the team should consider static hosting patterns. Static files such as HTML, CSS, JavaScript bundles, images, and public downloads do not always need a full web application runtime.

A possible variation is:

Front Door
  -> Static content from Blob Storage or a static hosting service
  -> API on App Service or Container Apps

This can reduce runtime complexity for static content. The API still needs identity, data access, monitoring, deployment safety, and cost controls.

Step 4: Add Secure Data Access

For the first version, the platform stores relational subscription data in Azure SQL Database and documents in Blob Storage.

The data access design should include:

• Managed identities for the web portal and API where supported.

• Key Vault for unavoidable secrets, certificates, or external provider keys.

• Private endpoints for Azure SQL, Storage, and possibly Key Vault if policy requires private reachability.

• Private DNS zones linked to the workload network so service names resolve to private addresses.

• Least-privilege authorization for database and storage access.

• Diagnostic logs for denied access, dependency failures, and suspicious patterns.

Private endpoints reduce public exposure. They do not replace authentication, authorization, input validation, database permissions, storage access controls, or application security.

Step 5: Add Production Operations

The design should be explainable during normal operation and during incidents.

For deployment:

• Use App Service deployment slots for the portal if App Service is chosen.

• Use Container Apps revisions and traffic splitting for the API if Container Apps is chosen.

• Keep configuration and secret changes controlled through the pipeline.

• Test rollback and database migration behavior.

For observability:

• Track request rate, latency, errors, exceptions, and dependency failures.

• Watch WAF blocks and false positives.

• Monitor Azure SQL performance and connection failures.

• Monitor Storage errors, latency, and access patterns.

• Alert on symptoms that represent user impact.

For cost:

• Tag resources by workload, environment, owner, and cost center.

• Set budgets and alerts for production and non-production.

• Review log ingestion and retention.

• Watch runtime scale settings and database tier changes.

• Shut down or right-size idle non-production resources where possible.

These decisions make the design more than a service diagram. They make it operable.

A Conversation-Ready Walkthrough

If you need to explain the design quickly, walk the path in order:

Customers reach the application through Front Door, which handles HTTPS, WAF protection, and routing. The web portal runs on App Service because it is a conventional web application and the team wants managed hosting and safer deployments. The account API runs on App Service unless its container packaging makes Container Apps a better fit. The application uses managed identities and Key Vault for secure access. Azure SQL stores subscription data, Blob Storage stores documents, and private endpoints with private DNS keep data dependencies on private paths where required. Azure Monitor and Application Insights collect request, dependency, runtime, and security signals. Tags, budgets, and alert ownership make the design supportable after launch.

That explanation is valuable because it does not merely list services. It names the responsibility of each layer.

Common Mistakes

• Presenting one service diagram without explaining decision reasons.

• Ignoring DNS, identity, deployment, monitoring, or cost.

• Over-engineering the first version with global, multi-region, or Kubernetes patterns before requirements justify them.

• Treating private endpoints as the whole security model.

• Choosing one runtime for every component even when static content, APIs, and workers have different shapes.

• Adding WAF without planning rule review, false-positive handling, and security ownership.

If Someone Asks You

How would you design a secure Azure web application architecture?

A good answer is:

I would start with the request path. Users enter through a controlled HTTPS entry point such as Front Door or Application Gateway with WAF. The web portal and APIs run on a managed hosting option such as App Service or Container Apps based on deployment shape and operating responsibility. Data goes to the right managed service, such as Azure SQL for relational data and Blob Storage for documents. The workload uses managed identities, Key Vault, least-privilege access, private endpoints, and private DNS where private reachability is required. Finally, the design includes deployment safety, logs, metrics, traces, alerts, incident ownership, tags, budgets, and cost review.

What You Should Remember

Explain the architecture by walking the request path and naming the responsibility at each step.

Questions to Check Your Understanding

1. Which service handles public entry and edge protection in the scenario?

2. Which controls protect data dependencies?

3. Which operating decisions make the design production-ready?

4. Why is AKS not the default choice for this small-team scenario?