Managing Costs and Optimizing Performance Part 4

When managing knowledge bases in Amazon Bedrock, plan for re-ingestion from the start. If you initially ingest 1,000 documents, those documents will change over time: new documents arrive, and existing documents are updated. Re-ingesting the entire corpus on every change is wasteful — instead, apply incremental updates only to changed items. Amazon Bedrock provides a synchronize (sync) operation for knowledge bases that performs incremental updates: it applies only changes rather than re-ingesting the whole corpus. Sync does not run automatically — you must decide how and when to trigger it (for example, event-driven when new data arrives, or on a schedule such as every six hours using Amazon EventBridge).

Use incremental sync to update only changed documents. Trigger sync either by events (when data arrives) or on a schedule (Amazon EventBridge) depending on your ingestion pattern and SLA.

A slide titled "Workflow: Manage Knowledge Base Costs" showing three document icons with only the center one highlighted as "Changed" while the other two are labeled "Unchanged" to illustrate avoiding re‑ingesting unchanged data. A callout says "Re‑ingest only the changed file; skip the other two" and suggests using versioning or timestamps to detect updates.

Detecting changed documents

Detect changes using one or more of the following methods and feed the changed-document list to Bedrock’s sync operation:

Versioning: increment a version number when a file changes.
Timestamps: compare last-modified timestamps.
Checksums/hashes: compute a checksum and compare to the stored value.
Event-driven notifications: publish an event when content changes and trigger a sync for that document.

If real-time eventing is not available or needed, schedule periodic syncs using Amazon EventBridge (hourly, every few hours, daily) to keep the knowledge base reasonably fresh without re-ingesting everything.

Avoid re-ingesting the entire knowledge base on every change. That increases token usage, processing cost, and embedding recomputation. Incremental syncs are the cost-efficient approach.

Example: Limit retrieved chunks in a RetrieveAndGenerate call

When using retrieval-augmented generation (RAG) with Bedrock, limit the number of retrieved chunks to reduce context injected into the model. Fewer chunks means fewer input tokens and lower cost. In the example below, the vector search configuration returns only the top three chunks by specifying numberOfResults: 3.

response = bedrock_agent_runtime.retrieve_and_generate(
    input={"text": "What is the returns policy?"},
    retrieveAndGenerateConfiguration={
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "kb-123",
            "modelArn": "amazon.nova-lite-v1:0",
            "retrievalConfiguration": {
                "vectorSearchConfiguration": {
                    "numberOfResults": 3  # limit retrieved chunks
                }
            }
        }
    }
)

By restricting retrieved chunks you control the size of the augmented prompt (fewer input tokens). This is one of the most effective levers for cost and performance control in RAG workflows.

Operational recommendations (quick reference)

Recommendation	Why it matters	Example / How-to
Start with smaller models	Lower cost and often sufficient for many tasks	Use `amazon.nova-lite-*` or similar; move to larger models only if metrics justify it
Track token usage	Understand cost drivers and tune parameters	Log request/response sizes and `max_tokens`
Use incremental sync	Avoid unnecessary embeddings and reprocessing	Detect changes via version/timestamp/checksum and call Bedrock sync only for changed items
Cache repeated prompts	Save tokens and latency for identical queries	Serve cached responses for repeat queries
Batch and pre-compute	Reduce call volume and reprocessing	Pre-compute embeddings; batch similar requests
Monitor billing	Detect cost anomalies and set alerts	Use AWS Billing Console and AWS Cost Explorer

Simple load-test example

A minimal timing loop helps estimate baseline response times and detect performance regressions. Replace the print statements with real model calls or HTTP requests to Bedrock for an actual load test.

import time

queries = ["What is the returns policy?"] * 10  # simulate 10 identical queries

start = time.time()

for q in queries:
    # simulate model call; replace with actual Bedrock call in real tests
    print(f"Processing: {q}")

end = time.time()

print(f"Total time: {end - start:.2f} seconds")

From these simple measurements you can derive practical actions: refine prompts to reduce token usage, add caching layers to avoid repeated calls, batch requests where appropriate, and provision throughput (or scale horizontally) when necessary.

Expected outcomes

Adopting these strategies will typically yield:

Lower operational costs by reducing unnecessary token usage and choosing appropriate models.
Faster responses because less irrelevant data is sent to the model.
Better scalability — moving from a handful of users to hundreds or thousands without runaway costs.
More predictable usage and billing.

A presentation slide titled "Key Takeaways" that lists numbered recommendations for cost-efficient GenAI—choose the right model, use RAG, reuse embeddings, and use caching/batching. The slide has a dark left panel with blue numbered markers and the text on a light background.

Key practical takeaways

Choose the right model for the task; don’t default to the largest model for everything.
Use RAG (retrieval-augmented generation) and Bedrock knowledge-base syncs so only relevant chunks are injected into prompts.
Reuse pre-computed data (embeddings) rather than recomputing them repeatedly.
Use caching and batching to avoid unnecessary Bedrock calls and lower overall token usage.
Prefer serving from cache or pre-computation for repeated identical prompts; use batching where real-time responses are not required.

Later sections will cover error handling, troubleshooting, edge cases, and defensive coding practices for reliable production deployments.

Links and references

Amazon EventBridge: https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html
AWS Billing Console: https://console.aws.amazon.com/billing/home
AWS Cost Explorer: https://aws.amazon.com/aws-cost-management/aws-cost-explorer/

Introduction to Gen AI and LLMs

Introduction to Amazon Bedrock

Getting Started With Amazon Bedrock

Foundation Models in Amazon Bedrock

Basic Concepts of Prompt Engineering

Introduction to Text Generation With Amazon Bedrock

How Foundation Models Process Input

Extract Insights Using Prompt Engineering

Working With Different Task Types

Integrating Amazon Bedrock With Other AWS Services

Build a Marketing Email Generation Application

Introduction to Retrieval Augmentation With Bedrock Knowledge Bases

Best Practices and Optimization

Governance, Safety in Responsible AI

Security

Monitoring and Logging

Taking action with Bedrock Agents

Advanced Topics (Optional)

Final Project

Wrap Up

Managing Costs and Optimizing Performance Part 4

Detecting changed documents

Example: Limit retrieved chunks in a RetrieveAndGenerate call

Operational recommendations (quick reference)

Simple load-test example

Expected outcomes

Key practical takeaways

Links and references

Watch Video

​Detecting changed documents

​Example: Limit retrieved chunks in a RetrieveAndGenerate call

​Operational recommendations (quick reference)

​Simple load-test example

​Expected outcomes

​Key practical takeaways

​Links and references

Watch Video

Detecting changed documents

Example: Limit retrieved chunks in a RetrieveAndGenerate call

Operational recommendations (quick reference)

Simple load-test example

Expected outcomes

Key practical takeaways

Links and references