Doctor SEO — Bedrock AgentCore vs. Lambda: Cost Analysis

01Scope & method Revised

This compares raw compute cost only — AWS Lambda (the current L6 choice) against Amazon Bedrock AgentCore Runtime (the alternative), for the agent invocations that actually call a Bedrock model. Deterministic, model-free steps (C1/C2 scoring, B6's metrics fetch, the Playwright/Chromium renderer) are excluded from both sides — there's no reason to run a plain Python function or a headless-browser render on an agent-execution platform, so they'd stay on Lambda regardless of what L6 decides.

Correction from the first pass of this analysis: AgentCore Runtime's vCPU-hour charge only bills for active CPU cycles — time spent blocked on a Bedrock response, a tool call, or a DB query is not charged. Only the GB-hour memory charge runs for the full session wall-clock. The original version of this doc billed AgentCore's CPU for full wall-clock duration with no idle discount, which understated AgentCore's advantage for I/O-heavy agents. §03–§05 below are recomputed with the corrected model. Source: CloudBurn's AgentCore pricing breakdown (§08).

02Workload assumptions

Per audit run, derived from the agent framework tiering and Bedrock model routing already decided in Agent-Pipeline-Tech-Stack.html §02–03. Duration is the single biggest lever in this whole analysis, and only one data point is real so far.

Profile	Agents in profile	# invocations/run	Duration	Memory / vCPU	Status
SEO & GEO (own entity)	B2, B3	2	120 s	2 GB / 1 vCPU	Confirmed
SEO & GEO (competitor re-run)	B5's 3× re-run of B2 + B3 against each rival	6	120 s (inferred, not measured)	2 GB / 1 vCPU	Inferred from B2/B3
Tool-loop	A1, B5's own reasoning step, C5 — LangGraph loop	3	15 s	1.5 GB / 1 vCPU	Unverified placeholder
Other structured calls	A2, A3, B1, B4, B7, C4 + B5's 3× re-run of B4	9	5 s	1 GB / 0.5 vCPU	Unverified placeholder
Narrative, single pass	C3 — Opus 5, one large completion, no tools	1	20 s	1 GB / 0.5 vCPU	Unverified placeholder

In scope: 21 model-calling invocations per audit run. The confirmed 120s for B2/B3 is 24× the original 5s guess this analysis used for every "structured call" agent — which means the placeholder durations for A1, B1, B4, B5, B7, C3, C5 (rows still marked "Unverified placeholder") are now low-confidence too, not just optimistic rounding. Real numbers for those would materially change §04–§05. Excluded from both sides regardless (stay on Lambda either way): C1/C2 (2 invocations), B6 (1), the renderer (1) — none call a model.

03Unit pricing Sourced

Service	Unit price	What's actually billed	Free tier
AWS Lambda (x86)	`$0.0000166667` / GB-second + `$0.20` / 1M requests	Memory × full wall-clock duration, no idle discount — a function blocked on an `await` is billed identically to one at 100% CPU.	400,000 GB-s + 1M requests / month, permanent, never expires
Bedrock AgentCore Runtime	`$0.0895` / vCPU-hour + `$0.00945` / GB-hour	CPU: active cycles only — I/O wait (Bedrock latency, tool calls, DB queries) isn't charged. Memory: full session wall-clock, same as Lambda.	None found in sources reviewed

Billing granularity: both services bill per second, and AgentCore Runtime's minimum is 1 second (confirmed via CloudBurn, §10) — no rounding penalty either way. ARM/Graviton Lambda runs ~20% cheaper per GB-second than the x86 rate used throughout — a further lever if adopted, not modeled here since the pipeline's runtime architecture isn't specified. AgentCore also bills Gateway ($0.005/1,000 tool-call invocations), Memory ($0.25/1,000 events + $0.75/1,000 records stored/month), and Identity ($0.010/1,000 token requests) as separate components — not included below because this architecture already has DBOS + RDS for state and Secrets Manager + typed adapters for tool credentials, so adopting AgentCore wouldn't need its Gateway/Memory/Identity modules unless those subsystems were also replaced.

The active-vs-idle split is the whole ballgame and it isn't measured yet. Every table below models three scenarios — 30% idle (agent is mostly CPU-bound: crawling, parsing, scoring), 50% idle (midpoint), 70% idle (agent is mostly waiting on external APIs/model latency) — because B2/B3's real split between "waiting on DataForSEO/PageSpeed/SE Ranking" and "local compute" isn't known. AWS's own agentic-workload guidance cites 30–70% idle as typical (source #3, §10); this analysis doesn't assume where in that range these specific agents land.

04Apples-to-apples unit price

§03's two rates aren't directly comparable as written — Lambda sells one bundled unit (GB-second, CPU included for free), AgentCore sells two separate units (vCPU-second, GB-second). Normalized to the same per-second basis, split into the same components:

	AWS Lambda	AgentCore Runtime
Memory rate	$0.0000166667 / GB-s ($0.0600 / GB-hr)	$0.0000026250 / GB-s ($0.00945 / GB-hr)
CPU rate	Not billed separately — bundled into the memory rate at ~1 vCPU per 1,769 MB allocated	$0.00002486 / vCPU-s ($0.0895 / vCPU-hr)
CPU cost while idle/waiting	Billed — bundled with memory, can't be separated out	$0 — only active cycles are charged
Memory cost while idle/waiting	Billed (same bundled number as above)	Billed — same rate as active

The only fair comparison is pricing out the same resource allocation on both sides. At this pipeline's actual sizing for B2/B3 — 1 vCPU + 2 GB, per second:

	Lambda	AgentCore Runtime
Memory-only cost	not separable	2 × $0.0000026250 = $0.0000052500
CPU cost, 100% active (worst case for AgentCore)	not separable	$0.00002486
Total, 100% active / 0% idle	$0.0000333333	$0.0000301100 — 9.7% cheaper
Total, 0% active / 100% idle (theoretical floor)	$0.0000333333	$0.0000052500 — 84.2% cheaper

At this specific sizing, AgentCore is cheaper than Lambda across the entire possible range — even in the worst case (100% CPU-bound, zero idle time), AgentCore still comes in ~10% under Lambda's flat rate. Add real idle time and the gap widens toward the 31–62% figures in §05–§07.

05Cost per audit run

Profile	Lambda cost	AgentCore @30% idle	AgentCore @50% idle	AgentCore @70% idle
SEO/GEO, own entity ×2 Confirmed dur.	$0.008000	$0.005436	$0.004243	$0.003050
SEO/GEO, competitor ×6	$0.024000	$0.016309	$0.012730	$0.009150
Tool-loop ×3	$0.001125	$0.000960	$0.000737	$0.000513
Other structured ×9	$0.000750	$0.000510	$0.000398	$0.000286
Narrative ×1	$0.000333	$0.000227	$0.000177	$0.000127
Total, 21 invocations/run	$0.034208	$0.023442	$0.020284	$0.013126
vs. Lambda	—	−31.5%	−40.7%	−61.6%

Once B2/B3's real duration is in the model, they and their competitor re-runs are ~94% of total per-run compute cost — the tool-loop, other-structured, and narrative rows barely move the total either direction. That means the AgentCore-vs-Lambda decision for this pipeline is really a decision about one thing: how I/O-bound B2 and B3 actually are. At every idle level modeled, AgentCore wins on raw compute — but the margin ranges from a modest 31.5% to a large 61.6% depending on a number nobody has measured yet.

06Monthly projection

Volume Assumed	Lambda / month	AgentCore @30% idle	AgentCore @50% idle	AgentCore @70% idle
500 audits (pilot)	$10.44	$11.72 (+12%)	$10.14 (−3%)	$6.56 (−37%)
5,000 audits (early scale)	$164.38	$117.21 (−29%)	$101.42 (−38%)	$65.63 (−60%)
20,000 audits (at scale)	$677.50	$468.85 (−31%)	$405.68 (−40%)	$262.51 (−61%)

The free tier barely matters now — B2/B3's real duration burns through it fast. In the first version of this analysis (5s placeholder durations), Lambda's 400,000 GB-s/month free tier covered 500 audits entirely, making Lambda free at pilot volume. With B2/B3 confirmed at 120s/2GB, a single audit run uses ~2,052 GB-seconds — the free tier now covers only ~195 audits/month, not 500+. At the 30%-idle (compute-heavy) end of the range, AgentCore is actually more expensive than Lambda at pilot volume specifically because Lambda's shrunk-but-still-present free tier still covers a meaningful slice of a smaller pilot run. That flips to an AgentCore win at every volume once idle time is 50%+.

07How far the free tier actually goes

Two direct follow-ups: how many audits fit inside Lambda's free tier at the confirmed B2/B3 duration, and what the monthly comparison looks like with that discount stripped out entirely — sticker price, not what you'd actually pay.

Free audits per month: 400,000 GB-s ÷ 2,052.5 GB-s/audit run = 194 audits/month fully inside the free tier (194 × 2,052.5 = 398,185 GB-s, just under the cap — the 195th audit would push 237.5 GB-s over). The request free tier (1M ÷ 21 requests/audit ≈ 47,619 audits) isn't the binding constraint here — duration is.

Volume	Lambda, no free tier (sticker price)	AgentCore @30% idle	AgentCore @50% idle	AgentCore @70% idle
500 audits	$17.11	$11.72 (−31.5%)	$10.14 (−40.7%)	$6.56 (−61.7%)
5,000 audits	$171.06	$117.21 (−31.5%)	$101.42 (−40.7%)	$65.63 (−61.6%)
20,000 audits	$684.25	$468.85 (−31.5%)	$405.68 (−40.7%)	$262.51 (−61.6%)

With the free tier removed, the savings % is flat across every volume — 31.5% / 40.7% / 61.6% regardless of scale — because the free tier was the only thing making §05's comparison volume-dependent; strip it out and it collapses to the same per-run ratio from §04, scaled linearly. This is the underlying rate difference cleanly isolated, not a real budget number — the actual Lambda bill does get the free-tier discount, so §05's $10.44 / $164.38 / $677.50 figures remain the accurate ones to plan against.

08What the dollar figure misses

120s is well inside Lambda's 15-minute cap — the "avoid chunking" argument doesn't apply here. A generic AgentCore pitch is that its 8-hour session ceiling lets you avoid splitting a long agent loop across multiple Lambda invocations to dodge the 15-minute limit. At 120s per B2/B3 invocation (or even several minutes if the unconfirmed agents turn out longer than guessed), this pipeline isn't remotely near that ceiling, and nothing in Agent-Pipeline-Tech-Stack.html describes DBOS chunking a step for timeout reasons. This argument would only start to matter if a single agent step grew into the multiple-minutes-to-hours range.

DBOS integration is unverified. The current ADR is explicit: DBOS Transact owns workflow state and "invokes one bounded Lambda" per step. Whether DBOS can target an AgentCore Runtime session as a step executor instead of a Lambda function isn't established in any doc reviewed — this would need a spike before it's a real option, not just a pricing swap. This matters more now: with a genuine 30–60%+ compute saving on the table (§04–§05) rather than the earlier "statistical tie," the case for doing that spike is stronger than it was.

AgentCore's real product is also Gateway + Memory + Identity + Observability. This architecture already has bespoke equivalents for all four (DBOS+RDS for state, Secrets Manager+typed adapters for tool credentials, Cognito for identity, OpenTelemetry+LangSmith for tracing). Adopting AgentCore Runtime alone (as modeled here) sidesteps this; adopting the rest of the platform would mean paying for capability already built, or a genuine re-architecture to retire DBOS/RDS state management in favor of AgentCore Memory.

The remaining 9 agents' durations could move the total either way. They're currently ~6% of per-run cost on unverified 5–20s placeholders. If A1/B5/C5's tool loops (which make several sequential tool + model round trips, plausibly with real wait time) turn out to be minutes rather than seconds, they'd start to matter for the total the way B2/B3 now do — and they'd likely skew idle-heavy too, given how much of a tool loop is spent waiting on a model or a provider API rather than computing locally.

09Recommendation

Revised from "stay on Lambda" to "worth a spike, pending two numbers." With the corrected billing model and B2/B3's real duration, AgentCore Runtime shows a genuine 31–62% compute saving depending on idle fraction — not the statistical tie this doc originally found, and not quite the flat 47% claimed elsewhere either (that figure ignored Lambda's free tier and would need to be checked against real idle-time data). Two things gate a real decision: (1) confirm whether DBOS Transact can target an AgentCore Runtime session as a step executor — if not, this is a bigger re-architecture than a pricing swap; (2) get an actual active-vs-idle split for B2/B3 (even a rough one — "mostly waiting on DataForSEO" vs. "mostly local crawling/scoring") to know which end of the 31–62% range is real. Until then, treat this as "promising, not yet actionable" rather than a settled recommendation either way.

10Sources

AWS — Amazon Bedrock AgentCore pricing (official): aws.amazon.com/bedrock/agentcore/pricing — Runtime/Browser/Code Interpreter vCPU-hour & GB-hour rates, Gateway/Memory/Identity/Evaluations pricing.
AWS — AWS Lambda pricing (official): aws.amazon.com/lambda/pricing — per-request and per-GB-second rates, free tier, provisioned concurrency.
CloudBurn — "Amazon Bedrock AgentCore Pricing: 12 Components Breakdown": cloudburn.io/blog/amazon-bedrock-agentcore-pricing — confirms per-second billing with 1-second minimum, 8-hour session ceiling, idle-session reuse.
Cipher Projects — "Amazon Bedrock AgentCore Pricing (2026): What Actually Drives the Bill": cipherprojects.com/blog/posts/amazon-bedrock-agentcore-pricing-2026 — framing for why a pure compute-cost comparison undersells AgentCore's platform value.
CloudZero — "AWS Lambda pricing: what it actually costs in 2026": cloudzero.com/blog/lambda-pricing — corroborates Lambda's permanent free tier and the ~20% ARM/Graviton discount.

All figures retrieved 2026-08-26. AWS pricing changes over time — re-verify the two official pricing pages before using this for a budget commitment.

Amazon Bedrock AgentCore vs. AWS Lambda — Compute Cost