DEV Community: Sergio Esteban

Launching your personal assistant

Sergio Esteban — Tue, 16 Dec 2025 07:49:36 +0000

Introduction

In this post, we will extend the implementation of an AI Agent. This time, we have improved the agent’s accessibility and its capacity to use different tools for a specific context.

TLDRS

All code used in this article is available in the repository.

Context

In addition to using AWS serverless services in the context of rapid experimentation, we have included the agent’s capacity to generate responses based on a certain predefined set of tools and the ability to operate using Gemini as a provider.

What’s the objective?

We want to obtain information in different formats through tools and then present it to the client within a mobile application.

Why mobile?

Greatest benefits of AI are when the technology is accessible on the devices you frequently carry.

I definitely don’t carry a laptop everywhere, do you?

Below is a high-level diagram representing what you want to achieve.

While there are no significant changes to the architecture, you will see the necessary considerations in how we handle responses from our Lambda.

Let’s move ahead.

Scope

We will use the Davis Instruments console manuals as data sources, and we will build a private Chatbot for iPhone that will answers from these manuals, as well as displaying data from the stations.

Functional requirements

The system should allow you to consult and receive information related to Vantage Pro2 equipment, such as setup questions and/or requests for data from the weather stations.
This interaction must be in natural language.
The system should allow sending messages and receiving a response in real time as it is generated.

Non-Functional requirements

As usual, you can rely on serverless capabilities and add a few additional characteristics.

The system that provides data supports to the app should be highly available.
The system should scale automatically to handle variable traffic patterns.
The system should remain secure with domain-level access control and encrypted traffic.

The following is a high level diagram of the architecture.

Out of scope

We will omit the feature of being able to request actual data from the WeatherLink API.

However, you can find a project of mine that enables an integration using AI and MCP.

It is also worth mentioning that the fact that this implementation is possible does not mean this is the ideal way to expose an API.

With that out of the way, let’s move on.

Cost breakdown

Considering a volume of 1,000 requests per month, which for our use case is very generous, we are running our solution with the following components.

Google AI API Calls

We will use Gemini 2.5 Flash for language inference and text-embedding-004 for embeddings.

gemini-2.5-flash input (500k tokens x $0.30/M) plus output (500k tokens x $2.50/M) = $0.15 + $1.25
text-embedding-004 (500k tokens x $0.10/M) = $0.05

This gives us an approximate total of $1.45 USD per month.

AWS Lambda

We will configure a function with 1024 MB and a 60 second timeout. AWS provides 1M free requests and 400,000 GB-seconds monthly, which covers typical usage.

This results in $0.00 USD per month (within free tier).

CloudFront

We will use PriceClass_100 (US and Europe) assuming moderate traffic of 5 GB data transfer and 50,000 HTTPS requests.

Data transfer: 5 GB x $0.085/GB = $0.43
HTTPS requests: 50,000 x $0.01/10,000 = $0.05

This results in about $0.48 USD per month.

S3 Storage

For storing static assets and application data, estimating 2 GB of storage with 100,000 GET requests.

Storage: 2 GB x $0.023/GB = $0.05
GET requests: 100,000 x $0.0004/1,000 = $0.04

This results in about $0.09 USD per month.

Container Registry (AWS ECR)

For storing 3 images of 400 MB each (1.2 GB total). Billable storage after 500 MB Free Tier is 0.7 GB.

0.7 GB x $0.10/GB = $0.07

This results in about $0.07 USD per month.

Route 53

We will use a hosted zone ($0.50/month) and include a standard .com domain registration fee ($13.00/year or $1.08/month).

Get warike-technologies’s stories in your inbox

Join Medium for free to get updates from this writer.

This results in about $1.58 USD per month.

CloudWatch

For logging with seven-day retention, estimating minimal volume (0.2 GB ingestion).

Log Ingestion: 0.2 GB x $0.50/GB = $0.10

This results in about $0.10 USD per month.

Apple Developer Account

The Apple Developer Program membership is $99 USD per year. This is a fixed annual fee required to publish apps on the App Store.

Annual Cost: $99.00 / 12 months = $8.25

This results in a monthly allocation of $8.25 USD per month.

Total Monthly Cost

This brings us to a total of approximately $12.02 USD per month.

Implementation

Let’s start from the App and we can progress towards to the infrastructure

Mobile App

For the technical implementation of a mobile application, I will suggest using the Galaxies Dev repository. Big shout out for his work.

Given that the video explains how to build the application from scratch, we will highlight the changes we have included on our part.

The first thing to consider is that the application will use the following dependencies:

import { useChat } from '@ai-sdk/react';
import { DefaultChatTransport } from "ai";

The important parts from the implementation at this point are the following:

We need to sign POST Requests as it is mentioned in the documentation.
We need to add Clerk token into our Resquest Headers.

const transport = useMemo(() => new DefaultChatTransport({
    fetch: async (url, options) => {
        if (options?.method === 'POST' && options.body && typeof options.body === 'string') {
            const hash = await Crypto.digestStringAsync(
                Crypto.CryptoDigestAlgorithm.SHA256,
                options.body
            );
            options.headers = {
                ...options.headers,
                'x-amz-content-sha256': hash,
            };
        }
        return expoFetch(url as string, options as any);
    },
    credentials: 'include',
    api: generateAPIUrl("/api/chat"),
    headers: async () => {
        const token = await getTokenRef.current();
        return {
            "Authorization": token ? `Bearer ${token}` : '',
            "X-Clerk-Token": token || '',
        };
    },
}), []);

  ...

const { messages, stop, sendMessage, status, setMessages } = useChat({
    transport: transport,

    onFinish: async ({ message }) => {
        scrollViewRef.current?.scrollToEnd({ animated: true });

        // Save assistant message to database
        const currentChatId = chatIdRef.current;

        if (currentChatId && message) {
            const chatIdNum = parseInt(currentChatId);
            if (isNaN(chatIdNum)) return;

            // Filter out tool invocations and empty parts
            const validParts = filterPartsForDB(message.parts);

            // Only save if there's actual text content
            if (validParts.length === 0) return;

            try {
                await addMessage(db, chatIdNum, {
                    parts: validParts,
                    role: Role.Assistant,
                });

            } catch {
                // Fail silently
            }
        }
    },
    onError: (err) => {
        console.error('Chat error:', err);
    },
});

And later, to display the messages from the API, we will assume that certain messages include the tools within the payload.

type ChatMessageProps = {
  message: UIMessage;
  isLoading?: boolean;
  status?: ChatStatus;
};

const ChatMessage = ({ message, isLoading, status }: ChatMessageProps) => {
  const { user } = useUser();
  const { role, id, parts } = message;
  const isUser = role === Role.User;
  const isAssistant = role === Role.Assistant;

  // Check if this is a streaming message with no content yet
  const hasTextContent = parts?.some(
    (part) => part.type === 'text' && part.text && part.text.trim().length > 0
  );

  // Check if we have a data tool response to avoid duplicate rendering
  const hasTools = parts?.some(
    // @ts-ignore
    (part) => part.type === 'tool-dataTool' || part.type === 'tool-weatherTool' || part.type === 'tool-gddTool'
  );

  // Show loader for assistant messages that are empty and we're streaming
  const showLoader = isLoading || (isAssistant && !hasTextContent && !hasTools && status === 'streaming');

  // Don't render empty user messages
  if (isUser && !hasTextContent) {
    return null;
  }

  return (
    <View style={[styles.row, isUser && { flexDirection: 'row-reverse' }]}>
      <View style={[styles.item, { backgroundColor: '#fff', paddingTop: 5 }]}>
        <Image
          source={
            isUser
              ? { uri: user?.imageUrl || 'https://placehold.co/250x250?text=U' }
              : require('@/assets/images/logo-white.png')
          }
          style={styles.avatar}
        />
      </View>

      <View style={[styles.text, { flex: 1, paddingBottom: 10 }, isUser && styles.userMessageBubble]}>
        {showLoader ? (
          <LottieLoader />
        ) : (
          parts?.map((part, i) => {
            switch (part.type) {
              case 'text':
                if (!part.text || part.text.trim().length === 0) {
                  return null;
                }
                return <CustomMarkdown key={`${id}-${i}`} content={part.text} />;
              case 'dynamic-tool':
                return <LottieLoader key={`${id}-${i}`} />;
              case 'tool-weatherTool':
                const weatherOutput = part.output as WeatherDataProps;
                if (weatherOutput) {
                  const { temperature, unit, description, forecast } = weatherOutput;
                  return <MessageData key={`${id}-${i}`} temperature={temperature} unit={unit} description={description} forecast={forecast} />;
                }
                return <LottieLoader key={`${id}-${i}`} />;
              case 'tool-dataTool':
                const soilOutput = part.output as SoilChartProps;
                if (soilOutput) {
                  const { labels, datasets, legend } = soilOutput;
                  return <MessageChart key={`${id}-${i}`} labels={labels} datasets={datasets} legend={legend} />;
                }
                return <LottieLoader key={`${id}-${i}`} />;
              case 'tool-gddTool':
                const gddOutput = part.output as GDDDataProps;
                if (gddOutput) {
                  const { labels, datasets } = gddOutput;
                  return <MessageGDD key={`${id}-${i}`} labels={labels} datasets={datasets} />;
                }
                return <LottieLoader key={`${id}-${i}`} />;
              default:
                return null;
            }
          })
        )}
      </View>
    </View>
  );
};

