There’s usually a Wait -> Poll -> Choice loop that runs until the task is complete (or failed), like the one below.

Polling is inefficient and can add unnecessary cost as standard workflows are charged based on the number of state transitions.

There is an event-driven alternative to this approach.

Here’s the high level approach:

1. To start the data migration, the state machine calls a Lambda function with a task token (required for callback). This pauses the state machine execution.
2. The Lambda function calls the Database Migration service to start the data migration.
3. The function saves the data migration ARN (hash key) and the callback token in DynamoDB, along with other relevant information (created date, etc.)
4. The Database Migration service publishes “StateChange” events to the default EventBridge event bus (see docs here). A Lambda function subscribes to this event and waits for a replication task to finish or fail.
5. When triggered, the function extracts the data migration ARN from the event payload and retrieves the Step Functions task token from DynamoDB.
6. It can use the task token to send a success or failure signal back to the state machine execution. From here, the state machine can proceed with the rest of its steps.

This is a more efficient but also more complex approach. There are more moving parts involved, but it’s simple to implement.

But what if you’re calling a 3rd party API that do not support events?

You can adapt this approach to work with any service that accept a callback URL. When the 3rd party service makes the callback, your API handler will look up the task token and make the callback to Step Functions. Everything else stays the same as before.

What’s more, both the polling and event-driven approach can be implemented with the new Lambda Durable Functions too!

The waitForCondition operation is perfect for implementing the polling loop in just a few lines, like this:

const job = await startDataMigrationJob();

const result = await context.waitForCondition(
  async (job, ctx) => {
    const status = await checkJobStatus(job.arn);
    return { ...job, status };
  },
  {
    initialState: { job, status: null },
    waitStrategy: (state) => 
      state.status === 'Stopped' || state.status === 'Failed' 
        ? { shouldContinue: false }
        : { shouldContinue: true, delay: { seconds: 30 } }
  }
);

Similarly, the waitForCallback operation makes implementing the event-driven approach trivial. Instead of a task token, we have to store a callback ID. As before, the callback can be triggered by an event or by a 3rd party service via a callback URL.

const job = await startDataMigrationJob();

const result = await context.waitForCallback(
  "wait for data migration to finish",
  async (callbackId, ctx) => {
    // save the callback ID against job ARN
    await saveJobDetails(job.arn, callbackId)

    // when the StateChange event is fired
    // another function will fetch the callback ID
    // and send a success/failure signal to the
    // durable execution
  }
);

Polling is the default because it’s easy, not because it’s good.

If you can get an event (or a callback), you can stop spinning your state machine and start treating “waiting” as a first-class step. Less noise, fewer transitions, lower cost.

Thank you to Patrick for bringing this up in our last Q&A session. If you want to level up your AWS game, check out my Production-Ready Serverless workshop. The next cohort starts on April 13th, and the early bird tickets (30% off) is available until March 16th.

Related Posts

The biggest re:Invent 2025 serverless announcements

What's the best way to do fan-out/fan-in serverlessly in 2024?

The post The anti-polling pattern for Step Functions appeared first on theburningmonk.com.

Lambda Managed Instances

Here’s the official announcement.

A common pushback against Lambda is that “it’s expensive at scale” because:

1) Each execution environment can only process one request at a time, wasting available CPU cycles while you wait for IO response.

2) Paying for execution time is less efficient when handling thousands of requests per second, especially given the above.

Lambda Managed Instances address these concerns.

You keep the same programming model with Lambda and the same event triggers.

But instead of your function running in a shared pool of bare metal EC2 instances, you can now instruct AWS to use EC2 instances from your account instead. Importantly, AWS still manages these EC2 instances for you, including OS patching, load balancing and auto-scaling.

It gives you more control and flexibility, e.g. what instance types to use (but no GPU instances) and the memory-to-CPU ratio.

See this post for my more in-depth coverage of this new feature.

Lambda Durable Functions

Here’s the official announcement.

This is my favourite announce from re:Invent 2025 :-)

Lambda Durable Functions use a replay mechanism similar to how reState works and how I implemented durable execution on Lambda for a client project.

The basic idea is simple – you can add checkpoints along the execution and the Lambda service will re-invoke your function from the start and skip over previously executed checkpoints when:

• The initial invocation timed out.
• You called context.wait to pause the current invocation.
• You used context.invoke to invoke another function and wait for its response (which suspends the current invocation).
• You created a callback and awaiting its response.

