TL;DR

Se voce esta rodando um Amazon Bedrock Knowledge Base apoiado por OpenSearch Serverless (AOSS), voce esta pagando um piso de ~$700/mes antes de ingerir um unico documento. Para a maioria das cargas de trabalho RAG de pequeno e medio porte, trocar o AOSS pelo Aurora PostgreSQL Serverless v2 com a extensao pgvector reduz esse piso para menos de $50/mes, uma reducao de custo de ~90%; mantendo-se como uma loja vetorial de primeira classe e totalmente suportada para Bedrock Knowledge Bases.

Este post percorre o porque, a matematica, os trade-offs e o caminho de migracao, usando uma infraestrutura real de producao como implementacao de referencia.

O problema: AOSS tem uma conta minima obrigatoria

Quando voce cria um Bedrock Knowledge Base pelo console ou Terraform, a AWS te direciona para o OpenSearch Serverless como a loja vetorial padrao. Esse padrao e conveniente, mas esconde uma realidade de precificacao que e facil de nao notar em uma prova de conceito e dolorosa em producao.

O OpenSearch Serverless cobra por OpenSearch Compute Units (OCUs):

• 2 OCUs minimo para indexacao
• 2 OCUs minimo para busca
• Mais multiplicadores de redundancia no modo producao

Isso te da um minimo de 4 OCUs para qualquer colecao nao-dev. Na taxa on-demand de eu-west-1 de aproximadamente $0.24 por OCU-hora: 4 OCU x $0.24/OCU-h x 730 h/mes ≈ $700/mes

Esse e o piso. Indice vazio. Sem trafego. Sem consultas. Apenas para a colecao existir.

Para um caso de uso RAG enxuto, um chatbot de documentacao, um assistente interno de Q&A, um bot de desvio de suporte; isso eclipsa todo o resto do stack. Invocacoes de modelo Bedrock, Lambda, API Gateway e S3 combinados geralmente ficam abaixo de $100/mes. O OpenSearch entao representa 80-90% da conta fazendo muito pouco trabalho.

A carga de trabalho de referencia

Os numeros abaixo vem de uma infraestrutura de IA em producao (Terraform, eu-west-1) com este perfil:

Em outras palavras: uma carga de trabalho RAG completamente normal de escala SMB. Do tipo para o qual o OpenSearch Serverless e agressivamente superdimensionado.

Por que Aurora Serverless v2 + pgvector e a escolha certa aqui

O Amazon Bedrock Knowledge Bases oferece suporte oficial ao Amazon Aurora PostgreSQL-Compativel como loja vetorial, junto com OpenSearch Serverless, Pinecone, MongoDB Atlas e Redis Enterprise. Isso nao e um hack ou uma gambiarra; e uma integracao de primeira classe documentada pela AWS.

Os ingredientes:

• Aurora Serverless v2 escala computacao em Aurora Capacity Units (ACUs) e, desde o final de 2024, suporta escalar a 0 ACUs quando ocioso.
• pgvector e a extensao padrao do PostgreSQL para busca por similaridade vetorial, com os tipos de indice ivfflat e hnsw.
• O Bedrock Knowledge Base pode usar um cluster Aurora diretamente, desde que a tabela, a coluna vetorial e o indice HNSW sejam pre-criados de acordo com a especificacao da AWS.

Para o nosso perfil Titan v2 / 1024 dimensoes / alguns milhares de chunks, um cluster Aurora Serverless v2 com min_capacity = 0 / max_capacity = 2 lida com ingestao e recuperacao confortavelmente.

Comparacao de custos

Usando a precificacao on-demand atual de eu-west-1 como base representativa (sempre refaca a matematica para sua regiao):

Sim, em numeros redondos, isso e uma reducao de custo de 10-15x na linha da loja vetorial, ou aproximadamente $600+/mes economizados por ambiente. Multiplique isso entre dev / staging / producao e a economia anual fica seria rapidamente.

Onde o AOSS ainda vence

Este nao e um post "pgvector supera OpenSearch." O AOSS continua sendo a resposta certa quando:

• Voce precisa de p99 abaixo de 100ms em QPS muito alto com indices grandes.
• Seu corpus tem dezenas de milhoes de vetores e esta crescendo.
• Voce quer busca hibrida palavra-chave + vetorial com os recursos de texto completo do OpenSearch.
• Voce precisa dos neural plugins, rerankers e pipelines semanticos que vem com o OpenSearch.

Para tudo abaixo desse teto, que e a maioria das cargas de trabalho RAG na pratica; Aurora + pgvector e rapido o suficiente e dramaticamente mais barato.

Roteiro de migracao

A migracao e direta, mas tem algumas pegadinhas que vale a pena conhecer de antemao.

1. Provisione Aurora Serverless v2 com pgvector

