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?
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.
Back in 2018, I shared several ways to implement fan-out/fan-in with Lambda. A lot has changed since, so let’s explore the solution space in 2024.
Remember, what’s “best” depends on your context. I will do my best to outline the trade-offs you should consider.
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.
If you’re using CDK, you should use L3 constructs to encapsulate common patterns and best practices in your architecture.
However, sometimes you’d find a 3rd-party L3 construct that does most of what you want, but you need to customize how it configures some of its resources. That can be tricky because you don’t own the source code, and the construct author might not be willing to make the changes you want.
In this article, let me show you an easy and effective way to do this without having to clone and maintain a copy of the construct yourself.
Here is the biggest mistake many teams make when they try to adopt serverless and why they ultimately fail.
Don’t make the same mistake.
AppSync now supports invoking Lambda resolvers asynchronously. This simplifies a common challenge in GenAI applications where we had to hand off the call to the LLM to a background function so we can stream the LLM response back to the caller.
Step Functions lets you set a timeout on both Task states and the whole execution. By default, an execution can run for a year if TimeoutSeconds is not configured. To a user, the execution would appear as “stuck”. Which is why AWS best practices recommend using timeouts to avoid such scenarios. But once you have configured a timeout for the execution, it’s then important to consider what happens when you experience a timeout.
In this post, let’s explore 3 ways you can handle an execution timeout and use a Lambda function to perform automated remediation (e.g. applying rollbacks).
DynamoDB now supports resource-based policies, which simplified cross-account access to tables.
But just because you can, doesn’t mean you should!
Cross-account access to DynamoDB tables is almost always a smell. But as with everything, there are exceptions and edge cases. You should think carefully before you use resource-based policies to enable cross-account access to your DynamoDB tables.
In this post, let’s explore some legitimate use cases for cross-account access to DynamoDB tables.
I’m a big fan of Step Functions, but it’s yet another AWS service you must learn and pay for.
It also introduces additional complexities. My application is harder to test; my business logic is split between configuration (ASL) and code; and I have new decision points, such as whether to use Express Workflows or Standard Workflows.
So it’s fair to ask, “Why should we even bother with Step Functions?”. Why not just do everything in code, inside a Lambda function?
Let’s break down the pros and cons and look at the trade-offs of each.
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.