AWS re:Invent 2026 Preview: Pre:Invent Launches, Expected Themes and What Platform Teams Should Watch

The most consequential AWS launches of 2026 may already be live, and most platform teams have not noticed. In the first two weeks of November, AWS quietly made a new agent runtime the default, gave every EKS pod the option of its own hardware-isolated virtual machine, shipped a local emulator for its APIs, and put 26 open-weight Bedrock models on a firm retirement date. None of that waited for a keynote. This AWS reinvent 2026 preview is about reading those signals before the Las Vegas noise starts.

It matters now because the conference runs from 30 November to 4 December 2026, and the week after it is when procurement, architecture boards and FinOps teams make commitments that last one to three years. Decisions made on keynote adrenaline are expensive to unwind.

You will leave with a verified list of pre:Invent launches, separated by status, a labelled set of expected themes, a five-question framework for judging any launch, an adopt, pilot or wait table, cost and lock-in arithmetic, and a 90-day plan.

What this covers: event logistics, verified pre:Invent 2026 launches, Amazon Bedrock AgentCore runtime changes, Nitro Sandboxes, Trainium and capacity economics, model lifecycle risk, a launch evaluation framework, a decision table, failure modes and a 90-day plan.

Context and Background

re:Invent is AWS’s annual flagship conference in Las Vegas. AWS’s own partner guide confirms that re:Invent 2026 runs November 30 to December 4, with AWS CEO Matt Garman’s keynote on Tuesday, 1 December, from 8:30 to 10:30 a.m. Pacific, and Dr. Ruba Borno’s partner keynote on Wednesday, 2 December, from 3:00 to 4:00 p.m. Pacific. The same post says the CEO keynote will cover AI infrastructure and inference, data, agent platforms and AWS’s own software agents. The 2 November AWS Weekly Roundup put the session count at more than 2,200.

“Pre:Invent” is the informal name for the weeks before the event, when AWS service teams ship features that are ready but not keynote-worthy. Historically, this window carries a large share of the year’s operational changes: pricing tweaks, region expansions, defaults that flip and APIs that reach general availability (GA). The keynotes then focus on a smaller number of headline services, often in preview.

The business backdrop is unusually loud this year. Amazon’s third-quarter 2026 results, released on 29 October, reported AWS segment sales of $46.0 billion, up 39% year over year, and AWS operating income of $17.8 billion. Amazon said it still expects 2026 cash capital expenditure of about $220 billion, mostly for artificial intelligence. That spend has to be monetised, which shapes what AWS will emphasise on stage: silicon, capacity, agent platforms and anything that turns tokens into durable consumption.

For platform teams, the relevant comparison is not AWS against itself but AWS against what the Kubernetes ecosystem shipped two weeks earlier. Our KubeCon North America 2026 recap covered open-source inference and agent workloads; re:Invent is where the managed equivalents get priced.

My thesis for this preview is specific. The pre:Invent 2026 launches show AWS turning three things into managed primitives: the agent runtime, workload isolation and model lifecycle. The keynotes will add features on top, but the platform decisions that matter in 2027 are already visible in the plumbing that shipped in November. Teams that evaluate the plumbing first will make better choices about the headlines.

The Pre:Invent 2026 Launch Map: What Shipped Before the Keynotes

Direct answer: Between 2 and 13 November 2026, AWS shipped the next-generation Amazon Bedrock AgentCore runtime as the default, a GA AgentCore Web Search API at $7 per 1,000 queries, AWS Nitro Sandboxes for EKS, ECS and EC2 at no additional charge, an AWS Emulator for local testing, and new security, networking and capacity tooling.

Figure 1: The pre:Invent 2026 launch map. Verified November launches stack into five layers, from silicon and capacity at the bottom through isolation and the agent runtime to the model catalogue and the developer loop at the top. Each layer changes a different platform decision.

