# amazon-bedrock-samples: what the AWS repository actually gives you

> The aws-samples/amazon-bedrock-samples repository is a collection of Jupyter notebooks and guides for Amazon Bedrock, organised by topic rather than by model. It is useful as a starting point and misleading as a production reference.

**aws-samples/amazon-bedrock-samples** — This repository contains examples for customers to get started using the Amazon Bedrock Service. This contains examples for all available foundational models

- Repository: https://github.com/aws-samples/amazon-bedrock-samples
- Website: https://aws.amazon.com/bedrock/
- Stars: 1,514 · Forks: 740
- Language: Jupyter Notebook
- License: MIT-0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/aws-samples-amazon-bedrock-samples

## What amazon-bedrock-samples is, and who it is written for

The repository describes itself as containing "pre-built examples to help customers get started with the Amazon Bedrock service." That phrasing matters. It is a sample collection, not a library, not an SDK wrapper, and not a deployable application. The primary language is Jupyter Notebook, and the top-level directory list confirms the shape: introduction-to-bedrock, agents-and-function-calling, rag, embeddings, multi-modal, custom-models, evaluation-observe, responsible_ai, poc-to-prod, workshops, and a few more. Each folder carries its own README with detailed instructions, per the main README's Getting Started section.

The audience is engineers who already have an AWS account and want a runnable path into Bedrock concepts. If you are evaluating whether Bedrock fits a workload, the notebooks let you see the request and response shapes without reading the API reference first. If you are already fluent in the Bedrock API, most of this repository will tell you nothing you do not know, and the parts that would help you (poc-to-prod, cost-reporting, model-latency-benchmarking) are a small fraction of the tree.

The README also points to a rendered website at aws-samples.github.io/amazon-bedrock-samples, built from an mkdocs.yml at the repository root. That is the intended reading experience. The GitHub view is the source of it.

## How the repository is organised and how the notebooks flow

There is no shared runtime, no package, and no abstraction layer. The architecture is a folder per topic, and inside each folder, notebooks that call the Bedrock API directly. That is the whole mechanism. Data flow in a typical notebook is: configure a boto3 client or a LangChain wrapper, name a model, send a prompt, read the response, and sometimes feed that response into a second call (for example, an embedding call followed by a vector store query in the rag folder).

The topics list confirms the intended coverage: amazon-bedrock, amazon-titan, bedrock, embeddings, generative-ai, knowledge-base, langchain, rag. So the repository spans both raw API examples and framework-mediated ones. That is a real trade-off. A raw boto3 example shows you exactly what Bedrock expects on the wire. A LangChain example shows you a pattern you might actually ship, but it hides the API surface and ties the sample to whatever LangChain version was current when the notebook was written. Neither is wrong, but they age differently, and the repository does not mark which is which.

The folder split is also uneven in maturity. introduction-to-bedrock and articles-guides are conceptual. agents-and-function-calling, rag, and embeddings are the heavy engineering folders. custom-models covers importing your own weights, which is a different product surface from calling a hosted model. Treating the repository as one coherent body of guidance would be a mistake; it is closer to a dozen small projects sharing a README.

## Installing amazon-bedrock-samples and running a first notebook

There is no install command in the sense of a package. The README's Getting Started section says to ensure you have access to Amazon Bedrock, then clone the repository and navigate to one of the topic folders. So the setup is a clone plus an AWS identity that can call Bedrock.

```bash
git clone https://github.com/aws-samples/amazon-bedrock-samples.git
cd amazon-bedrock-samples
```

After cloning, you pick a folder. The README states that detailed instructions live in each folder's own README, so the next step is to read the one you chose rather than to run anything from the root.

