π This is not properly displayed? Read all of our issues online! π‘
Hi Reader ππ½
in this newsletter, we want to give you insights and progress updates about our upcoming book: The CloudWatch Book π
We'll cover why we want to create such a book, what we will cover in the book, and give you a sneak peek into our example application.
CloudWatch is one of the most essential services in AWS. It gives you the power of having one centralized place for all of your logs, metrics, and alarms, and even gives you more tools to observe your application.
We saw many companies already paying for third-party providers before they even understood what CloudWatch is capable of. Often they even ended up with double the costs, for such simple use cases that could have been fulfilled with CloudWatch only.
This is where we want to educate. We want to showcase how to use CloudWatch in a distributed Cloud application and what it is capable of. This makes the decision of buying a third-party provider vs. using native AWS tooling much easier!
The CloudWatch Book consists of several parts.
At the core of our book is a Hands-On Project, featuring a web application to track GitHub repositories - complete with full IAC and business logic code.
We developed a web application for tracking GitHub repositories (stars, languages, etc.). We've included several native AWS Services like Lambda, DynamoDB, API Gateway, S3, and more. With this application, we will show you a real-world example of how to apply observability in a distributed application.
Alongside the book, we offer insightful infographics for key topics. The book will cover all the theoretical knowledge that is necessary to understand CloudWatch. We will include relevant code passages for you to follow along.
For major topics, we have created one-page infographics so that you can get all the information on one page.
You can see the full TOC here.
Our accompanying video course will guide you through the whole journey of CloudWatch.
In this course, we will:
We're making great progress! Key chapters such as Log Insights, Metrics, Alarms, and Distributed Tracing are going very well.
While each chapter includes more and more development in the hands-on project we are very happy with the progress.
The whole infrastructure is created with Terraform and we are still deciding if we add CDK support as well, but we do think we'll do that π (let us know what you think about this, do you need CDK)
If you have specific topics in mind that you want to learn please reach out to us. AWS Fundamentals was a great book because we wrote it together with you.
If you have anything in mind simply reply to this email, and we read every one of them π
Thank you for being part of our journey. We will keep you posted with more sample chapters, screencasts, and updates about our project.
Have a great week ahead!
Best,
Sandro & Tobi βπ½
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: 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...
AWS FOR THE REAL WORLD β±οΈ Reading time: 11 minutes π― Main Learning: Most teams should stay serverless. EKS only pays off at real scale. π Blog Post Hey Reader ππ½For years we told everyone the same thing: don't run Kubernetes! And we meant it. Running k8s yourself is a second full-time job. Cluster upgrades, etcd backups, some networking plugin that falls over on a Tuesday and nobody can say why.We're serverless people through and through. Lambda first, a queue behind it, scale to zero, go...