DEV Community: Matias Martinez

Strands Decider 2B: AWS's open source model that doesn't generate text, it decides

Matias Martinez — Tue, 13 Oct 2026 21:25:40 +0000

A lot of the LLM calls inside an agent aren't about generating text. They're tiny decisions: which team owns this ticket? Did the user actually say that tool argument, or did the model make it up? Is this message urgent? Cheap model or expensive model? For each one, we ship the full context to a frontier model, wait a second or two, and parse free text that comes with no measure of how confident the model is.

Strands Labs, the experimental arm of the Strands Agents team at AWS, released Strands Decider 2B, an Apache 2.0 model built for exactly that gap. It doesn't generate text. It takes a state plus a set of questions and, for each one, picks from closed options and returns a calibrated probability. It runs locally, answers in about 115 ms median on a desktop GPU, and plugs into Strands Agents' intervention system to review tool calls before they execute.

TL;DR

A decision model (the authors call it a "system one" model): picks options, answers yes/no, or scores on a scale, always with a probability. No text generation.
Architecture: the Qwen3.5-2B-Base torso with its LM head removed, a ~1M-parameter pointer head, and rank-16 LoRA adapters. One forward pass, no decoding loop.
First release latency: 115 ms median (299 ms p95) on an RTX 3090; 153 ms on an M3 Pro.
On JevBench (231 public tasks) the current reference model gets 180 right (0.779). Gemma 4 variants reach 207 with the 26B model.
pip install strands-decider, then use it from the CLI or as a local HTTP server (/v1/systemone).
It's an experiment, not a managed AWS service. You run it.

Why now

The "decision model" idea got attention in September when TypeSafe AI came out of stealth with Jev, a proprietary model that returns typed decisions instead of text, available via waitlist at $0.042 per million input tokens. Strands credits Jev for putting the approach on the map and evaluates against JevBench. The difference is distribution: Jev is closed; Strands Decider ships weights, code and the full training recipe.

There's also a design argument. Ask a chat model "are your own tool arguments grounded?" and it can be talked into yes. A classifier that returns a number your if statement branches on doesn't negotiate.

How it works

The decider keeps the transformer torso of Qwen3.5-2B-Base, throws away the vocabulary head, and replaces it with a pointer head. The input has a fixed format: state, question, numbered options, and an <answer> marker. The head scores each option's final hidden state against the hidden state at <answer>, a softmax turns those logits into probabilities, done. No tokens generated.

Two practical consequences: the head has no per-option parameters, so it can't learn "option 1 is usually right" and you can rename options without retraining; and only the LoRA adapters and the head are trained, which is why the repo can publish the recipe (about 11 hours on one RTX 3090, or ~70 minutes on eight H100s).

Three question types are supported: noul (yes/no, returns P(yes)), choice (one of N), and score (a level on an ordered rubric). You can ask many questions about one state in a single request; the state is encoded once.

Model	JevBench (of 231)	Brier (lower is better)
2B hobson-v19 (launch)	167	0.342
2B hobson-v21	176	0.323
2B qwen3.5-v1-2610 (reference)	180	0.280
E4B gemma4-v1-2610	187	0.243
26B-A4B gemma4-v1-2610	207	0.162

The README itself warns that gaps under ~10 tasks between single runs aren't reliable. For v19, Techstrong.ai reports 100% on easy tasks and 50.5% on hard ones: great at routine, mediocre at complex, which is the pitch.

Hands-on

pip install strands-decider

strands-decider ask StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail" \
  --noul "Does this convey urgency?" \
  --score "How frustrated is the writer?=calm,frustrated,depressed"

Sample output from the README (CPU run): billing at 0.773, urgency 0.858, and a frustration score of 1.03 with confidence 0.509. That last number is the model telling you it isn't sure, which is information an LLM doesn't give you.

As a server:

strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --port 8000
curl -s localhost:8000/v1/systemone -H 'content-type: application/json' \
  -d '{"state": "Help! My payouts have been failing for 3 days!",
       "questions": {"is_urgent": {"type": "noul", "instructions": "Does this convey urgency?"}}}'

The server binds to 127.0.0.1 and has no authentication. Don't put it behind a public Service.

Gating tool calls in a Strands agent

This is a trimmed version of examples/strands/ from the repo. The agent has an eager system prompt that makes it guess a city; the decider catches it:

from strands import Agent, tool
from strands.interventions import Guide, InterventionHandler, Proceed

YES = 0.45  # illustrative threshold; tune it on your own traffic

class ToolCallReviewer(InterventionHandler):
    name = "strands-decider-tool-call-reviewer"

    def __init__(self, decider):
        self._decider = decider

    def before_tool_call(self, event, **kwargs):
        state = build_state(event.agent.messages, event.tool_use)  # conversation + proposed call
        answers = self._decider.ask(state, QUESTIONS)  # args_grounded, premature (noul)
        if answers["args_grounded"]["noul"] < YES:
            return Guide(feedback="The arguments look guessed. Ask the user to confirm them.")
        if answers["premature"]["noul"] >= YES:
            return Guide(feedback="Too early to call this tool. Clarify with the user first.")
        return Proceed()

Guide doesn't block the call; it hands the turn back to the model with feedback, and the agent ends up asking "which city?" instead of reporting Seattle's weather. Strands interventions also support Deny and Confirm (human approval).

Running it on Amazon EKS

Because the server only listens on localhost, the natural Kubernetes pattern is a sidecar in the agent's pod. A native sidecar (an init container with restartPolicy: Always) starts before the agent and lives as long as the pod. Two gotchas: there's no published container image, so build your own and bake the weights in; and httpGet probes will always fail because the kubelet hits the pod IP, not 127.0.0.1, so use an exec probe against http://127.0.0.1:<port>/health. A g6-family node (NVIDIA L4, 24 GB) is plenty for the 2B model.

Cost

The model is free; you pay for hardware. A g6.xlarge is about $0.805/hour on demand in us-east-1, roughly $588/month always on. Back-of-the-envelope (mine): ~8 sequential decisions/second at ~115 ms is on the order of 20M decisions a month; at 500 tokens each, that volume on a per-token service like Jev would be around $450. Self-hosting wins with sustained volume or privacy requirements; at low volume an idle GPU costs more. Start on CPU, share the GPU, and use the decider as a first-pass filter that escalates low-confidence cases to the LLM.

Limitations worth knowing

Per the model card: rephrased questions often get the same answer, long multi-step documents are the weak spot, score and noul transfer poorly to unfamiliar rubrics, and calibration was fitted on short classification, so validate thresholds on your own traffic. Training data and examples are English.

My take

The benchmark isn't the point (231 tasks is noisy). The point is the separation: the model classifies and returns a number, your code decides. That turns decisions hidden inside prompts into something you can test, version and audit with explicit thresholds. It's the same logic platform teams apply with Kubernetes admission policies: a deterministic checkpoint before something runs. It's not production-ready, and the official example says its thresholds are illustrative. But I'd run it as a tool-call guardrail for an internal agent, in a pod with a shared GPU, and compare its decisions against what your LLM decides today.

Originally published in Spanish on CloudAcademy.ar, with the full Kubernetes manifest and the complete intervention example.

Resources

AWS Lambda Web Functions: your HTTP server on Lambda, with real concurrency and active-CPU billing

