Two basic and probably the most popular AWS services are EC2 and S3. In a nutshell: with EC2 you can set up your project and show it to the world, while S3 is used to store the data of any kind. However, in this article I would like to look at other more or less popular AWS tools that we normally use here, at Codest.
Cloudfront also offers a number of statistics. For example - pages, that have been requested the most, devices, the request for resource have been made with, http statuses, etc.
Of course, this tool is quite expensive, but the more requests to the cloudfront are going to be made, the less you pay for service. Therefore, you should consider this solution in case you want to place the resource on the websites with really big or even huge traffic.
To put it in simple terms, it’s a service that allows to execute of a large number of jobs directly on the AWS. All you have to prepare is an execution script and a docker image, whilst AWS Batch will do the rest. Batch will dynamically create instances on EC2, allocate a suitable place for jobs and launch them at the same time. You do not have to worry that your EC2 instance will be run out of space or memory, or that you have to constantly think about when and how the job can be started. For communication between the script in the docker image and your service you can just create the API and here you go. If you want to use Batch you should also prepare your docker repository in Amazon Elastic Container Registry (ECR) service.
Another service, which gets the benefits from docker containers, is also worth mentioning. It is called Elastic Container Service (ECS). Its main difference comparing to Batch is that you have to set up and scale EC2 instance by yourself whereas Batch does all the job for you. Batch costs depend on which EC2 instances are allowed to use, as, in this case, you only pay for running instances.
AWS Batch does the work by launching docker images, while the next service - AWS Lambda - allows you to run the script directly. You do not need to set up any server, the code is run virtually, and what's even better, you can also return some value in the way you like.
When can it be used? Let's say that you want to make some calculations on our website based on parameters from the browser, and maybe, in addition, these calculations require some extra queries to other places on the web. In this case, all you need to do is to create an endpoint in Lambda, add your script and use this endpoint on the website. It’s really easy.
The Lambda costs are counted only when the script is running, when the endpoint is not used, you pay nothing.
Simple Notification Service, as the name suggests, is a tool specially developed to send notifications. It can be easily used for communication between various AWS services. For example, you have a group of micro-services and you want one of them to lead the others - start some of them or run some actions. In this particular case, you can send notification from the main service and handle receiving messages in another micro-services you prefer. By the way, it is also worth mentioning the Amazon Simple Queue Service (SQS), which can create a very interesting connection together with SNS.
In case of SNS (as well as SQS), payment is provided only for executed requests: sending messages to SNS, sending messages from SNS to other services and other additional requests from the SNS API pool.
Amazon Relational Database Service is just an external database. With this service AWS allows an easy setup, usage and scaling of a relational database. For example, if you expect that your database will have quite a considerable size and will be growing more and more every day, and you plan to regularly perform more or less complex operations using it, e.g processing and copying data to another database, this solution is worth considering. Available database engines include PostgreSQL, MySQL and MariaDB.
It is easy to guess that RDS costs are related to the database size and its usage, so it’s hard to say whether it is going to be very expensive or not.
AWS is constantly changing, whether it is improving existing services or creating something new. It is not only preferable to keep yourself up to date with their technological innovations, but also get to know the already existing stuff.