Hey everyone, my name is Maximilian Kawek and I want to welcome you all to my talk on how to run powerful, scalable, and ultra budget apps on AWS. First, I wanted to say a few words about me. I am a full stack AI software engineer at Perlin with around five years of experience in the field, and I've worked with plenty of various. different technologies I've started with monolithic infrastructures, Java and standard databases. Then I moved on to more of the modern tech stack with plenty of cloud computing, also serverless infrastructures, microservices, and all of the newest bits. And today I wanted to talk to you a little bit about what I've learned, especially on how to. minimize the costs, without sacrificing too much, of your time in regards to development, but also, in regards as to scalability and also the possibility of, the possibilities of the infrastructure that you would actually develop. Now, I just briefly wanted to mention the agenda of the things that we'll talk about today. And in general, we'll be trying to answer the question on how to, basically focus on ultra budget AWS. Is it possible? And if so, what are the possible downsides of the, of this? thing of this idea of this concept. And then we'll also in the meantime, talk about the key components of the infrastructure, how to do the cost saving techniques, most, most efficiently. And also what are the possible trade offs. I also have one, real world breakdown, a cost breakdown prepared from one of our applications that we're running at our company. And yeah, let's get into that and we'll talk about all of those things. So why UltraBudget? Who is it for and why should you even care about this? So if you're a multinational, corporation, which spends thousands of dollars every month on AWS, additional 20, 30, or 50 probably won't make that big of a difference to it. But if you're a cost conscious team or an indie developer, or someone who just wants to develop a side project or an MVP, then Ultra Budget is definitely in my opinion, the way to go. And it's. It's can prove to be an additional perk that you can deliver such quality product and such maintain easy to maintain product at such low costs. And we of course need to look and tackle the challenges of traditional AWS setups, which the biggest thing is that. If you basically let AWS manage everything and you want to have everything provisioned all the time, then this will of course be reflected in your AWS bill. So we need to keep those two things in mind. And my solution to this is to basically strategize how to use which services. And basically, you can supply them with cheaper or even free alternatives in some cases. here you can see the architecture overview that I want to present to you. as you can see, it's one of the probably simplest and easiest solutions to deploying a full stack web application on AWS fully. But what I want to emphasize here that as you can see, it's still like quite modular and quite expandable. So for example, it's not, the type of all in the one solution, like Amplify, which AWS tries to encourage you to use. And where you're basically then fully locked in, not even to the vendor as AWS itself, but rather to even the specific service and it's quite difficult to migrate out of it. So what I definitely prefer on my end is to basically modularize the things. And, yeah, I just like to quickly go over this overview. So as you can see, for example, for my type of ultra budget AWS infrastructures, what I always use is, I use GitHub actions for the DevOps pipelines, which basically deploy the whole application. And I don't need to worry about all of the, infrastructure for it. It's quite simple and efficient. Also, it's free as is important in this regard in this topic. And what I then do is I use AWS as CDK, which is basically a really simple infrastructure as a code tool where you can, declare all of the components needed, the connections between them, pass the information between one and the one and the other, and then you don't basically need to go into AWS console ever to set anything up. And what I have inside of there is the actual AWS infrastructure that I want to show to you, show to you. And yeah, as you can see, first of all, we're like going, through the whole flow. What we have is we have a front end, which is in my, manner, usually a React application hosted in an, basically stored in an S3 bucket, which is then connected to CloudFront. This, yeah, I suppose we'll go into the detail in a little bit. So I will just go briefly between, through the whole flow. This then communicates directly with Cognito, using its JavaScript libraries, like Amplify, but not to. not to mistake it for the actual AWS Amplify tool, service, which are a little bit, which are, the, disconnected in this regard. it's this, it then connects, it then sends a REST request, but of course you can use, every type of API you can possibly imagine with this. And then it sends a REST request to API gateway. which, works as a middleman for, our authorization layer. And it takes a little bit of the, of the accountability and all of the, also a little bit of the responsibility of handling the actual request from the Lambda, which it then directs it to. So basically API gateway, I have set up as a proxy. And then it's, it proxies this, requests to Lambda, which is one of the more interesting things that I want to talk to you about. But this Lambda is also running an AWS Lambda Power Tool, module inside of it. Which is a really useful Python package that I will introduce to you in just a second. And then of course, this Lambda API is your main center of the backend of the application. And then it can connect to whatever it needs to. In this example, I wanted to show you that. for example, for some cases, which we'll discuss in a second, I'm, connecting it to DynamoDB and in some other regards, it needs to communicate with an EC2 instance with, for example, PostgreSQL installed on it. So regarding the specific bits of the infrastructure that I wanted to talk. to you about a little bit more in detail. first of all, we've got the front end, which is hosted on an S3 bucket and then connected to CloudFront and those two components are connected to Cognita. So this gives us a really like bare bones, simple structure type of hosting of static files. Because after you build your node project, it can be hosted as such. for example, on an S3 bucket. Then what we use is we use the CloudFront, service to provision, to give us basically HTTPS for free. that's one of the things, if you don't have the domain yet set up, it's the, simplest solution. And other perks that it offers is, for example, the global caching and fast access. yeah, there is, it's basically a free or a really cheap because it's only cost you per. hundreds of gigabytes transferred, but unless your website weighs it on, it won't be a problem in this scenario. And those components communicate with Cognita, which handles user sessions. also the authentication and it. provides you all of the necessary keys to actually communicate with the rest of your application. Next, we're going to briefly talk about the core backend of our application, which is running AWS Lambda with the AWS Lambda PowerTools package on top of it. And what Lambda is it's basically a serverless cloud computing platform. which, enables you to run your code basically virtually for free, unless you're using it, for hundreds or thousands of hours every month. And, yeah, what are the biggest advantages of it? Why are we picking it right here? comparing to some other, like more traditional. Types of applications like running a flask or a Django or fast API Python application on an EC2 instance or running it in a cluster and managing maybe those, training them to scale them down to zero when there is no traffic on the, on your platform. what Lambda does is it offers us great simplicity for those type of solutions. Also, you don't need to worry about. any infrastructure management at all. And it's automatic scaling is perfect because it basically doesn't run when it's not called. So once you're even, once your request finishes, it's processing in this Lambda, it will come back to zero and it won't cost you any more money. And there are a couple of challenges, of course, to keep in mind. some of them are, as mentioned here, for example, as you can see, the cold starts where you, if you've got a really, I would say heavy in size Lambda and, plenty with plenty of large files, you then need to keep in mind that it will take a little bit longer, a couple seconds, for example, if you haven't started your Lambda in production. in an hour, or if there were no requests hitting it, then it needs a second to basically heat up and to come back to life and to serve your users, still. And the other things are the stateless execution. So there isn't any, if there isn't anything like a server session, basically on Lambda, because every request is handled as a total separate entity. And of course there are some deployment memory limits. So you can't basically host huge applications with plenty of dependencies and packages on it. You need to keep all of those things in mind. And what is Lambda Power Tools? It's a great package that I've stumbled upon recently. And, before I introduce it, I want to, briefly explain to it, to you what is the biggest challenge in my opinion when developing APIs on Lambda without packages like this. And it's basically the boilerplate code. So when you're hitting an AP, an AWS Lambda. You need to somehow manage the requests, the types of requests, the bodies of those, the methods that are being used, the paths that are being sent to, because if you have a lambda as a proxy, basically every request that your frontend sends to an API, it goes to this one single lambda. And how I did this once in the past, which I definitely regret is with a huge list of L if statement, basically checking the string paths parameters and basically be the whole code base being a huge mess. And, yeah, there, there are a couple of ways to, to of course, omit that and to make the development process much nicer and much more develop, developer friendly, I would say. one of those that I used for a moment is basically, using Flask, or fast API on Lambda, which are like wrappers that allow you to write. flask like code with the function decorators, specifying paths and methods and basically handle it that for the Lambda. But this is a really, I'd say, messy workaround, which, incurs additional issues and potential bugs because you don't like flask wasn't built for that. So you're just, launching this. It's like trying to launch this package, that is meant to run on the server. And that was built to run on the server in a stateless cloud environment. So you basically, definitely misuse this quite a lot. And, it's just unnecessary, a huge dependency for that. And what is AWS Lambda Power Tools is basically the perfect, replacement for all of those things. And what it is, it's an AWS developed tool that allows you to write a Flask like code and FastAPI like code, but with the Lambda thing being in mind first. So they basically did, build this exactly for this to simplify the, procedure of writing code on lambdas and to simplify it and to make it much easier to debug, to run, and to maintain in the future. And, some of it's. features that are available to every one of you is my favorite one, which is the event handling, which I just described. And then it also enables you to make it a little bit easier for your application to keep track of logging, tracing. Also, we've got some neat Python specific features like validation, parsing, typing. So your whole code makes much more sense right away. And now I wanted to talk to you a little bit about different database solutions that I'm considering every time I'm building an infrastructure on AWS. And first I wanted to introduce you to DynoDB, which is a simple NoSQL key value based database, which is my preferred solution for anything. that can be a reliably run on it. and what it is I would probably compare it to, a Lambda in terms of, in the realm of databases. It allows you to pay only for the traffic also, of course, for the storage. but unless you're, gathering huge amounts of data. Still, again, it won't be a cost. You probably will be kept in the three tier limit of AWS. And it allows you to also forget about the whole infrastructure, the whole setup, and you only pay, for the amount of traffic and the amount of data that you actually use. And it's also really efficient. It has really low latency and it allows you to be really flexible. So. objects can, different differ between one table and another, of course, that, this can lead to some challenges in production. Great applications. If you really need to, have all of the data structures properly, then you need to keep the, storage of the model somewhere, but this can still be done in your applications code. So it can be aware of which, fields, are, for example, always present there or, and which might be missing. Of course, you can still run migrations on this table, but those are done using, just using Python scripts that you can execute there. And another, type of database that you can run, of course, with still having the budget in mind is, at least in my example, PostgreSQL on EC2. the default way suggested for, by AWS and by most users is to, use RDS, which is relational database service, or, yeah, service. And, the biggest challenge with that is it's quite difficult to keep, to make it cheap and to make it not, costs like at least 15 to 20 per month, even if you don't use it at all. If you don't have anything running on there. And, the answer to that, in my opinion, is, self hosting a database. Because you can, what you can do is you can run a really cheap EC2 instance that will cost you, even the free ones do well enough, I would say, but if you decide for a little bit more of a powerful one to handle more connections, for example, to the simultaneous connections to the database. Then still, it will cost you about two, three, 4 maximum per month, and then you've got an unlimited basically, database, unlimited in terms of traffic, of course, because for the volume, you will still need to pay a little bit. the biggest challenges of that, of course, are the maintenance and backup management. that you need to do on your own and that's basically the cost of, not paying AWS to do this, by themselves on using our, RWS. But in my opinion, it's still worth it because once you set it up, then you can basically forget about it. And yeah, if you have a low traffic application that needs an SQL database, that might be the way to go. it also allows you to, of course, be a little bit more custom and to adapt it to your needs. So for example, if you need some vector stores or those types of things, you can easily install them there as well. And that's something that DynamoDB wouldn't allow you to do. And, yeah, to finalize my talk and to show you a little bit of an example cost breakdown and the summary, it's basically, as you can see, this is a receipt from AWS bills, to one of our applications that, we are currently in a building in an MVP phase. And as you can see, the total cost of the whole application was 3 per month. That's something that's now easily achievable. If you follow all of the principles that I've mentioned, of course, adapting them to your needs. Of course, if you have, much more traffic than we did, then it can be a little bit higher. But, yeah, unless you go, from one day to another, scaling the application for hundreds and thousands of active users, nothing like this should or could happen. And yeah, this is basically the summary of my talk. So I wanted to show you how to run the ultra low, low total cost application. As you can see, this is. It's easily a production ready system that you can introduce to your client and yeah, unless they need to make it much more future proof or unless they need to implement their own hundreds of thousands of custom functionalities using specific services, then you can rely and basically build on top of that base architecture that I showed you. yeah, the serverless is the way to go in my opinion. in this. regard, if you're not going to, if you don't want to spend most of your time worrying about how to set everything up and how to maintain it and back it up, I would say, yeah, using as much, as many, serverless services is the way to go. Unless of course, those are the expensive ones that you will be paying 24 hours a day for just being present there like RDS, which we tried to omit. And yeah, there are a plenty of services that are budget friendly and it can be cost efficient if you try it, if you try to be with it. And I think that would be the end of my talk. Thanks a lot for listening to me, listening to my presentation. I hope you liked it and I hope to see you all in the future.