Choosing AWS services can feel overwhelming when you are building your first application. You may know that you want a website or an online store, but understanding why you need a delivery network, an API, compute, and a database is another challenge.

I built CloudMentor AI for students, solo developers, and curious builders who want an understandable starting point for their AWS architecture.

The idea is simple: describe your application, answer a few useful questions, and explore a reference architecture. Then click each service to understand what it contributes to the design.

Hosted frontend demo: Try CloudMentor AI 

Source code: CloudMentor AI on GitHub 

The hosted frontend currently runs an offline demonstration with illustrative pricing. The real Amazon Bedrock tests described below ran through the local frontend and backend. Hosted backend connectivity has not yet been demonstrated.

CloudMentor asks about monthly requests, database requirements, storage, and monthly data transfer. These questions help establish the workload before recommending a reference architecture.

For example, monthly users are different from monthly requests. A person might visit an application once and generate many requests. CloudMentor keeps these quantities separate instead of quietly treating them as interchangeable.

Once the requirements are confirmed, the interface presents a diagram, an architecture story, a partial cost illustration, and design review information. Builders can select individual services and export their design as JSON.

The cost illustration uses mock rates and identifies missing charges. It does not represent a complete monthly AWS bill.

The frontend uses React, TypeScript, Vite, and React Flow. The conversation panel sits beside an interactive architecture diagram, allowing builders to connect the explanation with the services they are exploring.

The Python backend uses FastAPI and Pydantic. Requirements and architecture data are validated outside the model. Session capability tokens protect access to individual sessions.

For conversational explanations, I integrated the Strands Agents SDK with Amazon Bedrock, using Amazon Nova Lite with model ID amazon.nova-lite-v1:0 in us-east-1.

The implementation explicitly executes two local, read-only catalog tools: get_architecture_patterns and get_service_metadata. These provide curated information about the supported architecture and its services. They cannot provision infrastructure, modify IAM, or execute shell commands.

There is an important boundary in the implementation: requirement extraction, reference-pattern selection, graph construction, and Story Mode content are deterministic. Bedrock generates the conversational explanation. The model does not independently invent an architecture or calculate a verified AWS bill.

The static website reference includes Amazon CloudFront and Amazon S3. The e-commerce reference also includes Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. These services appear as recommendations; the diagrams do not prove that those resources have been deployed.

AWS Amplify hosts the public frontend. During the real inference tests, the backend ran locally and sessions used memory storage.

My favorite feature is Architecture Story Mode.

When a builder selects a service, they can switch between Beginner, Developer, and Architect explanations while keeping that service highlighted in the diagram.

At the Beginner level, CloudFront is explained as a nearby delivery center for cached website content. Developer mode introduces implementation considerations. Architect mode adds questions about failure isolation, recovery objectives, and service quotas.

The goal is to let someone explore the same design at different depths without losing their place.

I verified this interaction through browser automation. During the Bedrock-connected e-commerce test, the browser selected AWS Lambda, switched through all three explanation levels, and checked that each displayed content. Earlier local browser tests also checked keyboard selection and explanation switching.

These checks demonstrate that the interaction behaves as intended. I have not conducted a user study, so I cannot claim measured improvements in understanding or enjoyment.

On October 10, 2026, I ran controlled tests through the actual browser, local FastAPI backend, Strands integration, and Amazon Bedrock.

The test allowance was three total inference attempts, including failures, with no automatic retries.

The static website scenario completed successfully. Amazon Bedrock returned a real Nova Lite response, the backend returned HTTP 200, and the browser displayed the explanation alongside a validated diagram containing CloudFront and S3.

The e-commerce scenario also completed successfully. The browser displayed the actual backend response and rendered a diagram containing five nodes and four connections. Browser automation then exercised Story Mode on the Lambda service.

Backend logs recorded completion of both catalog tools. This confirms explicit tool execution; it does not establish that the model autonomously selected those tools.

The two successful responses returned a combined 2,440 input tokens and 338 output tokens. The screenshots are genuine captures from these local, Bedrock-connected sessions.