AWS PrivateLink를 통해 다른 리전의 Amazon Bedrock을 내부 네트워크에서 사용하기

개요

AWS PrivateLink는 VPC Endpoint를 통해 트래픽이 인터넷을 경유하지 않고 AWS 내부망을 통해 AWS의 서비스에 더 빠르고 안전하게 접근할 수 있도록 합니다. 이를 통해 기업의 민감한 데이터를 보호하면서도 안정적이고 고속의 네트워크 연결을 유지할 수 있습니다.

그러나 Private VPC Endpoint를 통해 서비스에 연결하려면 Public 서비스 주소 대신 Private 주소를 사용해야 하므로 관련된 라이브러리를 수정하거나 설정을 변경하는 번거로움이 발생합니다. 이러한 번거로움을 해소하기 위해 AWS는 예외적으로 구축하고자 하는 시스템과 생성한 Private VPC Endpoint가 동일한 VPC에 위치하는 경우, 옵션 설정을 통해 Public 주소를 이용하여 서비스에 접속할 수 있는 기능을 제공합니다.

한편, 최근 많은 관심을 받고 있는 Amazon Bedrock 서비스는 아직은 모든 AWS 리전에서 가용하지 않으며, Amazon Bedrock을 사용하려면 해당 서비스가 가용한 원격지의 리전의 Amazon Bedrock 서비스에 접근해야 합니다. 혹은 사용하려고 하는 Foundation Model (FM)이 로컬 리전 에 가용하지 않을 수 있고, 이때도 해당 모델을 지원하는 원격지 리전의 Amazon Bedrock 서비스에 접근해야 합니다.

원격지 리전의 Amazon Bedrock 서비스에 접근하기 가장 쉬운 방법은 public 네트워크, 즉 인터넷망을 이용하는 것입니다. 그러나 이 경우는 데이터 보안상의 취약점이 있기에 권고되지 않습니다. 데이터 보안상으로 안전하게 원격지 리전에 접근할 수 있는 가장 일반적인 방법 중 하나는 원격지에 VPC Endpoint를 생성하여 AWS PrivateLink를 통해 서비스에 접근하는 방식인데, 이 서비스 엔드포인트의 private DNS name은 다른 리전과 공유되지 않아 내부 네트워크로 접근이 불가능합니다.

이러한 어려움을 해결하기 위해 본 글에서는 안전한 AWS 전용의 폐쇄망을 통해 원격지 Bedrock 서비스에 접근할 수 있으면서도 응용 시스템에서 추가적인 환경 설정이나 코드 변경없이 public 주소를 통해 서비스에 접근할 수 있는 Cross Region VPC Endpoint 기법에 대해 소개하고자 합니다.

솔루션 설명

전체 아키텍처 구성은 다음과 같습니다.

1. 서울 리전과 오레곤 리전에 각각 VPC 를 구성하고, 각 리전에 AWS Transit Gateway를 생성한 후 Peering connection을 통해 두 리전의 VPC 네트워크가 연결되도록 구성합니다.
2. 구성도와 같이 AWS Transit Gateway의 route table을 적절하게 구성하여 두 VPC 간 트래픽 전송이 가능하게 합니다.
3. 테스트를 위해 서울 리전의 VPC 에는 Internet Gateway를 구성하지 않습니다. 대신, Test EC2에 접근하기 위해 VPC Endpoint(ssm, ssmmessages, ec2messages)를 생성합니다.
4. 오레곤 리전에 Amazon Bedrock 서비스의 Endpoint를 두 개(bedrock, bedrock-runtime) 를 생성합니다. 주의할 점은 Amazon Bedrock 의 VPC Endpoint를 생성할 때, ‘Private DNS 활성화’ 옵션을 체크 해제한 후에 생성해야 합니다. 해당 옵션을 활성화 한 상태로 생성하게 되면, 아래에서 생성하려는 private 도메인이 AWS managed domain으로 생성되어 서울 리전에서 동일한 도메인을 생성할 수 없는 상태가 됩니다.
5. bedrock.us-west-2.amazonaws.com 의 이름으로 Amazon Route 53 Private Hosted Zone을 생성하고, 서울 리전과 오레곤 리전의 VPC 에 연결합니다.
6. Private Hosted Zone에 다음과 같이 record를 추가하고, Bedrock VPC Endpoint의 DNS Name과 Zone ID를 입력합니다.
   1. bedrock.us-west-2.amazonaws.com 
   2. *.bedrock.us-west-2.amazonaws.com