Having all that, most of the application should be operating. We can proceed to build the application so that it responds to your requests.

Implementing Mastra in Lambda

The first step would be to create a simple flow in Lambda where you must validate the request’s credentials, then check the path, and finally generate the response from the messages.

export const handler = awslambda.streamifyResponse<APIGatewayProxyEventV2>(
    async (event: APIGatewayProxyEventV2, responseStream: awslambda.HttpResponseStream) => {

        responseStream.setContentType('text/plain; charset=utf-8');

        if (!await checkAccess(event)) {
            responseStream.write('Unauthorized');
            responseStream.end();
            return;
        };

        if (event.rawPath !== '/api/chat') {
            const httpResponseMetadata = {
                statusCode: 404,
                statusMessage: "Not Found",
                headers: {},
            };
            responseStream = awslambda.HttpResponseStream.from(responseStream, httpResponseMetadata);
            responseStream.write('Not Found');
            responseStream.end();
            return;
        }

        try {
            const httpResponseMetadata = {
                statusCode: 200,
                statusMessage: "OK",
                headers: {},
            };
            responseStream = awslambda.HttpResponseStream.from(responseStream, httpResponseMetadata);
            // Parse request body
            if (event.body) {
                const body = JSON.parse(event.body);
                const { messages } = body;
                await runAgent(messages, responseStream);
            }
        } catch (error) {
            console.error(`Error in handler:`);
            console.error(error);
        } finally {
            responseStream.end();
        }
    }
);

Clerk authentication

The validation that the user is valid is quite simple through Clerk. You simply verify the token sent from the app, and Clerk takes care of the rest.

import type { APIGatewayProxyEventV2 } from "aws-lambda";
import { verifyToken } from '@clerk/backend';
import { env } from './env.js';

export const checkAccess = async (event: APIGatewayProxyEventV2): Promise<boolean> => {
  try {
    const headers = event.headers || {};
    const authHeader = headers['x-clerk-token'] ?? headers['authorization'] ?? headers['Authorization'];
    const token = authHeader?.replace(/^Bearer\s+/i, '');
    if (!token) {
      return false;
    }

    await verifyToken(token, {
      secretKey: env.CLERK_SECRET_KEY,
    });
    return true;
  } catch (error) {
    return false;
  }
}

All secrets and configuration variables are available on the Clerk dashboard.

Mastra

Our implementation cannot use the native functions of ai-sdk or Mastra. We must use the pipelines function in NodeJS to pipe the response to the stream of our Lambda function.

import { mastra } from './app.js';
import { UIMessage, stepCountIs } from 'ai';
import { pipeline } from 'node:stream/promises';

export const runAgent = async (messages: UIMessage[], responseStream: awslambda.HttpResponseStream) => {
    const agent = mastra.getAgent("basic");
    const result = await agent.stream(messages, {
        stopWhen: stepCountIs(5),
        modelSettings: {
            temperature: 0.0,
            topK: 3,
        },
    });
    const sseResponse = result.aisdk.v5.toUIMessageStreamResponse({ sendReasoning: false });
    await pipeline(sseResponse.body!, responseStream);
}

Also, we must consider creating the agent and its tools. I am going to reuse S3 functionalities and use static functions that represent the data functionalities.

Feel free to implementing them yourself, or DM me for more specifics.

// agents.ts

import { Agent } from '@mastra/core/agent';
import { rag_system_prompt } from './prompt.js';
import { languageModel } from './model.js';
import { queryTool, weatherTool, gddTool, dataTool } from './tools.js';

export const basicAgent = new Agent({
    id: "basic",
    name: "basic",
    instructions: [
        {
            role: "system", content: rag_system_prompt
        },
    ],
    model: languageModel,
    tools: {
        queryTool,
        weatherTool,
        gddTool,
        dataTool,
    },
});

// tools.ts

import { MastraLanguageModel } from '@mastra/core/memory';
import { createVectorQueryTool } from '@mastra/rag';
import { createTool } from "@mastra/core/tools";
import { embeddingModel, languageModel } from './model.js';
import { S3VectorsStoreName } from './vector.js';
import { env } from '../env.js';
import { z } from 'zod';

export const queryTool = createVectorQueryTool({
    id: 'tool_knowledgebase_s3vectors',
    description:
        'Use it to search for relevant documentation about Vantage Pro 2',
    vectorStoreName: S3VectorsStoreName,
    indexName: env.AWS_S3_VECTORS_INDEX_NAME,
    includeVectors: false,
    model: embeddingModel,
    reranker: {
        model: languageModel as unknown as MastraLanguageModel,
        options: {
            topK: 3,
        },
    },
});

export const weatherTool = createTool({
    id: "weather-tool",
    description: "Fetches temperature from weather stations for a location",
    inputSchema: z.object({
        stationId: z.string(),
    }),
    outputSchema: z.object({
        temperature: z.string(),
        unit: z.string(),
        description: z.string(),
        forecast: z.array(z.string()),
    }),
    execute: async (inputData) => {
        return {
            temperature: "10",
            unit: "C",
            description: "Sunny",
            forecast: ["10", "11", "15", "10", "4"],
        };
    },
});

export const dataTool = createTool({
    id: "data-tool",
    description: "Fetches soil moisture data from weather stations for a location",
    inputSchema: z.object({
        stationId: z.string(),
    }),
    outputSchema: z.object({
        labels: z.array(z.string()),
        legend: z.array(z.string()).optional(),
        datasets: z.array(z.object({
            data: z.array(z.number()),
            color: z.string().optional(),
            strokeWidth: z.number().optional(),
            withDots: z.boolean().optional()
        }))
    }),
    execute: async (inputData) => {
        return {
            labels: ["08-12", "09-12", "10-12", "11-12", "12-12"],
            legend: ["20cm", "50cm", "75cm"],
            datasets: [
                {
                    data: [80, 78, 108, 90, 85, 80],
                    color: "rgba(80, 119, 29, 1)",
                    strokeWidth: 2
                },
                {
                    data: [92, 91, 91, 91, 92, 91],
                    color: "rgba(120, 160, 250, 1)",
                    strokeWidth: 2
                },
                {
                    data: [101, 101, 102, 102, 101, 101],
                    color: "rgba(250, 200, 50, 1)",
                    strokeWidth: 2
                },
                {
                    data: [160],
                    withDots: false,
                    color: "transparent",
                    strokeWidth: 0
                },
                {
                    data: [0],
                    withDots: false,
                    color: "transparent",
                    strokeWidth: 0
                }
            ]
        };
    },
});

export const gddTool = createTool({
    id: "gdd-tool",
    description: "Fetches GDD data from weather stations for a location",
    inputSchema: z.object({
        stationId: z.string(),
    }),
    outputSchema: z.object({
        labels: z.array(z.string()),
        datasets: z.array(z.object({
            data: z.array(z.number())
        }))
    }),
    execute: async (inputData) => {
        return {
            labels: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
            datasets: [
                {
                    data: [5.64, 15, 7.64, 1, 8, 6.1, 10]
                }
            ]
        };
    },
});

Let’s move ahead to define the infrastructure.

Infrastructure

