Frontend Deployments in AWS: S3-Cloudfront vs AWS Amplify vs EC2

Introduction

Frontend Applications are the faces of the organization’s website. It is the first impression users, customers, and partners get for your product/service capabilities. Every user wants the best experience when visiting a website; one of the major experience parameters a user looks up to is speed. In this article I will discuss different ways to improve the user experience for front-end applications deployed on AWS.

In this article, I shall compare three front-end deployment methods on AWS.

• S3-Cloudfront deployment
• AWS Amplify deployment
• EC2 deployment

I shall be using different benchmarks for these comparisons;

Cost: How much does it cost in terms of CapEx (AWS charge for the different components that make up the service) and OpEx (cost of maintaining that method of deployment such as security and managing system resources and availability)?
Components:What is the combination of AWS services used for this deployment method.

Deployment:The number of operations/steps it takes to deploy a frontend application to this setup/environment.

Security:Security configurations and options available for that deployment method.

Scalability and Availability:How the system scales on demand and if any configurations are required/maintained for it to handle scale.

S3-Cloudfront deployment

Amazon S3 is a highly scalable object-storage service. It can be used to store all sorts of files and is capable of storing files in petabytes. 

Amazon CloudFront is a content delivery network (CDN) service. It is used for caching images, CSS, and JavaScript files. It is also beneficial in video streaming services and improves application speed. It does this, by using the AWS PoP global network presence, to deliver files, and content faster to users, regardless of where the original file(s) are hosted.

The S3-Cloudfront architecture for hosting frontend applications requires that the frontend applications written in any frontend framework i,.e React, Angular must be compiled to HTML, JSS, and Javascript and then deployed to S3.  After deploying to S3, Amazon CloudFront needs to be manually configured to help with caching and distribution of the website to the AWS global network for speed and high availability.

Cost

The fact that S3 and Cloudfront are the two services involved, they are both serverless services, so they are relatively very cheap. A combination of S3 and Cloudfront is a very affordable option for hosting your static websites. You only get significant costs when there is high traffic on the website, and the cost will come from Egress-Network-Reponses (network requests going out of the AWS Network).

CapEx (Capital Expense) was just analyzed. In terms of OpEx (Operational Expense), you will need to set up a pipeline that builds the app in HTML/CSS/JS, deploy it to S3, and manage the CloudFront invalidation, so that changes are applied to Amazon CloudFront immediately. There is also some minor technical knowledge of how Cloudfront works that is needed for the website to work effectively.

Components

When using S3-Cloudfront, you must generate your CloudFront certificate from the us-east-1 region, even if your static site is in the eu-west-1 region or any other AWS region. This already makes things complex because it means you have a resource in another AWS region that has to be managed.

Deployment
To deploy with this architecture, two major operations need to take place to have a proper deployment that applies all the new changes;

1. The frontend app is built and output is copied into S3 to replace all existing files in S3
2. The Cloudfront distribution needs to be invalidated so that Cloudfront can clear its cache and pull updated content from S3.
3. (Optional) In some cases, you might also need to add an object `max-age` to the S3 configuration

Pull Request Previews: This is not supported in this deployment method

Security

There are different layers of security that need to be configured when using Cloudfront-S3 for front-end deployments.

       1.The S3 bucket must not allow public read-and-write access

         Origin Access Identity or Origin Access Control (OAI/OAC) must be enforced on Cloudfront to allow it to pull file                       contents securely from S3.

2. Security headers for frontend web application security, such as; Cross-Site Request Forgery (CSRF), Cross- Site Scripting (XSS), Content Security Policy (CSP), Strict-Transport-Security Header (HSTS), X-Content-Type-Options, X-Frame-Options, Referrer-Policy are applied with the use of Lambda@Edge. It creates a Lambda function that is attached to the Cloudfront distribution and the function is triggered at specific events from the Cloudfront distribution.
3. Environment Variables: this is not a feature in this deployment method, so any parameters the application needs are built with it before the application is deployed into S3.
4. WAF: Setting up the AWS Web Application Firewall does not require any complex setup. WAF supports Cloudfront as one of the resource types that can be protected.

Scalability and Availability

The two AWS services used for this setup are Serverless services. This means that AWS manages scalability. S3 and Cloudfront are designed for “planet-scale”; they can quickly scale up when more resources are required of them, and they do not require any configurations to do that.
The next deployment method for frontend apps in AWS is Amplify, let us see how Amplify compares with the S3-Cloudfront method of deploying frontend applications.

AWS Amplify Deployment

AWS Amplify is a full-stack deployment environment for Javascript applications. AWS Amplify has the ability to host both frontend, backend, and mobile applications. Just like S3 and Cloudfront, Amplify is a serverless service; it requires less maintenance and management. AWS Amplify supports the following JavaScript frameworks: Angular, Vue.js, ReactJS, Ionic, and EmberJS, as well as static site generators like Gatsby, Eleventy, Hugo, VuePress, and Jekyll. Amplify has inbuilt features such as Authentication, Datastore, Pubsub, and Analytics. Let’s compare using the various parameters we already used for the S3-Cloudfront architecture above. Apart from supporting static website hosting, Amplify also hosts Next.js SSR (server-side rendering), making every page it generates at every request dynamic. Next, let us see what it costs to host an app running on AWS Amplify.

Cost
I already discussed the components that make up S3-Cloudfront architecture. AWS Amplify has some of these features, making it also a serverless service. Just like the S3-Cloudfront setup, it is possible to host an application on Amplify for absolutely $0/month, depending on the amount of traffic the application receives. The following diagram explains pricing in AWS Amplify.  