7. 동일하게 bedrock-runtime.us-west-2.amazonaws.com 의 이름으로 AWS Route 53 Private Hosted Zone을 생성하고, 두 개의 VPC 에 연결해 줍니다.
8. Private Hosted Zone에 다음과 같이 record를 추가하고, Bedrock Runtime VPC Endpoint의 DNS Name과 Zone ID를 입력합니다.
   1. bedrock-runtime.us-west-2.amazonaws.com 
   2. *.bedrock-runtime.us-west-2.amazonaws.com

위와 같이 구성하면 서울 리전에서 오레곤 리전의 Amazon Bedrock Endpoint를 Private하게 호출할 수 있는 상태가 됩니다.

참고로 Private Hosted Zone 을 구성할 때에, amazonaws.com이 아닌 다른 private 도메인을 사용할 수는 없습니다. 때때로 Route 53 Private Hosted Zone에 회사가 소유한 private 도메인을 등록하여 이를 통해 VPC Endpoint 호출을 시도하는 경우가 있는데, 이 경우는 서비스 API 인증서의 도메인과 호출한 도메인이 달라 인증서 오류가 발생하기 때문입니다.

테스트

서울 리전에서 오레곤 리전 간의 Cross-Region Bedrock VPC Endpoint가 올바르게 구성되었는 지 확인하기 위해 테스트 목적으로 생성한 EC2 인스턴스에 접속합니다. Private subnet에 위치한 인스턴스이기 때문에 접속 시 Session Manager를 이용합니다. 인스턴스는 서울 리전의 VPC에 위치하고 있습니다.

EC 인스턴스에 접속하면 AWS CLI 명령을 통해 오레곤 리전을 대상으로 ListFoundationModels를 실행합니다. ListFoundationModels은 대상으로 하는 리전에서 가용한 Foundation Model의 리스트를 출력하는 Bedrock API입니다. 명령어를 실행하는 환경은 서울 리전의 Private subnet에 위치한 작은 EC2 인스턴스로 인터넷망으로의 접근이 차단되어 있고, 때문에 VPC Endpoint를 거치지 않고는 인터넷망을 통해 Bedrock 서비스를 사용할 수 없습니다. VPC Endpoint를 통해 서울 리전과 오레곤 리전간의 통신이 정상적으로 이루어진다면 그림의 결과를 얻을 수 있습니다.

aws bedrock list-foundation-models --region us-west-2 --cli-connect-timeout 5

반면에, Cross-Region Bedrock VPC Endpoint를 구성하지 않은 버지니아 리전으로 동일한 Bedrock API를 호출할 시에는 인터넷망을 통해서도 해당 리전으로의 통신 연결을 할 수 없기 때문에 아래와 같이 타임아웃 에러가 발생합니다.

aws bedrock list-foundation-models --region us-east-1 --cli-connect-timeout 5

다음으로 서울 리전에서 오레곤 리전을 대상으로 InvokeModel Bedrock API를 호출해 보겠습니다. InvokeModel API는 사용을 원하는 Amazon Bedrock 모델 ID, 프롬프트 및 그 외 파라미터들을 전달하여 모델 추론을 실행하는 API입니다. 아래의 예제는 오레곤 리전의 Bedrock에서 가용한LLM 모델 (Claude3 Sonnet)을 대상으로 텍스트 생성을 테스트 합니다.