Read the figure bottom-up. Capacity and silicon sit at the base because every agent and model call ultimately consumes accelerator time. Above that, Nitro Sandboxes change how untrusted code is isolated. The AgentCore runtime and its tools change how agents are hosted. The model layer is where lifecycle and new models land. At the top, AWS Emulator and Security Hub change the developer and audit loop. The layering matters because a change low in the stack constrains every choice above it.

The table below lists only launches I verified on AWS’s What’s New pages or AWS blogs this week. Where AWS did not label a launch GA or preview, I say so rather than guess.

Date (2026)	Launch	Status per AWS	Why platform teams care
2 Nov	Lambda queue mode for self-managed Kafka event sources	Not labelled; all commercial regions with self-managed Kafka ESM	Scale consumers beyond partition count; ordering is lost
3 Nov	Amazon WorkSpaces for AI agents adds Linux and Windows 11 desktops	Not labelled	Agents get full desktops with IAM and network isolation
4 Nov	EC2 Capacity Manager supportability checks and fulfillment metrics	Available in all commercial regions; included with AWS Unified Operations	Score capacity odds before launching or reserving
4 Nov	AWS Interconnect last mile with Equinix	Preview	Managed private links from Equinix sites, 99.99% SLA, MACsec default
5 Nov	Web Answer on Amazon Bedrock AgentCore	GA, US East (N. Virginia) only	Cited answers via a Gateway target over MCP
6 Nov	Security Hub SBOM inventory for compute	Not labelled; no extra cost in Security Hub Essentials	Organisation-wide package inventory from Inspector SBOMs
9 Nov	AWS Nitro Sandboxes on EKS, ECS and EC2	“Now available”; no additional charge; all commercial regions	A hardware-isolated VM per pod, task or lightweight VM
9 Nov	Claude Fable 5.2 on Amazon Bedrock	Available	New Anthropic flagship; covered model with retention rules
9 Nov	Amazon Quick renamed AWS Quick	Rename only	No pricing or data changes
10 Nov	AgentCore Web Search API (InvokeWebSearch)	GA, six regions, $7 per 1,000 queries	Grounding without a third-party search contract
11 Nov	AWS Emulator	“Now available”; no service fee	Local and CI testing against AWS API models
12 Nov	Next-generation AgentCore runtime becomes the default	Default in 19 listed regions	Snapshot starts, memory paging, scale to zero

Two late-October items belong on the map as well. OpenAI’s GPT-6.1 Terra became generally available on Bedrock, per the 2 November Weekly Roundup, and Amazon EKS Auto Mode gained Kubernetes Gateway API support. Both were announced in the last days of October, so I treat them as context rather than pre:Invent proper.

The agent runtime became a compute primitive

The most important line in the table is the quietest. On 12 November AWS made the next-generation AgentCore runtime the default for new runtimes. Sessions restore from a snapshot of an initialised agent, compute and memory scale with the workload, and idle agents scale to zero. Each session still runs in its own hardware-isolated Firecracker microVM, according to the announcement. Sessions scale up to 8 vCPU and 32 GB of memory, and container images can be up to 10 GB.

The headline number is start time. AWS says sessions on a 2 GB image start in under 2 seconds at P75, against 29.7 seconds on the previous generation. The September launch post on the AWS Machine Learning blog explains the mechanism: the platform starts the container once, waits for it to report healthy, captures a snapshot with caches and transient memory stripped, and restores that snapshot for each new session. Because snapshot size stays roughly flat as the image grows, restore latency stays flat too.

Why does this justify calling it a primitive? Because the billing unit changed with it. The previous model effectively charged for memory held by the whole container for the life of a session. The new model pages memory in on demand and reclaims it when released, at a higher per-GB-hour rate. AWS claims up to 68% lower billed memory per session for multi-turn agents. That is the same economic shift Lambda made for functions: pay for the working set, not the reservation. Once agents are billed like functions, they will be designed like functions.