Matias Martinez — Tue, 13 Oct 2026 21:18:40 +0000

On October 12, AWS launched Lambda Web Functions, and it's the biggest change to Lambda's programming model in years. Instead of writing a handler that receives a JSON event, you ship a plain HTTP server (Express, Hono, Fastify, React Router) that listens on a port. Lambda puts a managed HTTPS endpoint in front of it, scales it with traffic (down to zero), and bills you for the CPU time you actually burn, not for the time your request spent waiting on Postgres.

Along with the launch, the existing functions were renamed Lambda Event Functions (naming only, no code changes), so Lambda now comes in three shapes: Event Functions, Web Functions, and MicroVMs.

TL;DR

Your server listens on the host:port Lambda passes in AWS_LAMBDA_HTTP_ENDPOINT. No adapter, no wrapper.
Each execution environment serves many requests at once: up to 128, default 64.
Billing is active CPU + memory consumed while the environment lives + requests. In us-east-1 (Arm): $0.0000276944 per vCPU-second, $0.0000036667 per GB-second, $0.30 per million requests.
One-command deploy: aws lambda-web deploy --name my-app --code ./my-app. Add --regions for a global endpoint with latency-based routing.
Immutable revisions plus weighted endpoints give you canary, blue/green and rollback out of the box.
Node.js 24 on Arm64 only, 2 GB per environment, 3–900 s request timeout.
Available in us-east-1, us-east-2, us-west-2, ap-northeast-1 and eu-west-1. Not in São Paulo yet.

Why this matters

Running web apps on Lambda was always possible, but awkward. You wrapped your framework with serverless-http or the Lambda Web Adapter, and each environment still handled exactly one request. If your API took 200 ms because it was waiting on a database, you paid for 200 ms of compute while the CPU idled most of that time. A burst of 50 concurrent requests meant up to 50 environments and 50 cold starts.

That model fits short, event-driven functions. It fits LLM-backed APIs terribly: a request that streams tokens for three seconds while the CPU mostly waits is the worst case for wall-clock billing and single-request isolation. Web Functions is AWS's answer, and it's no coincidence the launch post lists streaming inference endpoints among the first use cases.

The resource model: functions, revisions, endpoints

Web Function: the top-level resource.
Revision: an immutable snapshot of code and configuration (timeout, per-environment concurrency, env vars, execution role). Any change means a new revision, and a new revision doesn't inherit settings from the previous one.
Endpoint: the HTTPS entry point, with its own domain, auth type and scaling limits. It routes to one or two revisions by weight.

Endpoints come in three types, fixed at creation: HomeRegion (one Region, one domain), MultiRegion (several Regions behind a global *.lambda-web.global.on.aws domain with best-effort latency routing), and PerRegion (one domain per Region, you route).

Each environment goes through init, ready and shutdown. Your server must start listening within 10 seconds; listening on the port is the readiness signal, there's no separate health check. On shutdown you get SIGTERM and one second to clean up.

Concurrency and scaling

Setting	Where	Range	Default
`maxConcurrencyPerEnvironment`	Revision	1–128	64
`maxEnvironments`	Endpoint, per Region	2–10,000 (optional)	none
`rateLimit`	Endpoint, per Region	0–10,000 RPS (optional)	none
`timeoutSeconds`	Revision	3–900	30

Account quotas apply per Region even if you set nothing: 10,000 RPS per endpoint, 100,000 RPS per account, and 2,000 vCPUs. Each environment uses 2 vCPUs, so that's at most 1,000 environments per Region. Lambda keeps headroom to absorb gradual increases; bursts larger than the headroom wait on cold starts. When you hit a limit you get a 429 (not queued); a rateLimit of 0 returns 503 Platform.EndpointDisabled, which doubles as a kill switch.

Hands-on

The only code change versus running locally is where you listen:

const express = require('express');
const app = express();
app.get('/', (req, res) => res.json({ message: 'Hello from Lambda Web Functions' }));

const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host);

process.on('SIGTERM', () => process.exit(0)); // you get ~1s

Deploy (make sure your AWS CLI v2 has aws lambda-web):

aws lambda-web deploy --name my-api --code ./my-api --auth-type IamAuth

Note that deploy creates an ApplicationManaged (public, no auth) endpoint by default. Great for hello world, not for production accounts. The docs include an SCP that denies creating such endpoints via the lambda:Request/WebFunctionAuthType condition key.

Canary and rollback are just weight updates:

aws lambda-web update-web-function-endpoint \
  --function-name my-api --endpoint-name prod \
  --revision-weights '[{"revisionId": "rev-abc12", "weight": 90}, {"revisionId": "rev-def45", "weight": 10}]'

# rollback (include the mode so it works from any state)
aws lambda-web update-web-function-endpoint \
  --function-name my-api --endpoint-name prod \
  --auto-deployment-mode Disabled \
  --revision-weights '[{"revisionId": "rev-abc12", "weight": 100}]'

Protect your downstream database without a new revision:

aws lambda-web update-web-function-endpoint \
  --function-name my-api --endpoint-name prod \
  --scaling-config '{"maxEnvironments": 50}' \
  --throttle-config '{"rateLimit": 8000}'

For a custom domain and AWS WAF, put CloudFront in front with Origin Access Control (origin type lambda, signing behavior always-amz-auth) against an IamAuth endpoint. CloudFront origin support launched the same day at no extra cost.

Outbound VPC access uses a network connector (aws lambda-core create-network-connector) referenced by version-qualified ARN from the revision. It only works with HomeRegion endpoints, and you still need a NAT gateway for internet egress.

Gotchas

"Active" doesn't mean "working." Lambda doesn't check that your server answers. Always smoke-test after deploying.
Hardcoded ports never become ready. Read AWS_LAMBDA_HTTP_ENDPOINT.
Global mutable state is now a concurrency bug, just like in a container.
2 GB is shared by heap, buffers and every in-flight request. V8's default heap is 1,024 MB.
DNS is cached per environment; ship a new revision after private DNS changes.
Signed requests to IamAuth endpoints must include X-Amz-Content-SHA256, even with no body.
delete-web-function leaves the default IAM role, S3 packages and log groups behind.

Pricing, honestly

AWS's own examples assume one environment for a 30-day month: an SSR app with 15M requests costs $25.78; an I/O-heavy API with 10M requests (200 ms, 50 ms CPU) costs $19.61; an LLM streaming endpoint with 5M requests of 3 s (200 ms CPU) costs $33.94.

I ran the same workloads through Event Function pricing (x86 rate listed on the same page, my assumption of 512 MB, no free tier): roughly $18.67 for the I/O API, $21.75 for SSR, and about $126 for LLM streaming. So Web Functions isn't automatically cheaper for short requests (the vCPU-second rate is high and requests cost 50% more), but for long, I/O-bound requests like token streaming it's a different order of magnitude.

What to check before adopting

Regions: five at launch, no South America. For users in Argentina or Brazil, us-east-1 is the closest option.
Data residency: multi-Region endpoints replicate code, and request metrics and logs are centralized asynchronously in the home Region.
Cross-Region data transfer: a global endpoint serving from Tokyo but querying a database in Virginia pays in latency and transfer.
Maturity: one runtime, brand-new APIs, IaC tooling still catching up. LocalStack 2026.10.0 already emulates it for local testing.

