What's New in AWS: a re:Invent 2025 → Early 2026 Recap

AWS ships new features almost every day, and most of them slide past in the announcement feed before anyone gets to try them. This series is a recurring digest that does the filtering: pick what matters, say plainly why it matters, and actually try whatever is tryable. This first edition catches up on roughly six months, from late-2025 re:Invent to early 2026; later editions will be tighter, one per month. It spans several areas, from serverless to AI, security, cost, and even the services being retired. Every item cites the AWS docs, and every demo is run for real on a real account, then cleaned up.

Serverless

Lambda Durable Functions

Lambda can now run multi-step, long-running workflows inside a single function, for up to a year, while keeping reliable progress across interruptions. The model is called durable execution: the function uses checkpoints to track progress and recovers from failures by replay, re-running from the beginning but skipping work that's already done. In code you use two main primitives: step (runs logic, with retries and checkpointing) and wait (suspends with no compute charge). It's a lightweight alternative to Step Functions for workflows tightly coupled with application code (the docs have a whole section comparing the two).

Let's try it with the AWS CLI. The function is written with the new @aws/durable-execution-sdk-js SDK:

import { withDurableExecution } from "@aws/durable-execution-sdk-js";

export const handler = withDurableExecution(async (event, context) => {
  const message = await context.step("greet", (stepCtx) => {
    stepCtx.logger.info("STEP greet running");
    return "Hello from a durable function!";
  });
  await context.wait({ seconds: 10 });          // pause, no compute charge
  context.logger.info("RESUMED after wait");    // replay-aware: logs once
  return { statusCode: 200, body: message };
});

Activate durable execution with the --durable-config flag when you create the function:

aws lambda create-function --function-name durable-demo --runtime nodejs22.x \
  --role "$ROLE" --handler index.handler --zip-file fileb://function.zip \
  --durable-config '{"ExecutionTimeout": 900, "RetentionPeriodInDays": 1}'

Invoke it, and watch the timing:

$ time aws lambda invoke --function-name 'durable-demo:$LATEST' --payload '{}' response.json
invoke time: 13s
$ cat response.json
{"statusCode":200,"body":"Hello from a durable function!"}

Thirteen seconds, because the function pauses for 10 seconds at the wait before it resumes and returns. During those 10 seconds it consumes no compute. The most interesting evidence is in the logs: even though the function replays from the beginning after resuming, each log line appears exactly once:

$ aws logs tail /aws/lambda/durable-demo --since 5m | grep -oE '"message":"[^"]*"' | sort | uniq -c
   1 "message":"RESUMED after wait"
   1 "message":"STEP greet running"

The SDK knows it's replaying, so it doesn't re-log what's already been done. That's the checkpoint-and-replay mechanism: the code re-runs, but completed steps are served from stored results instead of executing again. Good for order processing, human-in-the-loop approval workflows, or long chains of AI model calls. (📄 whats-new · Durable functions)

Lambda cross-account DynamoDB Streams

A Lambda function in one account can now be triggered by DynamoDB Streams in another account, just by putting a resource policy on the stream. Multi-account architectures used to need a complex data-replication setup to share data across accounts; that layer goes away. Notable for anyone running many accounts under Organizations. (📄 whats-new)

Containers

EKS Capabilities (GA) — managed Argo CD

This is the most notable container change this period. EKS Capabilities are platform components fully managed by AWS, running outside the cluster, to cut operational overhead. Three capabilities at launch: continuous deployment with Argo CD, AWS resource management with ACK (AWS Controllers for Kubernetes), and dynamic resource orchestration with KRO (Kube Resource Orchestrator). AWS handles their auto scaling, patching, and upgrades; you just use them.

Running self-managed Argo CD (install, HA, patching, upgrades) has long been a burden for platform teams. The capability turns it into one command. Let's run it on an EKS cluster built with eksctl. Two things to know first: the Argo CD capability requires AWS Identity Center for authentication (local users are not supported), and it needs an IAM role trusted by the capabilities.eks.amazonaws.com service. With both in place:

aws eks create-capability --cluster-name whatsnew-eks --capability-name my-argocd \
  --type ARGOCD --role-arn "$CAPABILITY_ROLE_ARN" --delete-propagation-policy RETAIN \
  --configuration '{"argoCd":{
    "awsIdc":{"idcInstanceArn":"'$IDC_INSTANCE_ARN'","idcRegion":"ap-southeast-1"},
    "rbacRoleMappings":[{"role":"ADMIN","identities":[{"id":"'$IDC_USER_ID'","type":"SSO_USER"}]}]}}'

The command returns immediately with status CREATING; AWS provisions the Argo infrastructure outside the cluster and installs the CRDs into the cluster. After a few minutes it's ACTIVE:

$ aws eks describe-capability --cluster-name whatsnew-eks --capability-name my-argocd \
    --query 'capability.{Name:capabilityName,Type:type,Status:status}'
{ "Name": "my-argocd", "Type": "ARGOCD", "Status": "ACTIVE" }

Proof that Argo CD was actually installed: its custom resources show up in the cluster without us running any helm install or kubectl apply:

$ kubectl api-resources | grep argoproj.io
applications       app,apps         argoproj.io/v1alpha1   true   Application
applicationsets    appset,appsets   argoproj.io/v1alpha1   true   ApplicationSet
appprojects        appproj          argoproj.io/v1alpha1   true   AppProject

Having Application and ApplicationSet means Argo CD is ready for the GitOps workflow: point it at a Git repo, and Argo CD syncs the cluster state to match what's declared in the repo. The difference from rolling your own is that AWS handles all of Argo CD's install, HA, patching, and upgrades; only one capability of each type is allowed per cluster. (📄 whats-new · Create an Argo CD capability (CLI))

EKS Dashboard

A central dashboard for viewing your entire Kubernetes infrastructure across multiple Regions and accounts in an Organization: Kubernetes version, support status, end-of-life auto-upgrade schedule, managed node group AMI versions, add-on versions. Useful for governance and planning at multi-cluster scale without hopping between Regions. (📄 whats-new)

Data

DynamoDB multi-Region strong consistency (GA)

DynamoDB global tables have long been eventually consistent across Regions: write in Region A, and a read in Region B may briefly see a stale value. The new feature enables multi-Region strong consistency (MRSC): a read in any Region sees the latest value immediately, with zero RPO. The trade-off is a specific architectural constraint: MRSC requires exactly three participants — two replicas and one witness — in supported Regions (currently the US group, not ap-southeast-1).

Here's the test. Create an empty table in us-east-2, then enable MRSC with a replica in us-east-1 and a witness in us-west-2:

aws dynamodb update-table --table-name mrsc-demo --region us-east-2 \
  --replica-updates '[{"Create":{"RegionName":"us-east-1"}}]' \
  --global-table-witness-updates '[{"Create":{"RegionName":"us-west-2"}}]' \
  --multi-region-consistency STRONG

One practical note: this command may return UnrecognizedClientException the first time if you run it right when the table just became active; retry after a few seconds and it works. Once the replica and witness are both ACTIVE:

$ aws dynamodb describe-table --table-name mrsc-demo --region us-east-2 \
    --query 'Table.{MRSC:MultiRegionConsistency,Replicas:Replicas[*].ReplicaStatus,Witness:GlobalTableWitnesses[*].WitnessStatus}'
{ "MRSC": "STRONG", "Replicas": ["ACTIVE"], "Witness": ["ACTIVE"] }

Now the test: write in us-east-2, read strongly consistent, immediately in us-east-1, no waiting:

$ aws dynamodb put-item --table-name mrsc-demo --region us-east-2 \
    --item '{"PK":{"S":"song#hey-jude"},"plays":{"N":"100"}}'        # 07:52:27

