langchain-aws: the monorepo replacing LangChain's AWS integrations
Build LangChain Applications on AWS
At a glance
- What is it?
- langchain-aws splits AWS support into three PyPI packages: LangChain integrations, LangGraph checkpointers and stores, and an AgentCore code interpreter sandbox. The README states this repo will replace the AWS integrations currently in langchain-community, so the migration decision is the main thing to weigh.
- Who is it for?
- Adopt langchain-aws if your stack already runs on Bedrock, SageMaker, Kendra or Neptune and you want those integrations maintained outside langchain-community, or if you need a LangGraph checkpointer backed by DynamoDB, Bedrock AgentCore Memory or ElastiCache Valkey. Do not adopt it if you only need one Bedrock chat call and no LangGraph persistence, since that adds three packages to track for no gain.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What langchain-aws is for, and who ends up installing it
The README is explicit about the intent: this monorepo "aims to replace and expand upon the existing LangChain AWS components found in the langchain-community package." That sentence is the whole reason the project exists. AWS integrations that used to live in a single community package now have their own repository, their own release cadence, and their own dependency set. The README goes further and states that the repository "will replace all AWS integrations currently present in the langchain-community package," adding that users are encouraged to migrate as soon as possible.
The audience follows from that. If your application calls Bedrock models, queries a Knowledge Base, indexes into Amazon S3 Vectors or MemoryDB, or persists LangGraph state to DynamoDB, you are the target user. If you build LangGraph agents and need the conversation state to survive a process restart, the checkpointer package is the piece you actually care about. Teams that use AWS only as a deployment target and call an OpenAI-compatible endpoint do not need any of this.
Three packages, three different jobs
The repository hosts three distributions on PyPI, and they are not variations on one theme.
langchain-aws is the integration package. It carries chat and LLM classes for Bedrock and SageMaker endpoints, vector stores for Amazon MemoryDB, Amazon S3 Vectors and ElastiCache for Valkey, retrievers for Amazon Kendra and Knowledge Bases for Amazon Bedrock, components for AWS Neptune graphs, Runnables for Amazon Bedrock Agents, and toolkits for Bedrock AgentCore's built-in tools.
langgraph-checkpoint-aws is the persistence package. It supplies LangGraph checkpointers and memory stores backed by Bedrock AgentCore Memory, Bedrock Session Management, DynamoDB and ElastiCache Valkey. The README points to a separate README inside libs/langgraph-checkpoint-aws for usage examples rather than inlining them, which is worth knowing before you go looking for code samples on the repository front page.
langchain-agentcore-codeinterpreter is the smallest and most specific. It wraps an AgentCore Code Interpreter client as a sandbox backend for Deep Agents, described in the README as enabling "secure code execution in isolated MicroVM environments." Three packages means three version numbers to track, and the release list shows they move independently: langchain-aws==1.7.5 and langgraph-checkpoint-aws==1.2.3 shipped a day apart in early September 2026.
How a Bedrock call actually flows through the integration
The README's usage example is short enough to read as a data flow. You import ChatBedrockConverse from langchain_aws, construct it with a model identifier, and call invoke with a string. The model string in the example is a cross-region inference profile, "us.anthropic.claude-sonnet-4-5-20250929-v1:0", which is the form Bedrock uses when a request is routed across regions rather than pinned to one. Credentials and region are not passed in the constructor here, so boto3's standard resolution chain is what the class relies on.
The return value is a LangChain message object, not raw JSON, which is the point of the wrapper: the Bedrock response is normalized so it can be passed to the rest of a LangChain or LangGraph pipeline without a translation layer.
The AgentCore toolkits show a different shape. create_browser_toolkit and create_code_interpreter_toolkit take a region and return a tuple of a toolkit object and a list of tools. The code interpreter variant is awaited, so it is async-only. The example builds a ReAct agent from the model plus browser_tools + code_tools, invokes it with a config carrying thread_id, and then calls cleanup on both toolkits. That cleanup step is not decorative. The toolkits hold remote AgentCore resources, and leaving them open is a resource leak you will notice on your AWS bill before you notice it in logs.
Installing and running it
Each package installs independently from PyPI:
pip install langchain-aws pip install langgraph-checkpoint-aws pip install langchain-agentcore-codeinterpreter
The README's minimal langchain-aws example needs no configuration keys at all:
from langchain_aws import ChatBedrockConverse model = ChatBedrockConverse(model="us.anthropic.claude-sonnet-4-5-20250929-v1:0") response = model.invoke("Hello! How are you today?") print(response)
The AgentCore example does take a region argument explicitly, region="us-west-2" in both toolkit constructors, so that is the one config value the README pins down. The code interpreter example uses a different entry point, importing CodeInterpreter from bedrock_agentcore.tools.code_interpreter_client, calling start(), passing the interpreter into AgentCoreSandbox, executing "echo hello", and calling stop(). Note that this example imports from the bedrock_agentcore package, not from langchain_aws, so that dependency has to be present separately.
The README does not document environment variables, retry settings, timeout keys or credential configuration for any of the three packages. For anything beyond the snippets above, it defers to the LangChain docs at python.langchain.com/docs/integrations/platforms/aws/.
The migration from langchain-community is the real cost
The README frames migration as a recommendation, but the wording around replacement makes it closer to a deadline whose date is not published. What is not stated anywhere in the supplied material is a mapping table from old langchain_community import paths to new langchain_aws ones. That absence matters more than any feature list here. If your codebase imports Bedrock or Kendra classes from langchain_community, you cannot tell from this README alone which classes have landed in langchain-aws, which are still pending, and which were renamed in the move.
A second gap: the README's feature list covers LLMs, vector stores, retrievers, graphs, agents and tools, but it does not say which of those are feature-complete relative to the community versions. "...and more to come" appears under the feature list, which reads as an admission that the set is still growing. Treat a migration as an inventory exercise first: enumerate every AWS-related import in your code, then confirm each has a counterpart in the new package before you delete the old dependency. Running both packages side by side during the transition is the low-risk path, since nothing in the material suggests they conflict.
Where langchain-aws is the wrong tool
Three cases stand out.
First, if you are not on AWS. Every class in the package targets a named AWS service, and the credentials resolution assumes boto3 conventions. There is no generic HTTP or OpenAI-compatible path here.
Second, if you want a stable interface. The README says the repository "will continue to expand," and the release history shows langchain-aws moving from 1.7.4 to 1.7.5 within a week. Pre-2.0 versioning on a package that is still absorbing integrations means import paths and constructor arguments can shift. If you need a frozen surface for a long-lived service, pinning an exact version is not optional.
Third, if your persistence needs are simple. DynamoDB, ElastiCache Valkey, Bedrock AgentCore Memory and Bedrock Session Management are all managed services with their own operational overhead, IAM surface and cost model. For a single-process agent that does not need to resume across restarts, an in-memory checkpointer is less machinery. The checkpointer package is for teams that have already decided state must outlive the process.
One more limitation worth naming: the README does not document failure behaviour for any of the checkpointers. What happens when DynamoDB throttles, or when an AgentCore Memory write fails mid-graph, is not described in the supplied material.
How it differs from keeping the community integrations
The realistic alternative is not a competing framework. It is staying on the AWS classes inside langchain-community. The difference is one of ownership and release cadence rather than capability.
With langchain-community, AWS integrations ship when that monolith ships, alongside every other vendor's integrations, and bug fixes wait on that shared train. With langchain-aws, the AWS components have their own repository, their own PyPI distributions and their own version numbers, so a Bedrock fix can ship without waiting for unrelated changes. The trade is that you now depend on a smaller, faster-moving package set instead of one large one.
A second alternative, for the narrow case of chat models only, is calling Bedrock directly through boto3 and skipping the LangChain wrapper. You lose message normalization, streaming integration with LangChain callbacks, and the ability to drop the model into a LangGraph node without an adapter. You gain one fewer dependency and full control over the request shape. For a single script that sends one prompt and prints the answer, that is a reasonable trade. For anything with tools, memory or multi-step graphs, the wrapper is doing work you would otherwise write yourself.
Versioning, maintenance and the MIT licence
All three packages are MIT licensed, which permits commercial use and modification with the licence and copyright notice retained. That is a permissive baseline and creates no copyleft obligation on your own code. It says nothing about the AWS services the packages call, which are billed and governed separately, and it says nothing about LangSmith, which the README points to with a tip for developing, debugging and deploying agents. LangSmith is a separate product with its own terms, and nothing in this material indicates it is required to use any of the three packages.
On maintenance cost, the practical burden is the version matrix. langchain-aws, langgraph-checkpoint-aws and langchain-agentcore-codeinterpreter version independently, and each has to stay compatible with your LangChain and LangGraph core versions. The supplied material does not include a compatibility table, so the first thing to establish in a trial is which combination of core and integration versions you are actually running. Pin exact versions in your lockfile, and treat each bump as a change to review rather than a routine refresh. The README's own note that the repository "will replace" the community integrations means the maintenance question is not whether to move, but how much of your current import surface survives the move intact.
Editorial conclusion
Adopt langchain-aws if your stack already runs on Bedrock, SageMaker, Kendra or Neptune and you want those integrations maintained outside langchain-community, or if you need a LangGraph checkpointer backed by DynamoDB, Bedrock AgentCore Memory or ElastiCache Valkey. Do not adopt it if you only need one Bedrock chat call and no LangGraph persistence, since that adds three packages to track for no gain. Before migrating, check which of your current imports come from langchain_community and whether each has an equivalent in langchain-aws, then pin langchain-aws==1.7.5, since the README's own note says the community integrations are on the way out.
Community notes