Here’s a handy visualization from the official documentation.

(source: https://docs.aws.amazon.com/lambda/latest/dg/durable-functions.html)

In addition to the usual Lambda function timeout (max 15 mins), Durable Functions also have a “execution timeout” for the total duration of a durable execution which can span over multiple invocations. The max execution timeout is 1 year.

Durable functions can be invoked both synchronously and asynchronously.

However, for synchronous invocations, the max execution timeout is limited to 15 mins. Whereas asynchronous invocations can have execution timeout of up to 1 year.

Durable functions also work with all event source mappings. But ESM-triggered invocations are also limited to a max execution duration of 15 mins.

Additionally, Durable Functions support DLQs, but they DO NOT support Lambda destinations.

Similar to Step Functions, Durable Functions also supports exactly-once processing, if you provide an “DurableExecutionName” when invoking a durable function.

Durable Functions blur the line between Lambda and Step Functions. I’m still organizing my thoughts on how to choose between them, but off the top of my head, these are areas where I think Step Functions wins over Lambda Durable Functions:

• Visualization: being able to design and visualize the workflow as well as its executions. This is especially useful when working with non-technical stakeholders.
• Parallel processing: the context.parallel function of the Durable execution SDK does not actually guarantee parallel processing. In Node.js, it’s essentially a wrapper around promise.all, which gives you concurrency, not parallelism. So if you need to process large amounts of data in parallel, e.g. as part of a map-reduce task, then you want Step Function’s Parallel state.

The replay mechanic also has some interesting failure modes and gotchas. More on that in another post! Or, you can learn all about them in my next Production-Ready Serverless workshop ;-)

S3 Vectors goes GA with better scale and performance

Here’s the official announcement.

S3 Tables support intelligent-tiering and replication

Here’s the official announcement.

CloudFront supports mutual TLS authentication

Here’s the official announcement.

And a lot of AI-related announcements, such as Nova 2 models.

Related Posts

The biggest pre:invent serverless announcements you may have missed

What you need to know about Lambda Managed Instances

The post The biggest re:Invent 2025 serverless announcements appeared first on theburningmonk.com.

• Lambda Managed Instances
• Lambda Durable Functions

I will be updating the Production-Ready Serverless workshop to cover these new features in the January cohort.

In this post, let’s take a closer look at Lambda Managed Instances, why you should care and when to use it.

Introducing Lambda Managed Instances

A common pushback against Lambda is that “it’s expensive at scale” because:

1) Each execution environment can only process one request at a time, wasting available CPU cycles while you wait for IO response.

2) Paying for execution time is less efficient when handling thousands of requests per second, especially given the above.

Lambda Managed Instances address these concerns.

You keep the same programming model with Lambda and the same event triggers.

But instead of your function running in a shared pool of bare metal EC2 instances, you can now instruct AWS to use EC2 instances from your account instead.

Importantly, AWS still manages these EC2 instances for you, including OS patching, load balancing and auto-scaling.

With managed instances, you have more control over HOW the Lambda service should manage these EC2 instances.

For example, what CPU architecture and instance types to use.

You can choose specific instance types that works best for your workload, and use EC2 saving plans on these instances.

Note: GPU instances are NOT supported.

Similarly, you can let Lambda choose the scaling threshold or provide a target CPU utilization level you wish to maintain.

When creating a function using managed instances, you can also set the memory size and the memory-to-CPU ratio.

This lets you tailor the execution environment based on your workload. For example, for basic CRUD APIs, a 2-to-1 ratio is fine. But for memory intensive workloads you might choose a higher memory-to-cpu ratio.

Important considerations

Execution environments can handle multiple concurrent requests

This allows better utilization of the available CPU cycles. This is important for keeping cost in check when running at scale.

But it also means your code need to be thread-safe. For example, you need to be more careful when using and modifying global variables, because another concurrent request might have also modified them.

Paying for uptime instead of execution time

You no longer pay for execution time, but instead, you pay for a combination of:

• No. of Lambda requests – $0.20 per million.
• The EC2 cost.
• 15% premium on the EC2 cost.

As mentioned before, you can use existing EC2 saving plans on the managed EC2 instances.

No cold starts but slower scaling

Because execution environments are reused and can handle multiple concurrent requests, there are no more cold starts.