My take

The interesting part isn't "Express on Lambda"; we could already do that. It's that AWS changed both the billing unit and the isolation unit of its most used serverless service. For ten years Lambda made us think in one request per environment and pay for waiting time. That made sense for short event handlers and stopped making sense for apps that spend seconds waiting on a model. Web Functions brings Lambda close to a well-scaled container, without a cluster, and with revisions, canaries and multi-Region built in. The weak spots are the launch scope: Node.js only and five Regions. I'd try it now on a non-critical Node.js service, especially one that talks to Bedrock, and wait for the runtime and Region roadmap before making it a platform standard.

Originally published in Spanish on CloudAcademy.ar, with the full CLI walkthrough, VPC connector setup and SCP.

Resources

AWS Well-Architected Agent: Your Architecture Review, Now Done by an Agent (Preview)

Matias Martinez — Mon, 05 Oct 2026 12:55:30 +0000

A proper Well-Architected review has always had the same cost: a day or two of the team answering a long questionnaire, someone pulling evidence from five consoles, and a report that's stale within weeks. Trusted Advisor helps with point checks, but it has no idea which application matters or what your business is optimizing for this quarter.

On October 1, 2026, AWS launched AWS Well-Architected Agent in public preview. It continuously analyzes your accounts and returns cost, security, resilience, and performance recommendations ranked against goals you write yourself, and it hands you the fix: console steps, CLI commands, or the change to your infrastructure code. AWS positions it as the next step after Trusted Advisor and the Well-Architected Tool, delivered through AWS Support.

Here's how it works, how to wire it up with read-only cross-account roles, how to point it at an EKS Terraform repo before you deploy, and what to check before granting it access to your whole organization.

Profile → read-only role chaining → analysis → recommendations with remediation. (Diagram labels in Spanish, from the original article.)

TL;DR

Public preview since Oct 1, 2026. The service runs in us-east-1, us-east-2, and us-west-2, but can analyze resources in any commercial Region.
You create a profile: up to 100 accounts, their Regions, the pillars you care about, and a goal per pillar. First recommendations land within 24 hours.
It reads resource configuration across 65+ services, utilization metrics, and application topology via read-only roles.
Recommendations come at three levels (resource, application, architecture) with priority, effort, impact, ROI, and explicit trade-offs.
IaC review: upload a .zip of Terraform, CloudFormation, or CDK and get findings before anything is deployed.
Remediation via console, updated IaC, CLI, SDK, SSM runbooks, and MCP. In what AWS showed, it doesn't change resources on its own.
Requires an AWS Support plan. No published preview pricing.