The infrastructure doesn’t change that much from previous implementation.

Lambda definition

It is important to be able to map the corresponding variables.

locals {
  lambda_chat = {
    name        = "chat-${basename(path.cwd)}"
    image       = "${aws_ecr_repository.warike_development_ecr.repository_url}:chat-v1.0"
    description = "Lambda chat function for ${local.project_name}"
    memory_size = 1024
    timeout     = 60
    env_vars = {
      GOOGLE_GENERATIVE_AI_API_KEY = var.google_generative_ai_api_key
      GOOGLE_LANGUAGE_MODEL        = var.google_language_model
      GOOGLE_EMBEDDING_MODEL       = var.google_model_embedding

      AWS_S3_VECTORS_BUCKET_NAME = var.vector_bucket_name
      AWS_S3_VECTORS_INDEX_NAME  = var.vector_bucket_index_name

      LANGWATCH_API_KEY = var.langwatch_api_key
      CLERK_SECRET_KEY  = var.clerk_secret_key

      NODE_OPTIONS = "--enable-source-maps --stack-trace-limit=1000"
      NODE_ENV     = "production"
    }
  }
}

## Lambda Chat
module "warike_development_lambda_chat" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "~> 8.1.2"

  ## Configuration
  function_name = local.lambda_chat.name
  description   = local.lambda_chat.description
  memory_size   = local.lambda_chat.memory_size
  timeout       = local.lambda_chat.timeout

  ## Package
  create_package = false
  package_type   = "Image"
  image_uri      = local.lambda_chat.image
  environment_variables = merge(
    local.lambda_chat.env_vars,
    {}
  )

  create_current_version_allowed_triggers = false

  ## Permissions
  create_role = false
  lambda_role = aws_iam_role.warike_development_lambda_chat_role.arn

  ## Logging
  use_existing_cloudwatch_log_group = true
  logging_log_group                 = aws_cloudwatch_log_group.warike_development_lambda_chat_logs.name
  logging_log_format                = "JSON"
  logging_application_log_level     = "INFO"
  logging_system_log_level          = "WARN"

  ## Response Streaming
  invoke_mode = "RESPONSE_STREAM"

  ## Lambda Function URL for testing
  create_lambda_function_url = true
  authorization_type         = "AWS_IAM"

  cors = {
    allow_credentials = true
    allow_origins     = ["*"]
    allow_methods     = ["*"]
    allow_headers     = ["*"]
    expose_headers    = ["*"]
    max_age           = 86400
  }

  tags = merge(local.tags, { Name = local.lambda_chat.name })

  depends_on = [
    aws_cloudwatch_log_group.warike_development_lambda_chat_logs,
    aws_ecr_repository.warike_development_ecr,
    null_resource.warike_development_build_image_seed
  ]
}

Cloudfront

It is important to be able to map the corresponding domain names that you have chosen to use.

locals {
  cloudfront_oac_lambda_function_url = "chat_lambda_function_url"
  zone_name                          = var.zone_name
  app_domain_name                    = var.app_domain_name
}

module "warike_development_cloudfront" {
  source  = "terraform-aws-modules/cloudfront/aws"
  version = "5.0.1"

  ## Configuration
  enabled                        = true
  price_class                    = "PriceClass_100"
  retain_on_delete               = false
  wait_for_deployment            = true
  is_ipv6_enabled                = true
  create_monitoring_subscription = true

  ## Extra CNAMEs
  aliases = [local.app_domain_name]
  comment = "Chat CloudFront Distribution"

  ## Origin access control
  create_origin_access_control = true

  origin_access_control = {
    "chat_lambda_function_url" = {
      description      = "CloudFront access to Lambda Function URL"
      origin_type      = "lambda"
      signing_behavior = "always"
      signing_protocol = "sigv4"
    }
  }

  origin = {
    "chat_lambda_function_url" = {
      domain_name           = trimsuffix(replace(module.warike_development_lambda_chat.lambda_function_url, "https://", ""), "/")
      origin_access_control = local.cloudfront_oac_lambda_function_url
      custom_origin_config = {
        http_port              = 80
        https_port             = 443
        origin_protocol_policy = "match-viewer"
        origin_ssl_protocols   = ["TLSv1", "TLSv1.1", "TLSv1.2"]
      }
    }
  }

  default_cache_behavior = {
    target_origin_id       = local.cloudfront_oac_lambda_function_url
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["HEAD", "DELETE", "POST", "GET", "OPTIONS", "PUT", "PATCH"]
    cached_methods         = ["GET", "HEAD", "OPTIONS"]

    ## Cache policy disabled
    cache_policy_id          = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad"
    origin_request_policy_id = "b689b0a8-53d0-40ab-baf2-68738e2966ac"

    ## Forwarded values disabled
    use_forwarded_values = false

    ## TTL settings
    min_ttl     = 0
    default_ttl = 0
    max_ttl     = 0
    compress    = true

  }

  viewer_certificate = {
    acm_certificate_arn = module.warike_development_acm.acm_certificate_arn
    ssl_support_method  = "sni-only"
  }

  tags = merge(local.tags, { Name = local.cloudfront_oac_lambda_function_url })

  depends_on = [
    module.warike_development_acm,
    module.warike_development_lambda_chat,
  ]
}

Testing & Observability

As the implementation was getting ready, We need to way to understand if the tools are being used correctly.

Running tests for the Lambda functionality.

The implementation of the tests for the Lambda logic is quite straightforward.

PASS  src/__tests__/mastra/app.spec.ts
PASS  src/__tests__/mastra/agent.spec.ts
PASS  src/__tests__/mastra/tool.spec.ts
PASS  src/__tests__/auth.spec.ts
PASS  src/__tests__/mastra/prompt.spec.ts

Test Suites: 5 passed, 5 total
Tests:       10 passed, 10 total
Snapshots:   0 total
Time:        3.628 s, estimated 4 s
Ran all test suites.
Watch Usage: Press w to show more.

However, what we ideally want to know is whether the agent will behave according to the prompt we have defined.

LangWatch

Here is where I will use the LangWatch scenarios tool. It helps to test out my AI agent by integrating quite easily on Mastra.

import { type AgentAdapter, AgentRole, AgentReturnTypes } from "@langwatch/scenario";
import { mastra } from "../mastra/app.js";

export const basicAgent: AgentAdapter = {
    role: AgentRole.AGENT,
    call: async (input) => {
        const basic = mastra.getAgent("basic");
        const result = await basic.generate(input.messages);
        return result.response.messages as unknown as AgentReturnTypes;
    },
};

Next, the tests for the agent’s behavior are defined.

import scenario from "@langwatch/scenario";
import { describe, it, expect } from "vitest";
import { basicAgent } from "./agent-adapter.spec";

