Production-Grade Highly Available Web Platform on AWS
This reference expands the three-tier baseline with a global edge, separate scaling domains, caching, read scaling, private egress, secrets, backups, and operations. It is intended for teams evaluating a conventional production web platform rather than a minimal learning diagram.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasProduction high availability AWS web architecture diagram with Route 53, CloudFront, WAF, ALB, Auto Scaling web and API tiers, RDS, ElastiCache, and private subnets. The image links to a fully editable BuildPlane starter.
Overview
A production-grade, highly available web application. Traffic enters through a global edge (Route 53, CloudFront, WAF), reaches a Multi-AZ load balancer, and flows into independently scaled web and API tiers backed by a replicated relational store and a cache, with NAT egress for the private subnets.
Components
- Global Edge: Route 53 resolves the domain, CloudFront caches and terminates TLS, and WAF filters traffic before it reaches the Region.
- Load Balancing: An internet-facing ALB in public subnets health-checks targets and spreads requests across Availability Zones.
- Compute Tiers: Separate Auto Scaling Groups let the stateless web tier and the API tier scale on their own signals.
- Data Layer: An RDS Multi-AZ primary with a read replica, fronted by ElastiCache, separates durable writes from high-volume reads.
- Egress: A NAT gateway gives the private tiers controlled outbound access for patching and dependencies.
Traffic Flow
- Users resolve the domain in Route 53 and hit CloudFront, which forwards dynamic requests after WAF evaluation.
- CloudFront routes origin traffic to the ALB, which balances across the web tier in private subnets.
- The web tier calls the API tier and egresses through the NAT gateway for outbound calls.
- The API tier reads from ElastiCache and writes to the RDS primary.
- The RDS primary replicates asynchronously to the read replica for read scaling.
Customize First
- Pick instance/engine sizes, cache policy, and replica count that match your read/write ratio.
- Add a second Region with Route 53 failover and cross-Region replication when your RTO/RPO requires it.
- Add Secrets Manager for credential rotation and AWS Backup for point-in-time recovery.
Design rationale
Decisions that shape this architecture
Use the edge to protect and cache before the Region
Route 53, CloudFront, and WAF reduce avoidable origin traffic and provide a clear public protection boundary before requests reach the ALB.
Keep private tiers independently scalable
Web and API Auto Scaling groups respond to different signals. This prevents a busy presentation layer from forcing identical capacity into business logic.
Separate cache, writes, and read scaling
ElastiCache handles hot data, the RDS primary owns durable writes, and a read replica serves suitable read workloads. Each path has different consistency and failure behavior.
Before production
Operational checks
Test cache loss, database failover, and read-replica lag under realistic load.
Set scaling policies from measured latency, saturation, and queueing signals.
Use one NAT gateway per Availability Zone when zonal independence justifies the cost.
Validate backup restore, not only backup creation.
Scope and tradeoffs
What this diagram does not solve
The design is still regional
Global DNS and CDN services do not make the origin multi-Region. Regional recovery requires another regional stack and a data replication plan.
More components create more operating responsibility
Cache policy, replica lag, scaling thresholds, NAT cost, patching, secrets, and deployment safety require ownership and observability.
Common questions
Frequently asked questions
Why put CloudFront in front of an ALB?
CloudFront can cache content, terminate connections near users, reduce origin load, and provide a global attachment point for WAF before forwarding dynamic traffic to the ALB.
What is the difference between RDS Multi-AZ and a read replica?
Multi-AZ provides a synchronous standby for availability. A read replica is an asynchronous copy used primarily to scale eligible reads.
Does this architecture require two Auto Scaling groups?
Separate groups are valuable when web and API workloads have different releases, resource profiles, or scaling signals. A simpler product can combine them.
Keep exploring
Related AWS architectures
Highly Available Three-Tier Web Application on AWS
This starter architecture separates ingress, presentation, application logic, and relational data so each tier can fail and scale independently. It is a practical baseline for teams moving a conventional web application onto AWS without collapsing every responsibility into one server.
Explore the architecture
Containerized Web Service with Amazon ECS and Fargate
This architecture runs a production container service without managing an EC2 host fleet. A protected global edge forwards to a Multi-AZ ALB, Fargate tasks stay private, and managed data, image, secret, and observability services support the runtime.
Explore the architecture
An AWS Application That Survives an Availability Zone Failure
This architecture focuses on one failure question: what happens when an entire Availability Zone becomes unavailable? Healthy application capacity remains in the other zone, the load balancer removes failed targets, and RDS can promote its synchronous standby.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.