Cloud Computing Architecture Guide

Designing a Customer-Facing Application Across Provider Lenses

Goal

Apply the chapter's method to one design, then translate its responsibilities through AWS and Azure lenses without claiming false equivalence.

Scenario and Constraints

A company needs a customer portal for users in several countries. The portal serves static content, authenticates customers, exposes protected APIs, stores orders in a relational system, and performs fulfillment work asynchronously. Application and data components must not accept arbitrary internet traffic. Releases need limited exposure and rollback controls. The business can tolerate stale product recommendations, but not duplicate orders. It wants regional recovery, cost allocation, and production telemetry.

Unknowns remain: measurable latency targets, recovery time and recovery point objectives, data residency rules, peak workload shape, identity-provider constraints, and team operating skills. Those unknowns must become validation work rather than silent assumptions.

Provider-Neutral Design

Users
  |
  v
Global DNS/edge -- static content
  |
  v
Traffic protection and API policy
  |
  v
Regional application runtime ----> private relational order data
  |        |                                   |
  |        +----> cache                        +--> backup/restore path
  |
  +----> durable work queue ----> fulfillment worker

Identity, telemetry, deployment controls, and cost ownership span every path.

The application entry validates customer context and applies appropriate limits. Regional runtimes use narrow workload identities. Order creation owns an idempotency key so repeated requests cannot create repeated business effects. Background work is durable, retried with bounds, and reconciled. Static content and noncritical recommendations may degrade independently from ordering.

Recovery is not yet "multi-region." The team must decide whether another region is warm or active, how relational state is replicated and promoted, what data loss is acceptable, and how traffic returns safely.

AWS Implementation Lens

One AWS composition could use Route 53 and CloudFront for name resolution and edge delivery, AWS WAF for web filtering, and API Gateway or an application load balancer for controlled entry. The runtime might use a managed application platform, containers, functions, or Kubernetes depending on operating needs. Amazon RDS or Aurora could provide relational state; SQS could buffer background work; CloudWatch and related telemetry services could provide operational evidence.

That is an example composition, not a mandatory stack. Identity integration, private connectivity, regional database behavior, quotas, pricing dimensions, and recovery automation must be verified for the selected services and regions.

Azure Implementation Lens

One Azure composition could use Azure DNS and Front Door for global web entry and edge delivery, with Web Application Firewall policy and API Management for API policy. The runtime might use App Service, Container Apps, Functions, or AKS. Azure SQL options could provide relational state; Service Bus could hold durable work; Azure Monitor and Application Insights could provide telemetry.

The service categories resemble the AWS lens, but boundaries are not identical. Global routing, API management, private-origin support, identity integration, network attachment, zone and region behavior, and operational tooling compose differently. The design must follow documented behavior, not a name-matching table.

Decide and Validate

Before recommending either implementation:

  1. Quantify critical journeys, load, recovery, residency, and cost constraints.

  2. Build a thin end-to-end path with workload identity and private data access.

  3. Test origin bypass, abusive traffic, duplicate order submission, dependency slowdown, and a failed release.

  4. Restore data and rehearse the intended regional recovery path.

  5. Confirm quotas, supported regions, service limits, pricing drivers, and ownership with current official documentation.

Common Mistakes

  • Selecting the provider stack before agreeing on the architecture constraints.

  • Pairing products by category while ignoring behavior and operating boundaries.

  • Adding services from a reference diagram without assigning owners.

  • Preserving a multi-region label while losing the original recovery objective.

If Someone Asks You

Would this architecture look the same on AWS and Azure?

"The responsibility shape can remain similar: controlled entry, private runtime and data, durable work, identity, telemetry, safe change, and recovery. The service composition and operating boundaries will differ, so I translate each responsibility and then verify provider-specific behavior rather than claim one-to-one equivalents."

What You Should Remember

Translate responsibilities first; map services second; validate provider-specific behavior third.

Questions to Check Your Understanding

  1. Which decisions should remain provider-neutral?

  2. Which provider differences could change the team's operating model?

  3. What failure would you test before approving either implementation?

Further Study