The AWS Architecture I Wish I Learned First transcript

When it comes to infrastructure and building out SaaS applications or web applications, AWS is still one of the main cloud providers that people use all the time. And most of these other services are actually built on top of AWS just to kind of improve the user experience. But now with AI becoming so much better, you can literally prompt a cloud code or Opus to basically go through and just set up all the infrastructure as code for you.

I'm literally doing that right now. It's spinning up Terraform. It's trying to get everything deployed out. And I'm going to walk you through some of the core services AWS has that you may need to use for your SaaS product. Now, before I dive into this talk, I want to state that AWS is not the cheapest option. If you're trying to find the cheapest way to spin up an application, you probably just want to get a VPS that has a decent amount of cores and memory.

Throw a container on there, throw your database on there, have some type of system to do daily backups of your database, and you can even horizontally scale your application. But even with that approach, you're still going to be probably reaching out to third-party services like sending out emails. How would How would you do that on your own VPS? You have to set up an email server, and then the IP you have, is it even trusted to send out emails?

So, you're probably going to use AWS SES anyway to send out emails. So, the first thing that you're probably going to deploy out to AWS is probably going to be a container, right? I would recommend if you're going to deploy out an application, you should probably start with a container before you dive into using serverless and Lambda. Lambda has its own complexities and nuance that I would recommend just getting a container out there.

You can containerize your TanStack Start application, your Next.js application, whatever application that you have, you can probably have some type of container, and that needs to get deployed somewhere. So, the AWS service I recommend is something called Elastic Container Service. So, ECS, you can basically build your containers, and you're going to put those in something called ECR. So, this is like a storage location for your container images, and then ECS can actually connect to that to pull the image to run your service.

Now, under the hood with ECS, there's Fargate, and there's also just like EC2 containers. I'm not going to dive into the lower-level detail of like that, but just note that you can get a container running in AWS pretty easily by just kind of doing this. And I do want to kind of show you some of these things. So, for example, we can go to Elastic Container Service over here. You can actually spin up a cluster. You can have it auto scale.

You can make it scale based on traffic. You can actually use Fargate for simple task. You can use Fargate instances for doing one-off tasks like heavy compute. You can just spin up a container real quick to do the compute in there. It's a really great service, so that's the first service in the ECR is the container registry. So, this is where your actual containers, after you build them, I guess I should say your images, will get stored in, which ECR is going to kind of load from.

Now, of course, to have a web application, you're going to want a database, right? So, let's just go ahead and build a database. I'll just go like this. We're going to go ahead and just point this over here. So, your application needs to point to a database, and typically, RDS is the one I would probably recommend. I would probably use Postgres for all of your database stuff because I've done DynamoDB. It's pretty great for some use cases, but having that relational database is probably the best thing to start off with for your application if you're building like a SaaS product.

So, RDS. Let's look at RDS. What exactly is RDS? RDS is a service provided by AWS to allow you to spin up a Postgres database. They also have something called Aurora, which automatically scales for you. It's kind of convenient. I will state that RDS is not cheap, right? These things are kind of expensive. You're going to be paying like $10, $15, or $20 a month for one of the smaller instances on AWS for a database. So, you kind of look at your budget, but for most businesses and most of enterprises, like this is not a big deal because RDS is going to provide you with a bunch of things out of the box.

It can provide you with multi-region setup. It can provide you with availability zones. You're not going to get that type of functionality from a VPS, right? That's a lot of stuff you're going to have to build yourself. And if you have, you know, uptime requirements, which many applications probably do, that's why a lot of people use RDS. You're going to be paying a lot more for this, but automated backups, etc. You can also have automated updates.

So, like if Postgres has a new version that comes out, you can just have it automatically start updating your uh instance. Now, at some point you're going to want to have to do long-running asynchronous jobs. Like like I mentioned, you can use ECS Fargate for tasks, but another service you can use is something called AWS Lambda. This is a serverless environment. It's really great for basically setting up um work that just kind of pulls from a queue.

