High Availability and Scalability

Building Highly Available and Scalable Web Applications on AWS

Keeping your web site up and responsive is critical for your business. To accomplish this, we need to understand both scalability and high availability. These concepts go hand-in-hand; however, they are separate things to consider.

Scaling Up

High Availability

High availability is a set of techniques and architectures that allow your site to remain up and fully functional in the event of a failure. This applies to all tiers of your site, including networking gear, database servers, or even power. High availability could be as simple as having a spare web server ready to serve traffic, or as complicated as a load-balanced fleet spanning multiple Availability Zones.

A truly highly available architecture eliminates every single point of failure. When one component fails, another automatically takes over --- ideally without any perceptible interruption to end users. AWS makes this significantly easier by offering redundant infrastructure within and across its data centers, known as Availability Zones (AZs), within a given Region.

Scalability

Scalability is the handling of increases and decreases in traffic or load to your site. Generally, you want to scale in a way that you are not paying for spare resources when they are not needed.

Scaling up means increasing the size of a single server to handle extra load. Scaling out means adding more server nodes to distribute the load horizontally. You can even do both. The exact scaling strategy depends on the specifics of your application and your availability requirements. The more sophisticated your availability and capability needs are, the more it costs but cloud providers like AWS make cost-efficient scaling achievable even for smaller teams.

Highly Available and Scalable Web App on AWS

Highly Available and Scalable Web App

Since the advent of public "cloud” providers like Amazon Web Services (and a whole host of others), building a highly available and scalable site is easier than ever. You no longer need to worry about redundant network switches, routers, power, Internet connections, or even entire data centers as those concerns are handled for you by AWS. Instead, you can focus your engineering effort on your application architecture.

A well-architected highly available web application on AWS typically involves several core components working together: a Content Delivery Network for global caching and edge performance, a Web Application Firewall for security, a load balancer to distribute traffic, an auto-scaling fleet of web servers, and a managed database service. The sections below walk through each layer.

Content Delivery Network (CDN)

A Content Delivery Network (CDN) is one of the most impactful layers you can add to a highly available web architecture. A CDN works by caching copies of your content at geographically distributed edge locations around the world, so that requests from users are served from the nearest point of presence rather than traversing all the way back to your origin servers. This dramatically reduces latency, lowers origin load, and improves resilience.

Performance and Cost Benefits

By absorbing a large fraction of your traffic at the edge, CloudFront reduces the number of requests that ever reach your load balancer and application fleet. This means your Auto Scaling Group can run leaner in steady state, only scaling up for requests that actually require dynamic processing. The result is lower compute costs, reduced database pressure, and faster response times for end users around the world.

CloudFront also supports HTTP/2 and HTTP/3 (QUIC) between users and the edge, compresses content with Gzip and Brotli, and can terminate TLS at the edge to reduce connection setup latency.

Web Application Firewall (WAF)

A Web Application Firewall (WAF) inspects HTTP/HTTPS traffic at the application layer and blocks requests that match known attack patterns before they ever reach your web servers. Where a traditional network firewall operates on IP addresses and ports, a WAF understands the content of web requests such as URLs, query strings, headers, cookies, and POST body payloads and can enforce sophisticated security rules based on that context.

WAF in the Broader Architecture

When combined with CloudFront, AWS WAF provides defense in depth at the global edge. Malicious requests are identified and dropped within milliseconds at the nearest CloudFront Point of Presence, never consuming bandwidth or compute resources at your origin. This makes your application dramatically more resilient to application-layer DDoS attacks, since the attack traffic is absorbed and discarded before it reaches your load balancer or application fleet.

Web servers

COG - LAMP/LEMP Makes a great pre-configured Web server image to get you started since it has everything you need pre-installed and configured.

Code

Each Web server will not only need access to the code for your site, but also have access to that code when a new instance starts up. There are a few ways this can be accomplished:

Amazon CodeDeploy: A CodeDeploy deployment is a compressed archive (zip, tar.gz) of your code (with a few extra config files). You can create this archive manually, or with an automated build system. Once an updated archive has been created, you can deploy it from the command-line, an SDK, or the AWS Web console.
Amazon EFS: EFS is a shared Network File System (NFS) that can be mounted on any number of instances and provide file-system level access simultaneously to all instances. Linux has the ability to mount EFS shares without the need for additionsl software. This makes it easy to setup and use and requires little if any modifications to your app code. EFS does have performance issues and can get quite expensive.; You'll still need some method to copy your app to the EFS directory. This could be as simple as rsync'ing, or using some other deploy tool.

Auto-Scaling Group (ASG)

An Auto Scaling Group (ASG) will allow our app to scale automatically based on one or more CloudWatch metrics. As long as your CodeDeploy deployment is associated with the ASG, new instances will also get the current app deployed to it.

Load Balancer

You'll need to direct incoming traffic to our fleet of Web servers. A LoadBlancer will give you that single endpoint that you can point your Web address at.

Database Servers

Amazon RDS is a fully managed Relational Database Service that handles the heavy lifting of database administration: patching, backups, monitoring, and replication. RDS supports MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora.

RDS offers several high-availability options that you should evaluate based on your requirements and budget:

Multi-AZ Deployment: RDS automatically replicates data synchronously to a standby instance in a different Availability Zone. In the event of a primary instance failure, RDS performs an automatic failover to the standby, typically within 1--2 minutes, with no manual intervention required.
Read Replicas: For read-heavy workloads, you can create up to 15 read replicas (Aurora) to distribute SELECT query load and reduce pressure on the primary instance.
Amazon Aurora: A cloud-native relational database offering up to 5x the throughput of MySQL at a fraction of the cost of commercial databases, with built-in multi-AZ redundancy and auto-scaling storage.

Putting It All Together

A complete, production-grade highly available web application on AWS combines all of the layers described above into a coherent architecture:

Route 53 routes DNS to your CloudFront distribution
CloudFront caches static and dynamic content at global edge locations, reducing origin load and latency
AWS WAF, attached to CloudFront, inspects every request and blocks malicious traffic at the edge
The Load Balancer receives only the requests that pass through CloudFront and WAF, distributing them across your instance fleet
The Auto Scaling Group adjusts the number of EC2 web server instances in response to demand
Amazon RDS with Multi-AZ provides a resilient, managed database tier

Each layer contributes both to availability and to security. CloudFront and WAF together provide edge-level caching and protection; the ALB and ASG provide application-tier resilience; and RDS Multi-AZ provides database-tier failover. The result is an architecture that can withstand the failure of individual components, or even entire Availability Zones, without impacting end users.