Fixing n8n Bedrock Automation: Throttling, Duplicates, Cost Blowouts

A developer details common failure modes in n8n Bedrock automation pipelines, including throttling, duplicate content generation, and cost blowouts. The post explains that n8n is purely an orchestrator and that AWS Bedrock's per-model TPS quotas and credential signing requirements are frequent pitfalls. The developer recommends modular sub-workflows and idempotency checks to avoid cascading errors.

Originally published on kuryzhev.cloud Your n8n Bedrock automation pipeline works fine in testing. You trigger it manually, watch the Claude response come back in two seconds, ship the demo to your team. Then it goes live, a webhook retries three times because a downstream CMS timed out, and you've published the same blog draft twice while Bedrock throws ThrottlingException at every fourth request. We've rebuilt this exact pipeline for three different clients now, and the failure modes are almost identical every time. This post is about what actually happens when n8n talks to AWS Bedrock for content generation — drafts, summaries, repurposing — and where n8n Bedrock automation setups quietly fall apart once they leave the sandbox. Strip away the marketing framing and the data path is simple: an n8n trigger webhook, cron, or manual fires, an HTTP Request node or AWS-credentialed node calls Bedrock's InvokeModel or InvokeModelWithResponseStream endpoint, a parsing node extracts the completion, and a sink node pushes the result somewhere — a CMS API, a Slack channel, an S3 bucket for archival. The important thing to internalize: n8n does zero inference. It's purely an orchestrator that signs and sends AWS requests. Every millisecond of latency and every cent of cost lives inside Bedrock, not inside your n8n instance. This matters because people debug n8n performance when the actual bottleneck is a model's cold-start variance or a regional TPS quota. There's also a credential distinction that trips people up immediately. n8n's built-in "AWS" credential type — the one used for S3 and Lambda nodes — does not correctly sign Bedrock runtime requests out of the box. Bedrock runtime lives on a separate endpoint https://bedrock-runtime.<region .amazonaws.com/model/<model-id /invoke , and you need either the newer "Generic Credential Type: AWS" available in n8n 1.6x+ HTTP Request nodes, or manual SigV4 signing if you're stuck on an older version or a community node. Check the Bedrock API setup docs https://docs.aws.amazon.com/bedrock/latest/userguide/api-setup.html for the exact signing requirements — it's not optional, it's a hard 403 if you get it wrong. The most common anti-pattern I see is one giant workflow per content type. Summarization, drafting, and social repurposing all crammed into a single n8n canvas with twenty nodes. It works until you need to change one prompt — then you're redeploying the entire workflow, retesting every branch, and hoping you didn't break the Slack notification three nodes downstream. Modular sub-workflows exist for exactly this reason, and ignoring them is the single biggest maintainability killer I've seen in these builds. Second: no idempotency. A webhook fails, n8n retries, and now you've called Bedrock twice and published the same article twice to your CMS. There's no dedupe key, no execution-id check, nothing preventing a duplicate. I watched a client publish the same LinkedIn post three times in one morning because their webhook trigger had zero request deduplication — embarrassing, and entirely avoidable with a simple idempotency check against a Redis set or a database row. Gotcha: people treat Bedrock like a stateless, infinitely scalable API. It isn't. On-demand throughput has real per-model TPS quotas — sometimes as low as 5-10 requests per second per region — and batch content jobs that fan out fifty items at once will hit ThrottlingException almost immediately. Check your actual quota in the Service Quotas console before you architect around an assumption. Separate your "trigger/queue" workflow from your "generation" workflow, connected via n8n's sub-workflow call node. The trigger workflow handles dedupe, batching, and queuing. The generation workflow does one thing: call Bedrock, parse the response, hand it back. Each gets its own error workflow attached, so a Bedrock failure doesn't cascade into your entire pipeline throwing a generic red X. Use IAM role-based credentials, not static access keys, scoped to specific model ARNs — not bedrock: . I've lost count of how many times AccessDeniedException: User is not authorized to perform bedrock:InvokeModel turned out to be an IAM policy that granted the action but forgot to scope the resource to the actual model ARN like anthropic.claude-3-sonnet-20240229-v1:0 . Retry logic matters too. n8n's default "Retry On Fail" is 0 — off. You need to explicitly set retries with a wait time, or better, write exponential backoff yourself in a Function node so you can branch specifically on ThrottlingException versus a genuine model timeout. And keep prompt templates in S3 or Parameter Store instead of hardcoding them in Set nodes — that way editorial can iterate on prompts without you touching the workflow at all. Here's the queue-mode setup we run in production. Main-process mode chokes fast under concurrent Bedrock calls, so this is non-negotiable past a handful of parallel executions: docker-compose.yml — n8n queue mode setup for concurrent Bedrock workflows version: "3.8" services: postgres: image: postgres:15 restart: always environment: POSTGRES USER: n8n POSTGRES PASSWORD: ${DB PASSWORD} POSTGRES DB: n8n volumes: - pg data:/var/lib/postgresql/data redis: image: redis:7-alpine restart: always command: "redis-server", "--appendonly", "yes" n8n-main: image: n8nio/n8n:1.62.1 restart: always ports: - "5678:5678" environment: DB TYPE: postgresdb DB POSTGRESDB HOST: postgres DB POSTGRESDB USER: n8n DB POSTGRESDB PASSWORD: ${DB PASSWORD} EXECUTIONS MODE: queue required for async Bedrock calls QUEUE BUS REDIS HOST: redis EXECUTIONS DATA PRUNE: "true" avoid Postgres bloat from LLM payloads EXECUTIONS DATA MAX AGE: "168" hours, prune after 7 days N8N ENCRYPTION KEY: ${ENCRYPTION KEY} depends on: - postgres - redis n8n-worker: image: n8nio/n8n:1.62.1 restart: always command: worker environment: DB TYPE: postgresdb DB POSTGRESDB HOST: postgres DB POSTGRESDB USER: n8n DB POSTGRESDB PASSWORD: ${DB PASSWORD} EXECUTIONS MODE: queue QUEUE BUS REDIS HOST: redis N8N ENCRYPTION KEY: ${ENCRYPTION KEY} deploy: replicas: 3 scale workers to control Bedrock concurrency, not n8n itself depends on: - postgres - redis volumes: pg data: Watch out for: storing raw API keys or secrets inside a "Set" node in the workflow JSON. That JSON gets exported, committed to git, and now your Bedrock credentials are sitting in a public repo history. Always use n8n's credential vault. It's not extra effort, it's one dropdown. Once a single workflow works reliably, the next problem is scale. For batch jobs — say 500 items needing summaries — don't blast them all at Bedrock at once. Use n8n's "Split In Batches" node combined with queue-mode worker concurrency caps. We've seen a 500-item fan-out with no concurrency limit trigger a regional quota lockout that affected unrelated production workloads on the same AWS account. That's not a theoretical risk, that happened to a client's checkout service because a content job saturated the shared Bedrock quota. Model routing is worth building explicitly rather than hardcoding one model. A router node picks Claude 3 Sonnet for long-form drafts, a cheaper Llama 3 variant for short summaries, and falls back to a secondary model if the primary throttles repeatedly. This keeps cost proportional to content complexity instead of paying Sonnet rates for a two-sentence summary. For editorial previews where waiting on a full completion feels sluggish, switch to InvokeModelWithResponseStream and pipe chunks into a WebSocket or SSE node. It changes the perceived latency dramatically even though total generation time is the same. Guardrails deserve their own mention. Attach a guardrail ID in the request payload and branch on the response's guardrailAction field instead of trusting raw model output blindly — especially if this content is publishing anywhere public-facing without human review. // Bedrock InvokeModel payload used inside n8n Function node before HTTP Request { "anthropic version": "bedrock-2023-05-31", "max tokens": 1024, "temperature": 0.4, "messages": { "role": "user", "content": "{{ $json.promptTemplate }}" } , "guardrailConfig": { "guardrailIdentifier": "gr-content-safety-01", "guardrailVersion": "1" } } // Expected throttle error shape to branch on in the next node { " type": "ThrottlingException", "message": "Too many requests, please wait before trying again.", "$statusCode": 429 } Miss the anthropic version field on a Claude payload and Bedrock returns ValidationException instead — an easy mistake when copy-pasting between model families that expect different request shapes. Main-process mode in n8n starts choking somewhere around 10-15 parallel Bedrock executions. Past that, queue mode with Redis and multiple workers isn't optional — it's the only thing keeping your webhook triggers from blocking on long-running generations while waiting for a busy worker. On-demand throughput throttles hard during bursts. If you're running scheduled batch content jobs — nightly summaries, weekly digests — Provisioned Throughput on Bedrock removes the 429s entirely, at a higher fixed cost. We switched a client with a daily 200-article batch job to provisioned and their throttle rate dropped from roughly 12% of requests to zero, worth the extra spend for their volume. Token limits and payload size directly affect latency. We measured p95 latency on Claude 3 Sonnet nearly double when passing full multi-thousand-token context versus a truncated prompt — if your use case tolerates summarized context instead of raw source text, it's a real latency win, not just a cost one. Speaking of cost: Claude 3 Sonnet runs roughly $3 per million input tokens and $15 per million output tokens at current Bedrock pricing check the official Bedrock pricing page https://aws.amazon.com/bedrock/pricing/ since this shifts . A batch job without token-limit guards can blow through hundreds of dollars in a single unattended overnight run — we've seen it happen. Finally, don't ignore your Postgres execution log. n8n stores full JSON responses for every execution by default, and Bedrock responses aren't small. Without EXECUTIONS DATA PRUNE=true and a sane EXECUTIONS DATA MAX AGE , that table grows for weeks until query performance degrades silently — no error, just slowly worsening dashboard load times until someone notices. I check this on every n8n Bedrock automation deployment now, after watching one client's execution history table hit 40GB in under two months. If you want more on structuring infra config so it doesn't drift like this, we've covered related patterns over on our AWS automation posts https://kuryzhev.cloud/category/aws/ . n8n Bedrock automation is genuinely powerful once it's wired correctly — modular workflows, scoped IAM, explicit retry logic, and queue mode aren't optional extras, they're the difference between a demo and something that survives real traffic without duplicating content or draining your AWS bill overnight.