QnABot on AWS: A CloudFormation-Deployed Chatbot That Answers From an OpenSearch Question Bank
Guidance for QnABot on AWS is a multi-channel, multi-language conversational interface (chatbot) that responds to your customer's questions, answers, and feedback. The solution allows you to deploy a fully functional chatbot across multiple channels including chat, voice, SMS and Amazon Alexa.
At a glance
- What is it?
- QnABot on AWS is an AWS Solutions guidance implementation that wires Amazon Lex, OpenSearch, Lambda and optional Bedrock models into a question-and-answer chatbot across chat, voice, SMS and Alexa. It fits teams already committed to an AWS account and willing to own the OpenSearch and Bedrock costs.
- Who is it for?
- Adopt QnABot on AWS if you already run workloads in an AWS account and need a content-managed question bank that can be reached from Lex, Alexa or Amazon Connect without building the fulfillment layer yourself. Do not adopt it if you want a vendor-hosted chatbot with no OpenSearch domain to size, or if your answers live only in documents that a retrieval system must read.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem QnABot Solves: A Curated Answer Bank With a Fulfillment Layer Attached
Most chatbot projects stall in the same place. Someone has to build the retrieval layer, the conversation state, the admin interface for editing answers, and the channel adapters for web chat, voice and SMS. QnABot on AWS is an attempt to ship that whole assembly as a CloudFormation stack. The README describes it as a multi-channel, multi-language conversational interface that responds to questions, answers and feedback, deployed across chat, voice, SMS and Amazon Alexa. The intended users are administrators who edit content in a browser UI and end users who ask questions through whichever channel their organization already supports. The stated goals include reducing call center wait times by automating support workflows. That framing matters: this is a support-automation tool, not a general agent framework. The unit of content is a question with an answer, stored in an OpenSearch index the README calls the questions bank. If your knowledge is already structured as question and answer pairs, the model fits. If it is a pile of PDFs, you are relying on the optional retrieval paths described later, and those are configured separately.
How the Question Bank, Lex and the Fulfillment Lambda Fit Together
The flow in the README is worth following closely because it determines where your costs and failure points sit. An admin authenticates through Amazon Cognito and loads the Content Designer UI, which API Gateway and Amazon S3 serve. Saving a question sends a request to API Gateway, which invokes the Content Designer Lambda. That function writes to an OpenSearch questions bank index. If text embeddings are enabled, the request first passes through a model hosted on Amazon Bedrock to generate the embedding before the write. Configuration settings, both default and custom, go to DynamoDB. On the user side, Lex forwards requests to the Bot Fulfillment Lambda; Alexa devices can call the same function. User and chat information is stored in DynamoDB so that follow-up questions can be disambiguated against earlier context. Amazon Comprehend and Amazon Translate handle non-native language requests before the lookup. When no match comes back from OpenSearch, two fallbacks exist: an Amazon Kendra index, or a Bedrock Knowledge Base that the fulfillment Lambda queries with the RetrieveAndGenerate or RetrieveAndGenerateStream APIs. Streaming responses go over a WebSocket connection established through API Gateway V2 using the Lex sessionId. That is a lot of moving parts, and each one is a separate service with its own quota and pricing model.
Guardrails Sit at Three Points in the Request Path
The README describes guardrails in three positions, and the distinction is practical rather than cosmetic. Pre-processing guardrails scan and block harmful user input before it reaches the application. Bedrock guardrails apply contextual controls during LLM inference. Post-processing guardrails scan, mask or block content in the final response before it is sent to the client through the fulfillment Lambda. The README explicitly names PII masking as a post-processing concern. The design implication is that a request can be rejected at three different stages, and an operator debugging an unexpected refusal needs to know which stage produced it. Nothing in the supplied material describes how these guardrail outcomes are surfaced to the admin, so treat that as an open question to resolve in your own deployment rather than something the documentation answers.
Deploying the Stack and Where the Configuration Lives
Deployment is through the AWS CloudFormation template referenced in the README, with the default parameters producing the architecture in Figure 1. The README points to the implementation guide for the full procedure and to a separate page for modifying configuration settings. Those settings are stored in DynamoDB, and the README links the specific documentation page for them rather than listing keys inline. The optional capabilities are enabled by their own documentation paths: semantic matching using LLM embeddings, LLM retrieval and generative question answering, and Kendra fallback each have a dedicated README under source/docs. A Bedrock Knowledge Base is activated by configuring a knowledge base ID, per the retrieval documentation. The admin interface is the Content Designer UI, and there is also an Amazon Lex web client. Beyond the CloudFormation template and the configuration page, the supplied material does not include literal command lines, so any shell commands you run will come from the implementation guide, not from this review. Verify the guide against the release tag you intend to deploy.
Where QnABot Is the Wrong Tool
The architecture has a hard dependency on Amazon OpenSearch Service as the primary answer store. That means an OpenSearch domain to provision, size and pay for, plus the operational work of keeping it healthy. For a small team with a few hundred answers and no existing OpenSearch footprint, that is a large amount of infrastructure for the retrieval volume involved. The second constraint is that the primary path is a question bank, not document retrieval. If your content changes constantly and lives in documents, you are leaning on the Kendra or Bedrock Knowledge Base fallbacks, and the README describes those as triggers that fire only when no match is returned from OpenSearch. That ordering means a stale or low-quality question bank entry can shadow a better answer sitting in your document index. The third constraint is LLM dependence for the advanced modes. Embeddings, text generation and knowledge base retrieval all route through Amazon Bedrock, so model availability in your region and your account's access to those models become deployment prerequisites. None of this is disqualifying, but it does mean the default deployment is not a lightweight one.
Amazon Lex Alone Versus QnABot's Retrieval Layer
Amazon Lex is the obvious comparison because QnABot sits on top of it. Lex gives you intents, slots and a fulfillment hook. What it does not give you is a content management interface, a searchable answer index, or a fallback chain into document retrieval. QnABot adds the Content Designer UI, the OpenSearch questions bank, the DynamoDB configuration and session store, the Comprehend and Translate preprocessing, and the Kendra and Bedrock Knowledge Base fallbacks. The trade is control for assembly: with plain Lex you write and own the fulfillment logic and decide where answers come from, and you avoid running an OpenSearch domain. With QnABot you inherit a working end-to-end path and the operational surface that comes with it. If your answers are already in a system with an API, a custom Lex fulfillment function may be less infrastructure than standing up this stack. If you want the admin UI and the multi-channel wiring without building them, QnABot is the shorter path.
Upgrade Cadence, Observability and Licence
The repository shows a steady release cadence, with v7.4.6, v7.4.5 and v7.4.4 all published within August 2026 and the last push to the default branch in September 2026. Frequent releases are convenient for fixes and inconvenient for anyone who pins a version, because each upgrade is a CloudFormation stack update against live infrastructure. The observability story is built in: interactions with the Bot Fulfillment function generate logs and metrics that go to Amazon Kinesis Data Firehose and then to Amazon S3, and OpenSearch Dashboards can show usage history, logged utterances, no-hit utterances and positive or negative user feedback, with custom reports available. A CloudWatch dashboard created by QnABot covers operational health. That is a real advantage over hand-rolled fulfillment code, where you build the logging yourself. The licence is Apache-2.0, which permits commercial use and modification; the AWS Solutions guidance framing means AWS publishes the implementation rather than operating it for you, so support and patching remain your responsibility. This is not legal advice, and you should read the licence text and the AWS solutions terms before relying on either.
Editorial conclusion
Adopt QnABot on AWS if you already run workloads in an AWS account and need a content-managed question bank that can be reached from Lex, Alexa or Amazon Connect without building the fulfillment layer yourself. Do not adopt it if you want a vendor-hosted chatbot with no OpenSearch domain to size, or if your answers live only in documents that a retrieval system must read. Before committing, verify which Bedrock models and regions are available to your account, confirm the OpenSearch instance type the default CloudFormation parameters create, and check the current release tag against the deployment instructions rather than assuming the main branch is what you should ship.
Community notes