AWS comprises hundreds of services, and navigating this matrix of services can be a huge challenge for newbies; even experts in the field struggle with the right service to use for workload deployments. This confusion can lead to a lot of trial and error on the services to use and, in some cases, deploy the services in the wrong way, which can lead to higher operational expenses. Choosing the right service for your workload is key, and certain services have been designed for specific deployment workloads. The choice of AWS service will determine the scalability, security, and reliability of an application. Frontend engineers do not want to go through the hassles of understanding all the services in AWS, they just want to get their application deployed and running.
In a previous post, I explained the AWS services that can be used to deploy Container-based workloads. In this article, I shall describe the services that can be used for Frontend-based development. But before heading to the services for frontend-based deployment, what are frontend applications?
Frontend-based applications or Static Websites are applications that run on HTML, CSS, and JavaScript. They do not require server-side processing or an interpreter engine to run. When a frontend app loads, all its contents are downloaded by the browser and displayed to the user. Frontend applications do not require a database, a queuing system, or any storage engine; instead, they use the browser for all their needs, and everything starts and ends in the browser. Frontend applications can either be built using vanilla HTML, CSS, and JavaScript, or they can be built using JavaScript frameworks, such as Angular and React, and eventually compiled into HTML, CSS, and JavaScript. The opposite of Frontend applications is backend applications that require server-side processing, an interpreter, or a compiler to run.
The concept of frontend applications is well understood, and now it’s time to explore the various AWS services available for deploying them.
S3-Cloudfront
In the earlier days of frontend deployment in AWS, this was one of the most popular options used. Amazon S3 is a revolutionary object storage engine that has been used to house trillions of objects globally. But apart from its storage capability, it also has the feature to serve frontend applications as websites through a unique feature it possesses. All the components of the application need to be stored in Amazon S3, and the S3-website feature enabled. This will automatically generate a URL for the website,e and it becomes accessible over the public internet. Do not forget to “Allow Public Access” on all the objects in the S3 bucket.
Though this is the common practice for hosting and deploying frontend applications in S3, it is not the best approach. It leaves the S3 bucket vulnerable to attack. The bucket has been configured to allow public access, so it means that anyone on the internet can download all the files in the bucket. This means sensitive documents can be easily accessed by a malicious actor.
The best way to deploy frontend applications on S3 is to not allow the bucket to have public access. Instead, attach a CloudFront edge as the entry point for users, and allow CloudFront to pull the website files and cache them. Apart from the extra security later Cloudfront provides for the S3 Bucket, Cloudfront is a CDN, which is an acronym for Content Delivery Network. A CDN is designed to improve the speed of a website by caching it on a global network for easy access to users all over the globe. Lastly, CloudFront integrates easily with AWS WAF, which provides multiple functionalities to secure your website from malicious attackers. I have a previous article here that explains how to configure secure access to S3 via CloudFront.
CI/CD needs to be scripted from the ground up to build and deploy the static website into the Amazon S3 bucket, and Cloudfront Invalidation needs to be infused as part of the CI/CD pipeline to avoid Javascript caching from giving users a bad experience and not seeing the latest changes that have been deployed.
No well-defined Observability here, but logging can be enabled on CloudFront and sent to S3, then visualized on Athena or Amazon Quicksight.
AWS Amplify
The challenge with using S3 and Cloudfront is that two different services require operational work to manage and secure in the least bit. There might be no need to worry about scale because S3 and CloudFront are both serverless and highly scalable. Amplify is a serverless service strictly designed for deploying not just frontend applications, but also full-stack JavaScript applications. Amplify takes JavaScript deployments a notch higher than just static websites. Applications built on JavaScript/TypeScript frameworks such as VueJS, NextJS, GatsbyJS, and Angular are all supported in Amplify. It also has features such as storage, authorization, databases, support for mobile apps, functions, and support for environment variables. Amplify packs a punch when it comes to the management of your application, starting the journey from your Git repository. Amplify can configure an automated CI/CD pipeline that builds the application and deploys it without any knowledge of CI/CD needed. It has an automatic CDN configured for it (via AWS Cloudfront), with a nice, intuitive interface that is easy to navigate and understand what is going on with an application at any time. Recently, AWS added a WAF (Web Application Firewall) feature to Amplify.
All these features make Amplify a powerful tool for building, deploying, and managing static websites and JavaScript applications, which saves Operational cost to almost 0 because there are no servers to be managed and minimal configurations to be made to deploy, scale, and secure applications.
Amplify has observability inbuilt that shows logs and other important metrics to help monitor the status of the application at all times.
AWS Amplify’s basic cost structure is designed to be flexible, catering to both small projects and large-scale applications. It operates on a pay-as-you-go model, with costs primarily based on two components: build & deploy and hosting. The build & deploy service charges around $0.01 per build minute, while hosting costs approximately $0.023 per GB of storage and $0.15 per GB of data served. AWS also offers a free tier, which includes 1,000 build minutes per month, 5 GB of storage, and 15 GB of data transfer out for the first 12 months. Pricing may vary based on usage, region, and additional services, making it essential to monitor usage via the AWS cost calculator for accurate estimates.
Using Containers to Deploy: ECS, EKS, Appruner
Though I have my reservations about this method of deploying static websites, I have seen it being used in many scenarios. The basic concept here is to use containers as a packaging option to package static websites and deploy them to the container orchestration tool. The orchestration tool does not matter much at this point, as long as the application is properly packaged in Docker, it will run on any of them. When packaging a static website using Docker, an extra configuration is needed to ensure the website is served properly; that configuration is a web server running inside the Docker container, which I see arguably as an anti-pattern. So the static website is copied to a folder in the web server (Apache, Nginx, etc) and the web server is started, which then servers the static website. The script below is a sample Dockerfile that shows how to package a static website in Docker.
FROM nginx:alpine # Set the working directory WORKDIR /usr/share/nginx/html # Remove the default NGINX website RUN rm -rf ./* # Copy the static website files to the NGINX HTML directory COPY . /usr/share/nginx/html # Expose port 80 to the outside world EXPOSE 80 # Start NGINX when the container launches CMD ["nginx", "-g", "daemon off;"]
There is also the complexity of managing the life cycle of the containers yourself, no matter the container orchestration option selected for this deployment. The scaling, security, and reliability of the application are all on you. This method of deploying static websites will require a really good knowledge of containers and container orchestration technologies.
The reason this is used in some cases is to unify systems to use a single deployment plane for all applications. For example,e a company that is big on using ECS for all its Backend or full-stack deployments will most likely use the same ECS for frontend applications and static website deployments.
CI/CD is also easy to set up for this; if all the other applications have an existing workflow for packaging into Docker images, it is seamless to add the frontend as part of that workflow to build and deploy into the container orchestration service.
Observability here relies on the existing system that has been set up for other applications, no new setup is required to monitor the behavior of the frontend application. Although AWS Apprunner has some inbuilt observability that does the job and has features that can be expanded upon, such as Amazon X-ray, which is used for distributed traces.
The cost of running frontend applications in containers is mostly calculated based on the cost of virtual machines and the container orchestration tool, which can be hard to determine. If you are using EKS, the cost is the control plane (which is approximately $72/month) plus the worker node selected for deploying it, which can vary from $3.74 a month and above. Other container orchestration tools like Apprunner offer a minimal cost, depending on the compute resources and usage patterns of your application. App Runner charges based on vCPU and memory usage, along with outbound data transfer. The compute cost is $0.064 per vCPU-hour and $0.007 per GB-hour of memory, while outbound data transfer costs $0.09 per GB after the free tier. AWS offers a free tier for the first 12 months, which includes 50 vCPU-hours, 100 GB-hours of memory, and 1 GB of outbound data transfer per month. After the free tier, running a minimal service with 0.5 vCPU and 1 GB of memory continuously for a month would cost around $28.47, excluding data transfer. To minimize costs further, running the service part-time and optimizing resource usage is recommended.
Elasticbeanstalk, EC2, and Lightsail for running static websites
This deployment option is very similar to the previous option of containers just mentioned. Elastic Beanstalk literally creates an EC2 instance in the background and makes it visible for you to see, but manages the server setup to some extent and reduces the need to understand how EC2 instances work. For this setup option, a web server is deployed into the EC2 instance either automatically via Elastic Beanstalk or manually by creating the EC2 and installing any web server of choice. The static website is then uploaded (in the case of Elastic Beanstalk) or copied to the execution directory of the web server (in the case of Amazon EC2). In both cases, the management life cycle is totally on the engineer to ensure the EC2 instance is always up and running, security patches and updates are done regularly, and scaling and reliability of the application need to be handled efficiently also. This system might require some form of Linux Administration (mostly when using normal EC2), for it to run optimally and maintain system uptime. One of the common issues I have experienced in this setup is log rotation issues and managing logs efficiently. There are times when the nginx logs or Apache logs can fill up the space in the virtual machine, then you have to manually SSH into the virtual machine (or EC2 instance) to clear the logs for the application to start working again.
Although Elastic Beanstalk has a unique interface for showing some observability metrics, such as CPU and web Application metrics, which makes it easy to understand application health and status, EC2 does not do much on this. You will have to set up some form of application observability that can help to monitor the status of the running application.
The cost of running a static website is largely dependent on the EC2/Lightsail instance selected for it. Lightsail instance prices start from $3.50/month and a t4g.nano EC2 instance On-Demand price starts from $3.06/month.
Conclusion
Considering frontend Engineers are not specialized in Infrastructure management, it is important to select a service with less operational complexity, that can easily scale and with minimal configurations to get your application up and running in no time. This makes AWS more attractive to frontend engineers without the hassles of hiring a DevOps Engineer to handle the application life cycle for them.
Is this your first time hearing about Containers? We have an Introductory article on it that will give you a solid foundation.
