# amazon-bedrock-workshop: notebooks, extras and the cost warning

> This repository is the code half of a hands-on Amazon Bedrock workshop: four numbered notebook modules, a dependency spec whose optional extras map onto those module numbers, and a README that spends as much space on IAM permissions and cleanup as on code. The guided instructions live on the workshops catalogue site, not here.

**aws-samples/amazon-bedrock-workshop** — This is a workshop designed for Amazon Bedrock a foundational model service.  

- Repository: https://github.com/aws-samples/amazon-bedrock-workshop
- Website: https://catalog.us-east-1.prod.workshops.aws/amazon-bedrock/en-US
- Stars: 2,210 · Forks: 957
- Language: Jupyter Notebook
- License: MIT-0
- Published: 2026-09-30 · Updated: 2026-09-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/aws-samples-amazon-bedrock-workshop

## Four numbered folders, and the workshop that is not in the repository

The code samples are organised into numbered sub-folders that correspond to the modules of the workshop, and the numbering is the whole structure: `01_Inference_APIs/`, `02_Knowledge_Bases_and_RAG/`, `03_Model_customization/` and `04_Agents/`. Underneath sit `workshop_utils/` for shared helpers and `tutor/` for material you did not expect in a code repository.

The important structural point is that this repository is not the workshop. It accompanies a hands-on event aimed at developers and solution builders, and the guided instructions live on the AWS workshops catalogue site. What you get here is the dependency specification, the notebooks and the supporting code. If you work through the notebooks without the catalogue text, you are reverse-engineering the intended exercises rather than doing them, which is a different and much slower exercise.

The target is also explicit about who it is for. Anyone learning to use foundation models through Amazon Bedrock on AWS, and the repository points to a sibling project, amazon-bedrock-samples, when you want a broader set of samples beyond the four modules, plus the Bedrock user guide, the AI category in the AWS Solutions Library, and Amazon Bedrock AgentCore as a platform for building agents.

The primary language recorded for the project is Jupyter Notebook, which is the honest description of a repository whose substance is executable cells.

## Optional extras are the module system

The dependency design is the best thing in this repository, and it is easy to miss. pyproject.toml declares a small core set and then defines optional-dependency groups named after the module numbers, so you install the weight of the labs you are actually doing.

```toml
lab2 = [
    "opensearch-py>=3.2.0",
    "requests-aws4auth>=1.3.2",
]
```

That group maps to `02_Knowledge_Bases_and_RAG/`, and the pair of packages explains itself: the OpenSearch client and SigV4 request signing for the knowledge base lab. The agent module carries its own group:

```toml
lab4 = [
    "bedrock-agentcore>=1.13.0",
    "bedrock-agentcore-starter-toolkit>=0.3.9",
    "opensearch-py>=3.2.0",
    "retrying>=1.4.2",
    "strands-agents>=1.42.0",
    "strands-agents-tools>=0.8.0",
]
```

Two agent frameworks appear side by side there, the Bedrock AgentCore SDK and its starter toolkit alongside the Strands agents packages, plus a retry helper, which tells you the lab compares approaches rather than picking one.

The third group, `lab3` for model customization, is by far the largest: evaluation libraries including fmeval and bert-score, datasets, plotting with matplotlib and seaborn, pandas and numpy, pdf and archive handling with pypdf and py7zr, and tokenizers. That is a research environment, not an introductory one, which is exactly why the README suggests installing a subset such as `pip install .[lab2,lab4]`. A convenience group named `all` pulls the three together, and the first module, inference, needs only the core dependencies.

## Several client libraries for one service, on purpose

Look at the core dependency list and you will find the Anthropic SDK, the OpenAI SDK, langchain, langchain-aws, langchain-openai and boto3 all installed together. That is unusual for a sample and it is not accidental: the first module is named Inference APIs, plural, and the workshop is introducing the surface of Bedrock rather than one blessed client.

For a service that exposes a native runtime API, a Bedrock-hosted OpenAI-compatible endpoint and a direct model SDK, that is a defensible choice. You finish the first module knowing which interface suits which situation, and you have run the code rather than read about it.