However, when exceeding the capacity of the EC2 fleet, requests are throttled until the system is able to scale up the fleet.

Regular Lambda functions can scale rapidly by tapping into a large, shared pool of EC2 instances. With managed instances, it takes tens of seconds to launch new EC2 instances. As such, it’s not a good fit when you have large, unpredictable spikes in traffic.

When to use it

Considering the above, here are the reasons I’d consider using managed instances:

• Cost-efficiency at scale, when you have a consistent high throughput.
• Predictable performance. Managed instances is more effective at eliminating cold starts than Provisioned Concurrency.
• More control over execution environment. More choices of instance types, memory-to-CPU ratio, etc.

However, for most of us, who aren’t handling thousands, or even hundreds of requests per second consistently, it’s better to stay with the default compute mode for Lambda.

Also, if you have a very bursty traffic and you can deal with a bit of cold starts, then you’re also better off staying with regular functions.

Regardless, I’m glad that there’s another option we can upgrade to, should the needs arise. And after all the relentless focus on AI, it’s good to see AWS going back to and innovating on its core services.

Related Posts

The biggest pre:invent serverless announcements you may have missed

The biggest re:Invent 2025 serverless announcements

The post What you need to know about Lambda Managed Instances appeared first on theburningmonk.com.

Here is a list of the serverless-related announcements so far that you should know about.

API Gateway integration with ALB (without NLB)

Here’s the official announcement.

This is one of those things that everyone assumed just works, but never did. Until now, if you want to connect API Gateway to an ALB, you have to first go through an NLB.

With the introduction of VPC Link v2, you can now skip the NLB and connect API Gateway directly with ALB.

Fewer moving parts, less things that can break, less cost and a big win all around. It’s how it should work all along, and I’m glad we’re finally here!

API Gateway supports response streaming

Here’s the official announcement.

API Gateway now supports response streaming and works with Lambda’s response streaming capability.

Before this, if you wanted to do response streaming with Lambda, you had to use Function URLs and build Lambdaliths.

There are a couple of things worth noting:

1. Response streaming is only enabled for REST APIs, not HTTP APIs. It appears that the API Gateway team has abandoned the dream of HTTP APIs.

2. You can stream responses for up to 15 mins, which aligns with Lambda’s 15 mins timeout. You can exceed API Gateway’s 29s integration timeout without requesting a limit raise (which comes with reduced scalability).

2.1 But there is also an idle timeout of 5 mins for regional & private endpoints, and 30s for edge-optimised endpoints.

3. For each streamed response, the first 10mb has no bandwidth restriction. After that, the response is restricted to 2MB/s.

See the developer guide here for more details.

DynamoDB supports multi-attribute composite keys

Here’s the official announcement.

For me, this is the biggest pre:Invent announcement so far.

Multi-attribute GSI for DynamoDB is a huge win! No more building your own composite keys for GSIs and having to backfill every time you need a new composite key.

Now you just include the separate attributes in the key schema and add them to your queries, and voila!

Read the developer guide here for more details.

ALB adds built-in JWT verification

Here’s the official announcement.

Step Functions adds mocking support to its TestState API

Here’s the official announcement.

Step Function’s TestState API now supports mocking so you can test ASL in isolation.

The TestState API was useful at launch but it didn’t fit neatly into a typical development workflow where we tend to:
1. design and work on the state machine, ie. the ASL.
2. fill in the implementation of the required Lambda functions.

Without mocking, it was not possible to test the ASL in isolation. Which in practice, meant delaying discovery of problems in the state machine design until AFTER you’ve implemented everything.

Now we can test the ASL in isolation and make sure the various settings, including data transformations, are correct, before spending time on the Lambda functions (and then test them separately).

As I said previously, the TestState API is not a replacement for end-to-end tests where you exercise the state machine and execute it from beginning to end. But it’s a great way to test the individual parts in more detail, especially for execution paths that are difficult to reach on an end-to-end test (eg. error/timeout paths).

See the developer guide here on how to use the new mocking capability.

S3 supports Attribute-Based Access Control (ABAC)

Here’s the official announcement.

Lambda doesn’t need NAT Gateway anymore!

Here’s the official announcement.

With IPv6 support, Lambda functions inside a VPC no longer needs a NAT Gateway to access the internet (or other AWS services).

Instead, you can use the egress-only internet gateway, which only charges the standard EC2 data transfer cost and has no uptime cost.

