How to create a dynamic website using AWS serverless architecture?

In this post, we shall discuss AWS serverless architecture and showcase the dynamic website that we built on AWS serverless architecture for our call tracking tool. Many companies are moving or planning towards serverless architecture because of the following reasons:

  • Shorter time to market: You have a brilliant idea and can’t wait to launch a mobile app for it. Enter the serverless architecture era where you don’t have to buy any hardware or need to rent anything. All these things are now managed by your serverless platform provider. You can focus on product development planning and its marketing strategy. This significantly shortens your time to market.
  • More time for user experience: Users don’t care about infrastructure; they care about features and their experience. The serverless architecture allows teams to focus resources on the elements that keep users happy.
  • Flexibility: Gives the flexibility to change underlying technology without affecting user’s experience. If your development team is using nodejs for lambda function then can switch to python without affecting website or mobile experience. Also, your team can get rid of RDBMS and use NoSQL databases like dynamoDB or MongoDB.
  • Scalable: Supports from hundreds to millions of users without bothering about the hardware infrastructure. Gone are the days when you need a dedicated team to support the scalability of your platform. You can achieve limitless scalability using this architecture.
  • Cost Effective: There is no charge when the code is not running. Since you are going to pay for the number of requests to the architecture rather than paying the EC2 so the effective cost shall be substantially less than the conventional hosting solution.

Background about Call tracking app

A little background about our call tracking tool, Jiyo’s purpose is to record the calls of the business marketing callers and send the call information to the Server for processing. A business logic was written to process the call recordings and information related to the calls. All the consolidated information is displayed on the dashboard for a manager/company’s admin. This information helps a manager/company to improve the performance of agents by detecting the core problem and help their team accordingly.

The original architecture was a conventional architecture that was using EC2 machines to process and store the caller’s data. This approach starts hurting us in terms of performance and costing once we started to have more users on the platform. The architecture slows down once there was peak time and remains idle for the rest of the time. We tried to use AWS autoscaling to resolve it but it wasn’t long-term solution. In addition to that storing files on ECB was costing a lot. So these are the reasons that we decided to move from current architecture to serverless architecture.

AWS serverless architecture

Amazon Lambda lets programmers run code without managing any servers, not even Cloud servers. Developers write code, store it on Amazon Lambda and there is no charge when the code is not running. In our platform, our mobile app pushes the caller’s details to the server while our dashboard fetches the relevant data from the server. We took the advantage of serverless architecture and used following services for our platform.

  • Amazon Cognito

    We used Amazon Cognito for our dashboard as well as mobile apps for a consistent, cross-platform identifier for our users. Using Cognito we can control authentication and use the user’s identified in our persistent database for references. We used Cognito Android SDK for our mobile app while used javascript SDK for our dashboard.

  • AWS API Gateway

    Initially, all our REST APIs were written on Spring framework and we gradually move everything to Lambda(NodeJS). We had configured some APIs which were handled by Spring and rest by our Lambda service. We recommend using  Serverless – The Serverless Application Framework powered by AWS Lambda and API Gateway, which saves you from all the complexity of AWS configuration required for Lambda and API Gateway. Moreover, the framework makes collaboration easier and allow you to test and deploy your functions and APIs across multiple regions with very little effort.

  • Lambda

    The purpose of Lambda function was to handle the recorded files and calls details. The Lambda pushes the recorded files to the Amazon S3 buckets and push the call data to the RDS server. Storing files on S3 can be cost effective to the ec2 machine, moreover one needn’t bother about the backup for these files. This lambda function also serves REST APIs for the dynamic website built on AngularJS and Bootstrap.

  • Amazon S3

    We used Amazon S3 for two purposes, the first purpose was to store the call recordings and another purpose was to host our dashboard. Our dynamic dashboard consists of static HTML, CSS and JS files. We used AngularJs and Bootstrap for polished Admin’s dashboard while used Ajax to make the call to the REST APIs served by Lambda function.

  • RDS (MariaDB)

    Our data requires relational logics so we used MySQL’s fork MariaDB. We can scale the database based on our requirements and needn’t worry about conventional things like database backup. We are planning to move from RDBMS to DynoDB in coming months and making the architecture true serverless.


The concept of serverless has the ability to radically transform the cost structure of IT while providing essentially limitless scalability. In short, serverless architecture shall reduce the burden of deploying, scaling, managing the infrastructure behind their code.

Please comment here if you have any question or need our expertise to help you moving your platform to AWS serverless architecture.


For further reading


Leave a Comment

Scroll to Top