$ aws dynamodb get-item --table-name mrsc-demo --region us-east-1 \
    --key '{"PK":{"S":"song#hey-jude"}}' --consistent-read           # 07:52:29
{"PK":{"S":"song#hey-jude"},"plays":{"N":"100"}}

Written at 52:27, read strongly consistent in another Region at 52:29 returning the exact value just written, with no "read a stale value" window. And conditional writes apply consistently across Regions: an update-item from us-east-1 with the condition attribute_exists(PK) bumping plays to 101 succeeds. MRSC fits multi-Region applications that need absolute read-after-write guarantees, in exchange for the three-participant model and the Region restriction. (📄 whats-new)

AI and GenAI

Bedrock adds 18 open-weight models, all on one API

Bedrock's largest expansion to date: 18 new open-weight models from various providers (Google Gemma 3, Mistral Large 3, Qwen3, OpenAI gpt-oss, NVIDIA Nemotron, MiniMax, Moonshot Kimi...). The appeal isn't the count but the single API: every model goes through the unified Converse API, you change the model-id and you're done, no infrastructure changes, no per-model access requests.

A quick test. List a few new models, then call two from different providers with the exact same command:

$ aws bedrock list-foundation-models --region us-east-1 \
    --query "modelSummaries[?contains(modelId,'qwen')||contains(modelId,'gpt-oss')].modelId"
openai.gpt-oss-20b-1:0   openai.gpt-oss-120b-1:0   qwen.qwen3-32b-v1:0   qwen.qwen3-next-80b-a3b ...

$ aws bedrock-runtime converse --model-id "qwen.qwen3-32b-v1:0" \
    --messages '[{"role":"user","content":[{"text":"Reply in 5 words: why use serverless?"}]}]'
"Cost, scalability, simplicity, speed, no server management."

One thing to know with reasoning models: gpt-oss returns two content blocks, reasoningContent and then text, so you have to read the right block:

$ aws bedrock-runtime converse --model-id "openai.gpt-oss-20b-1:0" --messages '[...]' \
    --query 'output.message.content'
[ {"reasoningContent": ...}, {"text": "A Lambda cold start is the latency that occurs when AWS Lambda must spin up a fresh execution environment..."} ]

Cost is measurable via usage in the response (the call above: 13 input + 10 output = 23 tokens), so it's easy to keep under control. (📄 whats-new)

Bedrock AgentCore (GA) and friends

In the same AI-agent vein, AgentCore has gone GA: a platform to build, deploy, and operate agents at scale, with runtimes up to eight hours, session isolation, Agent-to-Agent protocol support, AgentCore Gateway turning APIs and Lambda functions into agent tools, AgentCore Identity, and observability through CloudWatch. Early 2026 added a managed harness and the AgentCore CLI for building agents faster, along with Bedrock bringing in OpenAI models and Codex (limited preview). This is the area AWS is pushing hardest; a dedicated agent demo deserves more than cramming it into a digest. (📄 AgentCore GA · new features · OpenAI models + Codex)

S3 Vectors (GA)

A new kind of S3 bucket that stores vectors natively, for RAG and semantic search at billion-vector scale, up to 90% cheaper than a dedicated vector database. Up to two billion vectors per index, queries return in under a second (around 100ms when queried frequently), and it integrates with Bedrock Knowledge Bases.

Try it with the new s3vectors CLI namespace:

aws s3vectors create-vector-bucket --vector-bucket-name "$B"
aws s3vectors create-index --vector-bucket-name "$B" --index-name demo \
  --data-type float32 --dimension 4 --distance-metric cosine
aws s3vectors put-vectors --vector-bucket-name "$B" --index-name demo --vectors '[
  {"key":"apple","data":{"float32":[1.0,0.1,0.0,0.0]}},
  {"key":"banana","data":{"float32":[0.9,0.2,0.1,0.0]}},
  {"key":"car","data":{"float32":[0.0,0.0,1.0,0.9]}}]'