describe("Weather Station RAG Agent", () => {
    it("should provide accurate calibration instructions", async () => {
        const result = await scenario.run({
            name: "barometric pressure calibration request",
            description: `The user needs help calibrating their Vantage Pro2 weather station's barometric pressure sensor.`,
            agents: [
                basicAgent,
                scenario.userSimulatorAgent(),
                scenario.judgeAgent({
                    criteria: [
                        "Agent should provide calibration steps directly without asking follow-up questions",
                        "Response should include step-by-step instructions",
                        "Response should cite the Vantage Pro2 Operations Manual as source",
                        "Response should use telegraphic style (imperative verbs, minimal articles)",
                        "Agent should not include greetings or filler text",
                        "Instructions should mention setting correct elevation first",
                    ],
                }),
            ],
            script: [
                scenario.user("How do I calibrate pressure?"),
                scenario.agent(),
                scenario.judge(),
            ],
        });

        expect(result.success).toBe(true);
    }, 30_000);

    it("should use weatherTool for temperature and humidity requests", async () => {
        const result = await scenario.run({
            name: "current weather data request",
            description: `The user wants current temperature and humidity readings.`,
            agents: [
                basicAgent,
                scenario.userSimulatorAgent(),
                scenario.judgeAgent({
                    criteria: [
                        "Agent should use the weatherTool to fetch current weather data",
                        "Agent should respond with 'Here's the weather data that you requested'",
                        "Agent should not ask follow-up questions",
                    ],
                }),
            ],
            script: [
                scenario.user("What's the current temperature and humidity?"),
                scenario.agent(),
                scenario.user("Station ID is TEST123009"),
                scenario.agent(),
                scenario.judge(),
            ],
        });

        expect(result.success).toBe(true);
    }, 30_000);

    it("should use dataTool for soil moisture requests", async () => {
        const result = await scenario.run({
            name: "soil moisture data request",
            description: `The user wants current soil moisture data from their weather station.`,
            agents: [
                basicAgent,
                scenario.userSimulatorAgent(),
                scenario.judgeAgent({
                    criteria: [
                        "Agent should request for Station ID",
                        "Agent should use the dataTool to fetch soil moisture data",
                        "Agent should respond with 'Here's the soil moisture data that you requested'",
                        "Agent should not provide additional explanation beyond tool usage",
                    ],
                }),
            ],
            script: [
                scenario.user("Show me current soil moisture levels"),
                scenario.agent(),
                scenario.user("Station ID is TEST123009"),
                scenario.agent(),
                scenario.judge(),
            ],
        });

        expect(result.success).toBe(true);
    }, 30_000);

    it("should use gddTool for growing degree day requests", async () => {
        const result = await scenario.run({
            name: "gdd data request",
            description: `The user wants current growing degree day data from their weather station.`,
            agents: [
                basicAgent,
                scenario.userSimulatorAgent(),
                scenario.judgeAgent({
                    criteria: [
                        "Agent should request for Station ID",
                        "Agent should use the gddTool to fetch growing degree day data",
                        "Agent should respond with 'Here's the growing degree day data that you requested'",
                        "Agent should not provide additional explanation beyond tool usage",
                    ],
                }),
            ],
            script: [
                scenario.user("Show me current GDD data"),
                scenario.agent(),
                scenario.user("Station ID is TEST123009"),
                scenario.agent(),
                scenario.judge(),
            ],
        });

        expect(result.success).toBe(true);
    }, 30_000);

});

And then I can view the results both in my terminal and on the LangWatch platform.

Additionally, I can configure LangWatch for the observability of my traces.

import { OtelExporter } from "@mastra/otel-exporter";
import { env } from "../env.js";

export const observabilityExporter = new OtelExporter({
    provider: {
        custom: {
            endpoint: "https://app.langwatch.ai/api/otel/v1/traces",
            headers: { "Authorization": `Bearer ${env.LANGWATCH_API_KEY}` },
        },
    },
})

Then you can see the traces in the dashboard.

Human Testing the app

To test the application, I will use the iPhone simulator.

et voila!

Conclusions

This article demonstrates a complete, end-to-end implementation for deploying a powerful, private AI assistant accessible via a mobile application.

By combining the accessibility of Expo on the frontend with the robustness of AWS Lambda and S3 on the backend, we created a scalable RAG solution.

A core takeaway is the effective orchestration of the AI Agent using Mastra. The agent is configured with multiple tools, including RAG for documentation and specific data fetching functionalities. This tool-calling capability is crucial for delivering diverse and context-specific responses directly to the user.

Furthermore, integrating LangWatch proved invaluable for ensuring the agent’s reliability. The use of scenarios for testing agent behavior, especially its tool-use decisions, confirms that the system adheres to the defined prompts and requirements before deployment.

This makes a personal assistant a very achievable goal.

Launching your RAG system on AWS: CloudFront, Lambda, Bedrock & S3 Vectors

Sergio Esteban — Mon, 24 Nov 2025 19:05:52 +0000

A step by step guide with AI SDK, AWS and Terraform

Introduction

In this post I revisit the implementation of an AI Agent, this time adding the ability to return responses tied to a specific context.

TLDRS

All code used in this article is available in the repository.

Context

As usual, I rely on Serverless services to launch the experiment quickly. With the new capabilities AWS is rolling out, the agent will stream responses in real time as they are generated.

Below is a high level diagram representing the target architecture.

Scope

For this project I will implement a RAG system using serverless services.

We can outline the following requirements for a low volume of 1000 requests per month.

Functional requirements

The system should allow sending messages and receiving a response in real time as it is generated.
The system should restrict access only through the predefined domain.
The system should respond only when the question is related to the previously provided content.

Non functional requirements

As usual we can rely on serverless capabilities and add a few additional characteristics.

The system should be highly available
The system should scale automatically to handle variable traffic patterns
The system should remain secure with domain level access control and encrypted traffic

Out of Scope

This article does not cover data ingestion for the context that the system will use when answering.

However, notebooks are available for testing.

It is also worth mentioning that being possible does not mean this is the ideal way to expose an Agent.

With that out of the way, let’s move on.

Cost breakdown

We are running a serverless RAG application with the following components

Considering a volume of 1k requests per month, we can list the following.

Bedrock API Calls

We will use the most cost effective models, Nova Micro and Titan Embed v2, for language inference and embeddings.

Nova Micro input (500K tokens × 0.00035 USD) plus output (500K tokens × 0.0014 USD)
Titan Embed v2 (500K tokens × 0.0001 USD) plus vector search operations

This gives us an approximate total of 1.05 USD per month.

AWS Lambda

We will configure a function with 512 MB and a 60 second timeout. This results in roughly 0.20 USD per month.

CloudFront

We will use PriceClass_100 (US and Europe) assuming minimal data transfer and HTTPS requests.

This results in about 0.085 USD per month.

Container Registry

For storing the Lambda function image, estimating 1 GB for the Docker image and handling all traffic within the same region.

This results in about 0.10 USD per month.

Route53

We will use a hosted zone regardless of traffic.

This results in about 0.50 USD per month.

CloudWatch

For logging with seven day retention.

This results in about 0.01 USD per month.

This brings us to a total of approximately 1.95 USD per month. This aligns with the low requirements we defined for model responses.

Let’s continue.

Implementation

S3 Vector

Terraform does not currently support S3 Vector resources, so everything must be created using the AWS CLI.

First, create the bucket.

aws s3vectors create-vector-bucket \      
  --vector-bucket-name "$VECTOR_BUCKET_NAME" \
  --region "$REGION" \
  --profile "$PROFILE"

Next, we will create the Index inside the bucket.

aws s3vectors create-index \
  --vector-bucket-name "$VECTOR_BUCKET_NAME" \
  --index-name "$VECTOR_BUCKET_NAME" \
  --data-type float32 \
  --dimension 1024 \
  --distance-metric cosine \
  --metadata-configuration nonFilterableMetadataKeys=id,chunk \
  --region "$REGION" \
  --profile "$PROFILE"

To continue, we will need the ARN.

aws s3vectors list-indexes \
    --vector-bucket-name "$VECTOR_BUCKET_NAME" \
    --region "$REGION" \
    --profile "$PROFILE" \
    --query "Indexes[?IndexName=='$INDEX_NAME'].IndexArn" \
    --output text 2>/dev/null || echo "Unable to retrieve ARN"

With these resources in place we can move forward using Terraform.

Unlike my previous article, this version will stream responses as they are generated.

Lambda creation

To support streamed responses we need to use streamText together with @types/aws-lambda.

The following is the final result.

import { pipeline } from 'node:stream/promises';
import { config } from "./bedrock/config";
import { streamText } from 'ai';
import { bedrock } from './bedrock/model';
import { findRelevantContent } from './bedrock/query-vector';
import type { APIGatewayProxyEventV2 } from 'aws-lambda';

exports.handler = awslambda.streamifyResponse<APIGatewayProxyEventV2>(
    async (event, responseStream, _context) => {
        try {
            responseStream.setContentType('text/plain; charset=utf-8');
            let prompt = '';
            if (event.body) {
                try {
                    const body = JSON.parse(event.body);
                    if (body.prompt) prompt = body.prompt;
                } catch (e) {
                    console.warn('Failed to parse request body:', e);
                }
            }

            if (!prompt) {
                responseStream.write('Error: No prompt provided');
                responseStream.end();
                return;
            }

            const { modelId } = config({});
            const similarDocuments = await findRelevantContent(prompt);
            const context = similarDocuments.map(doc => doc.chunk).join('\n\n');

            const systemPrompt = `You are a helpful assistant. Answer the user's question using ONLY the context provided below. 
            If the answer is not in the context, say "I don't know" or "The provided context does not contain the answer."
            Do not hallucinate or use outside knowledge.

            Context:
            ${context}`;

            const result = await streamText({
                model: bedrock(modelId),
                system: systemPrompt,
                messages: [
                    { role: "user", content: prompt },
                ],
            });
            await pipeline(result.textStream, responseStream);
            return;

        } catch (error) {
            console.error("Error in handler:", error);
            responseStream.write('Error');
            responseStream.end();
        }
    }
);

