AWS Bedrock Application Development

Why AWS hosted teams build on Bedrock

When your application, data and operations already live in AWS, sending prompts to an outside provider means new contracts, new keys, new network paths and a new security review. Amazon Bedrock avoids most of that. Models from several providers are reached through AWS endpoints, authorized with IAM, logged with CloudWatch and CloudTrail, and covered by agreements you already hold. AWS states that Bedrock does not use your prompts and outputs to train the base models or share them with model providers.

Tepia sees three common starting points. A logistics platform on AWS wants a plain language summary of each shipment exception for its customer service team. An ecommerce company with product data in Aurora wants shoppers to ask detailed compatibility questions. A healthcare software company with an existing AWS business associate addendum wants clinical staff to search internal protocols, and needs to confirm the services involved are eligible for that workload.

In each case Tepia adds Bedrock to the existing architecture as new services in your current accounts, deployed with the same pipelines, tagging and monitoring as everything else you run.

Bedrock building blocks and when Tepia uses them

Bedrock offers managed components on top of model access. Some save months; others constrain you. This is how Tepia decides:

For long running or approval based workflows, Tepia usually orchestrates with Step Functions and calls Bedrock at each step, which keeps state visible and auditable.

A reference architecture on AWS

Tepia adapts one proven layout to each client’s account structure:

• Entry: API Gateway or an Application Load Balancer in front of Lambda functions or ECS services that hold the AI logic.
• Model access: a VPC interface endpoint for Bedrock, with IAM policies restricted to approved model identifiers.
• Retrieval: source files in S3 and vectors in OpenSearch Serverless or Aurora PostgreSQL with pgvector, chosen based on what your team already operates.
• Workflow: Step Functions for multi step jobs such as reading a document, extracting fields, validating them and writing to your database.
• Observability: model invocation logging to S3 and CloudWatch, CloudWatch alarms on errors and throttling, and CloudTrail for every API action.
• Delivery: infrastructure in AWS CDK or Terraform, promoted through your existing development, staging and production accounts.

Your web and mobile clients call the new endpoints like any other API, so a React Native or Swift app gains the feature without knowing which model sits behind it. Our backend and cloud development team owns this layer.

Choosing models inside Bedrock

Bedrock’s catalog is broad, and the right model differs by task. Tepia runs a short benchmark on your real inputs during Discovery, usually comparing two or three candidates on accuracy, response time and consistency.

• Classification and routing: a small, fast model is usually enough, and its speed matters when every request passes through it.
• Customer facing generation: a stronger model such as Claude Sonnet tends to follow tone and policy instructions more reliably.
• Embeddings: Amazon Titan or Cohere embedding models, chosen once and kept stable because changing them means reindexing everything.
• Regional capacity: model access is enabled per account and region, and cross region inference can absorb traffic peaks where your data policies allow it.

Tepia records the chosen model and version for each feature in configuration and reruns the benchmark when a new version is released, so upgrades are decided by evidence. If Claude is your primary model, see our Claude API integration page.

How Tepia approaches AWS Bedrock application development

Tepia applies its six phase process with your cloud team involved, and a US based project manager owning the schedule.

1. Discovery: review of your AWS accounts, networking, data stores and compliance scope, plus the model benchmark. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a support agent asking why a shipment missed its delivery window.
2. Design: an architecture diagram and IAM model for review, plus wireframes for every screen where AI output appears.
3. Development and Testing: infrastructure in a development account first, then services and clients. Alpha and Beta schedules with functional, user acceptance and non functional test plans for throttling, latency, Guardrails behavior and IAM boundaries.
4. Training: sessions for users, and a runbook for your DevOps team covering alarms, logs and model access.
5. Launch: promotion to production, initial ingestion of documents into the index, and support reps through rollout.
6. Support: model version reviews, capacity tuning and new features on the same foundation.

Typically Discovery takes 1 to 3 months and development and QA 2 to 6 months. Read about our process.

Bedrock, SageMaker or a direct model API

Bedrock is not the answer for every AWS team. Tepia uses a simple guide:

• Bedrock when you want hosted foundation models, accessed under AWS identity and networking, without managing servers.
• SageMaker when you are training or hosting your own models, such as a demand forecast or a custom vision model on proprietary images.
• A provider’s own API when your app is not on AWS, or when you need a model feature the day it is released.
• A packaged assistant when staff only need to chat over company documents with no custom workflow.

Tepia often combines them, for example Bedrock for generation and a SageMaker endpoint for a specialized scoring model, all behind one internal API. See RAG development for retrieval specifics, our work for past builds, and contact Tepia to review your AWS setup.

Frequently asked questions