Hi Reader 👋🏽
Tobi & I took 3-days off of our full-time jobs, sat together and created content in full focus mode. In the upcoming weeks you will see a lot more visual content like Infographics, Cheatsheets, and blog posts.
This newsletter edition is all about 💾 Databases & Storage on AWS. You have endless options on AWS for using different services for persisting your data. This post will give you an introduction to the three most important services in this area.
DynamoDB was already covered in the last issue but we actually wanted to go one step back and provide you an overview of these three services.
We'll provide you with one example use case for every service. With that you should be able to understand when to use which service.
One thing all three services have in common is that they are fully-managed by AWS. As we’ve already learned in previous newsletters it is a good idea to hand over as much of the infrastructure responsibility to AWS. You can focus on your actual business logic of your application. AWS takes care of the rest.
RDS is a fully managed SQL database service. With RDS your deployments, scaling, migrations, and backups can easily be done and AWS takes care of that for you.
RDS is offering you to build a SQL (Structured Query Language) database. SQL databases are especially useful for doing so-called OLAP use cases. OLAP means Online Analytical Processing. A typical OLAP process includes aggregation operations such as:
A good example for that is analyzing your web data. Let's take the following example:
A user visits our landing page => An API is called that is handled by a Lambda function. The Lambda function adds an entry into RDS with the following data:
If you now want to analyze how many page-views you had in the last 7 days, you can execute a SQL query to get that result:
This is a typical OLAP use case.
DynamoDB on the other hand is a so-called NoSQL Database. It is optimized for Online Transaction Processing (OLTP) workloads.
OLTP workloads especially involve a high load of incoming traffic. DynamoDB automatically scales with you on this traffic. A typical example is the insertion of a high number of IOT sensors into DynamoDB via DynamoDB streams.
One amazing capability of DynamoDB is that its pricing is to 100% usage based. That means if you don't use it you won't pay 1 ct.
DynamoDB saves your data in a JSON format. One of the major differences to RDS is that DynamoDB doesn't follow a schema while inserting data. That means that there are no enforced constraints by the database engine about how the data has to look like. If you need to insert a new field, you can write it immediately.
This doesn't mean that there is no schema. Your application still follows an implicit schema definition, as it expects the data to be in a given format.
The last service we are introducing is S3. S3 is one of the most popular services of AWS out there.
S3 has one of the highest durability rates of 99.999999999%. Combined with an uptime Service-Level Agreement of 99.99%, your data is save and always available.
S3 is mostly used for saving BLOBs (Binary Large Object). Typical BLOB objects are:
S3 is not a database. It is a storage option. S3 lets you create buckets and objects within these buckets. S3 has no upper limit of storage size. You can save as much as you want in a bucket.
A typical S3 use case is hosting a static website. You can save your HTML file, images, and all assets in a bucket. Put a CloudFront distribution in front that will serve your files and your hosting is done.
Thats all about our recommend database & storage options on AWS. One amazing thing about AWS databases is that they offer purpose built database. You have even more options to choose from:
... to name just a few. We see that many people get overwhelmed with the sheer number of database options. That is why we recommend sticking to the three storage options of this newsletter from the beginning and focusing on mastering those first.
Let us know what you think. Are you interested in any other database solutions?
Reply to this email and send us your comments.
See you in two weeks 👋🏽
Tobi & Sandro
We teach AWS for the real world - not for certifications. Join more than 10,500 developers learning how to build real-world applications on AWS.
AWS FOR THE REAL WORLD ⏱️ Reading time: 11 minutes 🎯 Main Learning: A Karpenter NodePool is a placement policy, not an instance preference. Pin one instance family, and a Spot shortage moves your fleet across availability zones, where every internal call starts costing $0.01 per GB. 📝 Blog Post Hey Reader 👋🏽 Important off topic things first: Sandro got married! 🎉We were in Munich for it and it was a fantastic day! ☀️Highly recommend a wedding over sprint planning or fighting with AWS...
AWS FOR THE REAL WORLD ⏱️ Reading time: 6 minutes 🎯 Main Learning: One stack, reused for every project. Hono on Lambda, Postgres with Drizzle, a TanStack SPA on S3 and CloudFront, and Better Auth for login. 📝 Blog Post Hey Reader 👋🏽we've build a lot of fullstack applications so far: client projects side projects (this one, shopify apps, etc.) example tutorial apps Over the past few years we switched up tech stacks a lot. That taught us what actually matters in a stack and what is just...
AWS FOR THE REAL WORLD ⏱️ Reading time: 10 minutes 🎯 Main Learning: Wildcards come from the tooling, not from laziness. Put least privilege at the account level and let an agent write the policies. 📝 Blog Post Hey Reader 👋🏽 I have shipped my share of s3:* at unusual hours and told myself I would refactor it later - which obviously never happened 😅 So when someone on r/aws asked why developers can't write least privilege policies and put it down to laziness, I was excited to read through all...