With the general logic ready, we can move on to implementing semantic search inside our Vector Index.

Semantic search using Vector S3

We need to take the user message and generate embeddings using the amazon.titan-embed-text-v2:0 model.

Once we get the model response, we parse the result according to our needs. In this case we know each chunk contains the raw text we will use to look for relevant content.

With this simple flow we return additional context to the model so it can produce a response.

import { embed } from "ai";
import { bedrock } from "./model";
import { env } from "../env";
import { QueryVectorsCommand, S3VectorsClient } from '@aws-sdk/client-s3vectors'
import { config } from "./config";

export interface VectorMetadata {
    id: string
    chunk: string
}

const s3Vectors = new S3VectorsClient({})

export const findRelevantContent = async (query: string) => {
    const text = query.replaceAll('\\n', ' ');
    const { modelId } = config({ modelId: 'amazon.titan-embed-text-v2:0' })
    const { embedding: userQueryEmbedded } = await embed({
        model: bedrock.textEmbeddingModel(modelId),
        value: text,
        providerOptions: {
            bedrock: {
                normalize: true
            }
        },
    });
    const input = {
        indexArn: env.AWS_VECTOR_BUCKET_INDEX_ARN!,
        queryVector: {
            float32: userQueryEmbedded,
        },
        topK: 5,
        returnMetadata: true,
        returnDistance: true,
    }
    const result = await s3Vectors.send(new QueryVectorsCommand(input));

    if (!result.vectors || result.vectors.length === 0) {
        console.log('No vectors found for the query')
        return []
    }

    return result.vectors.map(v => {
        const metadata = v.metadata as VectorMetadata | undefined
        if (!metadata) {
            throw new Error('Metadata is required in the vector response')
        }

        if (!metadata.id || !metadata.chunk) {
            throw new Error('Vector metadata must contain id and chunk fields')
        }

        return {
            id: metadata.id,
            chunk: metadata.chunk,
            key: v.key,
            distance: v.distance,
        }
    })

}

It is important to note that the retrieved results do not always represent the right context. To get higher quality responses we need to spend more time preparing the data we process.

Docker

To package our solution we define the Lambda.

# ---- Build Stage ----
FROM public.ecr.aws/lambda/nodejs:22 AS builder

WORKDIR /usr/src/app
RUN corepack enable

COPY package.json pnpm-lock.yaml* ./

RUN pnpm install --frozen-lockfile

COPY . .

RUN pnpm run build

# ---- Runtime Stage ----
FROM public.ecr.aws/lambda/nodejs:22

WORKDIR ${LAMBDA_TASK_ROOT}

COPY --from=builder /usr/src/app/dist/ ./
COPY --from=builder /usr/src/app/node_modules ./node_modules

ENTRYPOINT [ "/lambda-entrypoint.sh", "index.handler" ]

With this in place we can move on to creating the cloud resources.

Infrastructure

Container registry

We need a centralized location to host our Docker images.

resource "aws_ecr_repository" "warike_development_ecr" {
  name                 = "ecr-${local.project_name}"
  image_tag_mutability = "IMMUTABLE_WITH_EXCLUSION"

  encryption_configuration {
    encryption_type = "AES256"
  }

  image_scanning_configuration {
    scan_on_push = true
  }

  image_tag_mutability_exclusion_filter {
    filter      = "*latest"
    filter_type = "WILDCARD"
  }

  force_delete = true
}

Lambda module

For deploying our Lambda function using Docker we need to set the invocation mode to RESPONSE_STREAM, enable create_lambda_function_url, and use AWS_IAM as the authorization type.

locals {
  lambda_chat = {
    name        = "chat-${basename(path.cwd)}"
    image       = "${aws_ecr_repository.warike_development_ecr.repository_url}:chat-latest"
    description = "Lambda chat function for ${local.project_name}"
    memory_size = 512
    timeout     = 60
    env_vars = {
      AWS_BEARER_TOKEN_BEDROCK    = var.aws_bearer_token_bedrock
      AWS_BEDROCK_MODEL           = var.aws_bedrock_model
      AWS_VECTOR_BUCKET_INDEX_ARN = var.vector_bucket_index_arn
      AWS_BEDROCK_MODEL_EMBEDDING = var.aws_bedrock_model_embedding
    }
  }
}

## Lambda Chat
module "warike_development_lambda_chat" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "~> 8.1.2"

  ## Configuration
  function_name = local.lambda_chat.name
  description   = local.lambda_chat.description
  memory_size   = local.lambda_chat.memory_size
  timeout       = local.lambda_chat.timeout

  ## Package
  create_package = false
  package_type   = "Image"
  image_uri      = local.lambda_chat.image
  environment_variables = merge(
    local.lambda_chat.env_vars,
    {}
  )

  ## API Gateway
  create_current_version_allowed_triggers = false

  ## Permissions
  create_role = false
  lambda_role = aws_iam_role.warike_development_lambda_chat_role.arn

  ## Logging
  use_existing_cloudwatch_log_group = true
  logging_log_group                 = aws_cloudwatch_log_group.warike_development_lambda_chat_logs.name
  logging_log_format                = "JSON"
  logging_application_log_level     = "INFO"
  logging_system_log_level          = "WARN"

  ## Response Streaming
  invoke_mode = "RESPONSE_STREAM"

  ## Lambda Function URL
  create_lambda_function_url = true
  authorization_type         = "AWS_IAM"

  cors = {
    allow_credentials = true
    allow_origins     = ["*"]
    allow_methods     = ["*"]
    allow_headers     = ["*"]
    expose_headers    = ["*"]
    max_age           = 86400
  }

  tags = merge(local.tags, { Name = local.lambda_chat.name })

  depends_on = [
    aws_cloudwatch_log_group.warike_development_lambda_chat_logs,
    aws_ecr_repository.warike_development_ecr,
    null_resource.warike_development_build_image_seed
  ]
}

ACM and Route 53

Next, to access our Lambda function through CloudFront, we define the DNS records and a certificate.

## Amazon Certificate Manager
module "warike_development_acm" {
  source  = "terraform-aws-modules/acm/aws"
  version = "~> 6.1.0"

  domain_name               = local.domain_name
  zone_id                   = data.aws_route53_zone.warike_development_warike_tech.id
  subject_alternative_names = ["*.${local.domain_name}"]

  validation_method = "DNS"

  tags = local.tags
}

## Route 53 - Hosted Zone
data "aws_route53_zone" "warike_development_warike_tech" {
  name = local.domain_name
}

## Route 53 - Apex Record
resource "aws_route53_record" "warike_development_apex_record" {
  zone_id = data.aws_route53_zone.warike_development_warike_tech.zone_id
  name    = local.domain_name
  type    = "A"

  alias {
    name                   = module.warike_development_cloudfront.cloudfront_distribution_domain_name
    zone_id                = module.warike_development_cloudfront.cloudfront_distribution_hosted_zone_id
    evaluate_target_health = false
  }

  depends_on = [
    module.warike_development_cloudfront,
  ]
}

With everything above in place we can start configuring CloudFront.

CloudFront

For CloudFront we need to consider that an Origin Access Control will be created.

We will reference lambda_function_url from it.

module "warike_development_cloudfront" {
  source  = "terraform-aws-modules/cloudfront/aws"
  version = "~> 5.0.1"

  ## Configuration
  enabled                        = true
  price_class                    = "PriceClass_100"
  retain_on_delete               = false
  wait_for_deployment            = true
  is_ipv6_enabled                = true
  create_monitoring_subscription = true

  ## Extra CNAMEs
  aliases = ["${local.domain_name}"]
  comment = "Chat CloudFront Distribution"

  ## Origin access control
  create_origin_access_control = true

  origin_access_control = {
    "chat_lambda_function_url" = {
      description      = "CloudFront access to Lambda Function URL"
      origin_type      = "lambda"
      signing_behavior = "always"
      signing_protocol = "sigv4"
    }
  }

