Designing a scalable, high-availability web architecture on AWS: From a single compute instance to CloudFront, ALB, and Auto Scaling

by Fabián BCH.in High availability, Architecture Best Practices, Architecture, AWS, DevOps, Well-Architected Frameworkon on

In the face of increasing traffic demand and intolerance of downtime, I share the technical rationale for migrating a monolithic instance as a single point of failure, to a resilient cloud-native architecture, and without failing in the attempt—a key technical model for ensuring that applications scale in line with demand and automatically recover from potential failures or incidents involving hardware, software, or an Availability Zone.

Using a single EC2 compute instance exposes organizations to three critical forms of unavailability:

  • Traffic spikes that overwhelm the processor (CPU).
  • Instance failures due to faulty deployments.
  • Dependency on a single Availability Zone (AZ).

This post describes a highly available, horizontally scalable architecture based on four core AWS components, designed to eliminate manual restarts and ensure business continuity. The proposed architecture is my own original work, developed based on my professional experience and aligned with established frameworks. AWS Well-Architected Framework and Architecture Best Practices.

Step 1 — Multi-AZ redundancy. Distribution of the workload across two or more Availability Zones (physically separate data centers with independent power and network infrastructure); if one zone fails, the other continues to handle traffic without interruption.

Step 2 — Intelligent Routing (Application Load Balancer). The ALB balancer acts as the single entry point (Layer 7 – HTTP/HTTPS) distributing traffic through Path-Based Routing (PBR):

  • Paths  /api/*  towards the dynamic backend.
  •  default (*)  towards the S3 bucket for static content.
  • Furthermore, they execute health checks continuous and carries out SSL Termination on the load balancer, centralizing certificate management.

Step 3 — Automated Elasticity (Auto Scaling Group). Maintains operational capacity based on defined thresholds:

  • Minimum: 2, an instance by AZ.
  • Maximum: 4.
  • Desired: 2.
  • Target Tracking: CPU 60%.
  • Health Check Type: ELB, no EC2.
  • Grace Period: 300 seconds to allow startup time for the instances before evaluating them.

In the event of a failure, a replacement is deployed automatically, without human operator intervention.

Step 4 — Content download using CloudFront and Amazon S3. CloudFront delivers static content from locations edge close to the user, caching copies. This way, files that reside in the private S3 bucket are accessible only through AWS CloudFront using Origin Access Control (OAC).

On the other hand, it is proposed that dynamic routes for example /api/* are routed directly to the ALB load balancer, optimizing the costs and performance of the proposed architecture by separating static traffic from dynamic traffic.

🎯 Results and their applicability.

Based on the foregoing, the resulting AWS architecture design enables:

  • Zero single points of failure, with active redundancy across multiple AZs.
  • Autonomous recovery, automatically detecting and replacing instances with incidents.
  • Optimized performance, downloading static traffic to edge and latency reduction.
  • On-demand scalability, horizontal growth controlled by business metrics, such as: RTO (Recovery Time Objective), RPO (Recovery Point Objective), MTTR (Mean Time to Repair), and MTBF (Mean Time Between Failures).

📝 Critical design best practices based on the pillars of the AWS Well-Architected Framework.

  • Configure the health check of the Auto Scaling Group (ASG) in mode ELB and not just EC2—to detect if the web application has frozen, even while the operating system remains active.
  • Implement an endpoint /health  lightweight, returning a 200 status without needing to query the database.
  • Configure appropriate thresholds and intervals; the ALB traffic-balancing service performs checks every 30 seconds and marks instances as unhealthy after 2 failures.
  • Ensure that the Web application is strictly stateless (sessions externalized to ElastiCache or DynamoDB). in addition to implementing consumption alerts in AWS Budgets from day one, to maintain visibility and control over costs.
  • Path-Based Routing in CloudFront, configuring two sources in the distribution:
  1. The S3 bucket for static content (default path)
  1. The ALB load balancer for dynamic routing  /api/* .

This optimizes costs and the performance of the web application by separating static traffic from dynamic traffic.

Finally:

¿Do you typically externalize user sessions in your web architectures, or do you still rely on local storage within your EC2 compute instances?

¿What metric do you use as the primary trigger for executing your Auto Scaling policies—for example, CPU, ALB Request Count, or custom metrics?

Technical references.