But, I will say that Lambda is really great when you hook it up with SQS. So, SQS over here is the queue service that AWS provides. Let me just go ahead and show you these things so you guys are kind of familiar. So, S QS simple queue service. You can set up a queue, right? So, if you imagine uh Redis, if you imagine ActiveMQ or RabbitMQ, you can get a queue, and then you can have the Lambdas consume from it, and you can have it just fan out and do a bunch of work concurrently as the work comes in.

Now, for most of your API-related tasks that are short-lived and fast, you should probably keep on your web application, but for that long-running task that could take minutes, Lambda can run up to 15 minutes, and you can also containerize stuff and put it in there. So, if you want to put a container in Lambda and run that, you can do that as well. Um a lot of great use cases for Lambda. You can even have your entire application run using Lambda and serverless, but that's a whole 'nother can of worms.

I don't want to get into that. Now, at some point you are probably going to want to send out emails. There is another service that AWS provides called AWS SES. This is something you can use for setting up domains. Let me just go to emails real quick. Simple email service. Let me go to SES over here. This is the dashboard. It's pretty easy. You set up an identity so that you can actually start sending out emails from a domain, and you have to go and set up like an A record in wherever your uh DNS provider actually is.

In my case, I use CloudFlare for a lot of stuff, but then I point that um to be able to send out emails on SES. So, the application as it's running, or maybe even the Lambda itself, can send out emails to your users as, you know, transactional emails or even marketing emails. I mean, if you want to build like your own marketing campaign thing, you can do that as well. Um, that's basically how that's kind of working. Now, sometimes when you're doing long-running tasks, you're going to want users to get a notification.

So, for example, you know, the user's going to kick off a task. It could take 5 minutes for that task to finish. How do you notify these people without doing, you know, long polling? One approach is by using WebSockets. And AWS has a service called API Gateway V2 and it has a WebSocket connection that you can basically do. So, your users can actually kick off these long-running tasks. They will run in Lambda and then at some point Lambda can send off a event to a connected user and that user will get the WebSocket event, okay?

So, at this point you may ask like, why can't we just have the WebSocket server live inside the container? Because when you horizontally scale this thing out and you probably should have this behind some type of auto scaling group, when one user decides that they want to broadcast a message to all the other users in the organization, if you have users connected to different ECS instances, they're not going to get that event.

So, you do still have to have some type of centralized service. Elastic Cache is one way you can achieve that. So, over here you can actually have, you know, many different ECS instances basically broadcasting to topics on this or you could just use something like SNS. SNS is another way you could broadcast a message to SNS and then behind the scenes that's going to use a queue. Your ECS instances will consume that queue so that you can kind of broadcast events to all your users when Bob makes an update to his document, how do you make sure that the other five users on that document get that notification?

Those are two different approaches you can do. So, Elastic Cache and SNS. But, honestly, I'd probably choose WebSocket. API is pretty cheap and it's pretty easy to get set up. Okay, so now at this point you realize that you have your application hosting stuff, but you want to make it a little bit faster. You want to actually put it in front of a CDN. So, one service that AWS provides is something called CloudFront, which is a CDN.

Um, so I'll just kind of put a cache label here. It's a CDN that sits in front of your applications, in front of anything that's publicly facing, so that when users try to request data from your application, they're going to get a cached version potentially. There's also a bunch of other CloudFront features that you can do as well. Okay, CloudFront is a content delivery network. You can, you know, set up WAF rules, you can put different routing rules in your distribution to point to your application, your different origins.

It's very useful. At some point, you're probably going to end up using this. Now, at some point, you're going to want to store files, right? Your users are going to want to upload files. How do you store those? Well, of course, you have something like an S3 bucket. So, let's just go ahead and spin up S3 over here. An S3 bucket is a way for your application to read and write files to basically an infinitely large storage device, right?

