Ember & Root — Highly Available Web Infrastructure

What Was Built

Ember & Root is a highly available, multi-AZ web infrastructure built on AWS for a restaurant brand, engineered to demonstrate production-grade EC2 compute and network architecture patterns. The system is designed to handle variable traffic loads, ranging from low-volume weekday browsing to peak weekend reservation surges, without requiring manual intervention or experiencing service degradation. At the center of the architecture is an Application Load Balancer (ALB) that distributes incoming web traffic across an Auto Scaling Group (ASG) of EC2 instances running Apache HTTP Server. The ASG utilizes EC2 Launch Templates to ensure consistent, repeatable configurations across all backend instances and is configured with target tracking scaling policies tied to CPU utilization and request count metrics. Static assets, including site imagery, stylesheets, and JavaScript bundles, are entirely offloaded from backend compute instances to an Amazon S3 storage bucket and delivered globally via Amazon CloudFront edge caching with Origin Access Control (OAC) enforced. The underlying network architecture is deployed across multiple Availability Zones inside a custom Virtual Private Cloud (VPC), establishing strict network isolation through public subnets for the load balancer and private subnets for the application instances.

Why Was It Built

Restaurant websites face unpredictable traffic patterns, experiencing severe traffic spikes during meal hours, holiday bookings, and promotional campaigns, followed by long periods of low activity. Hosting such applications on single, fixed EC2 instances leads to frequent downtime during high-demand periods or unnecessary operational costs during idle hours. Ember & Root was built to solve these availability and cost-efficiency challenges by implementing an automated, elastic compute architecture that dynamically matches infrastructure capacity to real-time user demand. The project also served as a hands-on implementation of enterprise cloud networking standards, demonstrating how to decouple static content delivery from compute tiers while enforcing zero-trust network boundaries between public-facing load balancers and private application servers.

How It Works

When a user accesses the Ember & Root application, initial requests for static assets are handled directly at the edge by Amazon CloudFront, which securely fetches and caches media files from the private Amazon S3 bucket using Origin Access Control without burdening the backend web servers. Dynamic HTTP and HTTPS requests from site visitors are directed to the public subnets of the custom VPC, where the Application Load Balancer receives the traffic and performs continuous health checks against target groups. The ALB then distributes healthy requests across the pool of EC2 instances residing in private subnets across multiple Availability Zones. As incoming request counts or instance CPU utilization thresholds increase, AWS Auto Scaling automatically provisions additional EC2 instances using the pre-configured Launch Template, registering them with the ALB target group once Apache passes initial health checks. Conversely, when traffic subsides, the ASG gracefully terminates excess instances down to the established minimum capacity, maintaining baseline system availability while optimizing compute expenditure.

What Broke and How Did I Fix It

During the initial deployment and load testing phases, several critical infrastructure and configuration issues were identified and resolved. A primary failure occurred when instances in private subnets failed to download necessary Apache web server packages during boot initialization, leaving new instances in an unhealthy state and causing the ALB to continually cycle instance launches. This was resolved by deploying NAT Gateways in the public subnets and updating private subnet route tables to grant instances secure outbound internet access for package management without exposing them to incoming public connections. Additionally, health check misconfigurations on the Application Load Balancer initially caused healthy EC2 instances to be marked as failed because the ALB default health check path was looking for a root index file that had not yet been fully rendered by the startup scripts; this was fixed by pointing the health check path to a dedicated status endpoint and increasing the initial health check grace period on the Launch Template. Finally, direct HTTP requests to S3 asset URLs resulted in access denied errors until the S3 bucket policy was updated to explicitly permit read access strictly to the CloudFront distribution's Service Principal while completely blocking public access to the bucket origin.