• Corporate
Published on 17 January 2020

AWS - Serverless project

AWS serverless project


Serverless is not a buzzword but a design concept that utilizes the most advanced PaaS/SaaS components of public Cloud providers.

The purpose is to build your application without using any VM (EC2 in AWS) by combining and interconnecting those components to work together.

Solution choice overview

The solution chosen for this project is a 3-tier architecture type with a Front-End, a Back-End, and a Data sections.

   - Front-End: S3 bucket hosting the HTML/Angular
   - Back-End: API gateway + Lambda (REST API)
   - Data: S3 bucket

At EVA Group, we have made the choice of python as the main language wherever we can as it is the most inclusive of all our expertise (Infrastructure Automation, Cloud providers, Software Development, RPA, ML, …).

As such, we have developed all our lambda functions in python, using the boto3 framework (AWS python framework).


Start with your lambda functions. Apply your SDLC best practices and always limit the resources and execution time (unless you may be ok to blow your financial balance if you have an infinity loop in your code :p). Add the testing sets to handle the TDD part and get confidence about all the limit cases management.

The Front-End is quite straightforward, just be careful to configure your Angular services to the API gateway URLs.

The trickiest part is actually finding all the relevant places to activate the serving of the lambda functions by API gateway component through the Cross-Site-Scripting activation, and not just roles. After a few hours, you get the gist of it.

The Data part can be a database, an S3 bucket, or anything else (e.g. S3+Athena). Your lambda functions will expose those through API anyway.

In my case, vacation photos were available so I opted for a S3 bucket to serve those instead of coming up with a dataset hosted on a table. However, I tried the DynamoDB + Lambda and it worked quite easily.


One of the benefits inherent to a good serverless design is the “Scalability by design”. You don’t have to configure anything (unless you introduce SPOF yourself) to benefit of this scalability. The application is working for 1, 10, 10 000 or even a few million transactions. Why? Because all those components are scalable by design. In case of multiple regions, you can use S3 bucket replication feature and/or CloudFront (CDN) to optimise.

The second benefit is Cost saving. In theory, you can save at least 3-5 times the cost of the same application hosted in EC2 (including scale-up and scale-down features as well as committed instances). The reality is even better, since in case of low usage or very low to high peaks usage types, the cost saving is about 1 to 10. This project is just costing the S3 storage so far as far I’m concerned.


Most organizations, while recognizing to various degrees serverless benefits, are still mainly designing their application with VM / containers in mind. However, a correct TCO calculation of an application should encompass the development time, as well as the running cost for at least 3y (most applications live 5-10 years minimum).

At EVA Group, we are developing our own tools in serverless and we bring this expertise in all our customer projects. Don’t hesitate to give us a shout, we work as well in reworking existing applications to be more serverless!

Article written by
Gabrielle Guerrini