Existing runtimes do not move automatically. AWS says they stay on the current version until you set platformVersion to V2, and new runtimes can pin V1. That is a gift to platform teams: you can run both side by side and measure.

Isolation moved from a design choice to a checkbox

The second structural launch is AWS Nitro Sandboxes, announced 9 November. Each EKS pod, ECS task or lightweight VM can run in its own hardware-isolated VM managed by the Nitro Hypervisor. AWS positions it for untrusted, multi-tenant or regulated workloads, explicitly including AI agents and LLM-generated code. On EKS and ECS it is described as a one-line change, and workloads keep Pod Identity, VPC CNI, EBS, EFS, S3 and CloudWatch support. Cryptographic attestation can gate secret release to sandboxes that prove their integrity. There is no additional charge, and it is available on most Nitro-based instances in all commercial regions.

This matters because isolation for agent code has been a build-it-yourself problem. Teams have chosen between gVisor, Kata Containers, Firecracker fleets and WebAssembly, each with real operational cost, as our comparison of sandboxing approaches for AI agent code execution laid out. A managed, free, per-pod VM boundary changes the default answer for EKS shops. It does not remove the need to think about density, startup time and which instance families are supported; AWS says “most” Nitro instances, so check the list before you plan node pools.

Grounding and the developer loop became AWS-native

Two smaller launches complete the picture. The AgentCore Web Search API reached GA on 10 November. It returns ranked results from Amazon’s own web index with text extracts, supports domain and publication-time filters, authorises with IAM, can be reached privately through AWS PrivateLink and logs to CloudTrail. It costs $7 per 1,000 queries in six regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Sydney), Asia Pacific (Tokyo) and Europe (Ireland). Web Answer, launched on 5 November, sits one level higher: it plans searches and returns a synthesised, cited answer, but only in US East (N. Virginia).

AWS Emulator arrived on 11 November. It intercepts existing SDK and CLI calls, gives each running copy its own port, keys and in-memory state, and returns the same results and errors as AWS for supported operations. Unsupported operations return HTTP 501. Services are generated from AWS’s published API models, with behaviour filled in over time, and AWS publishes a fidelity report. There is no service fee. For platform teams that run integration tests against shared sandbox accounts, this is a direct attack on slow, flaky and costly CI.

Expected Themes for re:Invent 2026: Analysis, Not Announcements

Everything in this section is my expectation, built from the pre:Invent launches, AWS’s own keynote descriptions and the Q3 earnings commentary. None of it is an announcement. Treat each theme as a hypothesis to check against what actually ships between 30 November and 4 December.

Expectation 1: AI infrastructure and Trainium capacity take the CEO keynote

AWS’s partner guide says the CEO keynote will cover “AI infrastructure and inference.” The logical centrepiece is Trainium. AWS announced Trainium3 UltraServers as available at re:Invent 2025, built on a 3 nm process and scaling to 144 Trainium3 chips per UltraServer with up to 362 FP8 petaflops. In the same post AWS said Trainium4 was in design, targeting at least 6x the FP4 performance, 3x the FP8 performance and 4x the memory bandwidth, and that it was being designed to support NVIDIA NVLink Fusion so Trainium, Graviton and Elastic Fabric Adapter (EFA) can share MGX racks with GPU servers.

What to watch for is not a spec sheet but availability terms. Secondary reporting of the Q3 2026 earnings call, which I could not verify against a transcript, says Andy Jassy described Trainium3 supply as fully committed and confirmed plans to sell Trainium hardware for customers’ own data centres from late 2027. If that is accurate, the useful questions for buyers are concrete: which regions get Trn3 capacity in 2027, whether there is an on-demand or Capacity Block path for smaller customers, and what the Neuron software stack supports out of the box. A Trainium4 date or a new UltraServer configuration would be news; a vague “coming” would not.

Expectation 2: Agent platforms move from runtime to governance