It's super cheap. You can store a bunch of files, and also your users can fetch these files directly with pre-signed gets and pre-signed posts if they want to actually upload files to this. So, it's a really useful service, S3. I'm sure you know about it. Um, and I can go over here and show you S3. Okay, you can make a bucket. You can have your application read and write from it. You can set up triggers so that when files enter the bucket, you can automatically kick off, you know, different lambdas that do some cool stuff.

It's It's really really powerful. So, at this point, your application's looking pretty good. You have your users doing stuff. But, as a system administrator, how do you actually go and verify that, you know, if errors are happening, where do you see those logs? There's another service you should probably be aware of called CloudWatch. Yeah, there's a lot of cloud stuff going on in AWS. is where all your logs can be forwarded to so that you can have a filter set up.

You can have notifications that will alert you and your admins. So, like this is like your admin of your system. When something goes wrong, you can have CloudWatch alerts basically send off notifications to your dev team. You can have it actually hook into lambdas with notifications to run like Slack integrations or whatnot. It's very powerful. You can have it just filter through logs and do various You can set up metrics as well.

So, if you have errors that happen five times in an hour, you could then kick off other triggers to do all this other really cool stuff. So, CloudWatch, you're probably going to end up using it. Um also, there's something called log insights that is a query language that lets you kind of look over your CloudWatch logs. Very useful as well. There are a couple of other services I want to touch on. So, if you're trying to get a domain set up for all your different applications and your services, you're probably going to want to use something called Route 53.

So, this is the domain management where you can go and set up a zone, and then in that zone, you can actually have different records set up. Basically like a DNS. So, what I sometimes do in CloudFlare, I will buy a domain and I'll just set up an NS record to point all the traffic from CloudFlare to my Route 53 zone so that I can set up subdomains for my different subservices. Uh you can set up subdomains for your emailers and whatnot.

I do believe AWS, you can actually buy domains here now. Like you can actually just buy a domain, and that's where you're going to manage your domain and your NS records, your your DNS records, okay? Very important service to learn because in in addition to this, you're probably going to want to be able to support HTTPS, right? So, TLS, how do you actually do that? There's another service called ACM. So, let's go back over here.

We're going to say ACM is Amazon Certificate Manager. So, this is where you go and you set up certificates that your application can actually use so that you can have HTTPS access, okay? You want to be able to have certificates so that you have that lock icon in your browser. This is where you can spin those up. You can then point them to Route 53 to automatically get verified, and you're probably going to run into this service as well.

Now, also, typically, because ECS, you know, just spins up containers, you're probably going to want to use something called ALB in front of that. So, elastic load balancer, where your certificates are probably going to be pointed to the ALB, and the ALB, this is kind of like a router. It's going to be able to the to your different uh ECS instances that are running. There's actually a bunch more I didn't even mention.

Like there's something called Bedrock if you want to have integration with LLMs, you can spin up a Bedrock instance and your applications can talk directly to a AWS hosted LLM versus having to go to Anthropic or go out to OpenAI. You can have that just set up in your system like this. You know, I thought I was going to be done with this video, but there's actually some other services that are very important. So, in order to give your services access to even connect to these other things, you have to bring in something called AIM.

Okay? So, you have to set up roles and permissions and policies so that when your ECS instances are trying to connect to SES or connect to Dynamo or RDS, you have to then set up a role and have this have an assumed role so when it spins up it it can actually access these services. And also your admins and your users, they are probably going to be setting up IAM users and roles for the people who work on your team. You can have like organizations and those can be broken down into different roles and policies.

I'm not going to dive into that, but IAM is probably probably a very very important service that you're going to end up needing. Um let me just go ahead and get like a key. This is like the keys of the castle where you actually give these services and your AWS team members access to do things. So, you're going to end up using this. And then also you end up having to store secrets. Okay? You do need to store secrets when you're building an applications.

