3. Overview of the basic AWS Serverless services

Filip Pýrek -

The AWS services that I’m going to show you today have many different uses; I’ll focus only on their important features from the serverless architecture point of view. I will also share a few tips on how and why to use these services in your serverless applications.

AWS Lambda

is the basic building block of Serverless applications.

It’s a block of source code, the so-called lambda function, which when invoked, you are charged only an amount based on the number of milliseconds your application has been running. An important feature of the lambda function is that when not used, you are not being charged.

Thanks to the lambda function you can modify the default behavior of the Serverless services according to your specific needs and requirements; for example, a Custom Message Trigger, in Amazon Cognito, helps you to modify the content and the appearance of the verification emails sent to your users by Amazon Cognito.

Connection of the lambda function to an AWS service is called a trigger.

Amazon API Gateway

is used to create REST or a WebSocket API powered by lambda functions.

An HTTP endpoint today is probably the easiest way to make any functionality available to the outside world, and the same goes for Lambda and API Gateway.

The API Gateway is a Gateway which enables the outer world to invoke your lambda functions. This means that the input of the function consists of all the HTTP request parameters, from headers, the body, to the query string, and the output of the function is the response parameters: the HTTP status code, response body, headers, etc.

A practical example of working with API Gateway can be found in the following part of this series.

Amazon DynamoDB

is a NoSQL column-oriented database that is fully serverless - meaning it can scale down to zero.

From the serverless point of view we can describe the Dynamo DB in two ways:

  1. It’s a high-performing and scalable database, optimized for heavy traffic, originally developed for the needs of Amazon and then thoroughly tested by other companies such as AirBnb, Lyft, Samsung, and others.
  2. It's a Serverless database that enables scaling down to zero and has pay-per-use pricing, so it can be used for a variety of microservices minimizing data storage costs. The database is controlled via the AWS SDK, which is the reason why access management is controlled by AWS IAM which significantly increases the overall security of the database.

At first glance, DynamoDB can appear to be a rather primitive database, but thanks to that it can be used in various ways which can easily lead to its misuse, affecting either the operating costs or the performance of the application.

For more information about the right design patterns and solutions to various general problems, I recommend The DynamoDB Book.

Amazon S3

the Simple Storage Service, is a cloud file storage.

S3 is a highly scalable and highly accessible storage system - so-called object storage - which due to its features, has many uses from the long-term storage of large amounts of data for subsequent data analysis, to the storage of thumbnails that are deleted after a few minutes.

In the world of serverless applications, S3 serves as a long-term repository in which files remain regardless of whether the lambda function is running or not.

For example, if you want to pass a file between two lambda functions, then one of the common design patterns is to upload an image to S3 in the lambda function "A" and then only pass the path of the given file to the lambda function "B", which will be then downloaded in the lambda function "B" from S3 for further processing.

S3 also offers triggers that allow you to respond, for example, to the upload of a new file, which might come in handy while processing documents in various background jobs, etc.

Another important serverless use of S3 is the hosting of static websites. You probably are familiar with server-side rendering - a javascript front-end application is rendered on the server with each request and the resulting HTML is sent to the client. Something similar is the so-called "static export", which is the rendering of the application into HTML only once during deployment of the application. Subsequently, the generated files are uploaded to S3, which then takes care of the distribution using its static web hosting. Static export is offered by all of today's mainstream frameworks such as Next.js, Gatsby, and others.

S3 belongs to a narrow group of the oldest services on AWS, which were launched in 2006.

Amazon CloudWatch

is the monitoring brain of your serverless application and its overall infrastructure.

CloudWatch can be divided into four main parts:

  • Monitoring – monitoring and analyzing any metrics from both AWS and your application. For example, the number of starts or number of errors of a given lambda function over a period of time
  • Alerting – setting alerts for cases when the given metrics exceed the defined limit
  • Logs – monitoring the logs of the lambda functions and searching through them
  • Events – setting timers (cron) for regular execution of lambda functions

Amazon SNS

or the Simple Notification Service is a Pub/Sub type message broker, which replicates and sends messages to all consumers of a given topic

SNS is suitable for cases where several independent lambda functions must respond to one event.

Usage example: a new order in an e-shop – one consumer writes the order into the database, another one sends the request to the warehouse and the last one saves the order in the big-data storage for an analysis. All the consumers receive the same input, in parallel.

In most cases it is better to replace the Amazon SNS with the new service Amazon Event Bridge, which is more refined and tailor-made for serverless applications.

Amazon SQS

or the Simple Queue Service is a fully managed message queue that stores messages from producers and then they get processed by consumers based on their available capacity at the moment.

The reason to use SQS is that no incoming message gets lost. If your API does complex operations, when under a high load, it will get overwhelmed the requests and will either start crashing or start rejecting new connections, which in both cases means that you will lose some of your incoming messages and thus, for example, new orders.

Whereas if the API only sent messages to SQS, from there they would be taken by another independent system, and the API wouldn’t be overwhelmed so quickly and therefore no messages would be lost. In case of a heavier workload, the only thing that would happen would be processing delay for the new messages.