The cost is real, though. Anyone who arrives with a strong preference for one client leaves the workshop with three partially-explored ones, and the dependency set pulls in more surface than a single path would. Two other core entries hint at what the labs do with files: `fsspec[s3]` and `universal-pathlib`, plus `aws-bedrock-token-generator` for token counting, which is the piece you need if you are working through model costs while you work through costs.

## Setting up, choosing a kernel, and the first notebook

There are three setup paths, and which one you use depends on whether AWS handed you an environment.

At an AWS-led event, a temporary account and a VS Code Server instance are provided and the dependencies are already installed in a `.venv` in this folder, so you can skip installation entirely. In a local IDE with uv, create the environment and sync everything:

```sh
uv venv .venv
uv sync --all-extras --all-groups
```

With plain pip and another environment manager, the equivalent is `pip install .[all]`, and the narrower form is `pip install .[lab2,lab4]` when you only want two modules.

The repository also carries `mise.toml` and a `.python-version`, so a tool-version manager is a supported alternative to uv rather than an accident of the tree.

Then the part where most first runs stop. The labs are Jupyter notebooks, so when you first open or run a cell you may be asked to select a kernel, and the answer is Python Environments followed by `.venv` (.venv/bin/python). If that option is missing, the `.venv` folder has not been created, which means the install step above did not run in the right directory. In VS Code or Kiro the other half of the problem is extensions, since Jupyter support and Python environment discovery both have to be present for the kernel to appear.

Once a kernel is chosen, run cells with Shift and Enter, and start with `01_Inference_APIs/01_Inference_APIs.ipynb`. The README's own advice before any of this is to clear your terminal, because whatever is in it is on screen while you work.

## IAM permissions and the bill: the part people skip

The prerequisites section is the most consequential part of the README and the easiest to skim, because it reads like boilerplate. It is not. Permissions are grouped by module, and each group corresponds to AWS services you will actually call.

All labs need Amazon Bedrock, and the Bedrock line carries a qualifier that matters: AWS Marketplace permissions to subscribe to new models. That is not a detail, because most Bedrock models are consumed through Marketplace and a session without those permissions cannot enable a model at all.

The knowledge base and RAG labs add Amazon OpenSearch Serverless and Amazon S3. The agent labs add Amazon Bedrock AgentCore, AWS CloudFormation, Amazon DynamoDB and IAM access, which is the widest grant in the list and the one worth reviewing before you run it in an account that holds anything real.

On top of the permissions there is the cost warning, and it is stated bluntly: running these samples in your own AWS account incurs costs, and you should run the cleanup steps promptly when you finish. Notebooks that create an OpenSearch collection, write to S3, stand up CloudFormation stacks or invoke a model per prompt will all leave something running. Plan for the teardown before you start, or run the labs on a throwaway account.

The other prerequisite worth taking literally is the AWS CLI being configured with those same permissions. A notebook that fails on a credentials error halfway through a module is a bad afternoon, and the CLI check catches it in a minute.

## Python 3.11 in the README, 3.12 in pyproject.toml

There is a small inconsistency worth knowing before you build an environment. The README's prerequisites say Python 3.11 or newer. The dependency specification says `requires-python = ">=3.12"`. Two different floors in one repository, and the packaging metadata is the one an installer will enforce, so 3.11 will fail at install time rather than at import time.

Nothing else about the project is ambiguous in the same way, which makes this look like documentation drift rather than a deliberate choice. The fix on your side is trivial: read pyproject.toml first, which is also where you learn that the project version is 0.1.0 and the description calls itself a dependency specification for an introductory hands-on workshop.

Maintenance itself looks ordinary. The last push was on 2026-09-28 and the repository is not archived. There are no GitHub releases, but there is a RELEASE_NOTES.md, so changes are recorded in a file rather than in tags, which is the norm for a sample repository that is updated in place as services move.

The licence is MIT-0, the variant of MIT with the attribution requirement removed. For an MIT-licensed sample you would normally keep the notice; with MIT-0 a notebook lifted into an internal repository does not require a credit line. This review does not interpret licences, so read the LICENSE file if your own policy needs the exact terms.

The quality tooling is also in the tree: `.pre-commit-config.yaml` and a dev dependency group, with a comment asking that the Ruff version be kept in sync with the pre-commit config and the lint workflow. There are two Markdown linter configuration files, one JSONC and one YAML, which is the kind of duplication that suggests a migration between the two.