Where do those go? Well, you can do AWS Secrets Manager. There's also one called SSM, I think Parameter Store. Let me just go ahead and SSM Parameter Store where you can store secret strings in there as well. So that when your services spin up, they can actually grab and decrypt some stored secrets and then use them. For example, if you need this service to be able to access OpenAI, you probably want to store an OpenAI API key inside of here so it can fetch that and then decrypt it and then start connecting with it.

So, it's a secure place to store all the secrets for your your Lambdas for example can do this as well. But yeah, as you can tell, this is a monstrosity at this point. In in to get anything working in AWS, this is all the things that you need to get set up. But I will say that AWS is built for enterprise and scale. So, all these different nodes, typically there is usually a toggle you can just turn up, or you can go and contact their support.

For example, if you want to send out more emails, I do believe like by default you have like 14 emails a second, you can ramp that up. Just go contact support and say, "Hey, I actually need to send out more emails a second." And they will just increase that throughput. If you need to spin up hundreds or thousands of concurrent processes at once, you can just use Lambda. It just scales up automatically based on how many messages you throw into the SQS queue, right?

If you have a bunch of traffic and you want to scale up your ECS instances at certain points of the day, you can just go ahead and set up an auto scaling group and also scale that up. If you have tons and tons and tons of files, of course, you could just have that all stored in S3. It just automatically scales up. You can actually have different tiers of storage. You can use Glacier long-term storage you want to use.

Having a way to access all of your production logs, like you don't have to go and set up New Relic and Elasticsearch and Kibana, which again, those are other services I have used. I didn't even talk about those. So, Open Open Search. That's a big one. I've used this as well. If you want like a way to kind of search over all your data, you can use Open Search. It's basically a fork of Elasticsearch and it gives you access to doing like a inverted index type of database.

And then with this, I do believe there's a a built-in Kibana support. So, like if you just want a nicer way to look over your logs, you can set up Open Search. You can have all your your messages kind of get indexed into Open Search, and then you can look over them with Kibana. I do believe you'll probably need some type of Lambda in there to process that type of transition. But yeah, there's just a lot of cool stuff you can do in AWS.

Obviously, this is highly complex, and um this is why DevOps engineers who are working at enterprises who really understand the AWS cloud ecosystem get paid a lot of money, because you have to know all these services, how they work, how they integrate, how do you actually get this all set up, because one thing I didn't even mention is on larger projects often you want to clone your entire environment. So you clone it so that you could have a staging environment.

This could be your production environment. And these can be in separate completely separate AWS accounts. So like I could just go ahead and put this in a different AWS account. So it's completely isolated from my lower environments as well. And then you could also have a dev environment. You can have sandbox environments so every user can spin up or every developer can spin up their own sandbox with basically running one command and that's going to spin up all the exact same stuff in the same configuration as production.

So then it's easy to basically make changes on staging, verify it's good, and then promote that to production. Okay? So that's kind of like an overview of AWS, why you want to use it, how you can use it to build out your SaaS applications. Would I recommend it for a small side project? I don't know. That's up to you, but for larger projects I have seen every every project I've worked on full time has been deployed to AWS.

I've never worked on a real project that uses like Railway or Vercel. Like when you get to serious projects, you end up using either GCP, which is Google Cloud Compute, or AWS because these are like the top dog players when it comes to cloud. Also Azure from Microsoft, but I've never touched GCP or Azure. I've always just used AWS because like I mentioned it is probably the best way to get all this stuff deployed out.

Now again, I'm going to I'm going to say it one more time. This stuff isn't cheap. This stuff adds up and you have to kind of weigh that out. Um but it does give you the flexibility of quickly scaling out and handling tons and tons of data, tons and tons of traffic without you having to SSH into a machine and doing manual stuff and making sure you're haven't accidentally misconfigured or insecurely configured something that uh you may be running.

Anyway, yeah, I hope you guys enjoyed that overview. Have a good day and happy coding.