Query a vector near the "fruit" group and take the two nearest results:

$ aws s3vectors query-vectors --vector-bucket-name "$B" --index-name demo \
    --query-vector '{"float32":[1.0,0.15,0.0,0.0]}' --top-k 2 --return-distance
{"vectors":[
  {"key":"apple","distance":0.001136},
  {"key":"banana","distance":0.007856}],
 "distanceMetric":"cosine"}

The two nearest vectors are apple and banana; car is excluded because it's far. Storing vectors while paying only S3-style prices, without running a vector database cluster, is a cost option to weigh for RAG. (📄 whats-new)

Nova Act (GA)

A new service for building agents that automate web UI workflows: filling forms, search and extract, shopping and booking, QA testing, with high reliability for enterprise use. It uses a Nova 2 Lite model, you define workflows with natural language plus Python, prototype on the playground, then deploy to AWS. Currently only in the US East (N. Virginia) Region, so you'll need that Region to try it. (📄 whats-new)

Security and operations

Security Hub (GA) — near real-time risk analytics

Security Hub has been reworked with near real-time risk analytics: it correlates and enriches signals from GuardDuty, Inspector, and CSPM into actionable insights, with exposure findings, a security-focused resource inventory, attack path visualization, and automated response workflows. It can be enabled for a single account or a whole Organization.

Enable and confirm it quickly via the CLI:

$ aws securityhub enable-security-hub
$ aws securityhub describe-hub \
    --query '{HubArn:HubArn,SubscribedAt:SubscribedAt,AutoEnableControls:AutoEnableControls}'
{ "HubArn": "arn:aws:securityhub:...:hub/default", "SubscribedAt": "2026-...", "AutoEnableControls": true }
$ aws securityhub disable-security-hub      # turn off right away to avoid charges when just trying

The CLI demo's limit needs stating plainly: the real value of the new Security Hub is in the console (the risk-analytics view, attack paths) and in having GuardDuty/Inspector feeding it data; the CLI only confirms it's enabled. The visual part is best seen in the console. (📄 whats-new)

CloudWatch Investigations (GA)

An AI agent in CloudWatch that finds anomalies, gathers related signals, proposes root-cause hypotheses and remediation steps, kicks off from an alarm or Amazon Q, integrates with Slack/Teams, and costs nothing extra. (Note: GA since mid-2025, a bit older than the six-month window, but still relevant for anyone doing ops.) (📄 whats-new)

Compute and cost

Graviton5 (Preview)

AWS's fifth-generation Graviton CPU, currently in preview via the EC2 M9g instances: clearly faster than M8g (AWS quotes up to ~25% compute, ~30% database, ~35% web/ML), with higher network and EBS bandwidth. Still preview, so not for production, but a signal of where AWS is heading on price-performance. (📄 whats-new)

Savings Plans and RI Group Sharing (GA)

Lets you share Savings Plans and Reserved Instances savings with a specific group of accounts in an Organization, instead of pooling them org-wide. Useful when you want the savings to land with the group that owns the cost. (📄 whats-new)

Lifecycle — what's winding down, plan ahead

A digest isn't only about what's new; what's going away matters just as much. AWS announced a batch of services moving into maintenance (no new customers from Nov 7, 2025) or sunset. A few to flag: Amazon CodeCatalyst, CodeGuru Reviewer, S3 Object Lambda, Amazon Glacier (the standalone service, distinct from the storage class), and Migration Hub into maintenance; AWS Proton and IoT Greengrass v1 into sunset (current customers should plan to migrate within 12 months). If your architecture leans on any of these, now's the time to look at alternatives. (📄 whats-new)

Every demo in this article was run for real on a real account, then deleted, leaving no billable resources behind. From the next edition, the digest tightens to monthly: the new things that month, with one or two of the standouts tried for real.