Serverless & AI in brief for week 45 covers November 2 to 8, 2026, and this time there was no big stage and no keynote. Still, several updates will affect your work in the coming weeks. One of them even this afternoon: starting at 16:00 UTC, GitHub tests what happens when pull_request_target is blocked by default.
At AWS, the week was mostly about data and configuration. Lambda now reads Kafka like a queue, DynamoDB loads large datasets from S3 into existing tables, and Parameter Store validates values on write. On the AI side, agents get a ready-made web search with citations, and the Claude API keeps long conversations on the server. For each item you get my take and a link to the original source, and for most of them there is also a detailed step-by-step article.
What you will learn in this article
Three AWS announcements this week touch things that show up in almost every serverless application: processing messages, data and reading configuration. None of them is spectacular, but each one replaces a piece of custom code.
Since November 2, Lambda supports a queue mode for self-managed Kafka clusters, including offerings such as Confluent Cloud. Until now, the event source mapping, the connection Lambda uses to pull messages from a source, followed the classic consumer group rule: each partition belongs to exactly one consumer. More parallelism meant more partitions. The new mode builds on the share groups from Apache Kafka 4.2. Several pollers then read from the same partition at once, each with up to ten concurrent invocations. You turn it on with ConsumptionMode set to Queue. Producers, topics and function code stay as they are. The catch: ordering within a partition is no longer guaranteed.
For me, this closes a gap that many teams have patched with extra partitions or a detour through SQS. Before you switch, though, answer one question honestly: does any consumer quietly rely on ordering? If so, that topic stays in the old mode. Your handler also has to be idempotent, because a message can be delivered again after an error. A complete example with a CDK stack and tests is in Kafka share groups with Lambda.
On November 5, bulk put items for DynamoDB became generally available. Until now, import from S3 could only create a new table. Now DynamoDB writes data from S3 into a table that is already in production. These writes use a separate path and consume none of the table’s read or write capacity, so your application doesn’t notice. You can pass a condition per record, for example attribute_not_exists(pk) for “insert only” or a comparison against a version attribute. Without a condition, an existing item with the same key gets overwritten. Anything that wasn’t written ends up in a report in S3, together with the reason. There is a standard tier and a faster accelerated tier, the latter only in selected Regions.
This is the announcement I wanted for backfills and nightly catalog updates. So far, that meant a custom script, BatchWriteItem, retry logic, throttling and the worry that the import would slow down production. My tip: always set a condition, even if you are sure the data is new. An accidentally overwritten record is hard to find in a large run. What this looks like with version guards and the Serverless Framework is shown in DynamoDB bulk put items.
Also since November 5, Parameter Store in AWS Systems Manager knows 13 data types. Ten of them work with standard and advanced parameters, such as integer, boolean, aws:region, aws:account:id, email or ipv4-address. The three types url, json and jsonc are only available for advanced parameters and are billed at their rates. If a value doesn’t match its type, PutParameter rejects it. This also works with SecureString, and an AllowedPattern adds extra rules. In the console and via DescribeParameters, you can also filter by type.
It sounds minor, but it targets a typical cause of incidents: a typo in the configuration only shows up when the Lambda function starts at three in the morning. I still wouldn’t drop validation in the code, because the type only says that a value is a number, not whether 5000 makes sense as a timeout. Together, both form a good safety net. I explain the new types with the CLI and AWS CDK in Parameter Store data types, and validation at cold start in Validate environment variables with Zod.
This week’s AI news answered two practical questions when building agents: where does the agent get current knowledge from, and how does a long agent loop stay fast?
On November 5, AWS made Web Answer for Amazon Bedrock AgentCore generally available. The agent asks a question in natural language and gets back a finished answer with citations in a single call. To do this, Web Answer plans several searches, runs them in parallel and decides when the evidence is sufficient. It extends Web Search, launched in June, which only returns results. You attach Web Answer as a target on an AgentCore Gateway, call it over MCP and secure it with IAM. Allowed domains, deny lists and date filters narrow down the search. Billing is per call, and for now it is only available in US East (N. Virginia).
Building your own pipeline of search, retrieval, summarization and citations is a lot of work and hard to get right. That is why I find this offering attractive. For teams in the EU, however, the Region is a real item for the data protection review before this goes into a product. And citations are no free pass: an agent that names sources seems more credible than it might be. Spot checks on whether the source actually supports the statement belong in the process. How to set up Web Answer with the Serverless Framework and evaluate the citations is covered in AgentCore Web Answer.
On November 2, Anthropic released message threads for the Messages API as a beta. Instead of resending the full history at every step of an agent loop, the API keeps the conversation on the server, and you only send the new messages. Requests get smaller and time to first token goes down. You enable it with the beta header message-threads-2026-08-12. A thread expires five minutes after the last request and is deleted no later than one hour after its last use. On November 5, IP allowlisting for organizations in the Claude Console followed, also as a beta: requests from addresses outside the list are refused. That makes a leaked API key largely useless outside your networks.
With message threads, I would take the five-minute limit seriously. If an agent waits for human approval, the thread is gone afterwards, and you need a way to rebuild the history. So keep storing the history yourself. IP allowlisting is, in my view, the underrated announcement of the week. For backend services with fixed egress IPs, it is quick to set up and closes a real gap. An agent loop with replay and tests in TypeScript is in Claude message threads: agent loops in TypeScript.
On November 2, GitHub adjusted the timeline: from December 2, GitHub Actions blocks workflows triggered by pull_request_target by default, unless a policy explicitly allows them. Before that, there are two brownouts, today on November 9 and on November 16, each from 16:00 to 18:00 UTC. During these windows, affected runs fail. The change applies to public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories and GitHub Enterprise Server are not affected. The reason: pull_request_target runs in the context of the base repository with access to secrets, and code from a fork can steal them. Insights show you in advance which runs the rule would block.
If you maintain open source projects, take a look at Insights before 16:00 UTC today, or the brownout will explain it to you. I would only allow workflows that don’t check out and run code from the pull request. Everything else I would rather rebuild than allow by policy. How to find affected workflows and rebuild them safely is described in pull_request_target blocked. On November 3, the Node.js project announced security releases for the 26.x, 24.x and 22.x lines. They are due on Wednesday, November 11, or shortly after. The highest severity is “High” in all three lines, and the project only publishes details on the individual issues with the releases. As always, versions without support are affected as well.
For Lambda functions with a managed runtime, AWS applies patches itself in the “Auto” update mode. Container images, your own build images in CI and developer machines are a different story. My suggestion: block half an hour on Wednesday or Thursday to rebuild base images and check the Node versions in your pipeline. If a team is still on Node.js 20 or older, this is a good reason for the upgrade plan from Node.js 26 LTS: plan your Lambda upgrade. A few smaller updates that don’t need their own section but are good to know:
What stands out is how many of this week’s announcements make custom code unnecessary. Kafka scaling, bulk data , configuration validation and web search with citations are things many teams have built and maintained themselves. At the same time, the questions shift: away from “How do we build this?” towards “Which assumption breaks when we switch?”. Ordering, overwrites, expiry times and Regions are exactly those assumptions.
If you only have one hour for this week, here is how I would spend it:
pull_request_target.
The next review appears on Monday, November 16, and covers week 46. The issue for week 44 and all others are on the page Series: Serverless & AI in brief. If you are missing an important update, feel free to add it in the comments.
Now it’s your turn: which of these updates will replace a piece of custom code for you first, and which piece of custom code would you rather keep?
This post was created with AI assistance.
👉 Next step: Working with AWS CDK? Grab my printable AWS CDK cheat sheet with commands, concepts and a stack skeleton.
📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en