AgentCore has been on a steady cadence: the runtime, Gateway, quality evaluations and policy controls at re:Invent 2025, Web Search in mid-2026, Runtime V2 in September and now the November defaults. The partner guide names “agent governance” as a theme. I expect the keynotes to focus on what enterprises ask for once agents run: registries of approved agents and tools, identity and delegated authorisation, spend limits, audit trails and evaluation gates.

This is where platform teams should be most careful, because governance features are sticky. An agent registry or policy language you adopt becomes the system of record for which agents may act on which data. Our guide to AI agent identity and delegated authorization explains why the identity layer should stay standards-based (OAuth token exchange, workload identity) even when the runtime is managed.

Expectation 3: Isolation and sovereignty become selling points

Nitro Sandboxes shipped three weeks before the keynote, which suggests AWS wants it in customers’ hands before it is discussed on stage. I expect the technical-innovations keynote, scheduled for Thursday per third-party schedules, to tie Nitro isolation, attestation and the AWS European Sovereign Cloud story together. AWS’s security blog has already published a “digital sovereignty at re:Invent 2026” session guide, which is a signal of emphasis rather than of any specific launch.

Expectation 4: Cost transparency follows price pressure

Accelerator pricing has moved up, not down, in 2026. A Classmethod analysis of AWS pricing pages reports that EC2 Capacity Blocks for ML prices rose in January, July and again on 7 October 2026, with the October change adding roughly 15% in US regions. I could not confirm those percentages on an AWS page, so treat them as reported. Against that backdrop, the November Capacity Manager launch, which scores the odds of getting capacity before you reserve it, looks like the start of a cost-and-capacity transparency theme. I expect more of it, and I expect FinOps features to be pitched as compensation for tighter supply.

Expectation 5: Models arrive, and older ones leave

Bedrock added Claude Fable 5.2 on 9 November and GPT-6.1 Terra in late October. More model launches at re:Invent are near certain. The underreported part is departures. The Bedrock model lifecycle (legacy) page lists 26 open-weight models, including Llama 3 and 4, Gemma 3, Mistral, Qwen3 Coder, DeepSeek-R1 and V3.1, Kimi K2 Thinking, MiniMax M2 and GLM 4.7, that entered Legacy on 30 September 2026 and reach end of life on 30 March 2027 in the listed regions. Claude Opus 4.1 reaches EOL on 8 January 2027 and Claude Sonnet 4.5 on 8 April 2027 in commercial regions. I expect AWS to announce replacements; I do not expect it to move those dates.

Walk-through: How to Evaluate a re:Invent Launch Before You Adopt It

Direct answer: Judge every re:Invent launch on five questions before it reaches a roadmap: what is its exact status, does it run in your regions, is the price published, what is the exit path, and does it replace something you already operate? A launch that fails two or more of these belongs in “wait,” however good the demo.

Figure 2: A five-gate evaluation flow for AWS announcements 2026. Each launch passes through status, region, price, exit and overlap checks; failures route it to pilot or wait rather than straight to production.

The gates are ordered by how cheaply they can be checked. Status and regions take minutes on the What’s New page. Price takes an hour with the pricing page and a usage estimate. Exit path and overlap take a design review. Running them in that order kills weak candidates before anyone spends design time.

Gate 1: status, read literally

Keynote language blurs three different states: preview, GA and “now available.” The pre:Invent list shows why this matters. Web Search API and Web Answer are explicitly GA. Interconnect last mile is explicitly preview. Nitro Sandboxes, AWS Emulator and Lambda’s Kafka queue mode are “now available” without a label. For production, demand an explicit GA statement and an entry in the service’s documentation and SLA. Preview features can change APIs, lack SLAs and are often excluded from compliance scopes.

Gate 2: regions, checked against your residency map

Regional coverage is where many launches quietly fail. Web Answer is US East (N. Virginia) only. The Web Search API runs in six regions, none in India, the Middle East or most of Europe outside Ireland. Runtime V2 is the default in 19 regions, including Mumbai. If you run in a region that is not listed, calling a service elsewhere moves data across a border, which your data-residency controls may forbid. Check every launch against the list of regions you actually deploy to, not against “available in the US.”

