How we used AWS to power our backend

Companies are switching to a serverless architecture. It results in a shorter time to market, decreases operational costs and developers can focus on improving applications instead of managing infrastructures.

If you are new to this concept, you might be asking: What is a serverless application? Basically, it’s software that runs in an environment where you don’t need to manage any servers. The host that provides it, is fully responsible for managing all the infrastructure and operational tasks.

One of the solutions that address this, is AWS Lambda. According to a report by Datadog, in less than 5 years AWS Lambda is used by half of the AWS users and is most common in the largest environments.

As a trainee at Imaginary Cloud, I had a project in hands: an application called Dwipper. It consisted of a social network to share shower thoughts (similar to Twitter). I needed to have a backend supporting all the essential operations like authentication and processing data. AWS Lambda could offer all I needed for the backend with the integration of other services AWS offers, such as Cognito, API Gateway, DynamoDB, CloudWatch, CodeCommit and CodePipeline. I even didn’t need to worry about managing servers. But before going straight to the application developed, I want you to understand what AWS Lambda is.

What is AWS Lambda?

This function can be associated with a specific AWS resource. For example AWS SNS (Simple Notification Service), that is a messaging service. As soon as this resource changes, Lambda executes your function and manages what is needed.

How does AWS Lambda work??

The next step is to set up your serverless backend, choose what services you will need, configure them and finally, to create your Git repository so you can start working on your application.

Now you can start by writing code in any language supported by AWS Lambda and upload it. You can also write your code in the code editor that Lambda provides. Then you set up your code to be triggered from other AWS services or in-app activity. Lambda receives your request and runs your code only when triggered.

Advantages of using AWS Lambda

Support multiple languages

Minimized cost

Fully managed infrastructure

Automatic scaling

Integration with other AWS products

When to use AWS Lambda

File processing

Data and analytics


Mobile applications

In addition to these scenarios where this service suits better, it is good to keep in mind the limitations that Lambda carry and realize if it’s actually the best service to integrate into your product.

AWS Lambda limitations


This can be a potential issue to consider if your workloads are time-sensitive. Some workarounds try to avoid it, for example, keep your functions small and focused, as cold start times increase linearly with memory and code size.

Function Limits

Not always cost-effective

If the load for your application increases, this will increase proportionally and might end up being a high cost. You need to have in mind that any other service you decide to use along with your Lambda functions, like API Gateway, CloudWatch or any other, will add to that cost. So you should consider how much you expect your application to scale.

Comparing AWS Lambda with other alternatives

AWS Lambda vs Azure Functions

AWS Lambda has a straightforward programming model, while Azure Functions has a more sophisticated one, based on triggers and bindings. The binding system provides extra flexibility, but it also brings some complexity. Both services can run multiple executions of the same function simultaneously.

If you want to add HTTP integration, with AWS Lambda you will have an additional cost, as we already saw, you pay for additional services. On the other hand, Azure Functions come with HTTP endpoint integration and there is no extra cost.

AWS Lambda vs Google Cloud Functions

In terms of the maximum execution time of a function, AWS Lambda stays ahead with six more minutes than Google Cloud Functions.

Regarding payment, just like AWS Lambda, with Cloud Functions you pay only for your function’s execution time. You are not billed when your function is idle.

AWS Lambda vs Kubernetes

On AWS Lambda, you don’t manage the infrastructure and you can’t install any extra software. On Kubernetes, you have to manage the infrastructure and you can install additional software.

Those are just some of the significant and main differences between both of them. In conclusion, if you want to have complete control of the environment, go for a container service like Kubernetes. If you want something more manageable and focus more on improving the product itself, you should choose a serverless service like AWS Lambda.

Other services AWS provides used in our backend

AWS Cognito

AWS API Gateway

AWS DynamoDB

AWS CloudWatch

AWS CodeCommit

AWS CodePipeline

How we built a serverless application with AWS

  • register
  • login
  • recover password/change it
  • see all Dwipps from all users
  • upvote a Dwipp
  • mark a Dwipp as favorite
  • create a new Dwipp
  • delete and edit a Dwipp
  • see the user’s own Dwipps.

We integrated DynamoDB as our database, where we store all the Dwipps created by users from our application, as well as editing and deleting them.

For authentication, AWS Cognito was the solution. It provided an easy management of user authentication that was needed for clients to register their email, generating tokens easily for each user every time they log in to have access to specific content.

To create the REST API and generate the necessary endpoints for all the flow of our application, we integrated Amazon API Gateway. We had to configure AWS Lambda to run our code in response to HTTP requests using API Gateway, which can validate the token generated during login and inject the user data into a lambda environment execution.

Starting with the authentication, we used Cognito User Pools in our function to create a new user account. Regarding the registration, it asks for email and password and the function gets those values, sending them to Cognito and returning the response whether the user has been successfully registered or not. The endpoint is configured in a separate file with the other endpoints, where we put its function. For the login function, we access Cognito once again, sending the user data. In case that user exists, Cognito returns a token needed for the user’s access to the application’s content.

One crucial function is to show all Dwipps from all users. For this one, we need to access DynamoDB, to get the specific table and return all its content. The function to create a Dwipp is basically the same, but instead of getting all items from the table, we want to insert a new item there. The unique ID for each Dwipp is created with uuidv4, a JavaScript package that helps create IDs. The ID and content of the new Dwipp are sent to that table with each field in its column. The user needs to have a token that was generated during the login, the API Gateway validates this token and injects the user data into the environment of the lambda execution. This way, we can identify the user trying to create a new Dwipp.

To upvote a Dwipp, we use the same table as before. But for the favorited Dwipps, we had to create a new table. For the first table, we have a function that checks the current user’s email address and if it has already upvoted the Dwipp registered in the table. If yes, the number of upvotes decreases by one and the email address is removed from the list. If not, it increases by one and the email address is added.

As for the function to mark a Dwipp as favorite, we check if that Dwipp is already in the favorite Dwipps’ table. If it’s there, we confirm if that user already favorited it before. If not, a new favorited Dwipp is added to that table. The information of users that favorited a specific Dwipp are kept in the table as well.

With all those available and easy-to-integrating services, we built a working application with authentication and some functionalities in less than one month.

In the beginning, our idea was to use both AWS Lambda and Google Cloud Functions. We’ve decided for AWS as it provides tools for user creation and authentication, while Google Cloud Functions does not. Everything lives up to expectations as all the required functionalities were possible to implement with only AWS.

It may seem like a big deal to understand all those services at first sight, but AWS provides complete documentation clarifying each of them and useful examples. If you take some time to understand it, start trying it out and test it, you will quickly be able to create a full working backend for your application: free of server and infrastructures management, in a short time and with a reduced cost.

Found this article useful? You might like these ones too!

Originally published at on August 20, 2020.

Applying our own Product Design Process to bring great digital products to life |