What it is (and isn't)

It's an AWS Support service surfaced in the Well-Architected console. It doesn't replace the Well-Architected Tool (AWS says you can keep using it for manual reviews), it isn't a compliance auditor, and every recommendation carries a disclaimer that it's AI-generated and may be wrong or incomplete.

Preview scope: the console offers four pillars (cost, security, resilience, performance). The API already lists OPERATIONAL_EXCELLENCE as a value, but it isn't exposed in the preview console. IaC reviews currently use the Well-Architected Framework lens.

How it works

Profile. Created in a host account. You list target accounts (up to 100) and Regions, choose pillars, write a goal for each ("reduce unnecessary spend across my accounts", "workloads recover gracefully from disruptions"), and pick the execution role. Deletion protection is on by default in the console.

Profile setup: Regions, accounts, pillars with goals, roles. Image: AWS.

Application context (optional). Tell it which applications exist, where they live, and which tags identify them. That's what turns "15 queues without alarms" into "your event pipeline has no failure observability in any of its three Regions."

Access. Role chaining: an execution role in the profile account trusts wellarchitected.amazonaws.com and can assume an access role in each target account; access roles use the managed policy WellArchitectedAgentResourceScanning and trust the execution role, with the profile ARN as external ID to prevent confused-deputy issues. Onboarding is opt-in per account.

Recommendations and remediation

Type	Scope	AWS example
Resource	One resource or a small group	CloudFormation role with `Action: ""` on `Resource: ""` that only needs 7 service namespaces
Application (beta)	Findings across one app	15 DLQs in three Regions with no alarms; 48-minute median time to detect
Architecture	Patterns and IaC changes	ECS Fargate tasks ~2x over-provisioned based on 30-day p95 CPU/memory

Each comes with priority, effort, impact, an ROI estimate, affected resources, cross-pillar benefits, and trade-offs. That last field is what a good architect always tells you, and here it's explicit.

Recommendations ranked against the profile's goals. Image: AWS.

Start remediation lets you pick console, updated IaC template, or AWS CLI. The API's remediation types also include SDK, MCP, and AUTO_REMEDIATION. In AWS's example, the IaC option returns a CDK helper ready to paste into your stack, split into phases.

IaC remediation returns the change for your repo. Image: AWS.

Architecture review. Upload a .zip of your IaC project to S3, choose lens and pillars, start the review. Binary and media files are excluded. Classmethod tried it on day one: the review took about 30 minutes and flagged, among other things, a Lambda function hard-coded to MemorySize: 256 with no alarms or tuning automation.

Hands-on

You need an active AWS Support plan, a recent AWS CLI, and one of the service Regions (us-east-1 here).

1. Execution role (profile account):

cat > exec-trust.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
 "Principal":{"Service":"wellarchitected.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --path /service-role/ --role-name WAAgentExecutionRole \
  --assume-role-policy-document file://exec-trust.json

Give it sts:AssumeRole on arn:aws:iam::*:role/AccessRoleForWellArchitectedAgent.

2. Access role (each target account). Look up the managed policy ARN instead of hard-coding it:

POLICY_ARN=$(aws iam list-policies --scope AWS \
  --query "Policies[?PolicyName=='WellArchitectedAgentResourceScanning'].Arn" --output text)
aws iam create-role --role-name AccessRoleForWellArchitectedAgent \
  --assume-role-policy-document file://access-trust.json
aws iam attach-role-policy --role-name AccessRoleForWellArchitectedAgent \
  --policy-arn "$POLICY_ARN"

At scale, deploy this with CloudFormation StackSets, and add the external ID condition per the IAM docs once the profile exists.

3. Profile:

aws wellarchitected create-agent-profile \
  --name platform-eks \
  --business-overview "EKS container platform for payment APIs" \
  --pillars COST_OPTIMIZATION SECURITY RESILIENCE PERFORMANCE \
  --execution-role-arn arn:aws:iam::111122223333:role/service-role/WAAgentExecutionRole \
  --aggregation-configuration file://aggregation.json \
  --deletion-protection --region us-east-1

aggregation.json is a list of {"accountId", "regions", "accessRoleArn"} objects. get-agent-profile reports eligibleForScheduledGeneration, eligibleForArchitectureGeneration, and any fieldErrors.

4. Review an EKS Terraform repo — package it without state, provider cache, or secrets:

zip -r ../infra-eks.zip . -x ".terraform/*" "*.tfstate" "*.tfstate.backup" "*.tfvars" ".git/*"
aws s3 cp ../infra-eks.zip s3://my-review-bucket/infra-eks.zip

Then Conduct architecture review in the console.

5. Pull recommendations from the CLI:

aws wellarchitected list-agent-recommendations \
  --profile-arn arn:aws:wellarchitected:us-east-1:111122223333:agent-profile/platform-eks \
  --pillar COST_OPTIMIZATION --state OPEN --region us-east-1

aws wellarchitected get-agent-recommendation \
  --recommendation-arn <recommendation ARN> --remediation-type IAC --region us-east-1

Each recommendation includes awsServices, so you can filter EKS/ECS items into a weekly platform report or open an issue per HIGH finding.

Traps: applying CLI fixes in a GitOps setup (Terraform or Argo CD will revert the drift; route IaC fixes through PRs); zipping tfvars or .env files; assuming read-only means nothing sensitive is read; expecting results before 24 hours; treating dollar figures as exact; forgetting deletion protection when you try to remove a profile.

Pricing and availability

No published price during preview; it requires an active AWS Support plan. You pay normally for the S3 object holding your IaC zip and for whatever remediation deploys (alarms, SSM runbooks, capacity changes).

The service runs only in three US Regions but can onboard resources from any commercial Region. That's the part to check: if your workloads live in, say, São Paulo, their configuration, metrics, and uploaded IaC get processed in the US, and the announcement doesn't say where that data is stored or for how long. Regulated workloads should get a compliance sign-off first. And it's a preview, so APIs, pillars, lenses, and pricing can change.

My take

What matters here isn't that it uses AI. It's that the unit of work changes. Trusted Advisor gave you checks; the Well-Architected Tool gave you a questionnaire. This gives you a recommendation with context, impact, trade-offs, and the change for your repo, ranked by goals you wrote. If quality holds up in messy real environments (AWS's demo was very polished; Classmethod got reasonable but medium/low-priority findings), it'll replace most annual manual reviews. Two things are still unknown: price and data residency. I'd try it now on non-production accounts, route every fix through a pull request, and wait for GA pricing before rolling it out org-wide.

Resources

Originally published in Spanish on CloudAcademy.ar.

S3 Vectors Now Filters Before It Searches: Metadata Pre-Filtering for Multi-Tenant RAG

Matias Martinez — Mon, 05 Oct 2026 12:55:30 +0000

If you run RAG on Amazon S3 Vectors with metadata filters, you may have been losing results without knowing it. Ask for the 10 nearest chunks for one tenant and you might get 3 back, or 10 that aren't actually the closest ones in that tenant's data. No error, no alarm, just a model answering with less context than it should have had.

On September 30, 2026, AWS shipped metadata pre-filtering for S3 Vectors. Indexes now come in two modes, and the new one evaluates your filter before the similarity search instead of during it. AWS says that returns up to 5x more matching vectors when the filter is selective. It also adds a $startsWith prefix operator, sets a 100-condition limit per query, and costs nothing extra.

Here's what changed, why the old behavior dropped results, how to measure the difference on your own index, and what a multi-tenant retrieval service on Amazon EKS looks like with it.

CLASSIC validates the filter while searching; ENHANCED narrows the set first. (Diagram labels in Spanish, from the original article.)

TL;DR

S3 Vectors indexes now have a mode: CLASSIC (filter evaluated in tandem with the approximate search) or ENHANCED (filter resolved first, then similarity search over the matching subset).
With selective filters, ENHANCED returns up to 5x more matching vectors, per AWS.
Vector buckets created on or after Sep 30, 2026 are ENHANCED-only. Older buckets stay CLASSIC until you run UpdateIndexMode; no re-ingestion needed.
You can test per query with queryMode=ENHANCED before switching the index.
New $startsWith operator; ENHANCED indexes cap filters at 100 conditions (each $in value counts).
No additional cost. Available in every commercial Region with S3 Vectors, including São Paulo, plus the China Regions.

Why the old mode lost results

Vector search at scale is approximate: the engine explores a neighborhood of promising candidates on a bounded budget rather than comparing your query against every vector.

In CLASSIC mode, filters are checked while that exploration runs. If your filter matches half the corpus, most candidates pass and nothing bad happens. If it matches 0.005%, almost every candidate gets thrown away, the budget runs out, and you get fewer than K results, or K results that aren't the true nearest neighbors within the filtered set. The docs say it plainly: in CLASSIC, filtered queries may return fewer than K results when few vectors match.

An AWS re:Post article measured this on one million synthetic vectors: recall@10 went from 0.86 unfiltered to 0.83 at 10% selectivity, 0.42 at 1%, and 0.15 at 0.01%. The workaround was to partition data into separate indexes by low-cardinality fields (tenant, language, Region), which recovered 15–31 recall points at the cost of managing more indexes.

ENHANCED flips the order. AWS's example: 8 million support tickets, one customer owns 400. With pre-filtering, the similarity search runs over those 400, not over candidates drawn from all 8 million.

One takeaway worth repeating: result count is not a quality signal. Getting 10 results back in CLASSIC never guaranteed they were the best 10.

Index modes at a glance

Situation	Default mode	Can you change it?
Buckets created on/after Sep 30, 2026	`ENHANCED`	No way back to `CLASSIC`
Buckets created before Sep 30, 2026	`CLASSIC`	Yes: to `ENHANCED` via `UpdateIndexMode`, and back to `CLASSIC` via CLI/SDK/API only
New indexes in an older bucket	Bucket default	Set with `PutVectorBucketDefaultIndexMode`

UpdateIndexMode affects only that index. The console offers Enable enhanced index mode on the index detail page; reverting is not available in the console. The current mode shows up as indexMode in GetIndex.

Filters: operators and the 100-condition limit

Filter syntax is unchanged: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists, $and, $or, plus the new $startsWith (string prefix, ENHANCED only). Prefix matching is handy for path-organized collections: {"s3_path": {"$startsWith": "matter-4417/exhibits/"}}.

The 100-condition cap applies to ENHANCED indexes and is counted per value: {"region": {"$in": ["us-east-1", "us-west-2", "eu-west-1"]}} is 3 conditions. If you build dynamic filters with long $in lists (say, every project a user can access), audit them before migrating: over 100, an ENHANCED index returns a validation error.

Metadata limits haven't changed: up to 40 KB per vector, of which up to 2 KB is filterable; up to 50 keys; up to 10 non-filterable keys per index, fixed at index creation. Keep filter fields short and put chunk text in non-filterable metadata. Bedrock Knowledge Bases already does this with AMAZON_BEDROCK_TEXT and AMAZON_BEDROCK_METADATA.

Non-filterable keys are declared at index creation and can't be changed later. Image: AWS.

Hands-on

You'll need a recent AWS CLI and boto3.

1. Check the mode

aws s3vectors get-index \
  --vector-bucket-name my-vector-bucket \
  --index-name tickets \
  --query 'index.indexMode' --output text

2. Measure recall before migrating. Pick a small tenant, compute its true top-K by brute force, and compare against the index in each mode. This reads the whole index with ListVectors, so do it on a test copy or a sample.

import boto3, json, numpy as np

BUCKET, INDEX, TENANT, K = "my-vector-bucket", "tickets", "t-10428", 10
s3v = boto3.client("s3vectors")
bedrock = boto3.client("bedrock-runtime")

def embed(text):
    body = json.dumps({"inputText": text, "dimensions": 1024, "normalize": True})
    r = bedrock.invoke_model(modelId="amazon.titan-embed-text-v2:0", body=body)
    return json.loads(r["body"].read())["embedding"]

keys, mat, token = [], [], None
while True:
    kw = dict(vectorBucketName=BUCKET, indexName=INDEX, maxResults=1000,
              returnData=True, returnMetadata=True)
    if token:
        kw["nextToken"] = token
    page = s3v.list_vectors(**kw)
    for v in page["vectors"]:
        if v.get("metadata", {}).get("tenant_id") == TENANT:
            keys.append(v["key"]); mat.append(v["data"]["float32"])
    token = page.get("nextToken")
    if not token:
        break
mat = np.array(mat)

def ground_truth(q):
    q = np.array(q)
    sims = mat @ q / (np.linalg.norm(mat, axis=1) * np.linalg.norm(q))
    return {keys[i] for i in np.argsort(-sims)[:K]}

def query(q, mode):
    r = s3v.query_vectors(vectorBucketName=BUCKET, indexName=INDEX,
                          queryVector={"float32": q}, topK=K,
                          filter={"tenant_id": TENANT}, queryMode=mode)
    return {v["key"] for v in r["vectors"]}

for text in ["can't log in", "billing error", "plan change"]:
    q = embed(text); gt = ground_truth(q)
    for mode in ("CLASSIC", "ENHANCED"):
        got = query(q, mode)
        print(f"{mode:9} {text:14} returned={len(got):2} recall@{K}={len(got & gt)/len(gt):.2f}")

This assumes cosine distance and 1024-dim Titan Text Embeddings V2; adjust to your index.

3. Migrate

aws s3vectors update-index-mode \
  --vector-bucket-name my-vector-bucket \
  --index-name tickets \
  --index-mode ENHANCED

aws s3vectors put-vector-bucket-default-index-mode \
  --vector-bucket-name my-vector-bucket \
  --default-index-mode ENHANCED

4. Retrieval on EKS with Pod Identity. The tenant ID comes from the user's token, never from a client-controlled parameter. The API builds the filter; the pod queries S3 Vectors with a role scoped to one index.

The tenant filter is built server-side and resolved before the similarity search. (Diagram labels in Spanish.)

A permissions gotcha: s3vectors:QueryVectors alone only works without filters and without returnMetadata. With either, you also need s3vectors:GetVectors, or you get a 403.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3vectors:QueryVectors", "s3vectors:GetVectors"],
    "Resource": "arn:aws:s3vectors:sa-east-1:111122223333:bucket/my-vector-bucket/index/tickets"
  }]
}