Gate 3: price, turned into a monthly number

A unit price is not a cost. Convert it. Take the Web Search API at $7 per 1,000 queries. An internal research agent that runs three searches per task and handles 20,000 tasks a day issues 60,000 queries daily. That is $420 a day, or about $12,600 over a 30-day month, before model tokens. The numbers are illustrative, but the method is the point: multiply unit price by calls per task by tasks per day, then compare with the alternative you already pay for.

Runtime pricing needs a different calculation because the unit changed. Suppose, illustratively, a multi-turn agent held a 2 GB working set for a 30-minute session on the old runtime: 1.0 GB-hour. If memory paging means its average resident set is 0.6 GB, billed memory falls to 0.3 GB-hours, a 70% cut. If the new per-GB-hour rate is k times the old one, the new session is cheaper whenever k is below 1.0 / 0.3, about 3.3. AWS has not framed the rate change as a multiplier, so measure your own agents on V1 and V2 side by side rather than assuming AWS’s “up to 68%.”

Gate 4: exit path, written down before adoption

Ask what it would take to leave. For the AgentCore runtime, the exit path is reasonable if your agent is a container with a standard HTTP interface: you can host it on EKS, ECS or another cloud. For Web Search, the exit is a different search provider behind the same tool interface, which is easy if you call it through MCP or an AI gateway and hard if the SDK call is scattered across code. Our comparison of LLM gateways such as LiteLLM, Portkey, Kong and Cloudflare shows how a gateway keeps that exit cheap for models; the same pattern applies to tools.

Gate 5: overlap with what you already run

Most platform teams already operate something that a launch replaces. Nitro Sandboxes overlaps with gVisor or Kata node pools. AWS Emulator overlaps with LocalStack or shared test accounts. Lambda’s Kafka queue mode overlaps with consumer fleets on ECS or EKS. Overlap is not a reason to reject a launch, but it means the benefit is the delta, not the whole feature. A free managed sandbox that removes a gVisor node pool you patch monthly is a clear win; one that duplicates a working Firecracker fleet is a migration project.

How the pieces fit at request time

Figure 3: An illustrative agent request across the pre:Invent launches. The client calls an agent hosted on the AgentCore runtime, which restores from a snapshot, calls Web Search through the Gateway, and hands generated code to a Nitro Sandbox pod on EKS before returning a grounded answer.

The sequence is a composition I am proposing, not a reference architecture AWS has published. It shows why the launches belong together. The runtime restores a session in roughly two seconds instead of thirty, which makes per-request agents viable. Grounding stays inside AWS with IAM, PrivateLink and CloudTrail, which simplifies audit. Untrusted code runs behind a hardware boundary that can be gated by attestation. Every hop is billed in a different unit: runtime GB-hours and vCPU-hours, search queries, model tokens and EC2 instance-hours for the sandbox nodes. Cost attribution therefore needs tags and a normalised billing feed, which is what the FOCUS specification for cloud billing data is for.

Decision table: adopt now, pilot or wait

The table applies the five gates to the verified launches. “Adopt now” means safe for new production work this quarter with normal change control. “Pilot” means run it on a real but non-critical workload with a measured comparison. “Wait” means revisit after re:Invent or after GA.