It’s egress-only and does not allow attackers to reach your infrastructure from the internet.

This is another huge win and a great quality of life improvement.

Lambda supports native tenant isolation

Here’s the official announcement.

Lambda now accepts a “TenantId” attribute in the Invoke request.

By providing a tenant ID in the invocation, you ensure that each tenant’s requests are processed by a separate execution environment.

This is useful when you have strict isolation requirements. However, it’s only part of the solution. You still need to ensure data access patterns do not break tenant boundary, e.g. a tenant cannot access another tenant’s data.

I have written about multi-tenant design multiple times on this blog.

• How to secure multi-tenant applications with AppSync and Cognito
• Group-based auth with AppSync Lambda authoriser
• How to model hierarchical access with AppSync
• Fine-grained access control in API Gateway with Cognito groups & Lambda authorizer

This new capability compliments the approach I outlined in these posts.

However, it’s worth noting that it will significantly impact your concurrency needs.

You’d need higher account level concurrency limit to handle the same amount of request previously because you cannot reuse execution environments across multiple tenants.

This will also impact your ability to scale quickly during a large spike.

A Lambda function can scale from 0 to 1000 concurrent executions instantly. Thereafter, it can add a further 1000 concurrent executions every 10 seconds.

If the execution environments are tenant specific, then, during a large scaling event, you will need many more concurrent executions to serve the same amount of requests.

It’s an interesting launch, but most of you don’t need to use it.

Lastly, Anton Aleksandrov has an example in CDK on how to integrate API Gateway with Lambda to pass the tenant ID (resolved by a Lambda authorizer) in the proxy request to Lambda.

You should never accept tenant ID from the caller!

Lambda adds provisioned mode for SQS ESM

Here’s the official announcement.

If you have a very spiky load and need to process millions of SQS messages quickly, you can now have up to 20,000 ESM event pollers & auto-scale the no. of pollers at 1,000 per minute.

This new provisioned mode is useful for some specific use cases. For example, if you have a very spiky traffic and strict processing time requirement.

It comes at a price of ~$6.66 per poller per month (min 2 pollers).

For most of us, the free ESM SQS pollers is more than sufficient and there’s no need to pay extra.

But this new capability is great for addressing edge cases.

Lambda ups max payload size for async invocations to 1MB

Here’s the official announcement.

But don’t get too excited just yet!

This is only useful when you trigger an async invocation via the Lambda Invoke API (by setting InvocationType to Event). Because the max message size for both SNS and EventBridge (the most common async event sources for Lambda) is still 256kb.

SQS raised its max payload size to 1MB a while back, but SQS triggers Lambda via ESM and is not impacted by this announcement.

Also, payload size beyond 256kb are charged as 1 additional request for each 64kb chunk. If you send a 1MB payload, then it counts as 13 invocation requests:

• 256kb as 1 request
• (1024 – 256) / 64 = 12 additional requests

Lambda supports Python 3.14

Here’s the official announcement.

Lambda’s Rust support goes GA

Here’s the official announcement.

This one has more hype than substance.

There are no new capabilities, the only thing that changed here is that the lambda_runtime crate was marked as GA.

CloudFront introduces flat rate price plan

Here’s the official announcement.

You can now get CloudFront and a bunch of associated services (WAF, Route53, CloudFront functions, logging, etc.) for a flat monthly fee.

Pay-per-use pricing removes waste, but teams often dislike it because it’s difficult to budget and it can result in sudden spikes, whether it’s from a successful launch or a DOS attack.

This sounds tempting, but there are some nuances you must consider.

• Lambda@Edge functions are not supported on the flat-rate plan, only CloudFront functions are.
• When you go over the usage quota for your tier, you can be throttled.

So the trade-off looks like this:

• Below quota -> you waste money.
• Above quota -> you risk throttling.

This is fine for personal projects or non-critical apps where downtime is not costly and you care more avoiding a nasty billing surprise.

But it’s a bad deal if availability and elasticity matter more to you than certainty around budget, which describes most business critical systems.

Also, the free tier in the flat rate plan gives you only 100GB of free data transfer for CloudFront. Whereas the free tier for the pay-per-use plan gives you 1TB of free data transfer.

So if you only care about CloudFront, and not the related services, then you might be better off sticking with the pay-per-use plan.