Trust policy principal is pods.eks.amazonaws.com with sts:AssumeRole and sts:TagSession, and the cluster needs the eks-pod-identity-agent add-on. Then:

aws eks create-pod-identity-association \
  --cluster-name my-cluster --namespace rag \
  --service-account retrieval \
  --role-arn arn:aws:iam::111122223333:role/rag-retrieval

And the search function:

import os, boto3
s3v = boto3.client("s3vectors")

def search(tenant_id, query_embedding, folder=None, k=8):
    conds = [{"tenant_id": tenant_id}, {"active": True}]
    if folder:
        conds.append({"s3_path": {"$startsWith": folder}})
    r = s3v.query_vectors(
        vectorBucketName=os.environ["VECTOR_BUCKET"],
        indexName=os.environ["VECTOR_INDEX"],
        queryVector={"float32": query_embedding},
        topK=k, filter={"$and": conds},
        returnMetadata=True, returnDistance=True,
    )
    return r["vectors"]

Common traps: treating a tenant filter as isolation (a bug that drops it exposes the whole index; use per-tenant indexes with separate IAM for strict isolation); exceeding 100 conditions; using $startsWith on a CLASSIC index without queryMode=ENHANCED; storing dates as strings (range operators are numeric only); and skipping latency tests with broad filters, since AWS notes latency grows with index size, filter breadth, and condition count.

Pricing

No extra charge for pre-filtering. S3 Vectors pricing in us-east-1: storage $0.06/GB-month; PUT $0.20/GB uploaded; $2.50 per million query API calls; plus per-TB data-processed charges tiered by index size, and the first 512 KB returned per query free. AWS's published example (10M 1024-dim vectors across 40 indexes, 1M queries/month at top-100) comes to $11.38/month.

Note from that example: processing is driven by the size of the index you query, not by how many vectors pass the filter. A selective filter improves recall but doesn't make the query cheaper. Large tenants that always query their own data are still good candidates for a dedicated index.

Availability and caveats

Regions: all commercial Regions where S3 Vectors runs (including sa-east-1) and the China Regions.
Data residency: vectors stay in the bucket's Region; check where your embedding model runs, especially with cross-Region inference profiles.
Cross-Region traffic: keep your compute and your vector bucket in the same Region.
Bedrock Knowledge Bases: the announcement doesn't detail how Retrieve filters interact with index mode. If your knowledge base sits on a pre-Sep 30 bucket, check the index mode and measure.

My take

This fixes a limitation that forced you to design around the engine instead of the problem. Until now, the honest answer to "can all my tenants share one index?" was "yes, but small tenants will lose results." With pre-filtering, a shared index becomes reasonable for the long tail, while large tenants or those needing strict IAM isolation keep dedicated indexes. What doesn't change: the filter is still your code, and in multi-tenant RAG a missing filter is a data leak. I'd run the recall test above, migrate CLASSIC indexes, and use the occasion to audit where tenant filters get built.

Resources

Originally published in Spanish on CloudAcademy.ar.

EventBridge's new custom event bus: one bus for the whole org, with ordering, replay and per-GB pricing

Matias Martinez — Mon, 28 Sep 2026 15:21:00 +0000

On September 24, 2026, AWS relaunched the Amazon EventBridge custom event bus. This isn't a new toggle on the bus you already know. It's a separate resource with its own API namespace (eventsv2), its own sharing model, and a pricing model based on data volume instead of event count. Your existing buses are renamed "Custom event bus – classic" and keep working exactly as before.

The interesting part is what AWS is going after. EventBridge has always been pleasant inside a single account, but in a multi-account organization you end up with a mesh of buses, forwarding rules and resource policies, and the platform team becomes the ticket queue for every new subscription. And the moment someone needs strict ordering or wants to reprocess last Tuesday's events, the answer used to be "put SQS FIFO, Kinesis or Kafka in the middle."

The new bus tackles both problems: one bus shared across the organization, per-group FIFO delivery, deduplication, retention of up to a year, and replay from any point in time.

TL;DR

New custom event bus resource (eventsv2 API). The old one becomes classic and doesn't change.
Share one bus with accounts, OUs or the whole organization through AWS RAM using four managed permissions. Default quota: 10,000 subscribers per bus.
New Subscriber resource: filter + transformation + one target + retries + DLQ, owned by each consuming account.
FIFO per EventGroupId, deduplication within a 5-minute window, retention from 1 to 365 days, replay via each subscriber's starting position.
PutRawEvents accepts JSON, Avro, Protobuf or raw bytes with custom metadata. Transformations are written in JSONata.
Pricing: $0.18/GB ingress ($0.12 after 5,000 GB), $0.05/GB egress per subscriber, $0.08/GB-month extra retention, $0.15 per million evaluations.
14 Regions at launch. Not in São Paulo (sa-east-1) yet.

One bus in the platform account, shared via AWS RAM. Each team creates, and pays for, its own subscribers.

