Run an AI SRE Agent Entirely Inside AWS with Bedrock
An on-call question returns the threshold and the escalation owner from your own runbooks, and the answer comes back without a call to anyone outside.
- Learn more about AURA → https://www.mezmo.com/aura
- Get started today → https://github.com/mezmo/aura
- Get deployment help→ https://www.mezmo.com/contact
AURA runs against Bedrock as its model provider, using Claude Sonnet 5 served by AWS in the same region. Authentication is the normal AWS credential chain: a profile on a laptop, an IAM role in EKS.
The knowledge base is a managed Bedrock knowledge base, declared with its ID. No embedding model appears in the config, because AURA does not do the retrieval. Bedrock does, inside the account. The documents are markdown files in an S3 bucket: ops runbooks, an incident policy, and an error code reference. The knowledge base syncs straight from the bucket, and access control uses IAM like everything else.
Two questions follow, of the kind an on-call engineer would ask. The tool call is visible along with the exact query run against the knowledge base, and the answer comes back out of the runbooks: 250 failed transactions a minute, with rollback going through the release captain. The second question turns on an error code that exists nowhere on the public internet, only in these documents, and the answer is still correct.
Then the request path itself. AURA talks to Bedrock for the model and to the Knowledge Base Retrieve API for the search, and the search pulls from S3. Every one of those hops starts and ends inside the AWS account. Run it in EKS with VPC endpoints and it never touches the public internet. Every model call and every retrieval is an AWS API call, so all of it is already tracked in CloudTrail.
AURA reads and reports here. It answers from the documents and does not act on the environment.
Chapters
0:00 Why a third-party agent stalls the security review
0:29 The agent config: Bedrock provider and AWS credentials
0:47 The knowledge base and the runbooks in S3
1:22 Every model call and retrieval lands in CloudTrail
1:35 Asking a question an on-call engineer would ask
1:58 The tool call, the query, and the answer from your runbooks
2:15 An error code that exists only in your docs
2:36 Tracing every hop inside the account
3:03 What changes if you use a different model
#AISREAgent #AWS #Bedrock
Transcript
Why a third-party agent stalls the security review
0:00 Hey, welcome back. So far this month, we've grounded agents and runbooks from GitHub and from Notion, and both of those builds sent every prompt and every document through a third-party API. If you've ever pitched that to your security team, you know exactly where the conversation goes.
Today, we're building an agent where the model, the embeddings, the vector search, and the documents all stay inside our AWS account.
The agent config: Bedrock provider and AWS credentials
0:29 This is the whole agent. The provider is Bedrock, using claude-sonnet-5, served by AWS in our region. Auth uses the normal AWS credential chain. On my laptop, that's a profile. In EKS, it'd be an IAM role.
The knowledge base and the runbooks in S3
0:47 Down here is the knowledge base, using type bedrock_kb, managed equals true, and the KB's ID. There's no embedding model in this file because AURA doesn't do the retrieval. Bedrock does, inside the account.
The docs themselves are markdown files in an S3 bucket, including a couple of ops runbooks, an incident policy, and an error code reference. The knowledge base syncs straight from the bucket, and access control uses IAM, same as everything else.
Every model call and retrieval lands in CloudTrail
1:22 Every model call and every retrieval is an AWS API call, which means it's all tracked in CloudTrail.
Asking a question an on-call engineer would ask
1:35 Okay, time to actually use it. I'll ask something an on-call engineer might ask.
The tool call, the query, and the answer from your runbooks
1:58 Watch the tool call. There it is. And you can see the exact query it ran against the knowledge base. The answer comes straight out of our runbooks: 250 failed transactions a minute, and the rollback goes through the release captain.
An error code that exists only in your docs
2:15 We can try one more question. And you can see the error code doesn't exist anywhere on the internet. It only exists in our docs, but the agent still finds the correct answer.
Tracing every hop inside the account
2:36 Here's the part your security team will care about. Trace the request. AURA talks to Bedrock for the model, the Knowledge Base Retrieve API for the search, and the search pulls from S3. Every one of these hops starts and ends inside the AWS account.
Run this in EKS with VPC endpoints and it doesn't even touch the public internet. When someone asks where the data goes, the answer is, it doesn't.
What changes if you use a different model
3:03 The same config format could be used with Anthropic, OpenAI, or any other model family served by Bedrock. Nothing leaves AWS.
Find more docs at docs.mezmo.com.
More videos
