AWS

Biggest pre:Invent 2024 serverless announcements

DynamoDB cuts on-demand price by 50% Announcement DynamoDB has reduced on-demand pricing by 50% and global tables by up to 67%. Amazing! Lambda SnapStart is now available for Python and .Net Announcement Previously, SnapStart was only available for Java. It makes sense to add support for .Net. But why Python and not Node.js? I guess …

Biggest pre:Invent 2024 serverless announcements Read More »

Here is one of the most misunderstood aspects of AWS Lambda

One of the most misunderstood aspects of Lambda is how throttling applies to async invocations. Or rather, how it doesn’t!

The TL;DR is that you will never experience throttling when you invoke a function asynchronously.

It also means that despite SNS and EventBridge having longer retry periods than Lambda’s internal queue, these have no practical impact in the case of Lambda throttling.

Read the full post to understand why.

EventBridge best practice: why you should wrap events in event envelopes

This article is about best practices for building event-driven architectures on AWS, with a focus on wrapping events in custom envelopes when using EventBridge.

While EventBridge provides metadata by default, a custom envelope allows for a standardized, consistent structure across all of your events, making it easier to manage and evolve the system over time.

By providing your own metadata, you can gain better interoperability between different services, end-to-end observability, idempotency control and versioning.

Should “serverless” just mean “function-as-a-service”?

Gregor Hohpe said something that has me mulling over for some time now. Essentially, he asked, “Should we narrow the definition of serverless to mean just function-as-a-service (FaaS)?” “Serviceful” For context, I’m firmly in the “serverless means serviceful” camp: a) Serverless is a mindset: To leverage managed services to deal with undifferentiated heavy lifting so …

Should “serverless” just mean “function-as-a-service”? Read More »

Fine-grained access control in API Gateway with Cognito access token and scopes

In this post, we look at how you can implement fine-grained access control using Cognito access tokens and scopes. We will discuss the trade-offs of this approach and the cost implications of enabling Cognito’s Advanced Security Features (required for this approach to work).

Personally, I think this is too costly an approach and doesn’t offer enough upside in return.

Unless you’re using Advanced Security Features already, or your application has a high value per user (e.g. a B2B enterprise application), this approach may be difficult to justify in terms of return on investment.

Is it safe to use ID tokens with Cognito authorizers?

A common narrative is that one should always use access tokens to call your APIs, while ID tokens are strictly for identifying users.

But how much of that actually makes sense when you use Cognito authorizers with your API?

Are ID tokens inherently less secure?

What is the cost of using access tokens instead?

Ultimately, is it safe to use ID tokens, or should you switch to access tokens?

Fine-grained access control in API Gateway with Cognito groups & Lambda authorizer

Authentication and authorization are two distinct things.
API Gateway has built-in integration with Cognito, which handles authentication, but no fine-grained authorization.

There are many ways to implement a fine-grained authorization with API Gateway. In this new post, I will show you one of these ways and give you the pros & cons and when to use it.

This is a cost-efficient approach that leverages Cognito, but without needing its more expensive Advanced Security Features.

Do you know your Fan-Out/Fan-In from Map-Reduce?

Many students and clients have asked me how to implement Map-Reduce workloads serverlessly. In most cases, they are actually asking about Fan-Out/Fan-In!

At a glance, the two patterns look very similar and they are often used interchangeably in conversations. So in this post, let’s compare them and see how they differ.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close