RonBot — Technical Overview

RonBot is a lightweight web chatbot built using Amazon Lex V2 to answer questions about my AWS projects, certifications, and background, similar to how a support bot would assist users on a product or service site.

This page explains the AWS architecture behind the web chat on chatbot.html, with a focus on identity, security boundaries, and how the browser interacts safely with Amazon Lex.

Web Chat Interface

The chatbot is embedded directly into the site as a lightweight web client. All user interaction occurs in the browser, with no application server acting as an intermediary between the frontend and Amazon Lex.

The web interface is intentionally minimal. Its responsibility is limited to collecting user input, maintaining conversational context, and displaying responses returned by the Lex service.

This separation keeps the frontend untrusted and stateless, while all intent recognition, response generation, and conversation management are handled by managed AWS services.

Identity & Authentication

Because the chatbot is accessed directly from the browser, the primary design challenge is allowing the client to interact with Amazon Lex without exposing long-lived AWS credentials or introducing a custom backend server.

This is solved using Amazon Cognito Identity Pools to provide short-lived, scoped AWS credentials to unauthenticated users. The browser assumes a limited IAM role that permits only the actions required to interact with the Lex runtime API.

  • Unauthenticated access: Users do not create accounts or sign in; Cognito issues temporary credentials automatically.
  • Least privilege: The IAM role attached to the identity pool allows only Lex runtime actions, with no access to other AWS services.
  • Credential isolation: AWS credentials are never embedded in client code or exposed in static assets.

This approach enables direct browser-to-Lex communication while preserving security boundaries and avoiding the operational overhead of a custom API layer.

Request Flow & Service Boundaries

Each user message follows a simple, well-defined request path that preserves clear service boundaries and minimizes the amount of custom logic in the system.

  • User input: The browser captures the user’s message and conversation context.
  • Authenticated request: Using temporary credentials issued by Cognito, the browser sends the request directly to the Amazon Lex runtime API.
  • Managed processing: Lex handles intent recognition, dialog management, and response generation.
  • Response rendering: The Lex response is returned to the browser and rendered in the chat interface.

No application server, API Gateway, or Lambda function sits in the middle of this flow. By relying on managed AWS services, the design minimizes operational complexity while keeping responsibility boundaries explicit.

Operational & Cost Considerations

RonBot is designed to operate with minimal ongoing maintenance and predictable cost by relying exclusively on managed AWS services.

  • No always-on infrastructure: There are no servers, containers, or scheduled workloads to operate or patch.
  • Pay-per-use model: Costs scale with actual chatbot usage, with no baseline expense when idle.
  • Managed scaling: Amazon Lex and Cognito automatically handle request volume without manual capacity planning.
  • Operational visibility: CloudWatch metrics and logs provide insight into bot activity and errors without custom monitoring code.

This operational posture makes the chatbot suitable for low-traffic public sites while still following production-style security and reliability practices.

Bottom Line

This project demonstrates how a browser-based application can interact directly with managed AWS services while maintaining clear security boundaries and avoiding unnecessary backend infrastructure.

By combining Amazon Lex with Cognito-issued, short-lived credentials, the chatbot exposes AI capabilities to end users without embedding AWS credentials in the frontend or introducing custom middleware. The result is a simple, low-maintenance architecture that models a common real-world pattern for public-facing, serverless applications.

All resources are provisioned via Terraform for consistency with the rest of the portfolio.