Launch	Status	Regions	Price published	Exit path	Verdict for most platform teams
AgentCore runtime V2	Default for new runtimes	19 regions	Rates on pricing page; committed pricing “coming soon”	Good if agent is a portable container	Pilot: A/B against V1, then adopt for new agents
AgentCore Web Search API	GA	6 regions	Yes, $7 per 1,000	Good behind MCP or a gateway	Adopt where regions fit; otherwise wait
Web Answer	GA	US East only	Per tool call	Moderate	Wait unless you already run in us-east-1
Nitro Sandboxes	Now available	All commercial	No additional charge	Good; standard pods and tasks	Pilot on agent code and multi-tenant jobs
AWS Emulator	Now available	Local	No service fee	Excellent; it is test tooling	Adopt in CI for supported operations
Security Hub SBOM inventory	Not labelled	Where Security Hub runs	Included in Essentials	N/A	Adopt; turn on Inspector where missing
Lambda Kafka queue mode	Not labelled	Commercial	Standard Lambda, plus EPU in provisioned mode	Good	Pilot for order-insensitive consumers only
Interconnect last mile	Preview	Two US metros	Free 1 Gbps in preview	Moderate	Wait for GA and bandwidth above 1 Gbps
Capacity Manager checks	Available	All commercial	Included with Unified Operations	N/A	Adopt if you hold that support plan

Notice how few launches land in a clean “adopt now.” That is normal, and it is the point of the framework. A good re:Invent week for a platform team ends with two adoptions, four pilots and a written list of waits with dates.

Capacity and cost: the Trainium and GPU arithmetic

AI infrastructure decisions after re:Invent tend to be the largest commitments, so it is worth doing the arithmetic now. Capacity Blocks are charged up front, priced by supply and demand at purchase, and are not covered by Savings Plans or Reserved Instance discounts, per the Capacity Blocks pricing and billing documentation. Using the reported October 2026 per-accelerator rate for P5 of $5.970 an hour, an eight-GPU p5.48xlarge costs about $47.76 an hour. A 14-day block of one instance, 336 hours, comes to roughly $16,000. A P6-B200 instance at the reported $14.208 per accelerator is about $113.66 an hour, or roughly $38,200 for the same 14 days. These are reported rates used for illustration; quote the console before you budget.

Two levers change this arithmetic. The first is utilisation: unused time inside a block costs nothing extra but is already paid for, so a block at 60% utilisation has an effective GPU-hour price 1.67 times the list price. The second is portability between accelerator families. A workload that runs on both NVIDIA GPUs and Trainium through a framework such as PyTorch with the Neuron SDK can buy whichever capacity is available. That optionality is worth real money when supply is tight, but it costs engineering time to validate every model on both. Our deep dive on spot and preemptible instances for interruption-tolerant GPU training covers the checkpointing discipline that makes either option safer.

For Kubernetes users, the capacity story runs through the autoscaler. If re:Invent brings new Trainium or GPU instance types, the first practical question is whether your Karpenter node pools can express them cleanly, which our comparison of Karpenter versus Cluster Autoscaler for GPU nodes addresses. The second is whether EKS still compares well with GKE and AKS on networking and upgrade cadence, which our managed Kubernetes comparison of EKS, GKE and AKS tracks.

Lock-in, quantified as switching cost

Lock-in is easier to manage when you estimate it as engineering weeks rather than as a feeling. For each candidate service, count the integration points that would change if you left: SDK calls, IAM policies, event formats, data stores and operational runbooks. Multiply by a rough effort per point. A team with Web Search called from three agents through a gateway has perhaps three configuration changes to exit. A team that built its approval workflow on a proprietary agent registry has a data migration, a policy rewrite and retraining. Same vendor, very different switching cost, and only the second one should require an architecture board.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: The lock-in gradient for re:Invent-era services. Portable layers such as containers, Kubernetes pods and MCP tool calls sit on the left; sticky layers such as agent registries, policy engines, multi-year capacity commitments and silicon-specific code sit on the right, where exit costs rise sharply.

Mistaking “now available” for GA. Several November launches carry no status label. That may simply be AWS house style, but your auditors will ask. If a feature is not called GA in its documentation and does not appear in the service’s SLA, treat it as pilot-grade, however polished the demo.

Region gaps that leak data. A team in Mumbai that adopts Web Answer must call US East (N. Virginia). The agent works, the demo passes, and the data-residency review fails three months later. Check regions before code, not after.