## When a workshop repository is the wrong tool

Three cases where this is the wrong starting point.

If you are not going to run it against a real AWS account, it will not teach you much. Every lab is an API call, and the interesting parts, cost, retries, quotas, regional availability, are all properties of the service rather than of the code. The catalogue site hosts the content in a us-east-1 endpoint, which is a fair hint about how tightly the material is tied to one account's configuration.

If you already know Bedrock and want breadth, the sibling project amazon-bedrock-samples exists for that, and the README says so. The workshop's job is a guided path through four modules, not a catalogue of features.

And if your constraint is a small environment, note what `lab3` pulls in. fmeval, datasets, tokenizers, matplotlib, seaborn, pandas and numpy are a data-science stack, and installing it on a laptop-sized machine before you have decided whether you want the model customization lab is a poor trade. The extras exist precisely so you can avoid it, and `pip install .[lab2,lab4]` is the command that respects your time.

What this repository is genuinely good at is one thing: showing several client surfaces for the same service in working code, in a structure where the dependency weight is declared up front. That is a better default than copying a snippet from a blog post.

## Conclusion

Use amazon-bedrock-workshop if you have an AWS account with Marketplace access to Bedrock models and want a guided path through inference, RAG, model customization and agents with working notebooks. Do not begin it if you are cost-sensitive without reading the cleanup steps first, and do not treat the repository as the workshop, because the instructions are on the catalogue site. Read pyproject.toml before creating the environment, since it requires Python 3.12 while the README says 3.11+, and start with `pip install .[lab2,lab4]` if the lab3 evaluation stack is more than you need.

## FAQ

### What modules are in the amazon-bedrock-workshop repository?

Four numbered folders matching the workshop modules: 01_Inference_APIs, 02_Knowledge_Bases_and_RAG, 03_Model_customization and 04_Agents, plus a workshop_utils/ directory for shared helpers. The pyproject.toml optional-dependency groups named lab2, lab3 and lab4 line up with the second, third and fourth folders.

### How do I install the amazon-bedrock-workshop dependencies?

With uv, run `uv venv .venv` and then `uv sync --all-extras --all-groups`. With plain pip, `pip install .[all]` installs everything and `pip install .[lab2,lab4]` installs a subset. At an AWS-led event the `.venv` is already provisioned and you can skip the step entirely.

### Which Python version does the amazon-bedrock-workshop need?

The README says Python 3.11 or newer, but pyproject.toml sets requires-python to ">=3.12", which is the floor an installer enforces. Use 3.12 or later. The repository also carries a mise.toml and a .python-version if you prefer a tool version manager over uv.

### What AWS permissions does the amazon-bedrock-workshop require?

All labs need Amazon Bedrock plus AWS Marketplace permissions to subscribe to new models. The knowledge base and RAG labs add Amazon OpenSearch Serverless and Amazon S3, and the agent labs add Amazon Bedrock AgentCore, AWS CloudFormation, Amazon DynamoDB and IAM access. The AWS CLI should be configured with the same permissions before you start.

### Does running the amazon-bedrock-workshop cost money?

Yes. The README carries an explicit cost warning for running the samples in your own AWS account and tells you to run the cleanup steps promptly, since the labs create OpenSearch collections, S3 objects and CloudFormation stacks and call models. AWS-hosted events provide a temporary account instead.

### Where are the guided instructions for the amazon-bedrock-workshop?

On the AWS workshops catalogue site, not in the repository. The README links the full guided instructions there and sends you to amazon-bedrock-samples for a broader set of code and notebook samples beyond the four modules.

## Sources

- [aws-samples/amazon-bedrock-workshop on GitHub](https://github.com/aws-samples/amazon-bedrock-workshop)
- [Issues](https://github.com/aws-samples/amazon-bedrock-workshop/issues)
- [License: MIT-0](https://github.com/aws-samples/amazon-bedrock-workshop/blob/main/LICENSE)
- [Project website](https://catalog.us-east-1.prod.workshops.aws/amazon-bedrock/en-US)
- [README](https://github.com/aws-samples/amazon-bedrock-workshop/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-workshop