  origin = {
    "chat_lambda_function_url" = {
      domain_name           = trimsuffix(replace(module.warike_development_lambda_chat.lambda_function_url, "https://", ""), "/")
      origin_access_control = local.cloudfront_oac_lambda_function_url
      custom_origin_config = {
        http_port              = 80
        https_port             = 443
        origin_protocol_policy = "match-viewer"
        origin_ssl_protocols   = ["TLSv1", "TLSv1.1", "TLSv1.2"]
      }
    }
  }

  default_cache_behavior = {
    target_origin_id       = local.cloudfront_oac_lambda_function_url
    viewer_protocol_policy = "redirect-to-https"
    allowed_methods        = ["HEAD", "DELETE", "POST", "GET", "OPTIONS", "PUT", "PATCH"]
    cached_methods         = ["GET", "HEAD", "OPTIONS"]

    ## Cache policy disabled
    cache_policy_id = "4135ea2d-6df8-44a3-9df3-4b5a84be39ad"

    ## Forwarded values disabled
    use_forwarded_values = false

    ## TTL settings
    min_ttl     = 0
    default_ttl = 0
    max_ttl     = 0
    compress    = true

    function_association = {
      viewer-request = {
        function_arn = aws_cloudfront_function.warike_development_restrict_domain.arn
      }
    }
  }

  viewer_certificate = {
    acm_certificate_arn = module.warike_development_acm.acm_certificate_arn
    ssl_support_method  = "sni-only"
  }

  tags = merge(local.tags, { Name = local.cloudfront_oac_lambda_function_url })

  depends_on = [
    module.warike_development_acm,
    module.warike_development_lambda_chat,
  ]
}

resource "aws_cloudfront_function" "warike_development_restrict_domain" {
  name    = "restrict-domain-${local.project_name}"
  runtime = "cloudfront-js-1.0"
  comment = "Restrict access to custom domain only"
  publish = true
  code    = file("${path.module}/functions/auth.js")

}

CloudFront function

Additionally, I added a lightweight CloudFront function to ensure requests are directed to the predefined domain.

function handler(event) {
    var request = event.request;
    var host = request.headers.host.value;
    var allowedDomain = 'dev.zaistev.com';

    if (host !== allowedDomain) {
        return {
            statusCode: 403,
            statusDescription: 'Forbidden',
            headers: {
                "content-type": { "value": "text/plain" }
            },
            body: { "encoding": "text", "value": "Access denied. Please use the custom domain." }
        };
    }
    return request;
}

With the main resources in place we can move on to the actual cloud deployment.

Deployment

I created a set of functions that automate the deployment.

.PHONY: deploy compile-server push-image terraform-apply

# Extract current version from terraform file (e.g., chat-v1)
CURRENT_VERSION := $(shell grep -o 'chat-v[0-9]*' infra/lambda-chat.tf | head -n 1)
# Extract the number part (e.g., 1)
VERSION_NUM := $(shell echo $(CURRENT_VERSION) | sed 's/chat-v//')
# Increment the number
NEXT_VERSION_NUM := $(shell echo $$(($(VERSION_NUM) + 1)))
# Form the new version string (e.g., chat-v2)
NEXT_VERSION := chat-v$(NEXT_VERSION_NUM)

deploy: compile-server push-image terraform-apply test

compile-server:
    @echo "Compiling server app..."
    cd apps/server && pnpm install && pnpm run build

push-image:
    @echo "Current version: $(CURRENT_VERSION)"
    @echo "Next version: $(NEXT_VERSION)"
    @echo "Building and pushing Docker image..."
    ./infra/push_chat_image.sh $(NEXT_VERSION)
    @echo "Updating Terraform configuration..."
    # Update the version in the terraform file
    sed -i '' 's/$(CURRENT_VERSION)/$(NEXT_VERSION)/g' infra/lambda-chat.tf

terraform-apply:
    @echo "Applying Terraform changes..."
    cd infra && terraform apply -auto-approve

test:
    @echo "Running integration tests..."
    ./infra/test_stream.sh

Therefore, to get it running we need to execute

make deploy

Testing

Additionally, we don’t have any context data available. This can be addressed by manually inserting data using Python.

def insert_vector(text, bucket_name, index_name):
    """
    Insert a single text chunk into the S3 Vector Index.
    """
    if not s3_vectors_client:
        print("❌ S3 Vectors client is not initialized.")
        return False

    if not bucket_name or not index_name:
        print("⚠️ S3_VECTOR_BUCKET_NAME or S3_VECTOR_INDEX_NAME is not set.")
        return False

    # Generate unique ID
    unique_id = generate_nanoid()

    # Generate embedding
    embedding = get_embedding(text)
    if not embedding:
        print(f"❌ Failed to generate embedding for text: {text[:50]}...")
        return False

    # Create metadata
    metadata = {
        "id": unique_id,
        "chunk": text
    }

    try:
        # Insert vector into S3 Vector Index
        response = s3_vectors_client.put_vectors(
            vectorBucketName=bucket_name,
            indexName=index_name,
            vectors=[
                {
                    "key": unique_id,
                    "data": {"float32": embedding},
                    "metadata": metadata
                }
            ]
        )

        print(f"✅ Inserted vector with ID: {unique_id}")
        print(f"   Text preview: {text[:80]}...")
        return True

    except Exception as e:
        print(f"❌ Error inserting vector: {e}")
        return False

# Insert all predefined texts
print("\n🚀 Starting vector insertion...\n")
success_count = 0
fail_count = 0

for i, text in enumerate(predefined_texts, 1):
    print(f"\n[{i}/{len(predefined_texts)}] Processing...")
    if insert_vector(text, s3_vector_bucket_name, s3_vector_index_name):
        success_count += 1
    else:
        fail_count += 1

print(f"\n\n📊 Insertion Summary:")
print(f"   ✅ Successful: {success_count}")
print(f"   ❌ Failed: {fail_count}")
print(f"   📝 Total: {len(predefined_texts)}")

Later, if we test with available context, we can get a result like the following.

🔍 Testing with query: 'Explain how EventBridge works in LLM Workflow context?'

✅ Found 3 similar vectors:

1. ID: HlgHN84M1CUmWH3q5tzHl
   Distance: 0.4293
   Text: An application emits an event (for example, {"type": "orderCreated", "priority": "high"}). Amazon EventBridge evaluates the event against its routing rules. Based on an event's attributes, the system dynamically dispatches to the following: HighPriorityOrderProcessor (service A), StandardOrderProcessor (service B), UpdateOrderProcessor (service C). This pattern supports loose coupling, domain-based specialization, and runtime extensibility. This allows systems to respond intelligently to changing requirements and event semantics.

2. ID: Pv2Y1r0zYKxdFRrToZ0fo
   Distance: 0.5672
   Text: LLM-based routing: In agentic systems, routing also performs dynamic task delegation - but instead of Amazon EventBridge rules or metadata filters, the LLM classifies and interprets the user's intent through natural language. The result is a flexible, semantic, and adaptive form of dispatching.

3. ID: Cp98hjhcis6SSNooIuhZ8
   Distance: 0.6386
   Text: Agent router workflow: A user submits a natural language request through an SDK. An Amazon Bedrock agent uses an LLM to classify the task (for example, legal, technical, or scheduling). The agent dynamically routes the task through an action group to invoke the required agent: Domain-specific agent, Specialized tool chain, Custom prompt configuration. The selected handler processes the task and returns a tailored response.

Conclusions

Building this context-aware Agent proves that serverless RAG is both practical and cost-efficient. By pairing the AI SDK with AWS Lambda, we achieved real-time streaming without the operational overhead of complex implementation, and yes, I mean WebSockets on Lambda.

We had to rely on the AWS CLI for S3 Vectors since native Terraform support is currently missing. While this adds a manual step, it effectively removes the need for a dedicated and expensive vector database.

Ultimately, this architecture provides a secure and scalable starting point. With CloudFront and Docker in place, you have a system that keeps costs remarkably low.

References

https://aws.plainenglish.io/uploading-documents-to-s3-vector-buckets-f418594feca3
https://dev.to/aws-builders/ai-sdk-streaming-text-from-lambda-cfd
https://docs.aws.amazon.com/lambda/latest/dg/configuration-response-streaming.html

Warike technologies

Launching Your AI Agent on AWS: Bedrock, Lambda & API Gateway