The main difference between the SNS and the SQS is that in the case of SNS all the consumers are informed of a new message whereas with SQS, each message is processed by one consumer.

Amazon EventBridge

provides a bus through which individual parts of the application can communicate with each other.

One of the main features of serverless computing is event-driven architecture, and the EventBus creates space for  the  mutual communication of independent lambda functions within the application.

Once all the events in the application are transmitted via the EventBus, this will rapidly simplify the complexity of the application development, as to add new functionality, you only need to know the name of the event, and to connect the new lambda function to it.

As always, with the EventBus you need to be careful about how many data/requests you transfer through it, as it could backfire over time 💸. A half-cheaper alternative is the already mentioned Amazon SNS, and for heavy loads, it pays to use Amazon Kinesis.

Amazon CloudFront

is the CDN for your applications on AWS.

At first glance, CloudFront seems to be a classic CDN, however, it’s a significant tool for serverless applications. As an example, let’s say you are going to host a static frontend in a S3 bucket and you will expose it using static hosting. Most probably you don’t want your application to run on some Amazon’s subdomain and without SSL, right?

The example mentioned above can be solved by CloudFront as following:

  • Create a free SSL certificate from Amazon for your domain in the Amazon Certificate Manager
  • Create a CloudFront distribution for your domain and add the static hosting URL of your S3 site as the origin
  • Add DNS records to your domain according to the instructions in the CloudFront documentation

As a result, you get:

  • access to your application will be secured via the SSL
  • your application will be available on the domain of your choice
  • Your application will load much faster due to being served from the CDN
  • 🎉 🚀

CloudFront is a good friend who can often save your neck.

Amazon Cognito

is a service that authenticates your users.

It takes care of the entire security cycle of your user base. From the registration, through the confirmation of a verification email, to a login or a multi-factor authentication. To give you a perspective, the most famous competitor of Cognito is the service Auth0.

The behavior of Cognito can be significantly modified through the aforementioned lambda triggers. Cognito as well as Auth0 offers login via Google, Facebook, Apple, Amazon, or its own SAML/OIDC providers.

It is always better to outsource a such a sensitive thing as authentication. Every small mistake can create a huge gap in your application or even sink an entire company.

AWS CloudFormation

cloud provisioning platform based on the Infrastructure-as-Code.

In my opinion, Infrastructure-as-Code is one of the basic building blocks of serverless and the modern cloud. It minimizes the risk of fatal errors, it makes the whole infrastructure more transparent, and, overall, it makes the work more efficiently. AWS offers its own service called CloudFormation, however, cloud agnostic tools can also be used, such as Terraform, Pulumi, and others.

CloudFormation is powering the Serverless Framework for AWS and handles deployment of the application infrastructure.

AWS Cost Explorer

is a service for collecting financial statistics on cloud usage.

A common problem in the growth of a company whose entire infrastructure is based on serverless might be that bad architectural decisions from times long in the past. For example, a team uses a service like the Amazon SQS without calculating how much it will cost in the future and how the cost of the SQS will evolve as the company grows. In the beginning, SQS costs a certain number of dollars, but when the company grows a hundred times, the cost of the SQS will increase a thousand times. At that point, the team looks at the cost structure in the Cost Explorer and begins to figure out how to optimize it. In the end, they might solve it by replacing the SQS with the Amazon Kinesis.

Serverless pricing is a good servant but a bad master.

AWS AppSync

is used to create GraphQL APIs powered by lambda functions and other cloud services.

AppSync is AWS's response to an old-fashioned trend in APIs. In principle, it works the same way as API Gateway, except that you can build with it a GraphQL API in it instead of a REST API.

It offers both a classic integration with AWS Lambda and also an integration with DynamoDB or RDS, whereby you define how a GraphQL query should be translated into a database query.

Unlike API Gateway it always requires some form of authentication, which means that each API must be secured with at least one of the following options:

  • API key
  • IAM token
  • OpenID Connect token
  • Cognito User Pool token

Therefore, you cannot have an open API that can be called by anyone at any time.

AWS Step Functions

is a service providing management for complex branched processes consisting of a large number of steps.

StepFunctions is AWS serverless response to the demand for long-running process solutions.

The main reasons for using StepFunctions are:

  • AWS Lambda has a limited maximum execution time of 15 minutes, which is a short time for long-running processes.
  • It is not recommended in lambda to wait for asynchronous processes, because this is in direct conflict with the basic idea of event-driven architecture, and in practice, it is throwing money out the window.
  • If you have a very complex and branched process, StepFunctions make it easier for you to clearly monitor the process and thus quickly find out where the problem is or what decisions were made during the execution and validate whether or not it was correct.
At Purple Technology, Step Functions were the main impulse for adopting Serverless.

Conclusion

This was a demonstration of only a handful of services and the tip of the iceberg of their use cases. I hope it gives you a basic idea of the cloud components you can use in your serverless applications.

In the following parts of this series, we will take a look at concrete examples of how to work with these services in practice.

In case you have any questions, feel free to contact me at Twitter @FilipPyrek.

With ❤️ made in Brno.