Get started with Amazon Bedrock AgentCore Runtime direct code deployment
Direct code deployment enables you to bring your Python-based agent to Amazon Bedrock AgentCore Runtime
simply by packaging agent code and its dependencies in a .zip file archive. Your agent still
needs to follow AgentCore Runtime requirements: have an entrypoint .py file that either uses the
@app.entrypoint annotation from Amazon Bedrock AgentCore Python
SDK/invocations POST and /ping GET
server endpoints.
To create your deployment package as .zip file archive, you can use Amazon Bedrock AgentCore starter
toolkitzip tool in a Linux or MacOS environment. To use the same commands
in Windows, you can install the Windows Subsystem for Linux
Note that AgentCore Runtime uses POSIX file permissions, so you may need to set permissions for the deployment package folder
Topics
Prerequisites
Before you start, make sure you have:
-
AWS Account with credentials configured. To configure your AWS credentials, see Configuration and credential file settings in the AWS CLI.
-
Uv
installed and Python 3.10+ installed -
AWS Permissions: To create and deploy an agent with the starter toolkit, you must have appropriate permissions. For information, see Use the starter toolkit.
-
Model access: Anthropic Claude Sonnet 4.0 enabled in the Amazon Bedrock console. For information about using a different model with the Strands Agents see the Model Providers section in the Strands Agents SDK
documentation.
Step 1: Set up project and install dependencies
Initialize your project with the following commands:
uv init agentcore_runtime_direct_deploy --python 3.13 cd agentcore_runtime_direct_deploy
Add core packages:
uv add bedrock-agentcore strands-agents
Add optional packages:
uv add --dev bedrock-agentcore-starter-toolkit
Package descriptions:
-
bedrock-agentcore - The Amazon Bedrock AgentCore SDK for building AI agents
-
strands-agents - The Strands Agents
SDK -
bedrock-agentcore-starter-toolkit - The Amazon Bedrock AgentCore starter toolkit
Optional, uv add aws-opentelemetry-distro, to enable Amazon Bedrock AgentCore observability traces.
Uv will automatically create a pyproject.toml file with
dependencies, uv.lock file with dependency closure and
.venv directory.
Step 2: Create your agent
Create/Edit an entrypoint file for your agent code named main.py.
Add the following code:
from bedrock_agentcore import BedrockAgentCoreApp from strands import Agent app = BedrockAgentCoreApp(debug=True) agent = Agent() @app.entrypoint def invoke(payload): """Your AI agent function""" user_message = payload.get("prompt", "Hello! How can I help you today?") app.logger.info(f"User message: {user_message}") result = agent(user_message) return {"result": result.message} if __name__ == "__main__": app.run()
Step 3: Test locally
Make sure port 8080 is free before starting. See Port 8080 in use (local only) in Common issues and solutions.
Open a terminal window and start your agent with the following command:
uv run main.py
Test your agent by opening another terminal window and enter the following command:
curl -X POST http://localhost:8080/invocations \ -H "Content-Type: application/json" \ -d '{"prompt": "Hello!"}'
Success: You should see a response like
{"result": "Hello! I'm here to help..."}. In the terminal window that's
running the agent, enter Ctrl+C to stop the agent.
Step 4: Enable observability for your agent
Amazon Bedrock AgentCore Observability helps you trace, debug, and monitor agents that you host in AgentCore Runtime. First enable CloudWatch Transaction Search by following the instructions at Enabling Amazon Bedrock AgentCore runtime observability. To observe your agent, see View observability data for your Amazon Bedrock AgentCore agents.
Step 5: Deploy to AgentCore Runtime and invoke
Deploy your agent using one of the following methods:
Step 6: Update or cleanup
Update or cleanup your agent using one of the following methods:
Direct code deployment concepts
Learn about key concepts when using direct code deployment with Amazon Bedrock AgentCore Runtime.
Topics
Amazon Bedrock AgentCore Runtime with direct code deployment uses a shared responsibility model similar to AWS Lambda. AgentCore Runtime manages the Python runtime environment and applies security patches automatically, while you focus on your agent code and dependencies.
If you're using container images to deploy your agents, then AgentCore Runtime is responsible to patch only compute kernel. In this case, you're responsible for rebuilding your agent's container image from the latest secure image and redeploying the container image.
This is summarized in the following table:
| Deployment mode | AgentCore Runtime's responsibility | Your responsibility |
|---|---|---|
| Direct deploy mode |
|
|
| Container image |
|
|
For more information about shared responsibility with AWS, see Shared
Responsibility Model
AgentCore Runtime keeps each direct code deploy runtime up to date with security updates, bug fixes, new features, performance enhancements, and support for minor version releases. These runtime updates are published as runtime versions. AgentCore Runtime applies direct code deploy runtime updates to agents by migrating the agents from an earlier runtime version to a new runtime version.
For direct deploy runtimes, AgentCore Runtime applies runtime updates automatically. With automatic runtime updates, AgentCore Runtime takes on the operational burden of patching the runtime versions. For most customers, this should be a safe choice as only language runtime patches will be automatically applied and customers are responsible to bring and managed their code dependencies. Currently AgentCore Runtime doesn't support changing this automated patching behavior.
AgentCore Runtime strives to provide runtime updates that are backward compatible with existing functions. However, as with software patching, there are rare cases in which a runtime update can negatively impact an existing function. For example, security patches can expose an underlying issue with an existing function that depends on the previous, insecure behavior. If in extremely rare cases this risk is not acceptable, please use container images to deploy your agent.
The following table lists the supported AgentCore Runtime direct code deploy language runtimes and projected deprecation dates. After a language environment is deprecated, you're still able to create and update functions for a limited period. The table provides the currently forecasted dates for runtime deprecation, based on our Runtime deprecation policy. These dates are provided for planning purposes and are subject to change.
| # | Name | Identifier | Operating system | Deprecation date | Block function update |
|---|---|---|---|---|---|
| 1 | Python 3.13 | PYTHON_3_13 |
Amazon Linux 2023 | 6/30/2029 | 8/31/2029 |
| 2 | Python 3.12 | PYTHON_3_12 |
Amazon Linux 2023 | 10/31/2028 | 1/10/2029 |
| 3 | Python 3.11 | PYTHON_3_11 |
Amazon Linux 2023 | 6/30/2026 | 8/31/2026 |
| 4 | Python 3.10 | PYTHON_3_10 |
Amazon Linux 2023 | 6/30/2026 | 8/31/2026 |
Language environment deprecation policy
AgentCore Runtime direct code deploy for .zip file archives are built around a combination of operating system, programming language, and software libraries that are subject to maintenance and security updates. AgentCore Runtime standard deprecation policy is to deprecate a language runtime when any major component of the runtime reaches the end of community long-term support (LTS) and security updates are no longer available. Most usually, this is the language runtime, though in some cases, a runtime can be deprecated because the operating system (OS) reaches end of LTS.
After a runtime is deprecated, AWS may no longer apply security patches or updates to that runtime, and functions using that runtime are no longer eligible for technical support. Such deprecated runtimes are provided 'as-is', without any warranties, and may contain bugs, errors, defects, or other vulnerabilities.
Important
AgentCore Runtime occasionally delays deprecation of a AgentCore Runtime direct code deploy programming language runtime for a limited period beyond the end of support date of the language version that the runtime supports. During this period, AgentCore Runtime only applies security patches to the runtime OS. AgentCore Runtime doesn't apply security patches to programming language runtimes after they reach their end of support date.
Some of the dimensions of comparison to see how one option differs from the other, so it helps to choose the right option
-
Deployment Process: Direct code deployment deploys agents using ZIP files instead of containers, lending itself to faster development iterations.
-
Deployment time: Although there is not much difference during first deployment of an agent, subsequent updates to the agent are significantly faster with direct code deployment.
-
Customization: Direct code supports for custom dependencies through ZIP-based packaging while maintaining deployment simplicity while container based depends on a Docker file.
-
Package size: Direct code deployment limits the package size to 250MB whereas container based packages can be upto 1GB in size.
-
Session creation rate: The direct code deployment allows for higher session creation of 25 new sessions/second compared to 0.16 new sessions/second with container based deployments.
Our general guidance is
-
If the size of the deployment package exceeds 250MB, and you have existing container CI/CD pipelines, and you need highly specialized dependencies and packaging, then container based deployments is a good option to choose.
-
If the size of the deployment package is small, the code and package is not complex to build and uses common frameworks and languages, and you need rapid prototyping and iteration, then direct code deployment would be the option.
There can also be a hybrid option where developers use the direct code deployment to quickly experiment and prototype agents and then switch to container based deployments (for the above reasons) to develop, test and deploy to production.
When you use an import statement in your code, the Python runtime
searches the directories in its search path until it finds the module or package. By
default, the first location the runtime searches is the directory into which your
.zip deployment package is decompressed and mounted
(/var/task).
You can see the full search path for your AgentCore Runtime agent by adding the following code snippet.
import sys search_path = sys.path print(search_path)
You can also add dependencies in a separate folder inside your .zip package. For
example, you might add a version of the Boto3 SDK to a folder in your .zip package
called common. When your .zip package is decompressed and
mounted, this folder is placed inside the /var/task directory.
To use a dependency from a folder in your .zip deployment package in your code, use
an import from statement. For example, to use a version of Boto3 from a
folder named common in your .zip package, use the following
statement.
from common import boto3
We recommend that you don't include __pycache__ folders in
your agent's deployment package. Python bytecode that's compiled on a build machine
with a different architecture or operating system might not be compatible with the
AgentCore Runtime execution environment.
If your function uses only pure Python packages and modules, you can use the
uv pip install command to install your dependencies on any local
build machine and create your .zip file. Many popular Python libraries, including
NumPy and Pandas, are not pure Python and contain code written in C or C++. When you
add libraries containing C/C++ code to your deployment package, you must build your
package correctly to make it compatible with the AgentCore Runtime execution
environment.
Most packages available on the Python Package Index (PyPI
Some packages may only be available as source distributions. For these packages, you need to compile and build the C/C++ components yourself.
To see what distributions are available for your required package, do the following:
-
Search for the name of the package on the Python Package Index main page
. -
Choose the version of the package you want to use.
-
Choose Download files.
If your package is only available as a source distribution, you need to build the C/C++ libraries yourself. To make your package compatible with the Amazon Bedrock AgentCore AgentCore Runtime execution environment, you need to build it in an environment that uses the same Amazon Linux operating system with arm64 instruction set. You can do this by building your package in an Amazon Elastic Compute Cloud (Amazon EC2) Linux instance.
To learn how to launch and connect to an Amazon EC2 Linux instance, see Get started with Amazon EC2 in the Amazon EC2 User Guide.
Common Issues
Common issues and solutions when getting started with the Amazon Bedrock AgentCore starter toolkit. For more troubleshooting information, see Troubleshoot Amazon Bedrock AgentCore AgentCore Runtime.
Permission Issues - Insufficient S3 permissions
When this occurs: During agent creation or update with zipped artifact in S3 via console, SDK, or CLI
Why this happens: The role used to call Create/UpdateAgentRuntime does not have s3:GetObject permissions on S3 uri passed in the API input.
Solution: Add s3:GetObject permission in role used to call the Agentcore Runtime create/update API.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::your-bucket-name/*" } ] }
Permission Issues - CMK Encrypted S3 Object Access
When this occurs: During agent creation with CMK-encrypted S3 objects when the execution role lacks KMS decrypt permissions.
Why this happens: The role used to call Create/UpdateAgentRuntime does not have kms:Decrypt permissions on the CMK used to encrypt the S3 object containing the agent code.
Solution: Add kms:Decrypt permission to the role for the specific CMK:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "kms:Decrypt" ], "Resource": [ "arn:aws:s3:::your-bucket-name/*", "arn:aws:kms:us-west-2:your-account:key/your-cmk-key-id" ] } ] }
Code Package Compatibility Issues
When this occurs: During agent creation or update with incompatible code packages (wrong architecture, Python version, or package format).
Why this happens: The uploaded ZIP file contains binaries compiled for wrong architecture (ARM64 vs x86_64), incompatible Python version, or incorrect package structure that doesn't match AgentCore Runtime requirements.
Solution:
-
Ensure code is compiled for arm64
-
Use compatible Python version (check AgentCore Runtime supported versions)
-
Verify ZIP structure contains proper entry points and dependencies
-
Rebuild packages on compatible runtime environment
Error indicators:
-
Agent status: CREATE_FAILED or runtime errors
-
Import errors or "cannot execute binary file" messages in cloudwatch logs
-
Architecture mismatch errors when you do getAgentRuntimeEndpoint.