aws bedrock-runtime invoke-model \
  --region us-west-2 \
  --model-id anthropic.claude-3-sonnet-20240229-v1:0 \
  --cli-binary-format raw-in-base64-out \
  --body '{"anthropic_version": "bedrock-2023-05-31", "max_tokens": 1000, "messages": [{"role": "user", "content": [{"type": "text", "text": "Describe the purpose of a \"hello world\" program in one line."}]}]}' \
  /tmp/response.json

명령어 실행 후 아래 같이 정상적으로 LLM 모델에 의해 텍스트가 생성 되었음을 확인할 수 있습니다.

jq . /tmp/response.json

다음으로 LLM 기반의 응용을 개발할 때 가장 많이 사용되는 LangChain을 이용하여 Cross-Region Bedrock VPC Endpoint의 동작을 확인하겠습니다. 테스트용 스크립트는 다음과 같으며, 리전명을 입력받으면 해당 리전으로 Bedrock API 요청을 보내 텍스트 생성을 하는 방식으로 동작합니다. 인자로 받은 리전으로의 연결이 정상적이면 생성한 텍스트를 출력하고, 그렇지 않으면 타임아웃 등의 에러를 표시합니다.

테스트 스크립트에서 주목해야 할 점은 Amazon Bedrock VPC Endpoint를 통해서 원격지 리전의 Amazon Bedrock 서비스에 접근할 시에 별도의 처리없이 region_name만 변경하면 된다는 것입니다. 따라서 기존의 Bedrock의 public endpoint 주소 (https://bedrock-runtime.<region-name>.amazonaws.com)를 사용하는 코드가 있다면 기존 코드에 대한 변경없이 그대로 사용할 수 있고, 더불어 Amazon Bedrock VPC Endpoint를 통해 보안적으로 안전하고 효율적인 네트워크를 구성할 수 있습니다.

import sys
from langchain_aws import ChatBedrock
import boto3
from botocore.config import Config
config = Config(read_timeout=20, connect_timeout=5, retries={'max_attempts': 0})
llm = ChatBedrock(region_name=sys.argv[1],
  config=config,
  model_id="anthropic.claude-3-sonnet-20240229-v1:0",
  model_kwargs=dict(max_tokens=1000),)

messages = [("user",
             "Describe the purpose of a \"hello world\" program in one line.",)]

ai_msg = llm.invoke(messages)

print(ai_msg.content)

먼저 Cross-Region Bedrock VPC Endpoint을 구성한 오레곤의 Amazon Bedrock 서비스를 사용할 시에는 다음과 같이 텍스트 생성이 정상적으로 이루어 진 것을 확인할 수 있습니다.

반면에 VPC Endpoint를 구성을 하지 않은 버지니아의 Amazon Bedrock 서비스로 접근할 시에는 인터넷망을 통해서도 접근이 가능하지 않아 아래와 같이 타임아웃 에러가 발생합니다.

Clean up

리소스의 삭제는 아키텍처 구성의 역순으로 진행합니다.

1. Amazon Route53 Private hosted zone을 삭제합니다.
2. 오레곤 리전의 VPC endpoint를 삭제합니다.
3. 오레곤 리전과 서울 리전의 Transit gateway를 삭제합니다.
4. 오레곤 리전과 서울 리전의 VPC를 삭제합니다.

결론

이 글에서는 Amazon Bedrock 서비스를 지원하지 않는 AWS 리전에서도 AWS PrivateLink와 Route 53 Private Hosted Zone을 활용하여 다른 리전의 Amazon Bedrock을 내부 네트워크를 통해 접근할 수 있는 방법에 대해 다뤘습니다. 이를 통해 Amazon Bedrock이 GA 되지 않은 리전에서도 Amazon Bedrock의 일관된 데이터 처리 및 분석 서비스를 제공할 수 있습니다. 이러한 접근 방식은 보안성이 중요한 애플리케이션에서 유용하게 활용될 수 있으며, Amazon Bedrock 뿐만 아니라 제한적으로 GA가 된 다른 AWS 서비스에도 적용해 볼 수 있을 것입니다.