resource "aws_rds_cluster" "kb" {
  engine                      = "aurora-postgresql"
  engine_mode                 = "provisioned"
  engine_version              = "15.5"
  database_name               = "kb"
  master_username             = "kb_admin"
  manage_master_user_password = true
  storage_encrypted           = true
serverlessv2_scaling_configuration {
min_capacity = 0      # scale-to-zero quando ocioso
max_capacity = 2
}
}
resource “aws_rds_cluster_instance” “kb” {
cluster_identifier = aws_rds_cluster.kb.id
instance_class     = “db.serverless”
engine             = aws_rds_cluster.kb.engine
engine_version     = aws_rds_cluster.kb.engine_version
}

Entao, na primeira conexao:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE SCHEMA bedrock_integration;
CREATE TABLE bedrock_integration.bedrock_kb (
id        uuid PRIMARY KEY,
embedding vector(1024),
chunks    text,
metadata  json
);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING gin (to_tsvector(‘simple’, chunks));

Os nomes e tipos das colunas (id, embedding, chunks, metadata) sao obrigatorios para o Bedrock Knowledge Base; siga a especificacao da AWS exatamente.

2. Armazene as credenciais do banco no Secrets Manager

O Bedrock KB le as credenciais do banco de dados de um segredo do Secrets Manager. Se voce usar manage_master_user_password = true no cluster, o Aurora gerencia esse segredo para voce, basta passar seu ARN para a configuracao do Knowledge Base.

3. Aponte o Knowledge Base para Aurora em vez de OpenSearch

No Terraform, troque o bloco storage_configuration:

storage_configuration {
  type = "RDS"
  rds_configuration {
    resource_arn           = aws_rds_cluster.kb.arn
    credentials_secret_arn = aws_rds_cluster.kb.master_user_secret[0].secret_arn
    database_name          = aws_rds_cluster.kb.database_name
    table_name             = "bedrock_integration.bedrock_kb"
    field_mapping {
      primary_key_field = "id"
      vector_field      = "embedding"
      text_field        = "chunks"
      metadata_field    = "metadata"
    }
  }
}

Tudo upstream, a fonte de dados S3, a estrategia de chunking, o modelo de embedding, a Lambda de ingestao, permanece identico.

4. Re-ingestao

Dispare um job de ingestao completo contra o novo Knowledge Base. Os embeddings sao recalculados a partir do S3, entao nao ha etapa de migracao de dados do AOSS para o Aurora, voce reconstroi o indice a partir da fonte da verdade.

5. Descomissione a colecao OpenSearch

Apenas depois de validar as respostas no novo KB. Mantenha a colecao antiga por uma ou duas semanas; o custo dessa sobreposicao e trivial comparado a um rollback mal-sucedido.

Ressalvas de producao

Algumas coisas que vale a pena sinalizar antes de colocar isso em producao:

• Cold starts. O Aurora Serverless v2 scale-to-zero retoma em aproximadamente 10-15 segundos. Se o seu chatbot tem SLAs rigorosos de p99, defina min_capacity = 0.5 em vez de 0; voce ainda economiza ~85% vs. AOSS.
• Ajuste do HNSW. Os padroes sao bons para comecar. Se a recall degradar em escala, ajuste m e ef_construction no indice e hnsw.ef_search no momento da consulta.
• Backups. Backups e snapshots do Aurora agora sao sua responsabilidade. O snapshotting do OpenSearch Serverless era automatico.
• VPC. Bedrock KB para Aurora roda sobre a VPC. Certifique-se de que subnets, security groups e a role de servico do Bedrock estejam conectados corretamente. Esta e a fonte numero 1 de bugs do tipo "funciona no console mas falha na ingestao."
• Teto de escala. Em ~1M+ de vetores com QPS alto sustentado, reavalie. pgvector + HNSW e excelente, mas AOSS e bancos vetoriais especializados de fato assumem a lideranca nesse regime.

Conclusao

Para a vasta maioria das aplicacoes RAG baseadas em Bedrock, bots de documentacao, assistentes de conhecimento, automacao de suporte, Q&A interno, OpenSearch Serverless e superdimensionado e superfaturado. Aurora Serverless v2 com pgvector e uma alternativa suportada, com qualidade de producao, que custa uma ordem de grandeza a menos em escala pequena e media, com migracao medida em horas em vez de semanas.

Se sua equipe de FinOps tem perguntado por que um "chatbot leve" custa $800+/mes na AWS, a resposta quase certamente esta na sua linha de cobranca do OpenSearch. Troque a loja vetorial, mantenha todo o resto, e recupere o orcamento.

Escrito a partir da experiencia de producao rodando Bedrock Knowledge Bases em eu-west-1. Precos e configuracoes refletem a AWS em abril de 2026, sempre valide a precificacao atual e os limites de servico para sua regiao antes de se comprometer com uma migracao.