DEV Community: Matias Kreder

OpenClaw on AWS Bedrock AgentCore: Secure and Serverless

Matias Kreder — Sun, 08 Mar 2026 13:54:36 +0000

Intro

This week AWS released an offering to run OpenClaw in Lightsail
That was a great announcement, and the community was very excited about this feature (Including myself).

While this is super easy to deploy, it requires the instance to be up and running (spending) the entire month. OpenClaw is a great open source product, but its security posture is a concern for many users. AWS Hero Gerardo Castro Arica did a great analysis on the security aspects of this Lightsail implementation. Bottom line, it is heading in the right direction, but it needs some extra steps to secure it.

But guess what? Lightsail is not the only way to run OpenClaw in AWS, there is another "more secure/serverless" way to run OpenClaw in AWS: Using Bedrock AgentCore.

A team of AWS Engineers released this repo that contains the resources to set up everything. It uses CDK to deploy the entire thing. This is not as simple as the Lightsail approach, but ok for users who are familiar with CLI tools (Yes, Kiro/Claude Code can read the instructions and do the deploy themselves)

Architecture

S3 Workspace Sync
AgentCore microVMs are ephemeral by design (They spin up on demand and disappear when idle)
The problem is that OpenClaw stores everything it knows about a user on the local filesystem under .openclaw/ (conversation memory, user profiles, agent configuration, tool outputs). Without a persistence strategy, all of that evaporates the moment a session ends.
The solution is a lightweight S3-backed sync layer built into the container:
When the session starts, the contract server restores the user's .openclaw/ directory from S3 before OpenClaw initializes, giving the agent full context as if the previous session never ended.
Every 5 minutes: a background timer pushes the workspace back to S3, protecting against unexpected failures mid-session.
On shutdown (SIGTERM): a final save runs within AgentCore's 15-second grace window, capturing everything from the session before the microVM terminates.

Security
Network: AgentCore containers run in private VPC subnets with no direct internet exposure. All AWS service traffic routes through VPC endpoints (S3, Bedrock, Secrets Manager, ECR, DynamoDB, STS, CloudWatch). The only public entry point is the API Gateway HTTP API.
Webhook authenticatin: Every inbound webhook is cryptographically validated before any processing occurs. Telegram uses a secret token registered via setWebhook; Slack uses HMAC-SHA256 signature validation with a 5-minute replay window. Both are fail-closed — requests are rejected if secrets aren't configured.
Per-user isolation: Each user runs in their own AgentCore microVM with a dedicated S3 namespace. There is no shared state between users, and namespace assignment is system-controlled — it cannot be influenced by user input.
STS session-scoped credentials: The container assumes its IAM role with a session policy that restricts S3 and DynamoDB access to the current user's namespace and records. Even if a user somehow gained shell access to the container, they couldn't read another user's data.
Secret management: All sensitive values (bot tokens, webhook secrets, Cognito credentials) live in Secrets Manager encrypted with a customer-managed KMS key, fetched at runtime into process memory.
Tool hardening: OpenClaw's read tool is blocked to prevent credential access via /proc or local file reads. The exec tool is allowed for skill management, but the scoped STS credentials limit blast radius. The proxy is bound to loopback only, and security group egress is restricted to HTTPS.
Container hardening: The bridge runs as a non-root user (openclaw, uid 1001). Request bodies are capped at 1 MB. Internal error details and stack traces are never surfaced in API responses.
Encryption: Everything is encrypted at rest (S3 and Secrets Manager with CMK, DynamoDB with AWS-managed keys) and in transit (TLS for all AWS API calls, HTTPS on API Gateway).
Least-privilege IAM: Each component has tightly scoped permissions. The Router Lambda can only invoke its specific AgentCore Runtime.

Instructions

Clone repo

git clone https://github.com/aws-samples/sample-host-openclaw-on-amazon-bedrock-agentcore.git
cd sample-host-openclaw-on-amazon-bedrock-agentcore

# Set your AWS account and region
export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
export CDK_DEFAULT_REGION=us-east-1  # change to your preferred region

Install Python dependencies

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

Bootstrap CDK

cdk bootstrap aws://$CDK_DEFAULT_ACCOUNT/$CDK_DEFAULT_REGION

Deploy all stacks

cdk synth          
cdk deploy --all --require-approval never

Build OpenClaw container image

# Authenticate Docker to ECR
aws ecr get-login-password --region $CDK_DEFAULT_REGION | \
  docker login --username AWS --password-stdin \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com

# Read version from cdk.json for versioned image tags
VERSION=$(python3 -c "import json; print(json.load(open('cdk.json'))['context']['image_version'])")

# Build ARM64 image (required by AgentCore Runtime)
docker build --platform linux/arm64 -t openclaw-bridge:v${VERSION} bridge/

# Tag and push
docker tag openclaw-bridge:v${VERSION} \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com/openclaw-bridge:v${VERSION}
docker push \
  $CDK_DEFAULT_ACCOUNT.dkr.ecr.$CDK_DEFAULT_REGION.amazonaws.com/openclaw-bridge:v${VERSION}

Create a bot on Telegram a. Message @botfather on Telegram b. Create a new bot with /newbot c. Copy the bot token
Store your telegram token

aws secretsmanager update-secret \
  --secret-id openclaw/channels/telegram \
  --secret-string 'YOUR_TELEGRAM_BOT_TOKEN' \
  --region $CDK_DEFAULT_REGION

Run telegram setup script to add yourself to the allowlist:
Start using openclaw, the first run takes a few minutes, but subsequent iterations are faster. If something fails, check AgentCore logs.

./scripts/setup-telegram.sh

Conclusion

The solution is nice, it works pretty well. However, I found a few things that you may need to consider:

This solution deploys an entirely new VPC including a NAT gateway. The NAT gateway cost (around 32 USD/month) is pricier than a Lightsail OpenClaw instance, but this architecture could be modified to reuse an existing VPC, or it could host multiple agents. (Not a great deal for a single instance)
There are a few things that didn't work for me, and I had to fix them: Hardcoded region configurations, DynamoDB API deprecation warnings, an IAM role circular dependency issue, and availability zones need to be configurable as some AZs don't support AgentCore yet (surprisingly). Submitted a PR
You can change the solution to use Nova Pro (I have some AWS credits that don't cover Claude spend, so I had to switch, and it works pretty well)

Want to try it? This is the GitHub Repo

How I used Amazon Q CLI to fix Amazon Q CLI error "Amazon Q is having trouble responding right now"

Matias Kreder — Thu, 17 Jul 2025 17:57:41 +0000

I know what you are thinking. I've just used Amazon Q CLI in the title 3 times. No regrets!

I recently ran into an annoying issue while using the Amazon Q Developer CLI. Every now and then, I'd get this frustrating error message over and over: "Amazon Q is having trouble responding right now.". This errors got more frequent after the Kiro announcement. The CLI would just give up immediately, forcing me to manually retry the command.

The error (technically a ModelOverloadedError) occurs when there's high traffic or resource constraints on AWS's end. There is a GitHub issue already reported.

Easy Solution
Just use /model to switch to Claude 3.7 or 3.5, which may not have capacity constraints. If you still need to use Claude 4, keep reading.

My Solution
I cloned the Amazon Q CLI repo and asked Q CLI to implement a retry mechanism with exponential backoff to automatically handle these temporary overloads:

Attempts the request up to 10 times before giving up
Uses exponential backoff starting at 500ms (doubling with each retry)
Adds random jitter to prevent "thundering herd" problems
Provides debug logs to track retry attempts

The core implementation looks like this:

if is_model_unavailable {
    if attempt > MAX_RETRIES {
        debug!("Model Overloaded: Maximum retry attempts ({}) reached", MAX_RETRIES);
        return Err(ApiClientError::ModelOverloadedError {
            request_id: err
                .as_service_error()
                .and_then(|err| err.meta().request_id())
                .map(|s| s.to_string()),
            status_code,
        });
    }

    // Calculate exponential backoff with jitter
    let backoff_ms = INITIAL_BACKOFF_MS * 2u64.pow(attempt - 1);
    let jitter = rand::random::<u64>() % (backoff_ms / 4); // Add up to 25% jitter
    let sleep_duration = Duration::from_millis(backoff_ms + jitter);

    debug!(
        "Model overloaded. Retrying attempt {}/{} after {}ms",
        attempt, MAX_RETRIES, sleep_duration.as_millis()
    );

    tokio::time::sleep(sleep_duration).await;
    continue;
}

I reviewed each line of the modified code, ran all the automated tests and tested the new version myself. The retry mechanism works.

Conclusion
This fix significantly improves the user experience by reducing frustration: Users don't have to manually retry when the service is temporarily overloaded. I've submitted this as a PR to the Amazon Q Developer CLI repository, and I hope it gets merged soon. In the meantime, if you're experiencing this issue, you can clone my repo and build Q cli with the fix. This is not a definitive fix. AWS needs to probably work on their model availability so it doesn't continue to occur, but at least the retry mechanism makes the developer experience a lot better.

Three Ways to Build Multi-Agent Systems on AWS

Matias Kreder — Sun, 06 Jul 2025 17:05:04 +0000

When building multi-agent AI systems, the architectural choices you make can dramatically impact performance, maintainability, and scalability. While Strands Agent is the "shiny new thing", we need to ask whether it’s always the best choice.

I set out to test different multi-agent architectural patterns by building the same system three different ways on AWS. I chose an HR Agent to evaluate resumes because it provides a perfect multi-step workflow that requires different types of AI reasoning and coordination.

The goal wasn’t to build the perfect HR system, but to understand the trade-offs between different multi-agent orchestration approaches.
I needed a use case that would effectively showcase different multi-agent coordination patterns. HR resume evaluation turned out to be ideal because it requires:

Multiple specialized tasks that benefit from different AI reasoning approaches (we could even use different LLM versions/providers)
Sequential and parallel processing opportunities
Complex data transformation from unstructured to structured formats
Coordination between agents with different areas of expertise
Real-world complexity without being overly domain-specific

The system needs to:

Parse resumes and extract structured information
Analyze job requirements and match them against candidates
Identify skill gaps and areas for development
Rate candidates numerically with detailed justification
Generate interview questions tailored to each candidate
Store everything in a structured, queryable format

Think of it as multiple AI specialists collaborating like a hiring committee, but the real focus is on how they coordinate and communicate.

Architecture #1: Step Functions – The Orchestrated Pipeline

Best for: Complex workflows with detailed monitoring needs and low latency

The Step Functions approach treats resume evaluation like a manufacturing pipeline. Each step is a specialized Lambda function that performs one specific task, with AWS Step Functions orchestrating the entire workflow.

Why I Love This Approach

Low Latency: Provides is a tiny lightweight agent management layer that reduces complexity and processing time.
Crystal clear workflow: You can see each step executing in the AWS console
Easy debugging: When something breaks, you know exactly which step failed
Granular monitoring: Each function can be optimized independently
Familiar patterns: While most developers wont consider StepFunctions to build an AI agent, it is a good fit because many of them are familiar with this tool.

The Trade-offs

More infrastructure: 6+ Lambda functions to manage
State management: Data flows between functions via JSON
Less flexibility: The workflow is relatively rigid

Perfect for: Low latency workflows and teams that want predictable, monitorable workflows and don't mind managing multiple functions.

Architecture #2: Bedrock Agents – The AI-Native Approach

Best for: AI-first teams who want Amazon's managed AI collaboration

This approach uses Amazon Bedrock Agents with a supervisor-collaborator pattern. A supervisor agent coordinates with specialized agents (Resume Parser, Job Analyzer, Skills Evaluator, etc.) to complete the evaluation.

Why This Feels Like the Future

AI-native design: Built specifically for multi-agent AI workflows
Managed complexity: Amazon handles agent coordination and communication
Rich agent interactions: Agents can have sophisticated conversations
Built-in monitoring: Bedrock console shows agent traces and interactions

The Reality Check

AWS-specific: You're locked into Amazon's agent framework
Learning curve: New concepts and debugging approaches
Cost considerations: Bedrock usage can add up with complex workflows

Perfect for: Teams building AI-first applications that want to leverage Amazon's managed AI services.

Architecture #3: Strands Agents – The Powerhouse Framework

Best for: Maximum flexibility and advanced multi-agent capabilities

The Strands approach uses the open-source Strands Agents SDK, where agents communicate in natural language and dynamically adapt their collaboration patterns. While it takes longer to process, this is where the real multi-agent magic happens. I initially used Lambda to deploy this agent by I recently updated it to Bedrock Agentcore.

What Makes This Special

Natural communication: Agents talk to each other like humans
Adaptive workflows: The system adjusts based on what it finds
Deep dives: Extended processing time enables sophisticated reasoning
Framework agnostic: Not tied to any specific cloud provider
Simplified architecture: Typically runs on a Lambda function or an ECS task

The Hidden Power

We're only using a fraction of Strands' capabilities in this implementation. The framework supports:

Dynamic tool integration during runtime
Complex multi-agent negotiations and decision-making
Adaptive workflow modification based on intermediate results
Advanced memory and context management across agent interactions
Custom agent personalities and specialized reasoning patterns

The Considerations

Longer processing: Takes 5–15 minutes, but enables deeper analysis. Not a good choice if you want to build a low-latency agent.
More complex setup: Requires proper dependency management and layer configuration
Resource intensive: Needs more memory and processing time
Learning curve: Understanding the full framework takes time

Perfect for: Teams that want to push the boundaries of multi-agent systems and are comfortable with complexity.

The Results: Architecture Matters More Than You Think

What surprised me most: all three approaches produce identical evaluation quality when using the same prompts and AI model.

The real differences are in:

Development experience and debugging
Operational complexity and monitoring
Processing time and resource utilization
Flexibility for future changes and integrations
Vendor lock-in and LLM portability

LLM Flexibility: A Critical Consideration

One of the most important components is LLM portability.

Strands and Step Functions: LLM Agnostic

Both implementations can easily pivot to different LLMs:

OpenAI GPT models via API calls
Anthropic Claude via direct API
Open-source models like Llama, Mistral, or custom fine-tuned models
Local models running on your infrastructure

This flexibility allows you to choose the best model for your use case, optimize costs, or even run workloads offline.

Bedrock Agents: AWS Ecosystem Limitation

The Bedrock Agents implementation is tied to AWS-supported models:

Limited to the Bedrock catalog – can't use models AWS doesn't support
Regional limitations based on model availability
Manual guardrail configuration you must explicitly set up guardrails, unlike other platforms which enforce some defaults automatically

This flexibility gap becomes crucial for:

Cost optimization across providers
Performance tuning with specialized models
Future-proofing against vendor changes or pricing shifts

Performance Comparison

Aspect	Step Functions	Bedrock Agents	Strands Agents
Processing Time	< 1 minute	2–5 minutes	2-5 minutes minutes*
Setup Complexity	Medium	Low	High
Debugging	Excellent	Not Great	Good
Multi-Agent Flexibility	Low	Medium	Very High
LLM Portability	High	Low	High
Cost	Low	Medium	Medium
Architecture Complexity	High	Medium	Low

*Strands' longer processing time enables sophisticated multi-agent reasoning that we're not fully utilizing in this implementation.

Real-World Lessons Learned

1. Architecture choice impacts more than performance

The biggest differences aren't in output quality, but in operational characteristics, vendor flexibility, and future extensibility.

2. Strands is a sleeping giant

We’re using maybe 30% of what Strands can do. The framework supports dynamic tool integration, complex agent negotiations, and adaptive workflows.

3. Bedrock Agents trade flexibility for simplicity

Great for getting started quickly, but debugging issues when something fails is hard.

4. Step Functions remain the reliable choice

When you need low-latency, predictable, debuggable workflows and don't mind managing multiple functions, it's hard to beat.

Which Multi-Agent Architecture Should You Choose?

Choose Step Functions if:

You want low-latency, predictable, monitorable workflows
Your team is comfortable with traditional serverless patterns
You need fast processing times and clear debugging
LLM flexibility is important for your use case
You prefer proven, stable architectural patterns

Choose Bedrock Agents if:

You're building AI-first applications within the AWS ecosystem
You want Amazon to handle multi-agent complexity
You're already using other Bedrock services
You prefer managed services over custom implementations

Choose Strands Agents if:

You need maximum multi-agent capabilities and flexibility
You want to explore cutting-edge AI coordination patterns
LLM portability and vendor independence are priorities
You're okay with longer processing times for deeper reasoning
You just want your agent to run with no cloud configuration using an AWS cli tool (agentcore)

The Code

All three implementations are available in my AWS Agents repository, including complete deployment scripts, sample data, and documentation. Each approach includes:

Complete SAM templates for one-click deployment
Sample resumes and job descriptions for testing
Comprehensive monitoring and logging
Identical evaluation quality across all approaches

Sample Output

All three implementations store the outputs in DynamoDB. A sample output looks like this:

{
  "id": "a5ec67f5-3e3f-4db3-8e68-d7127b9131f3",
  "name": "Sarah Smith Data Scientist.Txt",
  "resume_key": "resumes/sarah_smith_data_scientist.txt",
  "status": "completed",
  "job_title": "AI Engineer Position",
  "completed_at": "2025-06-29T18:05:58.708418",

  "candidate_rating": {
    "rating": 2,
    "job_fit": "Sarah would be a fair fit for a junior or mid-level AI engineering role but does not meet the requirements for the senior position. Her statistical background and basic ML experience provide a foundation to build upon, but she would need significant mentoring and development in deep learning, MLOps, containerization, and production deployment before being ready for a senior AI Engineer role.",
    "strengths": [
      "Strong educational background in Statistics and Mathematics with ML coursework",
      "Solid foundation in Python programming and data analysis",
      "Experience with basic ML algorithms and statistical modeling",
      "Some database knowledge (PostgreSQL) as required",
      "Collaborative experience working with product teams",
      "Good data visualization skills that would be useful for stakeholder communication"
    ],
    "weaknesses": [
      "Insufficient experience (2 years vs. required 3+ years)",
      "Limited experience with required deep learning frameworks (only project-level TensorFlow, no PyTorch)",
      "No experience with containerization (Docker, Kubernetes) or MLOps practices",
      "Limited cloud platform expertise beyond basic AWS knowledge",
      "No production-level AI system deployment experience",
      "Lack of experience with big data technologies (Spark, Hadoop)",
      "No demonstrated experience in model monitoring or CI/CD pipelines"
    ]
  },

  "evaluation_results": {
    "job_match_analysis": {
      "overall_fit": "Partial match - Junior to mid-level candidate applying for senior role",
      "recommendation": "Consider for a mid-level AI Engineer position rather than senior role. The candidate shows promise but lacks the depth of experience and technical breadth required for a senior position. Would benefit from mentorship and exposure to production ML systems, containerization, and MLOps practices."
    },
    "technical_expertise": {
      "programming": {
        "alignment": "Partial match - Strong in Python and SQL as required, but no Java",
        "depth": "Moderate - 2 years professional experience with Python"
      },
      "ml_frameworks": {
        "alignment": "Partial match - Experience with Scikit-learn but limited exposure to TensorFlow and no PyTorch mentioned",
        "depth": "Basic - Primary experience with traditional ML algorithms rather than deep learning"
      },
      "cloud_platforms": {
        "alignment": "Minimal match - Only basic AWS knowledge mentioned",
        "depth": "Limited - Only mentions S3 and EC2, no SageMaker or other ML-specific services"
      }
    }
  },

  "gaps_analysis": {
    "skill_mismatches": {
      "issues": [
        "Claims to be a Machine Learning Engineer but experience seems more aligned with Data Analyst/Scientist role",
        "Lists TensorFlow in project but not in skills section",
        "Claims 'Basic AWS knowledge' but doesn't demonstrate cloud implementation experience"
      ]
    },
    "overall_concerns": {
      "potential_under_qualification": "Limited professional experience (2 years) for roles requiring more extensive background. Experience appears more aligned with junior data scientist rather than machine learning engineer positions."
    }
  },

  "interview_notes": {
    "technical_questions": [
      "Can you walk me through your experience with TensorFlow beyond the stock price prediction project? What specific neural network architectures have you implemented?",
      "How would you approach deploying a machine learning model to a production environment? What tools and practices would you use for model monitoring and maintenance?",
      "What experience do you have with containerization technologies like Docker and Kubernetes? How have you used them in ML workflows?"
    ],
    "concerns_to_address": [
      "Experience gap (2 years vs. required 3+ years for senior role)",
      "Limited experience with deep learning frameworks beyond project work",
      "No demonstrated experience with containerization or MLOps",
      "Limited cloud platform expertise beyond basic AWS services"
    ],
    "general_notes": [
      "Candidate has strong educational background but lacks senior-level experience",
      "Consider for mid-level position rather than senior role",
      "Strong in statistics and traditional ML but gaps in deep learning and MLOps",
      "Would benefit from mentorship in production ML systems and DevOps practices"
    ]
  }
}

Conclusion

The future of multi-agent AI systems is incredibly exciting. After testing these three approaches, I'm convinced that the choice of coordination pattern matters more than the specific use case. Whether you're building HR automation, document processing, or any other multi-step AI workflow, these patterns offer strong foundations for production-ready systems.

The key takeaway? Each architecture comes with trade-offs that go far beyond performance. Step Functions is not an obvious choice, but it is a highly reliable approach for orchestrating multi-agent flows, especially when clarity and debugging are important. Bedrock Agents provide a managed experience that is great for fast prototyping, although troubleshooting can be difficult when issues arise. Strands offers unmatched reasoning and flexibility, but its longer processing time and higher resource requirements often lead to running it in ECS, where scaling may become a different challenge.

Bottom line, choosing the right approach is not just about the technology itself; it is about how much control, flexibility, and complexity your team is prepared to handle.

How to Solve dependencyFailedException on a Multi-Agent in AWS Bedrock

Matias Kreder — Sat, 28 Jun 2025 21:38:41 +0000

When working with AWS Bedrock Multi-Agent configurations, you might encounter an error message similar to this:

An error occurred (dependencyFailedException) when calling the InvokeAgent operation: Dependency resource: received model timeout/error exception from Bedrock. Try the request again.

This occurred when invoking the agent with the following call:

response = bedrock_agent_runtime.invoke_agent(
    agentId=agent_id,
    agentAliasId=agent_alias_id,
    sessionId=session_id,
    inputText=agent_input,
)

To investigate this issue, I added enableTrace=True to the previous call. This provided deeper insights into the problem:

{
    "agentAliasId": "BJIGGB72UG",
    "agentId": "DMMRLXVFLT",
    "agentVersion": "5",
    "callerChain": [
        {
            "agentAliasArn": "arn:aws:bedrock:us-east-1:479047237979:agent-alias/DMMRLXVFLT/BJIGGB72UG"
        }
    ],
    "sessionId": "89ec67ae-132a-4ecd-9182-ffef774cea68",
    "trace": {
        "failureTrace": {
            "failureReason": "Dependency resource: received model timeout/error exception from Bedrock. Try the request again.",
            "traceId": "4d5612ec-5f45-4797-94bb-c6f2b6276de6-0"
        }
    }
}

While this trace didn’t explicitly identify the root cause, it became clear that the issue related to model performance and the specific Bedrock foundational model used in a collaborator agent within the multi-agent setup.

According to the AWS documentation, the dependencyFailedException means:

"There was an issue with a dependency. Check the resource configurations and retry the request."

This definition is somewhat unclear and generic, and in this specific scenario, it wasn't actually a configuration issue but rather a performance limitation in the selected foundational model.

Solution

Switching from Amazon Nova Pro to Claude Sonnet 3.7 resolved the issue entirely. The request started working smoothly after this change.

Steps to Fix:

Enable tracing in your agent invocation to gather detailed error context:

response = bedrock_agent_runtime.invoke_agent(
    agentId=agent_id,
    agentAliasId=agent_alias_id,
    sessionId=session_id,
    inputText=agent_input,
    enableTrace=True
)

Analyze the trace logs provided by the Bedrock runtime.

Change the underlying foundation model used by the collaborator agent (e.g., switch from Amazon Nova Pro to Claude Sonnet 3.7).

Conclusion

This experience highlights how model selection within a multi-agent configuration can significantly impact stability and performance. Importantly, even though the error indicates a dependencyFailedException, it doesn't necessarily mean a collaborator agent dependency is misconfigured. Instead, it often points to one of the models being unable to generate a timely response or another non-obvious issue.

Building a Multi-Language Image Description API with Amazon Nova Lite and Polly

Matias Kreder — Sat, 21 Jun 2025 16:08:52 +0000

I've always been passionate about technology and how it can transform lives. I occasionally deal with small visual challenges. This has made me deeply interested in exploring ways technology can improve accessibility, particularly for those with greater visual difficulties.

For that reason, I recently embarked on a project to build an API that converts images into descriptive text (Image to Text) or audio (Image to Speech). Using AWS services like Bedrock and Nova Sonic. I built an open-source serverless API that generates image descriptions in multiple languages with optional audio output.

What Does This API Do?

The API accepts base64-encoded images and returns detailed descriptions in over 10 languages, with optional audio narration. It's designed for:

Accessibility applications: Generate alt-text for images in multiple languages or integrate with screen readers
Content management: Automatically describe uploaded images
E-commerce: Create product descriptions from images
Social media: Generate captions in different languages

Architecture Overview

The solution uses a serverless architecture built entirely on AWS:

Key AWS Services Used

1. Amazon Bedrock with Nova Lite Model

The heart of the application uses Amazon's Nova Lite model:

Multimodal understanding: Processes both text prompts and images
Cost efficiency: Optimized for high-volume applications
Fast inference: Low latency responses
Multi-language support: Native understanding of multiple languages

2. AWS Lambda

The serverless compute layer handles:

Image processing: Base64 decoding and validation
Bedrock integration: Model invocation and response handling
Polly integration: Audio generation for accessibility
Error handling: Comprehensive error responses

3. Amazon Polly

Provides text-to-speech capabilities with:

Multiple voices per language: Natural-sounding speech
SSML support: Enhanced audio control
MP3 output: Compressed audio for web delivery

4. API Gateway

Creates a production-ready API with:

REST endpoints: Clean API interface
SSL termination: Secure HTTPS connections
Request/response transformation: Clean JSON interfaces
Request/response transformation: Clean JSON interfaces

Technical Implementation

Lambda Function Structure

The Python Lambda function is organized into clear components:

def lambda_handler(event, context):
    # Parse request and validate input
    # Invoke Bedrock Nova Lite model
    # Generate audio with Polly (if requested)
    # Return structured JSON response

Bedrock Integration

The Nova Lite model is invoked with carefully crafted prompts:

prompt = f"Describe this image in {language_name}. Be descriptive and detailed."
response = bedrock_client.invoke_model(
    modelId="amazon.nova-lite-v1:0",
    body=json.dumps({
        "messages": [
            {
                "role": "user",
                "content": [
                    {
                        "image": {
                            "format": image_format,
                            "source": {
                                "bytes": base64.b64encode(image_bytes).decode('utf-8')
                            }
                        }
                    },
                    {
                        "text": prompt
                    }
                ]
            }
        ],
        "inferenceConfig": {
            "maxTokens": 300
        }
    })
)

Deployment with AWS SAM

The project uses AWS SAM (Serverless Application Model) for infrastructure as code:

# template.yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ImageDescriptionFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.9
      Handler: app.lambda_handler
      Policies:
        - Statement:
          - Effect: Allow
            Action:
              - bedrock:InvokeModel
            Resource: '*'
          - Effect: Allow
            Action:
              - polly:SynthesizeSpeech
            Resource: '*'

Deployment Commands

sam build
sam deploy --guided

API Endpoints

Text Description Endpoint

POST /describe/text

{
  "image": "base64_encoded_image_data",
  "language": "en"
}

Response:

{
  "description": "A detailed description of the image in the requested language",
  "format": "text",
  "language": "en"
}

Audio Description Endpoint

POST /describe/audio

{
  "image": "base64_encoded_image_data",
  "language": "en",
  "voice": "Joanna"
}

Response:

{
  "description": "Text description",
  "audio": "base64_encoded_mp3_data",
  "format": "audio",
  "voice": "Joanna",
  "language": "en"
}

Getting Started

Clone the repository
Enable Nova Lite access in Amazon Bedrock console
Deploy with SAM: sam build && sam deploy --guided
Test the endpoints with your images

Conclusion

This project demonstrates how modern AWS services can be combined to create powerful, cost-effective AI applications. The combination of Nova Lite's multimodal capabilities, Lambda's serverless compute, and Polly's text-to-speech creates a comprehensive solution for image accessibility.

The entire codebase is open-source and production-ready, making it easy for developers to deploy their own instance or extend the functionality for specific use cases.

Repository: https://github.com/mkreder/image-to-speech-api

Using a custom domain name in a Private REST API Gateway

Matias Kreder — Thu, 06 Jun 2024 02:54:39 +0000

When working on internal networks, particularly within a VPC, developers often encounter the need to interact with a private API gateway. A common scenario is when a network resource, which must make non-internet HTTPS calls without involving the AWS API, requires access to a specific lambda function. While using the API gateway assigned hostname is an option, opting for a private DNS name can provide a more consistent approach across environments.

According to the AWS Documentation: "Custom domain names are not supported for private APIs."
However, there is a simple hack to get this to work.

TL;DR; Architecture

Full Solution

On the VPC, create a "execute-api" VPC endpoint for API Gateway
On API Gateway, create a private REST API and all necessary/ resource methods. Create a resource policy that only allow access through the VPC Endpoint
On the VPC Endpoints, explore the Subnets section of the VPC endpoint created in step 1 and grab the IPs
Create a TLS target group using the IPs from step 3.
Create a TLS internal NLB, using the target group from step 4.
Create a custom domain name in API Gateway (Regional type) but point it to the private API gateway.
On Route53, configure a private zone attached to the same VPC with a CNAME record that points to the NLB DNS address.

Once this is done, it should work. I have done this many times in different projects but keep forgetting about it, so I figured it was a good time to document it to be useful for someone else.

Accelerating to Las Vegas: Inside the AWS DeepRacer 2023 Finals at reInvent

Matias Kreder — Thu, 29 Feb 2024 19:48:53 +0000

Intro

In 2023, I was a finalist in the AWS DeepRacer competition and had the chance to travel to AWS reInvent (all expenses paid by AWS). The experience was amazing; from start to finish, the organizers treated me as a VIP, and I met racers from around the world. I thought about writing this post to describe my experience as a racer, the final's perks, and how the final was organized.
This will be useful for future finalists who want to understand what they are about to live. I will also provide some tips at the end.

Story

I had the chance to attend AWS reInvent three previous times (2017, 2018, 2019). I was even there when DeepRacer was announced, but since I was always busy with something work-related, I only had a chance to get involved with it in May 2020, during the pandemic. That month, there was an F1 contest where two F1 professional racers created their own DeepRacer models and participated against developers to see who was best at virtual racing (the F1 racers didn't win).
Because of this contest, all DeepRacer training was free of charge, pushing me to try it. Since then, it has been my hobby. I could make it to the finals in 2020, but there was no physical reinvent that year, so the final was virtual. It was fun; I participated in several rounds and learned a lot from it. I ended in the top 30.
Then, in 2021 and 2022, the competition was tough, and I couldn't qualify.
The rules slightly changed in 2023; the qualification was per geographic region, and because of that, I could qualify quickly since only a few people were participating in LATAM. But that also pushed me to create content and give workshops and talks about DeepRacer; I wanted this technology to become more popular in my region.
At the same time, I also wanted to get experience in physical racing, but there are very few AWS Summits in the region. That's why I started collaborating with a university, and we started building a Community and hosting DeepRacer events and workshops. You can read more about this here.

League Prizes

As in any good competition, DeepRacer has excellent prizes. The prizes vary from year to year, but during 2023, the prizes were:

$50 for those ending among the top 10% on the virtual race (per region)
$400 for those ending among the top 3 on the virtual race (per region)
Trip to the finals for those that win the virtual race (per region)

The cash prizes could be redeemed via PayPal or Amazon credits.

The trip prize included:

Hotel Accommodations (All finalists stayed at the MGM Grand)
ReInvent ticket (Costs $2100)
Flight ticket from your nearest airport
Transportation to/from the airport
$400 pre-paid card for food or whatever you want to spend on (can't be used for gambling).

This was awarded to 48 racers (8 racers per region)

Final Prizes

Once you make it to the finals in Las Vegas, there are great prizes if you end up with the top racers. In 2023, the top 6 racers won:

1st place: $20,000 and a trophy.
2nd place: $10,000 and a trophy.
3rd place: $5,000 and a trophy.
4th to 6th place: $3,000 each.

These prizes are excellent, but even if you make it to the finals and don't end in the top 6, you still won a fantastic trip you will always remember.

Getting There

I flew from Buenos Aires to Las Vegas with a layover in Dallas, Texas. They put me on a convenient American Airlines flight with a 2-hour stopover. When I arrived in Las Vegas, I was greeted by a driver waiting for me to take me to my hotel.

PromoVeritas organizes the whole trip, and they do a great job making sure you feel like a VIP. And even the driver made me feel that way. When I asked her how busy Las Vegas was and if she thought the hotel would let me do an early check-in at 1 pm, she said: "I'm sure they will; You are a VIP". I felt that way during the whole trip.

Schedule

We had three rounds this week, including the final spread across the first three days of the week and an open race for everyone in the conference on Thursday.

First Round

Round 1 was a Virtual Round. All racers met at the Brooklyn Bowl and submitted their best models. Each region had its virtual race where racers from the region competed against each other. The top 5 from each region passed to round 2.
There were two chances per racer where. They could submit the same model or choose a different one. In my case, I had a model that I knew was good enough, so I used the same model twice. I was a little more aggressive the second time with the speed throttle.
I ended up 3rd in my region and made it to round 2.

I also received this beautiful box with DeepRacers socks and customized parts to tune my DeepRacer car.

This round was also an excellent opportunity to network with people from other regions, as this was one of the few times everyone in the competition participated simultaneously.

Practice Round

There was a practice round on Tuesday. I tried a few models, but I expected them to perform better. I continued to train some more models overnight.

Second Round

The second round started; this was the first time I raced in an AWS-hosted physical event.
Each racer has two tries (they can submit two different models or the same model twice).
On the first try, I tried a model I knew might work. It worked okay, but I used a more unstable model that performed poorly on the second try. I ended up in 29th place out of the 32 racers that made it to the second round (From 48 finalists that made it to the final itself).

This is how my model ran in the first try:

Final

Watching the final live was a lot of fun. All top competitors were close to each other, and I saw how they pushed their models more and more to try to make a difference. (The cars drive by themselves, but the racers can use a throttle to speed the models up or down)

The winner was FiatLux, but his model was run by a proxy driver (Doug Wozniak). Video below.

Final Picture (I'm on the right-most)

Karaoke

The AWS DeepRacer team organized a dinner in The Barbershop, a Karaoke place. DeepRacer finalists + AWS Pit Crew, and management were there.

The finalists even sang, "We are the champions".

All racers + pit crew from Latin America performed "La Bamba".

Final Thoughts

The finals are fun and are a great way to connect with like-minded individuals. There are also a lot of activities you can do at reInvent while you are not racing. If you read this because you made it to the finals and want to know how it will be, "Congratulations! You will have an amazing time". If you are not a finalist, I hope this encourages you to participate in DeepRacer and put some effort into it. It is worth it.

Here are a few tips from my experience:

Being in Las Vegas is a lot of fun, and you can quickly be booked with activities to do at night, but dedicate some time to sitting in your hotel every night to rework your models. You will be doing tweaks daily and running models every day.
For virtual sessions, run a practice round yourself in the simulator.
The organization will give you self-explanatory instructions on what will happen each day of the week. Read everything carefully.
Don't book any reInvent breakout sessions. All are recorded and uploaded to YouTube. But attend DeepRacer workshops as they are not recorded and usually help you gain more profound knowledge about DeepRacer.

And a few tips that apply to reInvent in general: Leave spare luggage space for swag, drink plenty of water, wear comfortable shoes, and be ready to walk 30k steps daily.

I hope you find this article helpful! The 2024 session just started, and the new rules have been announced.

Testing Amazon Bedrock Text G1 Models (Lite vs Express)

Matias Kreder — Wed, 17 Jan 2024 18:12:35 +0000

Intro

Amazon released its own LLMs at reInvent 2023, including the G1 Text LLMs Titan Lite and Express. The main difference is that the Lite model has a context length of 4000 tokens, while Express has a context length of up to 8000, making it more robust. While the Lite model has some cost benefits, the Express version should be able to generate better answers. I gave them a try.

Pricing

Bedrock prices are measured on how many "tokens" get in and out and out of the model. In Text models like Titan that is somehow connected to the number of words that get in and out of it.
The Lite model currently costs $0.0003 per 1,000 input tokens and $0.0008 per 1,000 output tokens while the Express model costs $0.0006 per 1,000 input tokens and $0.0016 per 1,000 output tokens.

Access

Before being able to use them, you need to request access to them. in the "Model Access" section inside the BedRock service console, click on "Manage Model Access", select the models you need access to, and click the "Save Changes" button.

It can take a couple of minutes to get access to the models. For some models that are not provided by Amazon, it can take several days or weeks as the access needs to be approved by the provider.

Text Generation

To test the output of both models, I used the following input text: 'Generate a text for a marketing campaign for a new Shampoo called "Lambda"'. This is the output they generated:

Lite:
"Introducing Lambda Shampoo, the ultimate solution for hair that looks and feels its best! Say goodbye to dull, lifeless locks and hello to vibrant, healthy-looking hair with Lambda Shampoo. Formulated with a blend of natural ingredients, Lambda Shampoo is designed to nourish, strengthen, and revitalize your hair from root to tip. Experience the power of botanical extracts, vitamins, and proteins that work in harmony to restore your hair's natural balance and restore its natural shine. Lambda Shampoo is suitable for all hair types, including color-treated hair, and is free from harsh chemicals and sulfates that can strip away natural moisture and damage your hair. It's gentle enough for daily use and leaves your hair feeling soft, smooth, and manageable. But that's not all! Lambda Shampoo comes in an attractive and eco-friendly packaging that reflects our commitment to sustainability. We believe in reducing our environmental footprint and doing our part to protect the planet. Join the Lambda Movement and experience the difference for yourself. Visit our website or find our shampoo at your nearest retailer to get started on your hair care journey today! #LambdaShampoo #HairRevitalization #NourishAndStrength #BotanicalExtracts #HealthyHair #SustainablePackaging"

Express:
"Lambda Shampoo: The Ultimate Hair Transformation Experience Introducing the revolutionary Lambda Shampoo, the game-changer in hair care that will transform your locks into a breathtaking masterpiece. Say goodbye to ordinary hair and hello to extraordinary beauty with Lambda's cutting-edge formula. Unlock the Power of Natural Ingredients: Lambda Shampoo is crafted with a blend of premium, natural ingredients that have been carefully selected to nourish, strengthen, and enhance your hair's natural beauty. Our formula contains a powerful combination of botanical extracts, vitamins, and antioxidants that work synergistically to promote healthy hair growth, improve scalp health, and restore shine and vitality. Revitalize Your Hair from Root to Tip: Lambda Shampoo is designed to revitalize your hair from root to tip. Our deep cleansing formula gently removes impurities, excess oil, and product buildup, leaving your hair feeling clean, refreshed, and revitalized. With regular use, you'll notice a noticeable improvement in hair texture, volume, and overall hair health. Silky Smooth and Frizz-Free: Say goodbye to frizzy, unruly hair and hello to silky, smooth locks. Lambda Shampoo contains nourishing ingredients that help to tame frizz and impart a lustrous shine to your hair. Experience the joy of running your fingers through hair that feels incredibly soft and manageable. Customized Hair Care for Every Need: Lambda Shampoo offers a range of customized hair care solutions to suit your individual needs. Whether you have dry, damaged hair, oily scalp, or color-treated hair, we have a formula that will address your specific concerns and deliver the desired results. Choose from our variety of scents, including refreshing citrus, soothing lavender, and invigorating mint, to add a touch of luxury to your hair care routine. Sustainable and Eco-Friendly: At Lambda, we are committed to sustainability and eco-friendliness. Our shampoo bottles are made from recycled materials, and our packaging is designed to minimize waste. By choosing Lambda Shampoo, you're not only taking care of your hair but also contributing to a greener and more sustainable future. Join the Lambda Hair Transformation Movement: Experience the transformative power of Lambda Shampoo and join the thousands of satisfied customers who have already embraced this hair care revolution. Elevate your hair care routine and unlock your hair's true potential with Lambda. Visit our website or your nearest retailer to discover the full range of Lambda Shampoo and experience the difference for yourself. Get ready to turn heads with your stunning, healthy hair. Lambda Shampoo: Where Science Meets Beauty, and Your Hair Becomes a Work of Art."

Both texts are useful for marketing campaigns. It is worth noticing that the Lite text was generated almost immediately, while the Express text took a few seconds to generate. If you don't need to generate long text for these types of tasks, then the Lite version should be enough.
I'm glad none of the models returned a hallucination about AWS Lambda!

Code Generation

I tried a few things. First, I tried "Generate a Python function that receives an array of numbers, and returns the biggest number" which worked pretty well for both models, returning this code:

def find_biggest_number(array):
    biggest_number = array[0]
    for number in array:
        if number > biggest_number:
            biggest_number = number
    return biggest_number

However, when I tried to do something a little more complex like "Generate a Python function that receives an array of numbers, sorts it from min to max and returns the biggest number" I got an error saying "Sorry - this model is unable to respond to this request."

When I tried with the Express version, it generated code (very similar to the previous one) but didn't do the sorting part.

def biggest_number(arr):
    biggest = arr[0]
    for num in arr:
        if num > biggest:
            biggest = num
    return biggest

Both models can generate simple code, but relying on other services like CodeWhisperer for complex tasks is better. I tried this same prompt with other LLMs available on BedRock, like Cohere Command or A21 Jurassic, but both failed to generate a good function as well.

Conclusion

Text generation tests showed that both models produce compelling marketing campaign content, with the Lite version offering a quicker response and the Express version taking a few seconds longer but delivering a more detailed output. Users aiming for shorter text generation tasks may find the Lite model sufficient for their needs.
Regarding Code generation, both models can handle simple requests effectively. However, limitations became evident when presented with more complex tasks, such as sorting an array of numbers. The Lite model failed to respond to the request, while the Express version generated code but omitted the sorting component. This suggests that relying on specialized services like CodeWhisperer may be more effective for complex coding tasks.
In essence, the choice between Titan Lite and Express depends on the specific requirements of the task at hand. For shorter text generation tasks with budget considerations, the Lite model may be a suitable choice. However, the Express model would be a better choice for more extensive tasks.

AWS DeepRacer activities in Buenos Aires (2023)

Matias Kreder — Sat, 16 Dec 2023 20:50:00 +0000

We were able to run many DeepRacer events in Buenos Aires in 2023; I thought about writing this article to describe how things were put together. The bottom line is that I wanted to gain experience in physical racing but needed a track. Many racers face the same problem, and I get asked how I did it. Finding a university and building a DeepRacer community around it was the solution for me.

Intro

I have been a racer for some time. I started racing in 2020 when DeepRacer announced the F1 contest. I made it to the finals that year, but there was no physical final as re:Invent was virtual because of the pandemic. That was when I also got my first DeepRacer Evo car as a prize for participating. I also joined the AWS Community Builder program and started talking and blogging about DeepRacer.

The competition in 2021 and 2022 was hard, and I couldn’t make it to the finals again. However, I kept trying and trying. On the other hand, my DeepRacer car was sitting in my Home Office, accumulating dust. I wanted to gain some practice in a physical track, but there are few AWS Summits in LATAM where the track is available to race. I had the money to buy a track myself but I needed to figure out where to place it as I live in a small apartment in the middle of Buenos Aires.

On the other side of the world, Pablo Inchausti (another AWS Community Builder from Buenos Aires) was at AWS reInvent 2022 and got obsessed with DeepRacer when he saw cars racing on the track. Pablo is also a teacher at UADE, so he thought it would be great for the university to give their students some experience with that technology. We have been working as a team since then.

Pablo and I started to talk. We spoke with the university. Daniel Feijó, the director of Computer Science Engineering, quickly saw the potential of this opportunity, and they built the track and bought their own DeepRacer Evo cars. The university also had at least five locations to assemble the track.

Since then, we have organized different races, and the university has always helped host the races in different places and helped with the logistics around those races (transporting the track to different places, assembling the track, providing facilities for events, etc.)

UADE Races (Engineering Projects)

In Computer Science Engineering, students must present a final thesis/project. Three groups of students started working on DeepRacer-related projects:.

Autonomous Vehicles Applied to Object Detection in Logistics Centers
Autonomous Vehicles Applied to Inventory Management in Logistics Centers
Optimizing Machine Learning Models for Autonomous Vehicles The first few times we built the track was for these students to test their DeepRacer models.

Nerdearla Technology Conference

Nerdearla is one of the most significant technology events in South America. It is a 3-day event and more than 10.000 people attended the conference in person and 27.000 virtually. We gave a virtual workshop before the in-person event so that people could see what DeepRacer was about and race. We had 20 racers competing on the track and the best lap time was 18 seconds. If you would like to know more about this race, you can read more in this blog post.

AWS User Group Buenos Aires Race

We also hosted a race for the local AWS User Group at UADE Belgrano. We assembled the track in a Garden house in an open park across the university’s street. We had about 18 racers, both from the local community and students. The best lap time was 10.2 seconds. Many neighbors stopped by to see what we were doing. After the race in the park, we had a small reception at the university.

UADE Application Development 2 Subject Race

During the last semester, I was offered the opportunity to participate as a teacher in one of the UADE courses that Pablo was running. The subject is about different ways for applications to integrate. Everyone works on the same project: The classroom is divided into groups; each group works on its own microservice, and then it needs to integrate with the other groups. The project was about an autonomous food delivery service, so we used DeepRacer to learn about how ML models work and we ran an internal race as well.

UADE’s own use

UADE has been using the track at science fairs and taking it across different parts of the country to showcase the DeepRacer technology, including high schools.

Final Notes

As you might see in this article, we ran several races for different groups. Hosting all these races was fun, and we are starting to build a DeepRacer community in the region, and that is rewarding. If you are facing the same problem I had: You want to get your hands on a physical track but don’t have the money or the space, reach out to the Universities in your region; one of them might be interested in collaborating with you. It is definitely worth it for both parties.

We are planning a wide variety of activities next year, from doing DeepRacer activities in high schools and universities to running races at Community and Technology events in the region. I’ll be posting about them on my LinkedIn page.

If you are in the region, feel free contact me through my LinkedIn or join the AWS DeepRacer Community on Slack, where you can get in touch and share experiences with me and other DeepRacer community leaders from across the globe.

Extra

I had the chance to take my kids to the race we did at Nerdearla in one of the three days, and a few days later, they built this beautiful representation of the race.

UADE AWS DeepRacer GrandPrix Buenos Aires

Matias Kreder — Tue, 28 Nov 2023 08:27:32 +0000

El 11 de Noviembre a las 11 en la calle 11 .................(no es broma) de Septiembre en UADE Belgrano organizamos en conjunto con UADE y el AWS User Group de Buenos Aires una competencia de DeepRacer. La competencia se hizo en una plaza del barrio de Belgrano debajo de una histórica Glorieta.

Muchas personas se acercaron a correr sus modelos de inteligencia artificial y Manuel Barreneche fue el ganador con un tiempo de 10.2 segundos!

Podemos ver el modelo de Manuel corriendo en el siguiente video:

Gracias UADE, por facilitarnos la logística y por prestarnos la Sede de Belgrano para reunirnos después del evento a conversar sobre el User Group y comer algo rico provisto por AWS.

Fotos

Corriendo DeepRacer con UADE en Nerdearla (Buenos Aires)

Matias Kreder — Thu, 26 Oct 2023 15:07:57 +0000

Intro

Nerdearla es probablemente el evento de tecnología mas grande de Argentina (incluso quizás de Latinoamérica). Para que se den una idea en números: Participan 200 speakers, 27.000 personas ven el evento por internet y unas 10.000 personas concurren al evento en persona. Vale mencionar que el evento es completamente gratuito desde el día 0.

En esta oportunidad UADE patrocinó la carrera de DeepRacer llevando su pista y los vehículos y todo lo relacionado a la organización de la carrera en si.

La Carrera

Antes de Nerdearla, dimos un workshop sobre conceptos básicos de DeepRacer y aprendizaje por refuerzos. Queríamos que las personas puedan familiarizarse con estos conceptos y puedan crear sus propios modelos para poder correrlos en la pista, durante la conferencia.
El video del workshop esta disponible en YouTube.

Por temas de espacio, tuvimos que armar la pista en el patio del Konex. Por suerte, ninguno de los 3 dias llovio! Hubo algunas complicaciones con armar la pista al aire libre ya que el reflejo del sol causaba reflexiones en la pista. Sin embargo, 20 corredores pudieron correr sus modelos exitosamente.

El mejor tiempo fue de 18 segundos. Siendo el record mundial en esta pista cerca de 7 segundos, todavía hay un montón para mejorar. Pero lo bueno es que ahora gracias a UADE tenemos una pista disponible para seguir practicando y aprendiendo ML en Buenos Aires.

En el mes de Noviembre vamos a estar haciendo mas carreras. Si están en la zona y se quieren sumar pueden seguir al UG de Buenos Aires o a mi en LinkedIn.

Foto del campeón de la carrera recibiendo el premio. De Izquierda a Derecha: Tomas Bond(organizador), Matias Kreder (organizador), Luciano Sosa (ganador), Pablo Ezequiel Inchausti (organizador)

Más Fotos

How to stream video from the DeepRacer camera

Matias Kreder — Sat, 02 Sep 2023 18:36:16 +0000

Intro

I have been working on several projects that require individuals to get access to the DeepRacer camera.

At UADE University, students needed access to the camera for some assignments.
At a conference called Nerdearla, the video streaming team would like access to the car's camera to stream from it.

After hacking around with the car a little and with some hints from David Smith from AWS, I came up with the following process. I'm documenting it here for anyone needing it and a future version of me.

Backup Configuration Files

mkdir -p /home/deepracer/backup
cp /opt/aws/deepracer/lib/device_console/static/bundle.js /home/deepracer/backup/
cp /etc/nginx/sites-enabled/default /home/deepracer/backup/site-config

Perform Configuration Changes

sudo sed -i "s/isVideoPlaying\: true/isVideoPlaying\: false/" /opt/aws/deepracer/lib/device_console/static/bundle.js
sudo sed -i "s/auth_request \/auth;/#auth_request \/auth;/" /etc/nginx/sites-enabled/default
systemctl restart nginx

Accessing The Car Camera

The URL to access the car camera is:

https://CAR_IP/route?topic=/camera_pkg/display_mjpeg&width=480&height=360

Please consider that this change disabled authentication on the ROS backend on the car, so make sure to do this only when you are working in an isolated network you trust.