# Bedrock Serverless GenAI Guide

Use this reference for Amazon Bedrock serverless applications, RAG flows, prompt orchestration, Guardrails, Lambda/API Gateway/Step Functions integrations, and production-readiness gaps.

## What people get wrong

The lazy story is:

> Bedrock is managed, so the app is safe if IAM is scoped and the model works.

Wrong. Managed inference does not solve prompt injection, data boundary, retrieval leakage, token cost, evaluation, observability, or fallback design.

Common bad assumptions:

- Guardrails replace application authorization and data filtering.
- A model invocation test proves production behavior.
- RAG quality is a vector database problem only.
- Prompt/version changes do not need release control.
- Cross-Region inference profiles are just a performance feature, not a residency and cost decision.
- CloudWatch GenAI observability exists for the app unless explicitly enabled and scoped.

## GenAI-specific failure modes

- User prompt or retrieved context overrides system intent or tool boundaries.
- Knowledge base retrieves unauthorized, stale, or ungrounded content.
- Lambda/API Gateway timeout, payload, streaming, or concurrency limits are ignored.
- Token usage, retries, and long context windows create unbounded cost.
- Logs capture prompts, documents, PII, secrets, or customer data without retention controls.
- Model, Region, guardrail, prompt, or embedding changes are not versioned or evaluated.
- Fallback path silently downgrades quality, safety, or data residency.

## Minimum safe workflow

1. Identify the use case, data classification, user roles, model/Region, latency target, and cost boundary.
2. Choose the simplest serverless shape: API Gateway or AppSync, Lambda, Step Functions for orchestration, EventBridge/SQS for async, S3/DynamoDB for state, and Bedrock managed capabilities.
3. Define prompt, guardrail, retrieval, tool, and output contracts before implementation.
4. Add explicit evaluation criteria: golden prompts, refusal cases, retrieval-grounding checks, latency, token budget, and safety regressions.
5. Design observability with redaction: token counts, latency, model errors, guardrail interventions, retrieval IDs, and user-impact metrics.
6. Require IAM/KMS/network/data-retention boundaries for prompts, documents, embeddings, logs, and outputs.
7. Keep deploy, model access changes, guardrail publishing, and data-source ingestion approval-gated.

## Verification targets

- Bedrock model, Region, inference profile, guardrail, prompt/version, and invocation path
- Knowledge Base data source, chunking, metadata filters, embedding model, sync status, and authorization boundary
- Lambda/API Gateway/Step Functions timeout, payload, streaming, concurrency, retry, and error handling
- IAM permissions for `bedrock:*` actions narrowed by model/resource where practical
- KMS, S3, DynamoDB, CloudWatch Logs retention, VPC/private connectivity, and data residency settings
- eval set, expected outputs, refusal cases, retrieval citations, and regression threshold
- cost controls: token budget, max output tokens, retry limits, quotas, and alerting

## When to push back

Push back if the user asks to:

- ship a GenAI app without prompt/retrieval safety evals
- treat Guardrails as a complete security boundary
- log raw prompts or retrieved documents broadly
- use broad Bedrock/IAM permissions for convenience
- ignore token/cost limits during retries or long conversations
- claim model availability proves app readiness

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html
- https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GenAI-observability.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- Amazon Bedrock provides managed access to foundation models and related application features; model availability, feature maturity, and regional coverage can vary.
- CloudWatch generative AI observability can trace prompts, track token latency, and monitor AgentCore agents, but observability must be enabled and scoped to the application.

Sampled live evidence:
- Read-only regional availability sampling reported Amazon Bedrock as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.

Review implications:
- Require model/region selection, guardrails, prompt/version management, RAG source boundaries, IAM/KMS controls, logging, cost/token limits, evaluation criteria, and rollback/fallback behavior.
- Do not infer deployed agent/model safety from Bedrock service availability; inspect app configuration, prompts, tools, data sources, and telemetry.

# Safety checklist

Use before recommending AWS generative AI architecture, Bedrock integrations, data retention, or production rollout.

## Non-negotiables

- Do not ask for or print secrets, credentials, private keys, account numbers, customer identifiers, prompt logs, or private source data.
- Prefer least-privilege IAM, scoped data access, sanitized prompts, and explicit approval before mutation or production rollout.
- Prefer serverless managed services for this role unless a concrete blocker is provided.
- Do not normalize prompt-injection exposure, unsafe tool invocation, or storing sensitive prompts/outputs without retention controls.
- Confirm logging, tracing, rate limits, quotas, and cost visibility before production recommendations.

## Component risks

- **Bedrock / prompts:** prompt injection, unsafe tool use, over-broad model access, unbounded token cost.
- **Lambda / orchestration:** timeouts, retries, idempotency bugs, DLQ gaps, concurrency spikes.
- **Retrieval / storage:** data leakage, stale embeddings, public buckets, over-broad table permissions.
- **APIs / auth:** weak auth, noisy anonymous traffic, over-broad CORS, missing throttling.
- **State / memory:** retaining user data too long, mixing tenants, no delete path.

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.

# Workflow and output contract

Use this reference for full AWS generative AI application design, architecture review, or implementation guidance.

## Workflow

1. **Classify the workload**
   - Chat API or assistant backend
   - Retrieval-augmented generation flow
   - Async document or event-driven pipeline
   - Bedrock app with Guardrails and policy concerns
   - AgentCore runtime versus non-AgentCore application logic

2. **Enforce serverless-first architecture**
   - Start with Bedrock managed capabilities plus Lambda, API Gateway, Step Functions, EventBridge, S3, DynamoDB, SQS, SNS, and Cognito.
   - Only move to ECS, EKS, or EC2 if the user provides a concrete serverless blocker such as runtime incompatibility, long-lived GPU needs, or explicit platform constraints.
   - If a non-serverless path is chosen, call out why the serverless path was rejected.

3. **Review the application shape**
   - ingress/auth path
   - prompt / orchestration path
   - retrieval / data path
   - asynchronous work and failure handling
   - Guardrails / safety / policy path
   - observability / tracing / cost controls

4. **Validate**
   - Confirm IAM boundaries, prompt-injection defenses, logging, retry behavior, quotas, cost guardrails, and rollback path.
   - Distinguish documentation-based patterns from live deployed evidence.

## Output contract

Return:

1. Workload classification
2. Evidence level and current unknowns
3. Serverless-first architecture recommendation
4. Main risks / blockers
5. Safe next actions
6. Validation and rollback path