The Cross-Cloud Web Application Service Map

How the building blocks of a modern web application line up across five cloud platforms.

Cloud platforms use different product names, consoles, and billing models. Underneath those differences, a production web application still needs the same basic capabilities: an entry point for users, frontend hosting, compute, identity, data, storage, messaging, observability, and a secure way to deliver changes.

This map organizes those capabilities by service layer rather than by vendor. It is designed to help architects, engineers, and technical decision-makers translate a design from one cloud environment to another without pretending the products are identical.

Start with the application path

A user reaches an application through an internet-facing entry layer. DNS, CDN delivery, WAF controls, access policies, and routing decisions sit here. Cloudflare groups several of these services at the edge, while AWS, Azure, Google Cloud, and Oracle Cloud use their own combinations of DNS, CDN, web application firewall, and load-balancing products.

The next decision is where the frontend and application logic run. Static sites may fit a managed frontend-hosting service. APIs and server-rendered applications may use functions, containers, or a managed application platform. The choice depends on runtime requirements, operational ownership, latency expectations, and how much portability matters.

The service categories that matter

The center of the map separates the backend into the service layers most teams must design deliberately:

• Frontend hosting and web UI for static assets, single-page applications, and server-side rendering where supported.
• API and backend compute for business logic, integration endpoints, scheduled work, and application services.
• Application data for transactional records, users, sessions, and structured data.
• Object and media storage for files, uploads, backups, artifacts, and large unstructured objects.
• Queues and background jobs for work that should be decoupled from the request path.
• Search and discovery for indexing, retrieval, and semantic or vector-search workloads.
• Realtime coordination for WebSockets, presence, live updates, and stateful collaboration patterns.
• Notifications for email, push, SMS, and application events.

A managed service in the same row may solve a similar problem, but it may not have the same operational model, compatibility surface, geographic footprint, throughput behavior, or cost. For example, a serverless function is not automatically interchangeable with a container service, and a key-value store is not a substitute for a relational database simply because both persist data.

Foundation services are part of the architecture

Secrets management, caching, observability, and CI/CD are often treated as supporting details. They are not. They determine how safely a service is deployed, how quickly an incident is diagnosed, and whether an architecture stays manageable as it grows.

Use the map as a starting point for questions such as: Which layer owns authentication? Where does asynchronous work happen? Which system is authoritative for data? How do we observe the request from edge to backend? Which services are managed, and which ones will the team operate?

The most useful cloud architecture is not the one with the most services. It is the one where each service has a clear responsibility, a documented failure mode, and an operational owner.

How to use this map

Begin with the workload and its constraints, then select the service category before selecting a vendor product. Confirm identity boundaries, data residency, recovery objectives, security controls, performance requirements, and the skills your team can support.

The comparison is intentionally high-level. Always validate current product capabilities, regional availability, limits, pricing, and support commitments with the provider before making a deployment decision.