DEV Community: Myron Zaiets

Building AI Agents with Amazon Bedrock AgentCore Runtime: A Complete Setup Guide

Myron Zaiets — Tue, 16 Sep 2025 12:25:47 +0000

Building AI Agents with Amazon Bedrock AgentCore Runtime: A Complete Setup Guide

Amazon Bedrock AgentCore Runtime represents a significant leap forward in deploying AI agents at scale. This serverless platform enables developers to run AI agents with extended execution times, session isolation, and built-in observability. In this blog, we'll walk through a complete setup of a Bedrock AgentCore sample application that demonstrates the platform's capabilities.

What is Bedrock AgentCore Runtime?

Bedrock AgentCore Runtime is AWS's serverless container platform specifically designed for AI agents. Unlike traditional serverless functions with strict time limits, AgentCore supports workloads up to 8 hours, making it perfect for complex AI workflows that require extended processing time.

Key Features

Extended Execution: Up to 8-hour workloads for complex AI tasks
Session Isolation: Each user session runs in a dedicated microVM
Framework Agnostic: Compatible with LangGraph, Strands, CrewAI, or custom frameworks
Model Flexibility: Works with any LLM (Bedrock, OpenAI, etc.)
Built-in Observability: Integrated CloudWatch monitoring

Architecture Overview

The sample application consists of three main components:

CDK Infrastructure Stack: Creates ECR repository and IAM execution roles
AI Agent Runtime: Containerized agent using the Strands framework
Memory Integration: Bedrock Memory for conversation continuity

┌─────────────────┐    ┌──────────────────┐    ┌─────────────────┐
│   CDK Stack     │    │  AgentCore       │    │  Bedrock        │
│                 │    │  Runtime         │    │  Memory         │
│ • ECR Repo      │───▶│                  │───▶│                 │
│ • IAM Roles     │    │ • Agent Container│    │ • Session Store │
│ • Permissions   │    │ • Strands Agent  │    │ • Context       │
└─────────────────┘    └──────────────────┘    └─────────────────┘

Prerequisites

Before starting, ensure you have:

AWS CLI configured with appropriate credentials
Node.js 18+ and npm
Python 3.10+
AWS CDK v2 installed globally: npm install -g aws-cdk
Docker (optional, for local testing)

Required AWS Permissions

Your AWS credentials need these permissions:

bedrock-agentcore:*
iam:CreateRole, iam:AttachRolePolicy
ecr:CreateRepository
cloudformation:*
logs:*

Also, you would have to enable Claude 4 model in your region:

Infrastructure Setup with CDK

The CDK stack creates the necessary AWS resources:

ECR Repository

const agentRepository = new ecr.Repository(this, 'AgentRepository', {
  repositoryName: 'bedrock-agentcore-sample',
  removalPolicy: cdk.RemovalPolicy.DESTROY,
});

IAM Execution Role

const executionRole = new iam.Role(this, 'AgentCoreExecutionRole', {
  assumedBy: new iam.ServicePrincipal('bedrock-agentcore.amazonaws.com'),
  inlinePolicies: {
    AgentCorePolicy: new iam.PolicyDocument({
      statements: [
        new iam.PolicyStatement({
          actions: [
            'bedrock:InvokeModel',
            'bedrock-agent:CreateEvent',
            'bedrock-agent:GetMemory',
            'logs:CreateLogGroup',
            // ... additional permissions
          ],
          resources: ['*'],
        }),
      ],
    }),
  },
});

Agent Implementation

The core agent uses the Strands framework with Bedrock Memory integration:

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent
import boto3

app = BedrockAgentCoreApp()
agent = Agent()

@app.entrypoint
def invoke(payload):
    user_message = payload.get("prompt", "Hello!")
    session_id = "custom-session-12345678901234567890123"

    # Memory integration for conversation continuity
    memory_client = boto3.client('bedrock-agent', region_name='eu-central-1')

    # Store user message and retrieve context
    # Get agent response with enhanced context
    # Store agent response for future context

    return {"result": result.message, "sessionId": session_id}

Deployment Process

The deployment is automated through a Python script that handles both infrastructure and agent deployment:

1. Infrastructure Deployment

npm install
npx cdk bootstrap --region eu-central-1
npx cdk deploy

2. Agent Deployment

cd agent
pip install bedrock-agentcore strands-agents bedrock-agentcore-starter-toolkit
agentcore configure -e my_agent.py --region eu-central-1
agentcore launch