The identity you use must have IAM permissions for Bedrock. The README gives this inline policy as an example to paste into the JSON editor under Add Permissions > Create Inline Policy:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BedrockFullAccess",
      "Effect": "Allow",
      "Action": ["bedrock:*"],
      "Resource": "*"
    }
  ]
}
```

That policy grants every Bedrock action on every resource. It is an example, and the README itself points to the Bedrock Developer Guide for fine-grained action and resource permissions. For anything beyond a sandbox account, treat bedrock:* as a starting point to narrow, not a target state. The README also warns that in SageMaker your notebook execution role is typically separate from the console user or role you log in with, so granting access to one does not grant it to the other.

What you should see: a cloned tree with the topic folders listed above, and, once permissions are in place, notebooks that execute against Bedrock without an access-denied error. If a notebook fails on permissions, the cause is almost always the execution role rather than the console user.

## Where the sample approach breaks down

The repository is a snapshot of patterns, not a maintained interface. There are no releases. The README does not document rollback, deprecation, or an upgrade path, and it does not state which model IDs or API versions any given notebook targets. Model availability and naming change on Bedrock's side, not the repository's, so a notebook that ran when it was written can fail later for reasons the repository never records.

A second limitation is scope creep by folder. The README says that for top-level folder changes you should reach out to the GitHub maintainers. That is a governance note, and it tells you the top-level structure is deliberately curated rather than open. Contributions are welcome under CONTRIBUTING.md, but the taxonomy is not a free-for-all.

A third issue is that the repository is not a place to look for production hardening. poc-to-prod exists as a folder, which acknowledges the gap, but the bulk of the tree is teaching material. If you need retries, timeouts, token accounting, throttling behaviour, or cost controls, you will be writing them yourself. cost-reporting and model-latency-benchmarking are the closest things to operational content, and they are two folders out of roughly twenty.

Finally, the licensing is permissive but the content is example code. MIT-0 removes attribution requirements, which makes copying snippets easy. It does not make those snippets correct for your workload.

## The alternative: boto3 and the Bedrock API reference

The obvious alternative is to skip the repository and work from the AWS SDK for Python directly, using the Bedrock API reference and the Bedrock Developer Guide that the README itself links to. The difference in approach is fundamental. amazon-bedrock-samples gives you a narrative: here is a task, here is a model, here is the prompt, here is the output. The SDK plus the API reference gives you a contract: here are the parameters, here are the required fields, here is the error model.

If you are learning, the narrative wins, because it answers questions you have not thought to ask. If you are shipping, the contract wins, because sample notebooks do not tell you what happens under throttling or which fields are optional. The repository's LangChain examples sit between the two: they give you a pattern with less API visibility, which is a reasonable trade only if you have already decided to use LangChain.

A practical middle path is to read a notebook from the folder closest to your task, then reimplement the call against the SDK and compare. The diffs are usually small, and they surface exactly the assumptions the notebook was making.

## Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-29. That is recent enough that the tree is being touched, but the README records no releases, so there is no version number to pin and no changelog to read. Your upgrade cost is therefore not a dependency bump. It is the cost of re-reading whichever notebook you borrowed from and checking whether the model IDs, prompt formats, and library imports still match what Bedrock and your chosen framework expect today.

Practically, that means copying a notebook into your own repository rather than referencing it from a submodule. Once copied, you own it, and the diff between your copy and upstream is the only upgrade signal you will get.

The licence is MIT-0. It permits use, modification, and redistribution without attribution. It does not carry a warranty, and it does not cover the AWS services the code calls, which are governed by your AWS agreement. Nothing here is legal advice; if you are redistributing the notebooks inside a product, read the LICENSE file at the repository root and your own counsel's view of it.

One more cost: because the repository spans raw SDK calls and framework-mediated calls, an upgrade to your LangChain version can invalidate the framework examples while leaving the boto3 examples untouched. Budget for the two halves separately.

## Conclusion

Adopt amazon-bedrock-samples if you need a working notebook to learn Bedrock concepts, or a reference for prompt engineering and RAG patterns before you write your own code. Do not adopt it as a production dependency: it is a sample collection, not a library, and nothing in it is versioned or released. Before you build on anything from it, verify which model IDs and API shapes the notebook assumes, and confirm that the IAM policy you attach is narrower than the bedrock:* example the README shows. The README does not document rollback, deprecation or upgrade paths, so pin nothing to these files.

## FAQ

### What exactly is Amazon Bedrock?

Amazon Bedrock is the AWS service this repository provides examples for. The README describes the repository as containing pre-built examples to help customers get started with the Amazon Bedrock service, and lists examples for all available foundational models.

### Can you give me an example of bedrock?

The repository is organised into topic folders that each serve as an example set, including introduction-to-bedrock, agents-and-function-calling, rag, embeddings, multi-modal, and custom-models. The README says detailed instructions are provided in each folder's own README.

### Is Amazon Bedrock easy to learn?

The README does not make a claim about difficulty. It does say the repository contains pre-built examples to help customers get started, and that you need access to Amazon Bedrock plus sufficient IAM permissions before the notebooks will run.

### How much does Amazon Bedrock cost?

The README states no pricing. The repository includes a cost-reporting folder among its top-level entries, but the README gives no figures and links only to the Bedrock product page.

## Sources

- [aws-samples/amazon-bedrock-samples on GitHub](https://github.com/aws-samples/amazon-bedrock-samples)
- [Issues](https://github.com/aws-samples/amazon-bedrock-samples/issues)
- [License: MIT-0](https://github.com/aws-samples/amazon-bedrock-samples/blob/main/LICENSE)
- [Project website](https://aws.amazon.com/bedrock/)
- [README](https://github.com/aws-samples/amazon-bedrock-samples/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-samples-amazon-bedrock-samples