Silent default changes. New AgentCore runtimes now default to V2. If your infrastructure-as-code creates runtimes without pinning platformVersion, a redeploy of an old stack in a new account will produce a different runtime, with different start behaviour and a different billing curve, than the stack it was copied from. Pin versions explicitly in Terraform or CloudFormation.

Model retirement cliffs. Legacy models are not just “old.” Per the Bedrock lifecycle page, new customers cannot adopt them, existing customers may lose access after 15 days of inactivity, and no new Provisioned Throughput can be created. After a minimum of three months in Legacy, models with EOL dates after 1 February 2026 can enter public extended access at higher, provider-set prices. A rarely used batch job pinned to Llama 3.1 70B can therefore break, or get more expensive, well before 30 March 2027. Version management with evaluation gates, as in our guide to prompt and model version management, is the antidote.

Ordering bugs from queue mode. Lambda’s Kafka queue mode explicitly does not preserve partition ordering and delivers at least once. Turning it on for a consumer that assumed per-key ordering, such as account balance updates, creates correctness bugs that only appear under load.

Sandbox density surprises. A VM per pod is a stronger boundary but not free in resource terms: each sandbox carries its own guest kernel and memory overhead, and support is limited to “most” Nitro instances. Expect fewer pods per node than with runc and benchmark startup latency for your images. The GPU sharing trade-offs between MIG, MPS and time-slicing are a reminder that isolation and density always trade against each other.

Emulator false confidence. AWS Emulator returns 501 for unsupported operations, which is honest. The subtler risk is supported operations whose eventual-consistency, throttling or IAM behaviour differs from production. Keep a thin layer of tests against real accounts and read the fidelity report for the services you depend on.

Committing during the hype window. The worst time to sign a three-year Savings Plan or a long capacity commitment is the week a vendor may change prices or instance families. Unless an expiry forces you, wait until the announcements settle.

Practical Recommendations

Treat re:Invent 2026 as an input to a planning cycle, not as a shopping trip. The highest-value work happens before the keynote, when you inventory what you depend on, and in the three weeks after it, when you decide what to pilot. Write the outcomes down with owners and dates, because “we’ll look at it” is how good launches never get evaluated and bad ones get adopted by default.

My 90-day plan for a typical platform team looks like this.

Days 0 to 30, before and during the event. Inventory every Bedrock model ID in use and map it to the lifecycle tables; anything on the 30 March 2027 list gets a migration ticket now. Pin platformVersion on all AgentCore runtimes in code. List Savings Plan, Reserved Instance and Capacity Block expiries. Prepare your five-gate checklist and a shortlist of the three problems you most want AWS to solve, so you watch keynotes for answers, not features.

Days 31 to 60, the pilot window. Run AgentCore V1 against V2 on one real agent and record P75 start time and billed GB-hours. Put one class of untrusted workload, such as agent-generated code or customer plug-ins, on a Nitro Sandbox node pool and measure density. Move one CI pipeline onto AWS Emulator and track runtime and flakiness against your current test account.

Days 61 to 90, the commitment window. Promote pilots that beat baseline on cost, latency or operational toil. Reprice accelerator commitments using post-re:Invent rates. Publish a short internal note listing adopted, piloted and deferred launches with revisit dates.

A compact checklist:

• [ ] Map every Bedrock model ID to its EOL date and owner.
• [ ] Pin AgentCore platformVersion in infrastructure code.
• [ ] Check region coverage before any proof of concept.
• [ ] Convert each unit price into a monthly estimate.
• [ ] Write an exit path for every service you adopt.
• [ ] Freeze new multi-year commitments until 4 December unless forced.
• [ ] Tag agents, sandboxes and capacity for cost attribution.

Frequently Asked Questions

When and where is AWS re:Invent 2026?