After the 12-month free plan, the cost of the different components on a monthly basis for example is around $8.08/mo, as shown in the above screenshot. But if your application does not get up to the traffic load stated above, then you might be spending much less than that at the end of the month. 

Components
Under the hood of Amplify is a combination of services that have been compacted to form Amplify. These services include; CodePipeline/CodeDeploy for CI/CD, Amazon S3 for storing website content files, CloudFront for caching, and CDN. Unlike the S3-Cloudfront architecture, Amplify helps to run cache invalidation for objects it has cached previously.

Deployment
Deploying to AWS Amplify has various options. One of the easiest methods to deploy to Amplify is linking a GitHub repository to the Amplify application. Amplify will automatically detect the Javascript framework in use and generate the CodeBuild script for building and deploying the application into Amplify. This configuration is a one-time setup. All other subsequent changes to the code/application will be automatically built and deployed to Amplify.

It also has a manual deployment process which involves uploading website files or pulling the files from Amazon S3.

Pull-Request previews: This feature is unique to Amplify, it enables engineers/developers to have a feature branch that can set up a feature environment, enabling them to test feature branches per environment before it gets merged into the main trunk.

Security
Frontend security is usually overlooked, but Amplify has made it easier and more attractive. All the security controls mentioned in the S3-Cloudfront architecture can be applied right in Amplify without the need for Lambda@Edge. Amplify has a feature called Custom Headers which is used to configure header security for web applications deployed in Amplify. It allows you to add all the necessary security headers needed to improve the security of the server and application.

Environment Variables:AWS Amplify has support for environment variables.

WAF:is not supported in AWS Amplify directly. You will have to create a CloudFront distribution that connects to the Amplify endpoint and then mount an AWS WAF to it.

Availability and Scalability
We already identified Amplify earlier as a serverless service. This means that it handles its own scale and is highly available. Plus the fact that it uses Cloudfront for caching, also makes the applications load faster than an app without a CDN configured for it. We can say that the S3-Cloudfront architecture is very similar to Amplify in terms of this metric. No monitoring of configuration is required for the system to scale.

EC2 Deployment

This is the de-facto method of deploying websites and frontend applications before serverless and even cloud computing became mainstream. EC2 in AWS is another name for a virtual machine. There are various methods to deploy a frontend app into EC2, but we shall focus on high availability for this type of setup. In this setup, many components will be needed for high availability and scalability which will not be needed in a simple setup.

Cost
Cost in this setup is based on the number of AWS service components that have been used for the setup. But for baseline cost, one component is core to this architecture which is the EC2 instance. According to the AWS calculator, the smallest instance which is a t3.nano (1vCPU, 0.5G RAM) costs $0.0057/hr approximately $4.16/monthly. Instances have to be larger for a frontend app to run effectively. So a t3.medium (2vCPU, 4G RAM) which goes for 0.0456/hour and 33.29/month, is a more realistic setup to have. When a load balancer is added (which costs approximately $16–$18/month) then the cost begins to go higher. It can become more expensive as more resources (EC2 instances) are needed.

Components
The components that make up an EC2 deployment of a front-end app vary. But the minimum is a webserver (nginx or Apache). This web server is installed and configured in an EC2 Instance. But for the application to be highly available and scalable then other AWS services need to be involved. Other services that are needed include; Load Balancer, Launch Configuration, and Autoscaling Group. We shall talk more about that scenario under the Availability and Scalability section.

Deployment
Various deployment options exist here. From manually copying the compiled file into the EC2 instance
and starting it to write a pipeline that can perform the same operation. The pipeline will connect to an EC2 instance (SSH for Linux, RDP for Windows) and copy the build files there and start/restart the
webserver to apply new changes.

In some cases, a service management tool like `pm2` is configured to help with the process management of the application.

Pull Request Previews: This is not supported in this deployment method

Next up is security, how do we secure our web app in an EC2 instance?

Security
The first two deployment techniques do not talk about securing the environment. But EC2 instances run on a network, so security in this setup is on various layers:

1. Network security: This is to ensure that the Security Group and NACL do not allow public access to certain ports on the instance. Ports like 22, 3389.
2. It is advisable for the instance to run in a private subnet and not have a public IP address.
3. Discourage manual access for applying changes, instead automated deployment should be used.
4. Header security has to be configured on the webserver. Different web servers have different ways to configure header security, so you will have to check the documentation and configure it accordingly.

Environment Variables: can be configured in the EC2 instance and used by the application.

WAF: By default, WAF is not possible in this setup. But if the architecture has an Application Load Balancer, then it can be mounted on AWS WAF to provide web application security.

Availability and Scalability
To make an application deployed into an EC2 instance highly available, a number of configurations need to be done. There needs to be a load balancer and an autoscaling group attached to it. This will help to launch more EC2 instances when the application has used up the CPU, Memory, or Network capability of the existing instances.

Apart from configuring a load balancer and autoscaling groups, there needs to be a trigger to deploy into the new instance(s) and manage changes that continue to occur in that environment. The reason is that the autoscaling group creates a fresh instance. Another alternative is that a baked AMI with all the configurations needed can be configured with the Launch Configurations and used in the Autoscaling group setup. The next section summarizes all the services deployment in a single table.


Conclusion

We have examined various forms of frontend applications deployments in AWS. We also know their pros and cons. In the end, it is advisable to start with what you understand, and gradually move to architectures that have less OpEX and high Performance Efficiency and Operational excellence. So that you can focus more on writing code, than managing infrastructure.