Sergio Esteban — Sat, 08 Nov 2025 14:34:29 +0000

Introduction

In this post, I’m going to explore the implementation of a service that allows us to send a questions and receive an answer back. Sending a question would be handle as a prompt to a specific model using Bedrock.

To minimize the costs of this implementation, I’ll be utilizing the services of API Gateway, AWS Lambda, and Amazon Bedrock.

Context

When we want to implement a Generative AI service, there are several possible paths, and we must take the time to understand the minimal requirements before making a decision.

In this post, I will demonstrate the process of deploying a simple GenAI solution that we can either connect to our current solution or expose to a third party via API Gateway.

TLDR

All the content for this implementation can be found in this repository.

Scope

For this implementation, I’m going to define a set of quite simple requirements.

Below is a diagram that represents the implementation we will be building.

Functional Requirements

We should be able to send a prompt and receive a responsein the form of model completion from Nova Micro.
We should be able to expose an HTTP endpoint to trigger the process of generating a response.
Let's estimate, for the sake of cost calculations, that we will serve a monthly volume of 100 requests.

Non-Functional Requirements

Since we're using AWS serverless services, we can lean on their built in features for our non-functional requirements.

For automation, the deployment should be handled completely by GitHub Actions. When it comes to availability, the API needs to maintain a monthly uptime of 99.9% or higher.

On the security front, we'll need IAM-scoped access for Bedrock, use OpenID Connect for authentication, and ensure all traffic is HTTPS only.

And finally, for observability, we must have structured logs that capture metadata, token usage, and any errors, all visualized with CloudWatch dashboards.

Simple.

What is Out of Scope?

For this implementation, I will be excluding authentication, sanitization, authorization and any security processes applied to the requests. This approach allows me to focus on the general GenAI implementation process.

Cost Breakdown per service

Given the predefined volume, we can estimate an average usage per request of 22 input tokens and 232 output tokens.

Amazon Bedrock (Nova Micro)

The Nova Micro model is processing 2,200 input tokens and 23,200 output tokens monthly. This runs about $0.003/month. Output tokens cost more than input about x 4 times.

AWS Lambda

Considering only 100 invocations and maybe 3 to 5 seconds per call** with 512MB memory, we are nowhere near the Free Tier limits. Lambda gives us 1 million requests and 400,000 GB-seconds free every month.

API Gateway

For the first year, we get 1 million requests free. After that, we are looking at maybe $0.0004/month.

Amazon ECR

That 300MB Docker imagesitting in ECR costs about a cent a month. After the 500MB Free Tier, we are paying for around 136MB of storage.

What Happens When It Scales?

If it reaches 1,000 requests monthly, costs are around $0.04. At 10K requests, it's about $0.39. Even at 100K requests, we are only paying about **$3.76/month.

Alrighty, let's move ahead.

Implementation

To begin the implementation, we can start by creating the agent.

Creating the Agent

To create the agent, I first need to set up the complete TypeScript project.

We can move quickly by following these instructions and installing the necessary dependencies so the project can operate correctly.

Feel free to use the configuration that suits you best.

mkdir -p handler terraform 
cd handler
pnpm init -y
pnpm --package=typescript dlx tsc --init
mkdir -p src __tests__
touch src/{app,env,index}.ts 

pnpm add -D @types/node tsx typescript
pnpm add ai @ai-sdk/amazon-bedrock
pnpm add zod dotenv

In this project, I will define three fundamental parts:

Logic for compatibility with AWS Lambda.
Logic to manage requests as prompts, solicit the text generation based on these, and handle their potential future evolution.
Core logic for the actual text generation using the @ai-sdk and Bedrock invocations.

Below is a summary of the project’s main files.

import { main } from "./app";

export const handler = async (event: any, context: any) => {
    try {
        const body = event.body ? JSON.parse(event.body) : {};
        const prompt = body.prompt ?? "Welcome from Warike technologies - GenAI solutions architecture";
        const response = await main(prompt);
        return {
            statusCode: 200,
            body: JSON.stringify({
                success: true,
                data: response,
            }),
        };
    } catch (error) {
        console.error('Error in Lambda handler:', error);
        return {
            statusCode: 500,
            body: JSON.stringify({
                success: false,
                error: error instanceof Error ? error.message : 'An unexpected error occurred'
            }),
        };
    }
};

// app.ts
import { generateResponse } from "./utils/bedrock";

export async function main(prompt: string) {
    try {
        console.log('🚀 Starting Bedrock:');
        return await generateResponse(prompt)
    } catch (error) {
        console.error('An unexpected error occurred running workflow:', error);
        throw error;
    }

}

// utils/bedrock.ts
import { config } from "./config";
import { createAmazonBedrock } from '@ai-sdk/amazon-bedrock';
import { generateText } from 'ai';

export async function generateResponse(prompt: string){
  const { regionId, modelId } = config({ });
  try {
    const bedrock = createAmazonBedrock({ 
        region: regionId
    });

    const { text, usage } = await generateText({
        model: bedrock(modelId),
        system: "You are a helpful assistant.",
        prompt: [
          { role: "user", content: prompt },
        ],
        });  
    console.log(`model: ${modelId}, \n response: ${text}, usage: ${JSON.stringify(usage)}`);
    return text;

  } catch (error) {
    console.log(`ERROR: Can't invoke '${modelId}'. Reason: ${error}`);
  }
}

For local testing, I've defined the following environment variables. We can use an AWS Bedrock API key for testing purposes.

AWS_REGION=us-west-2
AWS_BEDROCK_MODEL='amazon.nova-micro-v1:0'
AWS_BEARER_TOKEN_BEDROCK='aws_bearer_token_bedrock'

It's highly recommended to only use Short-term API keys to avoid compromising the system's security.

Defining the Infrastructure

Now that the system's logic is functional, we can create its Dockerfile, which will facilitate its deployment to AWS Lambda.

# ---- Build Stage ----
FROM node:22-alpine AS builder

WORKDIR /usr/src/app
RUN corepack enable

COPY package.json pnpm-lock.yaml* ./

RUN pnpm install --frozen-lockfile

COPY . .

RUN pnpm run build

# ---- Runtime Stage ----
FROM public.ecr.aws/lambda/nodejs:22

WORKDIR ${LAMBDA_TASK_ROOT}

COPY --from=builder /usr/src/app/dist/src ./ 
COPY --from=builder /usr/src/app/node_modules ./node_modules

CMD [ "index.handler" ]

With all components ready in our handler, we can proceed to define the resources in Terraform.

Exposing the Service with API Gateway

We'll start by defining our API Gateway. We'll use the HTTP protocol and focus solely on creating the API, its stage, and its subsequent integration with Lambda.

locals {
  api_gateway_name = "dev-http-${local.project_name}"
}

module "warike_development_api_gw" {
  source  = "terraform-aws-modules/apigateway-v2/aws"
  version = "5.4.1"

  name          = local.api_gateway_name
  description   = "API Gateway for ${local.project_name}"
  protocol_type = "HTTP"

  create_domain_name    = false
  create_certificate    = false
  create_domain_records = false

  cors_configuration = {
    allow_headers = ["*"]
    allow_methods = ["*"]
    allow_origins = ["*"]
  }

  # Access logs
  stage_name        = "dev"
  stage_description = "Development API Gateway"


  stage_access_log_settings = {

    create_log_group = false
    destination_arn = aws_cloudwatch_log_group.warike_development_api_gw_logs.arn

    format = jsonencode({
      context = {
        requestId               = "$context.requestId"
        requestTime             = "$context.requestTime"
        protocol                = "$context.protocol"
        httpMethod              = "$context.httpMethod"
        resourcePath            = "$context.resourcePath"
        routeKey                = "$context.routeKey"
        status                  = "$context.status"
        responseLength          = "$context.responseLength"
        integrationErrorMessage = "$context.integrationErrorMessage"

        error = {
          message      = "$context.error.message"
          responseType = "$context.error.responseType"
        }
        identity = {
          sourceIP = "$context.identity.sourceIp"
        }
        integration = {
          error             = "$context.integration.error"
          integrationStatus = "$context.integration.integrationStatus"
        }
      }
    })
  }

  # Routes & Integration
  routes = {
    "POST /" = {
      integration = {
        uri                    = module.warike_development_lambda.lambda_function_arn
        payload_format_version = "2.0"
      }
    }
  }

