Case Study - Angular SSR and AWS infrastructure

Overview

The work done was in two parts: first getting the existing client-side Angular 19 application working as a hybrid Angular SSR application, and second designing cloud infrastructure to deploy it reliably and cost-effectively.

Angular 19 out of the box is a Client Side Rendered application, aka Single Page Application. This meant that the marketing pages were not crawlable by common search engines. The client side approach when we re-wrote the ecommerce site lead to SPA based patterns being used throughout the entire application. This wasn't a bad thing as best practices were being used before the requirement of crawlable marketing pages was introduced. This meant we had to do a full audit of the code base to flag patterns and files that needed to have their patterns updated to work well within Angular SSR.

The bulk of this work was done within the Angular services layer as these purely run on the server in SSR and have zero access to the DOM. Any service that was using DOM based selectors in it's functionality had to be refactored to push that behavior to the component level and allow the components to drive any DOM specific manipulation. This allowed us to trim the services to purely the functionality needed.

We originally did a first pass on running Angular SSR through CloudFront using a Lambda function to render out our SSR pages. This lead to a very expensive AWS bill projected to be around $9,500 for that month. This was do to the fact that all our pages were running through this Lambda function. We quickly reverted the application to run as a SPA to pause the quickly escalating bill. The decision was made to upgrade the Angular version and take advantage of the new Angular SSR capabilities instead of Angular Universal. Doing this allowed us to have full control over what pages are rendered on the server vs client. This also lead to the need to find a new Cloud Infrastructure solution that was much more cost effective.

What is a hybrid Angular SSR application? This means that we define what routes are going to be rendered on the server. This allows us to maintain client side rendering for the majority of the application which is behind an auth layer. Pages behind auth have no need to be crawlable for SEO. This results in less server requests allowing us to really focus on the minimum compute resources needed at the AWS level. This also allowed us to maintain a client side rendered version of the application, something that was useful when AWS had an EC2(the service that our application load balancer lived in) outage Q4 2025. We were able to quickly deploy the sites as a SPA using our pre-ssr infrastructure to avoid a disruption to the users.

After looking into AWS Amplify, which we used to deploy and host a smaller Nextjs based application, I realized that dedicated support for Angular SSR was not offered by AWS Amplify. This lead me to look into what services we could use to host the Angular SSR application. The cloud stack I landed on was CloudFront, Elastic Container Repository, Elastic Container Service, Application Load Balancer, and CloudFormation.

This stack allowed us to build out multiple docker images with specific tagging for our different environments and region specific sites all within a single Elastic Container Repository. Additionally the use of CloudFormation allowed us to define the services and configurations as code. This allows us to keep the infrastructure tied to the codebase and keeps any changes to configuration within version control.

The use of Elastic Container Service allowed us to define the minimum number of tasks to handle our average user load with the least amount of compute resources needed, with the addition of an auto-scaling policy to handle spikes in traffic to insure 100% uptime. This piece was the most important in terms of opporational costs. Switching from the Lambda approach to these service dropped out AWS expenditure by 97%.

What we did