What’s most interesting about this launch is that, it’s the closest thing AWS has offered to a direct spending cap. Here are my thoughts on the pros & cons of a spending cap.

Wrap up

There has been over 150 announcements in the last few weeks! These are just the ones I find most interesting and relevant to serverless.

I’m excited for re:Invent this year and hoping to see a couple of big announcements around Lambda and Step Functions. It’s a shame I won’t be there in person this year, but I wish everyone a good time in Vegas next week!

Related Posts

Building a custom IAM system has made me appreciate AWS IAM even more

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

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

Group-based auth with AppSync Lambda authoriser

How to model hierarchical access with AppSync

How to secure multi-tenant applications with AppSync and Cognito

The biggest re:Invent 2025 serverless announcements

What you need to know about Lambda Managed Instances

The post The biggest pre:invent serverless announcements you may have missed appeared first on theburningmonk.com.

In this post, let’s look at three ways to implement unauthenticated GraphQL operations with AppSync and their pros & cons.

API Keys

To use API keys, you need to:

1. Add an API Key in AppSync.
2. Pass the API Key in the x-api-key header.

That’s it! It’s the easiest and most common way to implement unauthenticated GraphQL operations in AppSync.

However, AppSync API keys has a max expiry of 365 days. You can extend this by a further 365 days with the UpdateApiKey API [2]. There is no limit to how many times you can extend an API key’s expiry date.

In practice, it means you need a cron job to keep extending your API key’s expiry. It’s a manageable nuisance.

Finally, there’s no extra charge for using API keys.

Lambda authorizer

With a Lambda authorizer, the caller must provide a non-empty string in the authorization header. Instead of API keys, you can pass along a shared secret in the authorization header.

This gives you more control over the lifecycle of the shared secret (compared to using API keys).

You can also support more than one shared secrets with different levels of access. For example, different shared secrets for different clients, like this:

const SHARED_SECRETS = {
  mobile: "...",
  web: "..."
}

module.exports.handler = async (event) => {
  if (event.authorizationToken === SHARED_SECRETS.mobile) {
    return {
      "isAuthorized": true,
      "deniedFields": [ 
        //... deny web client-only fields
      ]
    }
  } else if (event.authorizationToken === SHARED_SECRETS.web) {
    return {
      "isAuthorized": true,
      "deniedFields": [ 
        //... deny mobile client-only fields
      ]
    }
  } else {
    return {
      "isAuthorized": false
    }
  }
}

This is easy to implement, and you can cache authorization results for up to an hour. Furthermore, you can eliminate invalid authorization headers using the IdentityValidationExpression.

It’s a regex that allows AppSync to reject invalid authorization tokens without needing to invoke your Lambda authorizer. Of course, you won’t pay for these unauthorized requests.

However, even with caching, there will still be additional charges involved for the Lambda authorizer. There is also a performance hit because of Lambda cold starts, especially if caching means the function will not be invoked frequently.

AWS IAM

Lastly, you can use Cognito Identity Pool to issue temporary IAM credentials for unauthenticated clients. The client can then use these temporary IAM credentials to call AppSync.

Cognito Identity Pool is free to use, but the GetCredentialsForIdentity API call has a default throughput limit of 200 reqs/s.

Luckily, this is a soft limit and can be raised through the Service Quotas console or a support ticket.

Conclusions

You can enable unauthenticated GraphQL operations in AppSync through three main approaches.

1. API Keys: east to set up and free to use, but requires periodic key renewal and offers limited control over individual clients.
2. Lambda Authorizer (with shared secrets): offers more fine-grained access control at the expense of extra Lambda costs and potential latency from cold starts.
3. AWS IAM via Cognito Identity Pool: leverages temporary AWS credentials for fine-grained access control. Free to use, (can be) highly scalability, though initial throughput limits and setup complexity may be a hurdle for simple use cases.

Here is a side-by-side comparison of their pros and cons:

Links

[1] Configuring authorization and authentication to secure your GraphQL APIs

[2] UpdateApiKey API

Related Posts

Group-based auth with AppSync Lambda authoriser

How I built a social network in 4 weeks with GraphQL and serverless

How to Securely let Frontend Apps to Directly Access AWS services

How to invalidate Cognito-issued JWT tokens

How to secure multi-tenant applications with AppSync and Cognito

The post AppSync: how to implement unauthenticated operations appeared first on theburningmonk.com.