The ownership model is the real change

The classic model has the bus owner writing rules on behalf of everyone. In the new model, the platform team creates the bus and shares it; each team creates subscribers in its own account, only sees its own subscribers when listing, and can't modify or delete the bus. The owner sees every subscriber and can cut one off with RevokeResource.

Sharing uses four RAM managed permissions: AWSRAMEventBridgeEventBusV2PublishOnly, ...SubscribeOnly, ...EventSourceAccess and ...FullAccess. Two constraints to design around: consumers can't re-share the bus, and the bus and its subscribers must live in the same Region and partition. Sharing is free, and the owner gets per-consumer EventsDelivered and EgressBytes metrics, which is handy for chargeback.

Creating a custom event bus: new vs. classic. Image: AWS.

Sharing the bus through AWS RAM. Image: AWS.

Subscribers

A subscriber bundles what used to be spread across a rule, its targets, an input transformer, a retry policy and a DLQ:

Filters use regular event pattern syntax with three scopes: DATA (payload), METADATA (producer-supplied key/value pairs, exact match only) and SYSTEM_METADATA (fields EventBridge sets, such as EventGroupId). An event must match every filter.
Transformers: RAW (default), WITH_METADATA, or JSONATA with the event exposed as $events. Syntax is validated at creation, but evaluation happens at delivery time, so a bad expression fails deliveries, not deployments.
One target per subscriber: SQS, Lambda, Kinesis, Step Functions, SNS, HTTP/API destinations, Firehose, another bus, or universal targets like arn:aws:events:::aws-sdk:dynamodb:putItem.
Retries: 5 attempts within 300 seconds by default, configurable up to 185 attempts and 24 hours, then an SQS DLQ.

What happens to an event on the new bus, per subscriber.

Ordering and deduplication, with the fine print

Producers set SystemMetadata.EventGroupId. Subscribers configured for ordered delivery get events from the same group in sequence; other subscribers get the same events unordered. For Lambda or Express state machines you can invoke synchronously (REQUEST_RESPONSE) so EventBridge waits for the result before moving on. Standard state machines don't support that mode.

The docs are upfront about the tradeoff: a failing event blocks later events in its group for as long as it's retried. Keep the retry window short on ordered subscribers and use a FIFO DLQ, where EventBridge sets MessageGroupId from the EventGroupId so failures stay ordered too.

Deduplication happens at publish time, within 5 minutes, using your DeduplicationId or a content hash. Duplicates come back as DEDUPLICATED, which is a success code. AWS frames this as exactly-once semantics; I'd read it more narrowly as protection against producer retries. Your consumers still need to be idempotent.

Hands-on

Create a bus with 30 days of retention and a customer managed key:

aws eventsv2 create-event-bus \
    --name orders \
    --description "Order events from the checkout service" \
    --storage-configuration RetentionPeriodInDays=30 \
    --encryption-configuration KmsKeyIdentifier=arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
    --tags team=orders

Wait for ACTIVE before publishing. A KMS problem leaves it in CREATE_FAILED, and all you can do is delete it.

Share it with a consuming account:

aws ram create-resource-share \
    --name orders-bus-share \
    --resource-arns arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
    --principals 444455556666 \
    --permission-arns arn:aws:ram::aws:permission/AWSRAMEventBridgeEventBusV2SubscribeOnly

From the consuming account, create a subscriber for large orders with a DLQ:

aws eventsv2 create-subscriber \
    --name large-orders \
    --event-bus-arn arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
    --filter-configuration '{
        "Filters": [
            { "Scope": "DATA", "Pattern": "{\"detail\":{\"total\":[{\"numeric\":[\">\",500]}]}}" }
        ]
    }' \
    --invoke-configuration '{
        "TargetArn": "arn:aws:sqs:us-east-1:111122223333:large-orders",
        "RoleArn": "arn:aws:iam::111122223333:role/EventBusDeliveryRole"
    }' \
    --on-failure-configuration '{ "Arn": "arn:aws:sqs:us-east-1:111122223333:large-orders-dlq" }'

Reprocess from a timestamp by creating a subscriber with --starting-position POINT_IN_TIME and --point-in-time-configuration '{ "PointType": "TIMESTAMP", "StartingPoint": "2026-09-01T00:00:00Z" }'. Pause with update-subscriber --state STOPPED, and resume with --resume-position LAST_PROCESSED (drain the backlog) or LATEST (skip it).

Gotchas worth knowing before your first 2 a.m. page:

Only one subscriber create/delete runs at a time per bus. Parallel IaC gets ConcurrentModificationException, so retry or serialize.
Filters depend on the publish API. A pattern written for the PutEvents envelope matches nothing when the producer uses PutRawEvents.
A LATEST subscriber won't see events published before it existed.
For FIFO targets, derive MessageDeduplicationId per message with JSONata. A constant value means SQS drops everything after the first message.
Debug with the AWS/EventsV2 metrics as a funnel: FilterEvaluated → FilterMatched → EventsDelivered.

Pricing: cheaper, until your events get big

AWS's worked example (1,000 events/s at 2 KB, two subscribers, JSONata plus schema validation, 7-day retention, 1% failures) comes to $2,317/month: $922 ingress, $518 egress, $16 retry egress, $778 evaluation, $83 storage. The math checks out.

What the announcement doesn't show is the comparison with classic, which charges $1 per million events in 64 KB chunks, delivery within an account free and $1 per million for each cross-account delivery. Same volume (2.592 billion events/month, two subscribers, ingress and egress only):

Event size	New bus	Classic (same account / 2 cross-account deliveries)
1 KB	~$726	$2,592 / $7,776
2 KB	~$1,440	$2,592 / $7,776
10 KB	~$6,002	$2,592 / $7,776
60 KB	~$34,514	$2,592 / $7,776

My own math from published prices; excludes retention, retries, evaluation, and classic archives.

Small events crossing accounts get much cheaper. Large events can get several times more expensive, because classic charges the same for 1 KB and 64 KB. Against same-account classic with two subscribers, break-even sits around 4 KB per event. So slim your events (claim-check pattern), consider Avro or Protobuf via PutRawEvents, be deliberate about paid evaluations, and size retention to what you'll actually replay.

Availability

Launch Regions: N. Virginia, Ohio, Oregon, Ireland, Frankfurt, Stockholm, Spain, Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand and Tokyo. No São Paulo. Because subscribers must be in the bus's Region, South American workloads would need to bridge from a classic bus to a new bus in another Region. That's possible, but it adds latency, inter-Region transfer costs and data residency questions, especially now that the bus stores events.

My take

This is the biggest change to EventBridge since it launched, and ownership matters more than ordering here. Letting each team create and pay for subscribers on a bus it doesn't own is what makes a central bus something the platform team operates instead of something it serves by ticket. Per-subscriber replay from built-in retention is the other big win. Before migrating, run your real event sizes through the pricing, understand the per-group blocking on ordered subscribers, and check Region coverage. Start with a new domain, or one that's hurting for ordering or replay, and leave the rest on classic, which isn't going anywhere.

Originally published in Spanish on CloudAcademy.ar.

Resources

Amazon GuardDuty AI-powered investigations: a SOC copilot, not an autopilot

Matias Martinez — Mon, 29 Jun 2026 22:51:46 +0000