3. Once deployed, you will see the runtime in AgentCore interface:

Configuration Details

The agent configuration is managed through .bedrock_agentcore.yaml:

default_agent: my_agent
agents:
  my_agent:
    name: my_agent
    entrypoint: my_agent.py
    platform: linux/arm64
    aws:
      region: eu-central-1
      network_configuration:
        network_mode: PUBLIC
      observability:
        enabled: true

Memory Integration

One of the standout features is the integration with Bedrock Memory for conversation continuity:

# Store conversation events
memory_client.create_event(
    memoryId=MEMORY_ID,
    actorId=ACTOR_ID,
    sessionId=session_id,
    eventTimestamp=datetime.utcnow(),
    payload={"message": user_message, "role": "user"}
)

# Retrieve conversation context
memory_response = memory_client.get_memory(
    memoryId=MEMORY_ID,
    actorId=ACTOR_ID,
    sessionId=session_id
)

Testing Your Agent

Once deployed, test your agent:

cd agent
agentcore invoke '{"prompt": "What can you help me with?"}'

Bonus deployment

Let's quickly add CloudFront and Api Gateway with Lambda that will call this agent:

Lambda looks like:


import json
import boto3
import uuid
from datetime import datetime

def handler(event, context):
    try:
        # Parse request
        body = json.loads(event['body'])
        prompt = body.get('prompt', '')

        # Create AgentCore client (same region)
        client = boto3.client('bedrock-agentcore', region_name='eu-central-1')

        # Generate consistent session ID (same as agent uses)
        session_id = 'custom-session-12345678901234567890123'

        # Call AgentCore Runtime
        payload = json.dumps({"prompt": prompt})

        response = client.invoke_agent_runtime(
            agentRuntimeArn='arn:aws:bedrock-agentcore:eu-central-1:{accountId}:runtime/my_agent-{customString}',
            runtimeSessionId=session_id,
            payload=payload,
            qualifier="DEFAULT"
        )

        # Parse response
        response_body = b''.join(response['response']).decode('utf-8')
        response_data = json.loads(response_body)

        return {
            'statusCode': 200,
            'headers': {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*',
                'Access-Control-Allow-Methods': 'POST, OPTIONS',
                'Access-Control-Allow-Headers': 'Content-Type'
            },
            'body': json.dumps({
                'response': response_data['result']['content'][0]['text'],
                'sessionId': session_id
            })
        }

    except Exception as e:
        print(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'headers': {
                'Content-Type': 'application/json',
                'Access-Control-Allow-Origin': '*'
            },
            'body': json.dumps({'error': str(e)})
        }

Api Gateway definition:

I also added CloudFront with S3 as OAC origin. So once visiting our CloudFront url we can see:

Let's test the memory:

Now I open another tab and ask about my name:

Best Practices for Production

Security

Use least privilege IAM policies
Implement proper session management
Enable CloudWatch logging for monitoring

Performance

Configure appropriate memory and CPU limits
Use ARM64 platform for cost optimization
Implement proper error handling and retries

Monitoring

Enable observability in agent configuration
Set up CloudWatch alarms for error rates
Monitor execution duration and costs

Cleanup

To remove all resources:

npx cdk destroy
# Delete the AgentCore Runtime from console or CLI

Conclusion

Bedrock AgentCore Runtime provides a powerful platform for deploying AI agents with enterprise-grade features. The combination of extended execution times, session isolation, and built-in observability makes it ideal for complex AI workflows.

The sample application demonstrates how to:

Set up infrastructure with CDK
Deploy agents with memory integration
Implement conversation continuity
Monitor and observe agent performance

This setup provides a solid foundation for building production-ready AI agents that can handle complex, long-running tasks while maintaining conversation context across sessions.

For more details, refer to the AWS Bedrock AgentCore Documentation.

AWS CloudFormation Git Sync

Myron Zaiets — Thu, 18 Jan 2024 18:01:25 +0000

Infrastructure as Code (IaC) has become the cornerstone of modern cloud management, empowering developers and DevOps teams to declaratively define and provision their cloud resources. CloudFormation is a leading IaC tool from Amazon Web Services (AWS), enabling you to define your infrastructure in templates and then automate its deployment and management. However, maintaining and updating these templates can be a time-consuming and error-prone task.

CloudFormation allows you to sync with your Git repo now, so there is no need for manual deployments, your infrastructure always reflects the latest version of your code.