  stage_tags = merge(local.tags, {
    Name = "${local.api_gateway_name}-dev"
  })

  tags = merge(local.tags, {
    Name = local.api_gateway_name
  })

  depends_on = [
    aws_cloudwatch_log_group.warike_development_api_gw_logs,
  ]
}

resource "aws_cloudwatch_log_group" "warike_development_api_gw_logs" {
  name              = "/aws/api-gw/${local.api_gateway_name}"
  retention_in_days = 7
}

Connecting to Amazon Bedrock

Next, to utilize Amazon Bedrock, this implementation will use the Amazon Nova Micro inference profile in the US region.

locals {
  model_id = "amazon.nova-micro-v1:0"
}

data "aws_bedrock_inference_profile" "warike_development_lambda_bedrock_model" {
  inference_profile_id = "us.${local.model_id}"
}

## Bedrock Policy ##
data "aws_iam_policy_document" "warike_development_lambda_bedrock_policy_doc" {
  statement {
    effect = "Allow"
    actions = [
      "bedrock:InvokeModel",
    ]
    resources = ["*"]
  }
}

Lambda Service

Finally, we'll create the Lambda function associated with all the components we've created, along with others that can be found in the repository.

locals {
  lambda_function_name = local.project_name
  lambda_env_vars = {
    AWS_BEDROCK_MODEL = data.aws_bedrock_inference_profile.warike_development_lambda_bedrock_model.inference_profile_arn
  }
}

module "warike_development_lambda" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "8.1.2"

  function_name = local.lambda_function_name
  description   = "Lambda function for ${local.project_name}"

  image_uri               = "${aws_ecr_repository.warike_development_ecr.repository_url}:latest"
  package_type            = "Image"
  create_package          = false
  ignore_source_code_hash = true
  memory_size             = 128
  timeout                 = 900

  environment_variables = merge(
    local.lambda_env_vars,
    {}
  )

  create_role = false
  lambda_role = aws_iam_role.warike_development_lambda_role.arn

  ## Cloudwatch logging
  use_existing_cloudwatch_log_group = true
  logging_log_group                 = aws_cloudwatch_log_group.warike_development_lambda_logs.name
  logging_log_format                = "JSON"
  logging_application_log_level     = "INFO"
  logging_system_log_level          = "WARN"

  ## function URL
  create_lambda_function_url = false

  depends_on = [
    aws_cloudwatch_log_group.warike_development_lambda_logs,
    null_resource.warike_development_seed_ecr_image
  ]

  tags = merge(local.tags, {
    Name = local.lambda_function_name
  })

}

resource "null_resource" "warike_development_seed_ecr_image" {
  provisioner "local-exec" {
    command = <<EOT
      aws ecr get-login-password --region ${local.aws_region} --profile ${local.aws_profile} \
        | docker login --username AWS --password-stdin ${data.aws_caller_identity.current.account_id}.dkr.ecr.${local.aws_region}.amazonaws.com

      docker pull public.ecr.aws/lambda/nodejs:22
      docker tag public.ecr.aws/lambda/nodejs:22 ${aws_ecr_repository.warike_development_ecr.repository_url}:latest
      docker push ${aws_ecr_repository.warike_development_ecr.repository_url}:latest
    EOT
  }

  depends_on = [aws_ecr_repository.warike_development_ecr]
}

Important notice, warike_development_seed_ecr_image will require you to have your local docker running.

Let’s move ahead.

Creating the Resources

Once the resources are created, you should see a message similar to this:

terraform apply
...
Apply complete! Resources: 26 added, 0 changed, 0 destroyed.

Configuring CI/CD with GitHub + ECR

Additionally, we need a Docker image containing our project. The following GitHub pipeline will allow us to build and push an image to ECR, followed by its deployment to Lambda.

---
name: Lambda CI/CD Common
'on':
  workflow_call:
    inputs:
      app-name:
        type: string
      lambda-function-secret-name:
        required: true
        type: string
      pnpm-version:
        required: false
        type: number
        default: 10
      node-version:
        required: false
        type: number
        default: 22
    secrets:
      PROJECT_NAME:
        required: true
      AWS_OIDC_ROLE_ARN:
        required: true
      AWS_REGION:
        required: true
      ECR_REPOSITORY:
        required: true
      AWS_LAMBDA_FUNCTION_NAME:
        required: true
      AWS_LAMBDA_FUNCTION_ROLE_ARN:
        required: true
jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./handler
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install pnpm
        uses: pnpm/action-setup@v4
        with:
          version: ${{ inputs.pnpm-version }}

      - name: Use Node.js ${{ inputs.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}

      - name: Install Dependencies
        run: pnpm install --frozen-lockfile

      - name: Scan for critical vulnerabilities
        run: pnpm audit --audit-level=critical

      - name: Run Tests
        env:
          DOTENV_QUIET: true
        run: pnpm test:ci

      - name: Build
        run: pnpm run build

  build-docker:
    name: Build and Push Docker Image
    runs-on: ubuntu-latest
    needs: build
    permissions:
      id-token: write
      contents: read
    outputs:
      sha: ${{ steps.vars.outputs.sha }}
    defaults:
      run:
        working-directory: ./handler
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
        with:
          mask-password: 'true'

      - name: Set commit-sha
        id: vars
        run: |
          calculatedSha=$(git rev-parse --short ${{ github.sha }})
          echo "sha=${calculatedSha}" >> $GITHUB_OUTPUT

      - name: Build and Push Docker Image
        env:
          DOCKER_IMAGE: ${{ secrets.ECR_REPOSITORY }}:${{ inputs.app-name }}-${{ steps.vars.outputs.sha }}
        run: |
          echo "Building Docker image $DOCKER_IMAGE"
          docker build -t $DOCKER_IMAGE .
          docker tag $DOCKER_IMAGE "${{ secrets.ECR_REPOSITORY }}:${{ inputs.app-name }}-${{ steps.vars.outputs.sha }}"
          docker tag $DOCKER_IMAGE "${{ secrets.ECR_REPOSITORY }}:latest"
          docker push $DOCKER_IMAGE
          docker push "${{ secrets.ECR_REPOSITORY }}:${{ inputs.app-name }}-${{ steps.vars.outputs.sha }}"
          docker push "${{ secrets.ECR_REPOSITORY }}:latest"

  deploy-prod:
    name: Deploy Production Lambda
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    needs: build-docker
    permissions:
      id-token: write
      contents: read
    defaults:
      run:
        working-directory: ./handler
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE_ARN }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Deploy Production Lambda
        uses: aws-actions/aws-lambda-deploy@v1.1.0
        with:
          function-name: ${{ secrets.AWS_LAMBDA_FUNCTION_NAME }}
          package-type: Image
          image-uri: ${{ secrets.ECR_REPOSITORY }}:${{ inputs.app-name }}-${{ needs.build-docker.outputs.sha }}

And if everything is correct, we will be in a position to test Amazon Bedrock.

Testing

Let's perform a test. From our terminal, we can make the following query and observe the result:

curl -sS "https://123456.execute-api.us-west-2.amazonaws.com/dev/" \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Heeey hoe gaat het?"}' | jq

The expected output is something like this:

{
  "success": true,
  "data": "Hoi! Het gaat prima, bedankt voor het vragen. Hoe gaat het met jou? Is er iets waar ik je kan helpen of iets waar je graag over wilt praten?"
}

I call that a success.

Observability

It is important to mention that we can monitor any errors from CloudWatch, so we don't have to navigate in the dark.

Cleaning

Finally, we clean up the resources.

terraform destroy
...
Destroy complete! Resources: 26 destroyed.

Conclusions

Overall, implementing this GenAI service using AWS serverless components was quite straightforward.

The combination of API Gateway, AWS Lambda, and Amazon Bedrock, specifically with the Nova Micro model, proves to be not only functional but also incredibly cost-effective. The analysis showed that this solution remains exceptionally inexpensive, even when (manually) scaling traffic significantly.

By leveraging Terraform for infrastructure management and GitHub Actions for the CI/CD pipeline, we achieved a robust and fully automated deployment process.

Finally, even by excluding aspects like authentication, it provides a solid and scalable foundation for building more complex Generative AI applications.