Amazon GuardDuty AI-powered investigations: a useful SOC copilot, not an autopilot

AWS just added a capability that many security teams have been trying to build around GuardDuty for years: a faster way to move from “there is a finding” to “this is probably what happened, here is the evidence, and these are the next actions.” The new feature is called GuardDuty Investigation, and it is now available in preview as AI-powered investigations for Amazon GuardDuty.

That wording matters. GuardDuty has already used machine learning and threat intelligence to detect suspicious behavior across AWS accounts, EC2, EKS, ECS, Lambda, S3, RDS, and other surfaces. This launch is not only about detecting another signal. It is about reducing the investigation tax that comes after the alert.

If you have operated cloud security at scale, you know the pattern: a finding appears, the analyst checks CloudTrail, IAM context, affected resources, related activity, known indicators, suppression rules, account ownership, and whether the finding is a real incident or just a noisy but expected behavior. That work is valuable, but it is also repetitive. It is exactly where a well-scoped AI assistant can help.

🔵 What changed

According to the AWS announcement, AI-powered investigations automatically analyze GuardDuty findings and AWS accounts to help distinguish true threats from benign findings. The investigation looks at finding context, related activity from the last 90 days, affected resources, and threat indicators. AWS says it uses knowledge graphs and threat intelligence to produce the analysis in minutes.

The GuardDuty Investigation documentation gives more detail on the output. Each investigation can produce:

a risk level: Info, Low, Medium, High, or Critical;
a confidence level: Unknown, Low, Medium, or High;
a summary with key observations;
investigation details with supporting context;
recommended actions, including CLI commands;
MITRE ATT&CK technique classification, using the common security knowledge base for attacker tactics and techniques.

That is a meaningful step beyond a plain alert. It gives the responder a starting hypothesis and evidence trail. The important part is not that the model “knows security.” The useful part is that GuardDuty already has the AWS-native context and can package that context into a structured investigation.

🔶 Three analysis modes

The preview supports three investigation scopes.

Finding analysis focuses on one GuardDuty finding. You provide a 32-character finding ID, and GuardDuty analyzes that specific signal. During preview, AWS says this supports all Extended Threat Detection findings and selected findings from foundational, S3, and Runtime plans.

Account analysis looks at the threat posture of one AWS account. This is useful when an account has multiple signals or when the first question is not “is this one finding real?” but “is this account behaving like it is under attack?”

Organization analysis lets an administrator analyze organization-wide posture, with a preview limit of up to 100 accounts. This is the most interesting mode for larger AWS environments because cloud incidents rarely respect account boundaries. A compromised principal, suspicious API activity, or lateral movement pattern may only make sense when viewed across accounts.

That said, the preview limits are real. The documentation states that, during preview, you can initiate up to 10 investigations per account per day, with a total limit of 100 investigations per account. The trigger prompt for API or CLI usage can be up to 2,048 characters. Failed investigations do not count against those quotas.

⚙️ How to enable it

You need an active GuardDuty detector in the Region where you want to create investigations, and the investigation feature must be enabled for that detector. In the console, AWS exposes this under Settings → AI powered investigations - Preview.

From the CLI, the docs show the feature name as AI_ANALYST:

aws guardduty update-detector \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --features '[{"Name":"AI_ANALYST","Status":"ENABLED"}]'

Your IAM identity also needs the investigation permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "guardduty:CreateInvestigation",
        "guardduty:GetInvestigation",
        "guardduty:ListInvestigations"
      ],
      "Resource": "arn:aws:guardduty:us-west-2:123456789012:detector/2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7"
    }
  ]
}

A basic investigation can be started with create-investigation:

aws guardduty create-investigation \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --trigger-prompt "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012"

The API is asynchronous. You get an InvestigationId, then retrieve the result with get-investigation once it completes.

🛡️ Where this helps in practice

The obvious use case is SOC triage. Instead of every finding starting as a blank page, the analyst receives a structured summary with risk, confidence, evidence, and recommended commands. That can cut the first 20–40 minutes of manual digging, especially for teams that already receive more alerts than they can deeply review.

The second use case is consistency. Different analysts may investigate the same GuardDuty finding differently. A standardized AI-generated package can help normalize the first response: what was checked, why the risk was assigned, which known attack technique may apply, and which resources need attention.

The third use case is managed security. If you operate AWS Organizations for many teams, account analysis and organization analysis are more interesting than single-finding analysis. They can help a central security team answer “which accounts deserve attention first?” instead of treating every alert as equal.

⚠️ What to be careful about

The preview documentation is explicit: investigation recommendations may contain errors or incomplete assessments, and human review is recommended. That is the right mental model. This feature should not auto-remediate production resources without a review gate.

There is also a data residency detail worth reading carefully. GuardDuty Investigation uses Cross-Region Inference Service. AWS says your data remains stored only in the Region where the investigation request originates, but investigation data and summary results may be processed outside that Region within the supported geography. For many organizations that is acceptable; for regulated environments, it needs review.

Availability is also limited to 10 commercial Regions in preview: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), and Asia Pacific (Tokyo).

🔍 What this means for security teams

This is the right direction for cloud security tooling. The value is not “AI replaces the analyst.” The value is that AWS has the telemetry, the resource graph, the threat intelligence, and the service context. If GuardDuty can assemble that into a defensible investigation package, analysts can spend less time collecting facts and more time making decisions.

I would not wire this directly to remediation on day one. I would start by enabling it in a controlled set of accounts, comparing its summaries against human investigations, measuring time saved, and building a review workflow around the recommendations. If the results are good, the next step is not full autopilot. It is faster triage, better evidence, and cleaner escalation.

Sources

AWS Lambda MicroVMs: serverless sandboxes for AI and untrusted code

Matias Martinez — Sat, 27 Jun 2026 02:02:27 +0000

AWS Lambda MicroVMs: serverless sandboxes for AI and untrusted code

AWS just shipped one of the more interesting Lambda launches in years: AWS Lambda MicroVMs. It is not “Lambda functions, but bigger.” It is a new serverless compute primitive aimed at a problem that has become very real with AI agents: how do you safely run code that your application did not write?

If you are building an AI coding assistant, a browser-based IDE, a data notebook platform, a vulnerability scanner, a multi-tenant CI runner, or any product that executes user-supplied scripts, you usually have to pick two out of three: strong isolation, fast startup, and stateful sessions. Traditional VMs give you isolation but can be slow and operationally heavy. Containers are fast, but shared-kernel isolation is a risk when the workload is untrusted. Functions are great for request-response workloads, but they are not designed for long-lived interactive environments that need to preserve state across user actions.

Lambda MicroVMs is AWS trying to close that gap.

What changed

According to the AWS announcement, Lambda MicroVMs provides VM-level isolation, near-instant launch and resume, and state preservation for user-generated or AI-generated code. The service is built on Firecracker, the same lightweight virtualization technology behind AWS Lambda functions. AWS says Firecracker powers more than 15 trillion monthly Lambda function invocations, which matters because this is not an experimental isolation model bolted onto Lambda; it is based on a virtualization layer AWS already runs at massive scale.