Let’s speak about the benefits of Git Sync:

Continuous Deployment for Infrastructure: Automate the deployment of your infrastructure changes with every commit or pull request to your Git repository.

Improved Collaboration and Version Control: Leverage the power of Git for collaboration and version control.

Simplified Infrastructure Management: Automate infrastructure updates and reduce the burden of manual deployments. You don’t need GitHub Action to deploy to AWS.

Let’s start with Git Sync:

Create a Git Repository: Initialize a new Git repository to store your CloudFormation templates.

Configure CloudFormation Git Sync.

Create a CloudFormation Stack.

Deploy Infrastructure Changes: Commit your changes to your Git repository, and CloudFormation Git Sync will automatically deploy the updated infrastructure.

Let’s discuss the points 2 and 3.

Configuring Git SYNC in CloudFormation

Firstly, you need to create a connection. As you can see, there are several repository providers.

Once the connection is ready, you need 2 roles:

The role is to update the stack from Git. Use this link to create a role: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/git-sync-prereq.html

CF role to interact with AWS resources. You can add an admin policy just for testing purposes.

Once roles are ready, let’s create a stack:

As you can see, the Git sync status is enabled. My deployment-file.yaml looks this way:

So Git will constantly monitor changes in vpc.yaml file. Let’s add some SG to our template:

Now, CF after a few seconds after commit will create a changeset:

Finally, we will check a template in CF console, our template is updated and SG was successfully created:

Conclusion

CloudFormation Git Sync is a valuable tool for streamlining your infrastructure automation and deployment processes. By integrating your CloudFormation templates with your Git repository, you can automate infrastructure updates, improve collaboration, and simplify infrastructure management. Embrace the power of continuous deployment for your infrastructure and experience the benefits of enhanced agility and reduced risk.

Thank you for your time.

Cheers!

ECS Exec (AWS Fargate)

Myron Zaiets — Fri, 05 Jan 2024 16:21:30 +0000

Use of ECS Exec feature

Hi,

When using ECS, sometimes you will want to debug your app by trying to connect to it.

ECS Exec is an Amazon Elastic Container Service (ECS) feature that allows you to execute commands in or get a shell to a container running on an Amazon EC2 instance or AWS Fargate. This makes it easier to collect diagnostic information and quickly troubleshoot errors.

Prerequisites

An ECS cluster
A task running in the cluster
An IAM role with permissions to execute commands in containers

Example Use Cases

ECS Exec can be used for a variety of purposes, including:

Debugging container applications
Collecting diagnostic information
Installing packages
Running scripts
Additional Considerations

When using ECS Exec, it is important to be aware of the following:

The IAM role used to execute the command must have the necessary permissions to execute commands in the container.

The container must be running in a state that allows execution. For example, the container must not be stopped or terminated.

The container must be running on a compatible infrastructure. For example, the container must run on an Amazon EC2 instance or AWS Fargate.

ECS Exec is not currently supported using the AWS Management Console.

There is a beneficial tool where you can check prerequisites — https://github.com/aws-containers/amazon-ecs-exec-checker

Additional info you can find here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html

Once you have all IAM permissions, and you install the session manager plugin, we can try to connect to the ECS task.

Use AWS CLI and try this command:



aws ecs create-service \
    --cluster YOUR_CLUSTER_NAME \
    --task-definition TASK_DEFINITION_NAME \
    --enable-execute-command \
    --launch-type FARGATE \
    --service-name SERVICE_NAME\
    --desired-count 1 \
    --region eu-west-1 \
    --network-configuration "awsvpcConfiguration={subnets=[SUBNET_NAME],securityGroups=[SG_NAME],assignPublicIp=ENABLED}"

Let’s check the ECS console now:

As you can see, our task is running, so now we can connect to a container.

Now we run the execute statement:



aws ecs execute-command --cluster YOUR_CLUSTER_NAME \
    --task 69e2ecb626944671b9ad9c5199d911ef \
    --container CONTAINER_NAME \
    --interactive \
    --command "/bin/sh"

You will see this output, so now you can communicate with a container:

- If you’ve already created an ECS Service, but want to enable the ECS exec command you can do this also, using this command:



aws ecs update-service SERVICE_NAME --cluster YOUR_CLUSTER_NAME \
  --enable-execute-command \
  --force-new-deployment

That’s all.

Now you can debug your apps by using the ECS exec feature.

Thank you for your time.