 Hello, and welcome to today's Amazon Web Services tutorial. We will be covering a new concept in cloud computing, namely the serverless architecture. What does this mean? Well, essentially, serverless computing allows you to build and run applications and services without the need to manage the actual server. It also provides flexible scaling under heavy load and automated high availability, becoming a very versatile tool. The AWS serverless platform has many capabilities. As you can see, but for the purpose of this video, we will be showcasing the creation of a serverless web app from scratch. The structure of this project can be easily understood by following this diagram. All of the front-end code will reside in the S3 storage unit, which allows us to host the website publicly. Therefore, we start by creating an empty S3 bucket, like so. Give it a unique global name and click Create. And now to upload the static website's content into the bucket, I simply click Upload and drag and drop the build folder into here, like so. Note that I am using React as a framework, so it might be a bit different for you. The next step is making the bucket public, and for that we go on to Permissions and Bucket Policy and paste this bucket policy in order to allow public reads. Click Save and do not forget to change the bucket name. Now this bucket has gained public access. As far as configuration is concerned, the only thing remaining is enabling the website hosting in the S3, which will allow the objects to be available at the website endpoint of the bucket. Click Properties and select this card to do so. Check Use this bucket to host a website and input a root. For us it will be index.html. Furthermore, you can set up a custom domain for your S3 bucket by following the tutorial right here, which will be linked in the description. Anyhow, now you have the endpoint of the website. And if you click it, you will see that the static website has come online. Going back to the diagram, there are a couple of things left to do. We should set up an instance of the Amazon Cognito user pool, which enables us to register, login and authenticate securely. Then we will write the backbone of the serverless project that are the various AWS Lambda functions, which replace the server as they access and manipulate of Amazon DynamoDB, no SQL database, and respond to easy to use RESTful API calls. But first, the user pool. Head to Amazon Cognito and click Manage User Pools. Here you can create one or several user pools based on your application. For instance, one for your regular users and one for administrator. You give it a name and click Review Default Settings. Here there are various options, the password length, some type of restrictions for it. Authentication by email is a really important one, because you actually also gain a two-factor authentication while using the Amazon Cognito and finally create the user pool. You can find it under the user pools category and make sure you note down the pool ID that it has given itself, as well as the previous endpoint of the website. The final step of configuring the user pool is creating an app client for your project. I already have one in here, but you can always add multiple ones. Just give it a name and make sure you deselect the Generate Secret Client option, because that means that it doesn't support the JavaScript SDK. You can also manage and configure every single user in your user group by clicking here and for instance having the option to disable, delete users even, creating or importing new ones as well, and most projects use JavaScript these days. After that, leave the other options as default and click Create App Client. Make sure you save the App Client ID for future use. Once you have the two IDs, you can insert them into your application and benefit from the various Cognito APIs, like the login and register ones. Let us test this new functionality into the website. Now we can register a new user, for instance, with this email, a password that satisfies the constraints, and the verification code has been sent to the said email. It has sent this JSON using the user pool ID and client ID that we have just provided it with, and we have already appeared as an unconfirmed user in the user pool. After user verifies himself, he can also login by following the same procedure, and of course he would get a warning if his password is incorrect. Once Cognito is out of the way, all that remains is the serverless backend. AWS Lambda interacts with a database, so we must first create one. Head on to DynamoDB and click Create Table. Here give it a name and the primary key you can choose between various types, and then Create. For instance, here is my database. I have events with various categories. DynamoDB is a non-relational database, and you can edit the data inside at any time, as long as it is not the primary key of the item. For instance, here I have made a mistake, event capacity should be a number, and then click Save, it successfully changed it. Furthermore, you can customize it by adding new fields inside it. Let's say time of day, morning, and then it would add that category. Now that we have the database, we need to create a role, more specifically an identity and access management role for the future function, so that it has access to read and write to this database specifically. So let us do just that. Go on to the Overview tab and write down the Amazon resource name, so that we know which database we'll use. Then proceed to go to IAM and create a new role. Here choose Lambda, as that's the type of function that we'll use. In the Filter Policies search bar, begin typing Lambda, and choose AWS Lambda Basic Execution Role, so that it will have permissions to write to CloudWatch Logs, so that you can see whether you have errors or not. Then click Next, provide a name for it, and then you're ready to create the actual role. You can find it here, in my case. Now to attach the policy for our specific database, click here Add inline policy. For Choose a service, type DynamoDB, Actions, let's give it all the types of read, writes, and lists, and for Resources with specific option checked, go on to Table and click Add ARN. Here you can paste your own database ARN, and it will automatically fill in the fields for you. Click Add, and then you can review the policy, giving it a name as well. Once the role is created with both policies in place, we are now ready to create the actual Lambda function. This is easily done by going to AWS Lambda, and clicking Create Function. I like leaving author from scratch option enabled. For runtime, give it the programming language of your choice, a name, and a role. You can choose an existing role, and here you can see the one that we've just made, example Lambda role. Create Function, and the base one will be created for you. After we create the Function, you can see that it already has access to the CloudWatch logs, as well as the Amazon DynamoDB database that we've just created. The Function itself is a HelloWords tab, onto which you can build other functionalities. In order to test it, you click here, give it a name, and some parameters, if needed. In our case, it doesn't use them, so it doesn't really matter. Click Create, and again Test. As you can see, it says Hello from Lambda back. This is why we've added the CloudWatch logs policy. Now onto a more complex example. We go onto Functions and Get Events. This is a Lambda Function, which takes all of the events in the database we've previously looked at that have reached past a certain hard-coded date, due to this line here, using a DB Client Scan method. We click Test, and check out the results. Seeing that it does output all of the events. In the same way, you can make a post-event Function, which takes into account the parameters required to make a new entry in the database. Let's name it Test3, in this case, and click Test. The Function has added Test3. So let us see that. And here it is. Going back to the Function, a keen eye would have noticed that we have something called an API Gateway here as a trigger. What this does is it enables an URL, which we can use in our application, on which we call with a Get or a Post, for instance, and receive the result of the Function back in JSON format. This is essentially the final piece of the puzzle that connects all of the services together. In order to create one, remember, every Function has one API Gateway. We give it a name, a description if necessary, and an endpoint type. Let's choose Edge Optimized, in this case. Go to the API, go to Actions, create a method of the type that your Function is. Let's put it at any. Select Lambda Function, the region, and the Function that you've wanted the API for. Let's continue with the example Function, in our case. Use DefaultTimeout should be checked as well. You will land in this page, and the API Gateway is almost ready to be deployed. You will notice here in Method Request, Authentification is set to None. What does this mean? Well, if we change that, we can make it so that, for instance, the View Events, viewing all of the events in the database, is only allowed if you're already logged in. So after we do so, only then we'll be able to see the events. This is done by creating a new Authorizer. Click Cognito and give it a name. Let's call it User. Select the user pool that you've previously created, and the token source should be Authorization. Select and then back in Resources, click Any, Method Request, Authorization, Refresh, and you can see the newly created user. Now only being logged in into that specific Cognito user pool will allow you to access this specific Function. Those being said, we are now ready to deploy the Gateway API. You should also note this option here, Enable Cross-Origin Resource Sharing. I recommend you do enable it if you, like me, have opted to use Axios as a method of communication with the API, otherwise it wouldn't work. And finally, Deploy API. Select a new deployment stage with the name of your choice and clicking Deploy. This will yield evoke URL, which you will put in your application and onto which you will call with the get or post depending on the Function that you've wanted to call. The serverless web app functionality is now complete. You have the static website, sitting in the S3 storage unit with all the images CSS, HTML. The user pool uses Cognito to manage the login register and authentication, followed by the newly created database, which is populated and manipulated by the various Lambda Functions that you'll create, which are called from the project through the Gateway API. Thus, they all amounts to a single web application, which can be expanded upon easily. Last but not least, regarding price. Well, the cost of creating the serverless web app is null, as AWS accounts only for the time its service is actually run, which is mainly the amount of traffic and how many times the Lambda Functions compute. For me personally, it has been less than $0.1, and I have had the web app on for a period of about two weeks time, with extensive function tests. Ultimately, all of these resources are available in a GitHub project, and check the video description for more details. Thank you for watching.