The AWS News Blog launch post frames the service around a new class of multi-tenant applications: AI coding assistants, interactive coding environments, analytics platforms, vulnerability scanners, and game servers that run user-supplied scripts. These systems need one isolated environment per user, job, or session. Lambda MicroVMs gives each session a dedicated MicroVM with no shared kernel and no shared resources between sessions.

That last point is the key architectural difference. This is not just a container with stricter defaults. The isolation boundary is a virtual machine boundary.

How the model works

The developer flow is different from regular Lambda functions. The Lambda MicroVMs developer guide describes the lifecycle like this:

Package your application code and a Dockerfile into a zip file and upload it to S3.
Call the Lambda API to create a MicroVM image.
Lambda builds the image, starts the application, and captures a snapshot of the initialized environment.
When your app needs a sandbox, call run-microvm.
Lambda launches a MicroVM from the snapshot and creates a dedicated HTTPS endpoint.
When idle, the MicroVM can suspend while preserving memory and disk state.
When traffic returns, it resumes.
When the session ends, you terminate it.

That snapshot-based startup is what makes the service interesting. Instead of booting from scratch every time, a new MicroVM starts from a pre-initialized image. For interactive workloads, that means the environment can feel ready quickly while still keeping an isolation model closer to VMs than containers.

A concrete CLI example

The running MicroVMs documentation shows a run-microvm command like this:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \
  --ingress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
  --egress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS" \
  --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800}' \
  --maximum-duration-in-seconds 14400

The only required parameter is the image identifier. The rest control networking, execution role, idle policy, logging, runtime payload, and maximum duration. The maximum time a MicroVM can remain running or suspended is 28,800 seconds, or 8 hours.

There is also an important networking detail: each MicroVM has its own dedicated endpoint. There is no load balancing across many MicroVMs behind a single endpoint. The endpoint maps to one MicroVM, which fits the “one sandbox per user/session/job” model.

Why this matters for AI agents

AI agents changed the risk profile of application infrastructure. It is now normal to have software generating code, executing shell commands, installing packages, reading files, transforming data, or running tests. If you let that happen inside a generic shared container pool, you inherit a security problem.

Lambda MicroVMs is useful because it gives product teams a managed primitive for isolated execution without asking them to become virtualization experts. A SaaS company building an AI data analyst could create one MicroVM per user session, preload dependencies, expose a notebook-like endpoint, suspend it after 15 minutes of inactivity, and resume it when the user returns. A security product could run each scan in a clean VM-level boundary. A CI platform could isolate tenant jobs without maintaining its own fleet of Firecracker hosts.

This does not remove application-level security work. You still need IAM boundaries, careful network egress rules, secret handling, logging, quota controls, and abuse protection. But it moves the hardest part of the compute isolation problem into a managed AWS service.

Limits and tradeoffs to watch

The launch is promising, but it is not a drop-in replacement for every compute pattern.

First, the service is region-limited at launch. AWS lists availability in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland) in the announcement.

Second, the lifecycle is session-oriented. If you need a continuously running service, ECS, EKS, EC2, or Lambda Managed Instances may still be a better fit. Lambda MicroVMs shines when you need isolated, stateful, per-user or per-job environments.

Third, pricing requires a different mental model from Lambda functions. The Lambda pricing page says Lambda MicroVMs are priced by compute resources used, snapshot read/write operations, snapshot storage, and standard data transfer. The announcement also notes that you pay for baseline compute resources while the MicroVM is running, and only for active duration of additional resources when the workload exceeds that baseline. In other words: idle suspension is not a minor feature; it is central to making the economics work.

My take

This launch shows where serverless is heading. The original Lambda abstraction was “run this function when an event arrives.” Lambda MicroVMs expands the idea to “give me a secure, stateful, short-lived compute environment for this user or agent.” That is a very different primitive.

For AI-native applications, this is likely to become one of the more important AWS building blocks to evaluate. The winners will be teams that treat Lambda MicroVMs as a sandbox lifecycle service, not as a generic container platform. Model your sessions clearly, minimize what goes into the image, make idle policy explicit, constrain networking, and terminate aggressively when work is done.

The direction is clear: AWS is turning the infrastructure needed for AI agents into managed primitives. Bedrock gives you models and agent tooling. Lambda MicroVMs gives you safer places to execute the messy code those agents produce.

Sources

AWS Step Functions: 1M ejecuciones/segundo y novedades de la semana

Matias Martinez — Mon, 06 Apr 2026 18:51:09 +0000

AWS Step Functions Express Workflows ya soporta hasta 1 millón de ejecuciones por segundo

Esta semana AWS duplicó el límite de ejecuciones concurrentes en Step Functions Express Workflows, RDS Proxy para PostgreSQL mejoró su manejo de conexiones, y Lambda Powertools for Python v3 agregó métricas custom más granulares.

🔥 Noticias principales

1. AWS Step Functions Express Workflows — 1M ejecuciones/segundo

AWS duplicó el límite de ejecuciones concurrentes de 500K a 1 millón por segundo.

Por qué importa: Si tenés workloads de procesamiento en tiempo real (IoT, stream processing, APIs de alta frecuencia), ahora podés escalar el doble sin rearchitecturar.

2. Amazon RDS Proxy for PostgreSQL — 10K conexiones simultáneas

Mejoró el pooling de conexiones para manejar picos de tráfico.

Por qué importa: Aplicaciones con muchos microservicios o serverless functions que acceden a PostgreSQL ya no necesitan implementar connection pooling manual.

3. AWS Lambda Powertools for Python v3 — Métricas custom

Ahora podés emitir métricas custom con dimensions específicas.

Por qué importa: Monitoring más granular sin escribir código boilerplate.

📋 Otras noticias

AWS Config Rules ahora soporta EKS
Amazon S3 Intelligent-Tiering agregó Archive Instant Access tier
AWS Backup agregó soporte para Amazon MemoryDB
Amazon EC2 M7i-flex instances ya disponibles en más regiones

📅 Eventos en Español

AWS Community Day Argentina 2026 — 15 de abril, Buenos Aires
EKS Workshop Latinoamérica — 22 de abril, virtual

📚 Artículos interesantes

Cómo debuguear Lambda functions con X-Ray y Powertools — Tutorial paso a paso
Architecting multi-tenant SaaS on AWS — Patrones de isolation
Cost optimization for EKS clusters — Spot instances + HPA

Fuentes: AWS What\u0027s New, AWS Blog, Last Week in AWS, InfoQ, Desplegando.cloud

Artículo prueba con variable de entorno DEVTO_API_KEY

Matias Martinez — Mon, 06 Apr 2026 01:21:25 +0000

¡Funciona! Variable de entorno configurada

Este artículo demuestra que la variable de entorno DEVTO_API_KEY está correctamente configurada en el pod de OpenClaw.

Configuración exitosa

Kubernetes secret creado
Variable inyectada en el pod
API key segura fuera del workspace
Autenticación funcionando

Tags: kubernetes, security, devto, aws

Creado automáticamente por el agente de CloudAcademy.ar

Artículo de prueba - Conexión dev.to API

Matias Martinez — Mon, 06 Apr 2026 01:05:54 +0000

Artículo de prueba

Este es un artículo de prueba para verificar la conexión con la API de dev.to.

Contenido de prueba

Verificación de autenticación
Creación de artículos
Configuración del blog

Tags: testing, api, aws

Creado automáticamente por el agente de CloudAcademy.ar