AWS re:Invent 2026 runs from Monday 30 November to Friday 4 December 2026 in Las Vegas, according to AWS’s partner guide published in October. AWS CEO Matt Garman delivers the main keynote on Tuesday, 1 December, from 8:30 to 10:30 a.m. Pacific time, and the partner keynote is on Wednesday, 2 December, from 3:00 to 4:00 p.m. Pacific. Keynotes are livestreamed free for virtual attendees. Teams in Asia should note that most keynotes fall late at night locally, so plan to watch recordings and summarise the next morning.

What did AWS announce in the pre:Invent 2026 window?

Verified November launches include the next-generation Amazon Bedrock AgentCore runtime becoming the default for new runtimes, the GA AgentCore Web Search API at $7 per 1,000 queries, Web Answer on AgentCore in US East (N. Virginia), AWS Nitro Sandboxes for EKS, ECS and EC2 at no additional charge, AWS Emulator for local testing, Security Hub SBOM inventory, Lambda queue mode for Kafka, Linux and Windows 11 desktops for WorkSpaces for AI agents, and a preview of AWS Interconnect last mile with Equinix. Claude Fable 5.2 also arrived on Bedrock.

What is Amazon Bedrock AgentCore and what changed in November 2026?

Amazon Bedrock AgentCore is AWS’s managed platform for hosting and operating AI agents, with a runtime, a gateway for tools, memory, identity, observability and built-in tools such as web search. On 12 November 2026 the next-generation runtime became the default for new runtimes. It restores sessions from snapshots, pages memory on demand and scales idle agents to zero, with AWS citing sub-two-second P75 starts on a 2 GB image versus 29.7 seconds before. Existing runtimes stay on the old version until you opt in with platformVersion V2.

Will AWS announce a new Trainium chip at re:Invent 2026?

Nothing is confirmed. At re:Invent 2025 AWS launched Trainium3 UltraServers with up to 144 chips and said Trainium4 was in design with support for NVIDIA NVLink Fusion. Reporting on the October 2026 earnings call says Trainium3 supply is fully committed and Amazon plans to sell Trainium outside AWS from late 2027, though I could not verify the exact remarks in a transcript. A Trainium4 update is plausible given the CEO keynote’s stated focus on AI infrastructure, but treat any prediction, including mine, as speculation until the keynote.

Which Bedrock models are being retired and when?

According to the Bedrock model lifecycle documentation, 26 open-weight models entered Legacy on 30 September 2026 and reach end of life on 30 March 2027 in their listed regions. They include Llama 3, 3.1, 3.3 and 4 models, Gemma 3, several Mistral models, DeepSeek-R1 and V3.1, Qwen3 Coder, Kimi K2 Thinking, MiniMax M2 and GLM 4.7. Claude Opus 4.1 reaches EOL on 8 January 2027 and Claude Sonnet 4.5 on 8 April 2027 in commercial regions. Inactive accounts can lose access to Legacy models after 15 days.

Should platform teams buy Savings Plans or Capacity Blocks before re:Invent?

Generally, no, unless an existing commitment expires and the alternative is on-demand pricing for a large steady workload. re:Invent is when AWS tends to announce new instance families and pricing changes, so committing a week before can lock you into a generation that is about to be superseded. Capacity Blocks are priced by supply and demand at purchase and are not discounted by Savings Plans, so compare block prices after the event. Use the waiting time to measure real utilisation, which drives effective cost more than list price.

Further Reading

• Managed Kubernetes compared: EKS vs GKE vs AKS in 2026 benchmarks networking, upgrades, autoscaling and cost across the three managed control planes.
• Karpenter vs Cluster Autoscaler for GPU workloads explains how to provision new accelerator instance types quickly and cheaply after launch.
• LLM gateways compared: LiteLLM, Portkey, Kong AI Gateway and Cloudflare AI Gateway shows how routing, fallback and budgets keep model and tool choices portable.
• AWS What’s New is the primary source for launch dates and status; check it during re:Invent week.
• Amazon Bedrock model lifecycle documentation defines the Active, Legacy and EOL states and the notice periods for newer models.

By Riju — about