TL;DR

OpenSearch Serverless (AOSS)로 백엔드를 구성한 Amazon Bedrock Knowledge Base를 운영 중이라면, 단일 문서를 수집하기도 전에 월 약 $700의 기본 비용을 지불하고 있다. 대부분의 소규모 및 중간 규모 RAG 워크로드에서는 AOSS를 Aurora PostgreSQL Serverless v2 + pgvector 확장으로 교체하는 것만으로 이 기본 비용이 월 $50 미만으로, 약 90% 비용 절감 효과를 얻을 수 있다. 동시에 Bedrock Knowledge Base의 완전히 지원되는 1등급 벡터 스토어 지위도 유지된다.

이 글에서는 실제 프로덕션 인프라를 참조 구현으로 삼아, 배경, 계산, 트레이드오프, 그리고 마이그레이션 경로를 단계별로 설명한다.

문제: AOSS에는 하드한 최소 과금이 존재한다

콘솔이나 Terraform을 통해 Bedrock Knowledge Base를 생성할 때, AWS는 기본 벡터 스토어로 OpenSearch Serverless를 권장한다. 이 기본값은 편리하지만, PoC 단계에서는 간과하기 쉽고 프로덕션에서는 뼈아픈 과금 현실을 숨기고 있다.

OpenSearch Serverless는 OpenSearch Compute Units (OCU) 단위로 과금된다:

• 인덱싱용 최소 2 OCU
• 검색용 최소 2 OCU
• 프로덕션 모드에서는 중복 승수까지 추가

따라서 개발용이 아닌 모든 컬렉션에 최소 4 OCU가 필요하다. eu-west-1 기준 온디맨드 요금이 OCU-시간당 약 $0.24라고 할 때: 4 OCU x $0.24/OCU-hour x 730 hours/month = 약 $700/month

이게 최소 비용이다. 빈 인덱스. 트래픽 없음. 쿼리 없음. 그저 컬렉션이 존재한다는 이유만으로 발생한다.

문서화 챗봇, 내부 Q&A 어시스턴트, 지원 문의 경감 봇 같은 소규모 RAG 사용 사례에서 이 비용은 스택의 다른 모든 것을 압도한다. Bedrock 모델 호출, Lambda, API Gateway, S3를 모두 합쳐도 보통 월 $100 미만이다. 그러면 OpenSearch가 전체 청구서의 80~90%를 차지하며, 실제로 하는 일은 거의 없다.

참조 워크로드

아래 수치는 다음과 같은 형태의 프로덕션 AI 인프라(Terraform, eu-west-1)에서 얻은 것이다:

다시 말해, 완전히 평범한 SMB 규모의 RAG 워크로드다. OpenSearch Serverless가 심각하게 오버프로비저닝되는 종류의 워크로드다.

Aurora Serverless v2 + pgvector가 여기에 적합한 이유

Amazon Bedrock Knowledge Base는 OpenSearch Serverless, Pinecone, MongoDB Atlas, Redis Enterprise와 함께 Amazon Aurora PostgreSQL-Compatible을 벡터 스토어로 공식 지원한다. 이는 해킹이나 우회 방법이 아니라 AWS가 문서화한 1등급 통합이다.

구성 요소:

• Aurora Serverless v2는 Aurora Capacity Units (ACU) 단위로 컴퓨트를 스케일링하며, 2024년 말부터 유휴 시 0 ACU까지 스케일 다운을 지원한다.
• pgvector는 ivfflat 및 hnsw 인덱스 타입을 갖춘 PostgreSQL의 표준 벡터 유사도 검색 확장이다.
• Bedrock Knowledge Base는 테이블, 벡터 컬럼, HNSW 인덱스가 AWS 명세에 따라 사전 생성되어 있으면 Aurora 클러스터를 직접 사용할 수 있다.

Titan v2 / 1024차원 / 수천 개 청크 프로필의 경우, min_capacity = 0 / max_capacity = 2인 Aurora Serverless v2 클러스터로 수집과 검색을 충분히 처리할 수 있다.

비용 비교

현재 eu-west-1 온디맨드 가격을 기준으로 비교한다 (리전에 따라 반드시 재계산할 것):

그렇다: 대략적인 수치로 벡터 스토어 비용이 10~15배 절감되며, 환경당 월 $600 이상 절약된다. dev/staging/prod 환경에 곱하면 연간 절감액은 빠르게 유의미한 규모가 된다.

AOSS가 여전히 유리한 경우

이 글은 "pgvector가 OpenSearch를 이긴다"는 주장이 아니다. 다음과 같은 경우 AOSS가 여전히 올바른 선택이다:

• 대규모 인덱스에서 매우 높은 QPS로 p99 100ms 미만이 필요한 경우.
• 코퍼스가 수천만 개 벡터이며 계속 증가하는 경우.
• OpenSearch의 전체 텍스트 기능을 활용한 하이브리드 키워드 + 벡터 검색이 필요한 경우.
• OpenSearch에 포함된 neural plugin, reranker, 시맨틱 파이프라인이 필요한 경우.

그 기준 이하의 모든 워크로드, 즉 현실의 대부분 RAG 워크로드에서는 Aurora + pgvector로 충분히 빠르며 비용은 극적으로 저렴하다.

마이그레이션 개요

마이그레이션은 직관적이지만 미리 알아두면 좋은 몇 가지 주의점이 있다.

1. pgvector를 포함한 Aurora Serverless v2 프로비저닝

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      # 유휴 시 0으로 스케일
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
}

그다음, 최초 접속 시:

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));

컬럼 이름과 타입(id, embedding, chunks, metadata)은 Bedrock Knowledge Base가 필수로 요구하는 사항이므로 AWS 명세를 정확히 따라야 한다.

2. DB 자격 증명을 Secrets Manager에 저장

Bedrock KB는 Secrets Manager 시크릿에서 데이터베이스 자격 증명을 읽는다. 클러스터에서 manage_master_user_password = true를 사용하면 Aurora가 해당 시크릿을 관리하므로, 그 ARN을 Knowledge Base 설정에 전달하기만 하면 된다.

3. Knowledge Base를 OpenSearch 대신 Aurora로 지정

Terraform에서 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"
    }
  }
}

S3 데이터 소스, 청킹 전략, 임베딩 모델, 수집 Lambda 등 업스트림의 모든 것은 그대로 유지된다.

4. 재수집

새 Knowledge Base에 대해 전체 수집 작업을 트리거한다. 임베딩은 S3에서 재계산되므로 AOSS에서 Aurora로의 데이터 마이그레이션 단계가 필요 없다. 원본 데이터로부터 인덱스를 재구축하면 된다.

5. OpenSearch 컬렉션 해제

새 KB에서 응답을 검증한 후에만 수행한다. 기존 컬렉션을 1~2주 정도 유지하는 것이 좋다. 이 중첩 기간의 비용은 잘못된 롤백 한 번의 대가에 비하면 사소하다.

프로덕션 주의사항

배포 전에 알아둘 몇 가지 사항:

• 콜드 스타트. Aurora Serverless v2 scale-to-zero 재개에는 약 10~15초가 소요된다. 챗봇이 엄격한 p99 SLA를 요구한다면 min_capacity = 0.5로 설정하는 것이 좋다. 그래도 AOSS 대비 약 85% 절감된다.
• HNSW 튜닝. 기본값으로 시작해도 무방하다. 규모가 커지면서 재현율이 저하되면 인덱스의 m과 ef_construction, 그리고 쿼리 시 hnsw.ef_search를 튜닝한다.
• 백업. 이제 Aurora 백업과 스냅샷은 직접 관리해야 한다. OpenSearch Serverless는 스냅샷이 자동이었다.
• VPC. Bedrock KB에서 Aurora로의 연결은 VPC를 통해 이루어진다. 서브넷, 보안 그룹, Bedrock 서비스 롤이 올바르게 구성되었는지 확인해야 한다. "콘솔에서는 되는데 수집 시 실패한다"는 버그의 가장 큰 원인이다.
• 스케일링 상한. 지속적으로 높은 QPS로 백만 개 이상의 벡터에 도달하면 재평가가 필요하다. pgvector + HNSW는 훌륭하지만, 그 규모에서는 AOSS와 전용 벡터 DB가 확실히 앞서기 시작한다.

결론

Bedrock 기반 RAG 애플리케이션의 대다수, 즉 문서화 봇, 지식 어시스턴트, 지원 자동화, 내부 Q&A에서는 OpenSearch Serverless가 과도하게 설계되었고 과도하게 비싸다. Aurora Serverless v2 + pgvector는 완전히 지원되는 프로덕션 등급의 대안이며, 중소 규모에서 한 자릿수 이상 저렴하고 마이그레이션은 몇 주가 아닌 몇 시간 단위로 측정된다.

FinOps 팀이 "가벼운 챗봇"이 AWS에서 월 $800 이상 나오는 이유를 묻는다면, 그 답은 거의 확실히 OpenSearch 청구 항목에 있다. 벡터 스토어만 교체하고 나머지는 그대로 두면 예산을 되찾을 수 있다.

eu-west-1에서 Bedrock Knowledge Base를 운영한 프로덕션 경험을 바탕으로 작성되었다. 가격과 설정은 2026년 4월 기준 AWS를 반영한다. 마이그레이션을 결정하기 전에 반드시 현재 리전의 가격과 서비스 한도를 확인하기 바란다.