Using Micro Frontends with AWS Amplify: A Cost-Effective Approach to Creating Startups

Melchor Tatlonghari

I’ve built and manage multiple micro-frontend web applications by using a single domain and routing them into multiple subdomains using Route 53 and AWS Amplify.

Domains are Expensive

Unfortunately, the expense of domain names is something that cannot be avoided, especially if you want a good name that is in demand. These costs can be astronomical, reaching up to $30,000 per year. Additionally, domain names must be purchased for a full year and cannot be bought on an ephemeral basis like other services offered by providers such as Google Domains.

Ironically, while you can save thousands of dollars by building your own product and going completely serverless, you may find yourself blindsided by the high cost of domain names. This goes against the logic of wanting to build as many products as possible to test the market.

Some may suggest using default names provided by Cloud Service Providers (CSPs), but this is not feasible if you want any traffic on your site. For example, when I ran my backend servers on Heroku, I was given a URL like “https://boiling-sands-25945-0f256938e138.herokuapp.com". Today, with people being more tech-savvy, no one in their right mind would visit a site with such a URL out of fear for their social media accounts being compromised and don’t even get me started on auto-generated URLs for AWS S3 buckets.

Deliberate Names

The high cost of domain names forces you to choose your domain name carefully instead of settling for the first option that comes to mind. It requires foresight when committing to a domain because buying the wrong one could result in having to purchase additional domains later on. For example, I initially bought 'insurancepolicy.net', but later realized it wasn’t versatile enough for the other tools I wanted to build. This forced me to buy more domains.

On the other hand, using my personal domain allows me to share the other tools I’ve created under a subdomain. These subdomains make sense because they are tools I use and openly share with the public. Although each tool runs on a different URL, I only had to pay for the main domain ('melchortatlonghari') instead of purchasing multiple domain names. This approach works well for now since these tools are built under my name. If I were building a suite of applications under one common name, for example, pdf-tools.com or ai-tools.com, it would still make sense.

Below are the sites that run on different URLs but only require one domain payment:

https://www.melchortatlonghari.com/ — main personal site https://quotes.melchortatlonghari.com/ — tool for auto generating qoutes for marketing https://snippets.melchortatlonghari.com/ — collection of code snippets designed for increasing productivity Show me the money Below is my billing statement for the month of June for running 4 applications in total, including my new application which sits in a different domain altogether (https://insurancepolicyai.net/) :

Costs for running four web applications

Traffic details for one month Micro Frontends using AWS Amplify Depending on your technical expertise, you can also use subdomains to run multiple micro frontends. Each of my sites has a different tech stack that I experiment with. For example, quotes currently uses sveltekit because I wanted to learn the language, while snippets uses docusaurus, a framework focused on publishing markdown files. My home page follows the traditional react tech stack.

Routing is currently done through Route 53, with each site running on AWS Amplify. I appreciate how simple AWS Amplify makes things. You just need to add one YAML file where you specify the commands to be executed by AWS Amplify at different stages of the build pipeline. With this setup, you can have a fully serverless front-end web application running in production.

Backend is a Different Story, as Always Deploying backends in AWS Amplify can be a bit tricky. I had a simple Python flask backend API and realized that there was some configuration required to deploy it via the Command Line Interface (CLI), which wasn’t properly documented. I have a couple of Terraform scripts ready to go for bringing up my API in AWS, but I didn’t like how many resources AWS needed just to build a simple GET API.

To set up a simple serverless REST API in AWS, my Terraform script would need to create IAM roles/users (to allow applications to access resources), API Gateway (to connect external requests to Lambda functions), Lambda Function (for serverless execution of functions), and CloudWatch (for logging). If I had a more complex backend, I would also need to handle VPC networking (to allow Lambda functions to connect to databases), RDS (for database persistence), and possibly even S3 Bucket (for file storage), along with additional IAM configurations for service authentication.

This headache was too much for me when testing out a proof of concept, so for now, I turned to Heroku.

Traffic is Hard to Get

As anyone who has started building things on their own knows, getting traffic to your site is the most challenging part. It requires marketing efforts and some magic to make people aware of the sites you’ve built. Running on subdomains can be trickier because you need to consider how SEO works. Indexing would group all subdomains under one umbrella, and if your subdomains aren’t entirely related, it could work against you in terms of getting traffic.

However, once your site becomes more mature and gains more traffic, it’s always easy to redirect from a subdomain to a new full domain using Route 53. This allows you to start with minimal investment while building up your application.

Closing Words

In the world of Software Engineering, there are always multiple ways to achieve the same goal. You don’t have to follow the traditional route of a heavy-weight approach of deploying a web application through conventional means with multiple services required just to run your static site.

When starting out, you can be creative in how you get your application off the ground. The good news is that different providers offer a myriad of options for deploying things online; you just need to test what works best for your current situation. Avoid over-engineering your deployment when you only have 0–50 users.

Think of it this way: when you’re learning to drive, do you start with a Ferrari? So why do some engineers always jump straight to Kubernetes or using all the bells and whistle on their first step in deployment? The old adage, KISS, Keep It Simple Stupid