There is a recurring thing that happens nearly every time I work on a serverless function behind an API Gateway. I deploy the function, open a browser and navigate to the URL, and finally see an Internal server error. Bummer, something is broken. But what? Let’s check the logs! But to do that, I need to open CloudWatch logs, find the function, then find the appropriate log stream, and finally, I’ll see the logs.

Let’s say you have an image on a customers-only corner of your website. To ease the bandwidth requirements on your servers, you decided to move the image to S3 and use signed URLs to selectively grant access to it. This can be a small thing like an avatar, or a bigger one, for example, some promotional content.

I’ve seen a few applications with hardcoded AWS credentials. Even though it is something that should not happen, I can see why this pattern emerges from time to time. When there is nobody with adequate experience with the cloud it is the easiest and the “just works” solution that ticks all checkboxes. And not until much later, just before the product goes to production will it surface (well, I’ve seen teams where it wouldn’t have been a problem even then).

This month I’ve attended the Craft Conference. Last time I used my laptop to take notes, but this time, I tried a new setup to save some space in my backpack: an Android smartphone with a Bluetooth keyboard.