엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

AI Agent를 프로덕션 환경에 도입하려는 엔터프라이즈 고객과 이야기하다 보면, 공통적으로 마주하는 질문들이 있습니다.

“사내에서 운영 중인 LLM을 Agent에서 호출할 수 있는가?”
“인증을 회사가 이미 운영 중인 사내 IdP(Identity Provider)로 처리할 수 있는가? 단, IdP를 인터넷에 노출하지 않고?”
“내부 데이터에 접근하는 MCP(Model Context Protocol) 서버를 사내망 안에서만 호출할 수 있는가?”

세 질문의 공통점은 하나입니다. 사내 자산을 인터넷에 노출하지 않아야 한다는 것입니다. 금융, 공공, 제조 등 규제 산업의 고객들은 자체 호스팅 중인 sLLM, Keycloak과 같은 사내 IdP, 내부 시스템과 연동된 MCP 서버를 이미 운영하고 있으며, 이 자산들을 그대로 활용하면서도 외부 노출 없이 AI Agent 환경을 구성해야 합니다.

Amazon Bedrock AgentCore는 AI Agent를 안전하게 배포하고 운영할 수 있는 완전관리형 서비스입니다. 다만 인증 요구사항에는 제약이 있었습니다. AgentCore의 CUSTOM_JWT 인증은 퍼블릭 HTTPS Discovery URL만 수용했기 때문에, 사내망의 Keycloak을 사용하려면 Discovery URL을 인터넷에 노출하거나 Amazon Cognito를 중간 다리로 두고 토큰 교환(Token Exchange)을 수행하는 우회 구성이 필요했습니다. 물론 IAM(SigV4) 인증만 사용하는 구성이라면 해당되지 않는 제약이지만, 사용자 인증을 사내 IdP로 일원화해야 하는 엔터프라이즈 환경이라면 피해 가기 어려운 제약이었습니다.

AgentCore Runtime은 VPC 연결(VPC Connectivity)을 통해 프라이빗 네트워크의 리소스에 접근할 수 있으며, 2026년 4월에는 AgentCore Gateway와 AgentCore Identity에도 VPC egress 기능이 추가되었습니다. 이제 VPC 내부 또는 AWS Direct Connect/VPN으로 연결된 온프레미스의 리소스를 인터넷에 노출하지 않고 AgentCore와 직접 연동할 수 있습니다.

이 글에서는 다음 세 가지를 인터넷 노출 없이 구성하는 방법을 단계별로 다룹니다.

온프레미스 LLM 활용 – AgentCore Runtime에 배포된 Agent가 사내에서 호스팅 중인 vLLM 기반 모델을 호출합니다.
사내 IdP 기반 인증 – 사용자가 Agent를 호출할 때, 그리고 Agent가 AgentCore Gateway를 호출할 때 모두 사내 Keycloak으로 인증을 처리합니다.
사내 MCP 서버 연동 – AgentCore Gateway의 타겟으로 온프레미스에 위치한 MCP 서버를 지정합니다.

1. Amazon Bedrock AgentCore 란

Amazon Bedrock AgentCore는 AI Agent를 프로덕션 규모로 배포하고 운영하기 위한 완전관리형 서비스입니다. Runtime, Identity, Gateway, Memory, Observability 등의 컴포넌트로 구성되며, 각 컴포넌트는 독립적으로 사용할 수도, 조합해서 사용할 수도 있습니다. 이 글에서 사용하는 핵심 컴포넌트는 다음 세 가지입니다.

컴포넌트	역할	온프레미스 연동 포인트
AgentCore Runtime	Agent 코드를 서버리스 환경에서 호스팅하고 세션 단위로 격리 실행	VPC 모드로 배포하여 온프레미스 LLM 활용
AgentCore Identity	Agent 호출(inbound)과 외부 리소스 접근(outbound)에 대한 인증/인가 처리	사내 Keycloak 기반 CUSTOM_JWT 인증
AgentCore Gateway	API, Lambda, MCP 서버 등 다양한 백엔드를 단일 MCP 엔드포인트로 통합	온프레미스 MCP 서버를 타겟으로 연결

이 글에서는 각 컴포넌트의 기본 사용법보다는 온프레미스 리소스의 프라이빗 연결 구성에 초점을 맞춥니다.

1.1 프라이빗 연결을 가능하게 하는 두 가지 기능

온프레미스 리소스 연동의 핵심이 되는 기능은 두 가지입니다.

첫째, AgentCore Runtime의 VPC 연결(VPC Connectivity)입니다. AgentCore Runtime 배포 시 VPC 모드를 활성화하면 AgentCore Runtime이 지정한 서브넷에 ENI(Elastic Network Interface)를 할당받아, VPC 내부 리소스는 물론 Direct Connect/VPN으로 연결된 온프레미스 리소스와도 프라이빗 네트워크로 통신할 수 있습니다.

둘째, 2026년 4월 추가된 AgentCore Gateway와 AgentCore Identity의 VPC egress 입니다. AgentCore Identity가 프라이빗 네트워크에 위치한 IdP의 OIDC Discovery/JWKS 엔드포인트를 조회하거나, AgentCore Gateway가 프라이빗 MCP 서버를 타겟으로 호출할 수 있게 되었습니다. 이 기능은 VPC Lattice Resource Gateway를 기반으로 동작하며, API 설정에서는 privateEndpoint 블록으로 구성합니다. 이후 섹션에서 등장하는 privateEndpoint가 바로 이 기능입니다.

1.2 왜 VPC Lattice인가 – 트래픽 방향의 문제

AWS에서 프라이빗 연결을 구성할 때 흔히 사용하는 도구는 인터페이스 VPC 엔드포인트(AWS PrivateLink)와 Private Hosted Zone입니다. 두 도구는 모두 내 VPC에서 출발하는 트래픽을 전제로 합니다. 인터페이스 VPC 엔드포인트는 내 VPC에서 AWS 서비스로 나가는 통로를 만들고, Private Hosted Zone은 연결된 VPC의 리졸버에서만 도메인을 해석해줍니다.

그런데 이번 구성에서 필요한 트래픽은 반대 방향입니다. JWT 토큰 검증을 위한 JWKS 조회는 AgentCore Identity, 즉 AWS 서비스 측이 클라이언트가 되어 고객 네트워크 안의 IdP를 호출합니다. AgentCore Gateway가 온프레미스 MCP 서버를 호출할 때도 마찬가지입니다. 고객 VPC 밖에서 동작하는 AgentCore는 고객의 Private Hosted Zone을 볼 수 없어 도메인 해석부터 실패하고, 해석이 되더라도 사설 IP에 도달할 네트워크 경로가 없습니다. 정리하면 두 방향에 필요한 도구가 서로 다릅니다.

트래픽	필요한 도구
사내망/VPC → AgentCore Runtime/Gateway 호출	인터페이스 VPC 엔드포인트(PrivateLink)
AgentCore Identity/Gateway → 사내 IdP/MCP 서버	privateEndpoint(VPC Lattice Resource Gateway)

그래서 이 기능은 AWS PrivateLink가 아닌 VPC Lattice Resource Gateway를 기반으로 합니다. AgentCore가 서비스 연결 역할(Service-Linked Role)을 통해 고객이 지정한 서브넷에 ENI를 생성하고, 이 경로로 고객 네트워크 안의 리소스에 접근하는 구조입니다. Lambda의 VPC 연결과 같은 계열의 패턴이라고 이해하면 쉽습니다.

그리고 Private Hosted Zone이 필요 없어지는 것은 아닙니다. 2026년 5월부터 VPC Lattice resource configuration이 IN_VPC DNS 해석을 지원합니다. 타겟 도메인을 Resource Gateway가 위치한 VPC의 리졸버로 해석하므로, Private Hosted Zone이나 온프레미스 DNS에만 등록된 도메인도 타겟으로 사용할 수 있습니다. 이전에는 타겟 도메인이 퍼블릭 DNS에서 해석 가능해야 했기 때문에, 사설 IP를 가리키는 레코드라도 퍼블릭 존에 등록해야 했습니다. 즉 Private Hosted Zone은 그대로 활용되고, 부족했던 “들어오는 길”을 Resource Gateway가 채워주는 셈입니다.

privateEndpoint에는 Lattice 리소스의 수명주기를 AgentCore가 관리하는 managed 모드와 고객이 직접 관리하는 self-managed 모드가 있으며, 두 모드의 차이는 AgentCore Gateway 섹션에서 자세히 다룹니다.

2. 전체 아키텍처 및 Agent 인증 흐름

위 다이어그램은 호출 흐름을 중심으로 간략화한 것입니다. AgentCore Runtime에서 나가는 트래픽(4·6·8번)은 모두 VPC 모드로 생성된 ENI를 경유하며, 6번의 AgentCore Gateway 호출은 별도의 gateway용 VPC Endpoint를 통해 이루어집니다. 상세 네트워크 경로는 3.1.3과 3.3.3에서 다룹니다.

Client 용 JWT 토큰 발급 – Agent을 호출하는 Client는 호출에 대한 인증 수단으로 사내 IdP을 통해 JWT 토큰을 발급 받습니다. JWT 토큰 발급을 위한 목적지로는 IdP를 Target Group으로 지정한 Application Load Balancer을 대상으로 호출합니다.
AgentCore Runtime 호출 – IdP을 통해 발급 받은 JWT 토큰과 함께 AgentCore Runtime을 호출합니다. 호출 시 AWS Direct Connect 및 AWS Site-to-Site VPN을 기반으로 AWS와 사설 네트워크 환경에서 호출합니다. 호출 시 VPC Endpoint을 통해 Public IP을 경유하지 않고 사설 네트워크를 기반으로 AgentCore Runtime을 호출합니다.
Client의 토큰 검증 – 사용자가 호출한 AgentCore Runtime에 대한 인증을 AgentCore Identity을 통해 인증합니다. AgentCore Identity는 IdP의 OIDC discovery URL에서 JWKS(공개키)를 조회해 JWT의 서명을 검증합니다. 이때 IdP가 사설 네트워크에 있으므로 VPC Lattice Resource Gateway을 통해 사설 네트워크로 JWKS를 조회합니다.
AgentCore Gateway 호출을 위한 JWT 토큰 발급 – AgentCore Runtime은 AgentCore Gateway을 호출하기 위한 인증 수단으로 사내 IdP에서 JWT 토큰을 발급합니다.
AgentCore Runtime의 토큰 검증 – AgentCore Runtime이 발급받은 JWT 토큰과 함께 AgentCore Gateway를 호출하면, 3번과 동일한 방식으로 AgentCore Identity가 토큰의 서명을 검증합니다.
AgentCore Gateway을 통한 MCP 서버 및 도구 조회 – AgentCore Runtime은 사용자의 질의를 처리하기 위해 MCP 도구 목록 조회 및 도구 목록의 실행을 AgentCore Gateway을 통해 요청합니다. 요청 시 VPC Mode을 통해 생성한 ENI을 통해 AgentCore Gateway VPC Endpoint을 통해 사설 네트워크 기반으로 호출합니다.
사내 MCP 도구 호출 – AgentCore Gateway는 등록된 Target을 통해 사내에 위치한 MCP 서버를 호출합니다. MCP 서버를 호출 시에도 VPC Lattice Resource Gateway을 통해 사설 네트워크 기반으로 동작합니다.
사내 LLM을 통한 최종 답변 생성 – AgentCore Runtime은 MCP 서버의 응답 및 사용자 요청에 대한 최종 답변을 생성하기 위해 사내에 위치한 vLLM을 호출합니다. AgentCore Runtime은 VPC Mode을 통해 사내 네트워크에 위치한 vLLM을 사설 네트워크 기반으로 호출합니다.
사용자에게 최종 답변 전달 – Agent가 생성한 최종 답변을 사용자에게 전달합니다.

3. 프라이빗 Amazon Bedrock AgentCore을 위한 구성 및 배포 방안

3.1 AgentCore Runtime의 프라이빗 호출을 위한 방안

앞선 아키텍처의 2번 흐름과 같이, 사내 환경에 위치한 사용자 및 시스템이 AgentCore Runtime을 프라이빗하게 호출하기 위해서는 1. AgentCore Runtime을 위한 VPC Endpoint 생성, 2. Amazon Route53 Inbound Endpoint을 통한 사설 DNS 구성이 필요합니다. 각 항목 별 필요한 이유 및 구성 방법을 살펴봅니다.

3.1.1 AgentCore Runtime을 위한 VPC Endpoint 생성

AgentCore Runtime은 기본적으로 bedrock-agentcore.ap-northeast-2.amazonaws.com의 엔드포인트를 활용하며, 별도의 구성이 없을 경우에는 퍼블릭 DNS 이름을 통해 호출됩니다. 즉 VPC Endpoint를 사용하지 않을 경우 사용자의 트래픽이 인터넷으로의 경유가 필요합니다. 이로 인해 사내 보안 정책상 외부 인터넷 경유 없이 AWS 서비스를 호출해야 하는 경우, VPC Endpoint 생성하여 이를 통해 호출해야합니다. 위 그림과 같이 VPC Endpoint을 VPC 내 서브넷에 생성 할 경우 AgentCore Runtime을 DNS을 활용하여 프라이빗 IP 기반의 통신을 가능하게 합니다.

그러나 VPC Endpoint는 AgentCore Runtime의 DNS 이름을 프라이빗 IP 기반으로 통신을 가능하게 하지만, 이는 VPC Endpoint가 생성된 VPC 내부에서만 조회 가능합니다. VPC 내부 리소스는 AWS가 제공하는 VPC 내부 DNS 리졸버를 통해 자동으로 이를 조회 할 수 있지만 VPN이나 Direct Connect로 AWS와 연결된 사내 네트워크에서는 이 VPC 내부 리졸버에 직접 질의할 수 없습니다. 이를 위해 사내 네트워크에서도 DNS 기반으로 AgentCore Runtime을 호출할 수 있는 방안이 필요합니다.

3.1.2 Amazon Route53 Inbound Endpoint을 통한 사설 DNS 구성

사내 네트워크에서도 DNS 기반으로 AgentCore Runtime을 프라이빗 하게 호출하기 위해서는 Amazon Route53 Inbound Endpoint을 DNS 질의를 VPC Resolver까지 전달이 필요합니다. Amazon Route53 Resolver Inbound Endpoint는 VPC 외부에서도 VPC 내부 리졸버로 질의를 보낼 수 있도록 열어주는 진입점입니다. 지정한 VPC의 프라이빗 서브넷에 고정 IP를 가진 ENI를 생성하며, VPN이나 Direct Connect로 AWS와 연결된 사내 네트워크에서는 이 ENI의 IP로 DNS 질의를 보내 VPC 내부 리졸버에 접근할 수 있게 됩니다.

사용자 관점에서 전체 DNS 질의 흐름을 정리하면 다음과 같습니다.

Client의 DNS 질의 – Client는 bedrock-agentcore.ap-northeast-2.amazonaws.com 호출을 위해 사내 DNS 서버(DNS Resolver)로 먼저 DNS 질의를 보냅니다.
사내 DNS 서버의 조건부 전달 – 사내 DNS 서버에는 amazonaws.com 도메인(또는 필요한 서비스 도메인)에 대한 조건부 전달 규칙이 미리 설정되어 있어야 하며, 이 규칙에 따라 해당 질의는 Route53 Resolver Inbound Endpoint의 IP로 전달됩니다. 이 전달은 VPN 또는 Direct Connect를 통한 사설 네트워크 경로로 이루어지며, 퍼블릭 인터넷을 경유하지 않습니다.
Inbound Endpoint를 통해 Amazon Route53으로의 전달 – Inbound Endpoint는 전달받은 질의를 VPC 내부의 Route53 Resolver로 넘깁니다.
Private Hosted Zone 조회 – VPC 내부 Resolver는 해당 VPC에 연결된 Private Hosted Zone에서 bedrock-agentcore.ap-northeast-2.amazonaws.com에 대한 레코드를 조회합니다. 이 레코드는 VPC Endpoint의 프라이빗 IP를 가리키도록 구성되어 있으므로, 조회 결과로 해당 프라이빗 IP가 반환됩니다.

3.1.3 AgentCore Runtime에서의 사내 리소스(LLM, IdP) 사용

앞선 아키텍처의 4번/8번 흐름과 같이, AgentCore Runtime이 사내에 위치한 IdP을 통해 JWT 토큰을 발급받고, LLM 호출을 통한 작업을 수행하기 위한 네트워크 구성이 필요합니다. AgentCore Runtime을 배포 시 VPC Mode을 통해 배포 할 경우 사용자가 지정한 VPC 및 서브넷에 AgentCore Runtime용 ENI가 생성되고, 이 ENI을 통해 VPC 내부 리소스와의 통신을 가능하게 합니다.

핵심 동작 방식은 다음과 같습니다.

AgentCore Runtime을 VPC Mode로 배포 시 지정된 서브넷에 ENI를 생성하고, 각 ENI에 VPC 대역의 프라이빗 IP를 할당합니다.
이 ENI에 부착된 보안 그룹은 AgentCore Runtime이 통신할 수 있는 대상을 Outbound Rules을 통해 제어합니다.
이를 통해 AgentCore Runtime은 인터넷에 노출하지 않고도 VPC 내부 및 Direct Connect/VPN으로 연결된 사내 리소스(DB, 내부 API, 온프레미스 서비스 등)에 접근할 수 있습니다.

AgentCore Runtime 배포 시 VPC 및 ENI가 지정 될 Subnet을 지정해야합니다.

aws bedrock-agentcore-control create-agent-runtime \
  --region ap-northeast-2 \
  --agent-runtime-name agentcore_doc_agent \
  --agent-runtime-artifact '{
    "containerConfiguration": {
      "containerUri": "########.dkr.ecr.ap-northeast-2.amazonaws.com/bedrock-agentcore-agentcore_doc_agent:20260714-065428-745"
    }
  }' \
  --role-arn arn:aws:iam::########:role/AmazonBedrockAgentCoreSDKRuntime-ap-northeast-2-df1054f838 \
  --network-configuration '{
    "networkMode": "VPC",
    "networkModeConfig": {
      "subnets": ["subnet-#######", "subnet-#######"],
      "securityGroups": ["sg-#######"]
    }
  }'

AgentCore Runtime에 배포된 코드에서도 LLM에 대한 baseURL을 사내 LLM의 엔드포인트로 지정 할 경우 사내 리소스와의 통신을 가능하게 합니다.

QWEN_URL = os.environ.get("QWEN_URL", "https://llm.internal.example.com/v1")

client = OpenAI(api_key="dummy", base_url=QWEN_URL)
messages = [{"role": "user", "content": question}]

3.2 AgentCore Identity – 사내 IdP 기반 인증 구성

앞선 호출 흐름에서 3번(Client 토큰 검증)과 5번(Gateway 호출 시 토큰 검증)은 같은 동작에 의존합니다. AgentCore Identity가 IdP의 OIDC Discovery URL에서 JWKS(공개키)를 조회해 JWT 서명을 검증하는 것입니다.

한 가지 짚고 갈 점이 있습니다. inbound 인증에 관한 한 AgentCore Identity는 별도로 생성하거나 설정하는 리소스가 아닙니다. AgentCore Runtime 이나 AgentCore Gateway를 생성할 때 지정하는 authorizerConfiguration이 곧 inbound 인증 설정이며, 이 설정에 따라 토큰 검증을 실제로 수행하는 주체가 AgentCore Identity입니다. 따라서 이 섹션에서 다루는 설정도 AgentCore Runtime, AgentCore Gateway 생성 명령 안에서 이루어집니다.

IdP가 사내에 있다면 앞서 말한 JWKS 조회 경로를 privateEndpoint로 열어주어야 하는데, 그 전에 충족해야 할 요건이 하나 있습니다.

3.2.1 TLS 요건 – 퍼블릭 인증서가 필요한 이유

customJWTAuthorizer의 Discovery URL에는 두 가지 요건이 있습니다.

HTTPS 필수 – HTTP는 지원하지 않습니다.
퍼블릭 CA(publicly trusted CA)가 발급한 인증서 필수 – 사설 CA나 자체 서명 인증서는 거부됩니다.

토큰 검증은 JWKS 조회로 받아온 공개키를 그대로 신뢰하는 구조입니다. 이 구간의 통신이 변조되어 공격자의 공개키가 섞여 들어오면 위조된 토큰도 유효한 것으로 통과되기 때문에, AgentCore는 이 구간의 TLS 검증을 엄격하게 강제합니다. 관리형 서비스 특성상 고객의 사설 CA를 신뢰 저장소에 추가하는 기능도 제공되지 않습니다.

대부분의 사내 Keycloak은 사설 인증서를 사용하고 있을 텐데, 이 경우 공식 문서가 안내하는 방법은 ACM 퍼블릭 인증서를 연결한 Internal ALB를 앞단에 두는 것입니다.

ACM 퍼블릭 인증서 발급 – IdP 도메인(예: idp.internal.example.com)에 대해 ACM 퍼블릭 인증서를 발급합니다. 도메인 검증용 CNAME 레코드 한 건만 퍼블릭 존에 추가하면 되며, 이 레코드는 도메인 소유 증명용일 뿐 IdP의 주소를 가리키지 않습니다.
internal ALB 구성 – HTTPS(443) 리스너에 ACM 인증서를 연결하고, 타겟 그룹으로 Keycloak(HTTP:8080)을 지정합니다.
Private Hosted Zone에만 레코드 생성 – idp.internal.example.com 의 A레코드를 Private Hosted Zone에 만들어 internal ALB를 가리키게 합니다. 퍼블릭 존에는 A레코드를 만들지 않으므로 인터넷에서는 이 도메인이 해석조차 되지 않습니다.

3.2.2 customJWTAuthorizer와 privateEndpoint 설정

IdP쪽은 일반적인 OIDC 연동과 동일하게 realm과 confidential client(client_credentials)을 준비하면 됩니다. 한 가지 주의할 점은 allowedAudience로 검증하는 경우입니다. Keycloak이 기본 발급하는 access token의 aud에는 account만 들어 있어 검증에 실패하므로, audience mapper로 검증 대상 값을 토큰에 추가해야 합니다. 이 글의 구성처럼 allowedClients 로 검증한다면 해당되지 않습니다.

다음은 앞서 VPC 모드로 배포한 AgentCore Runtime에 사내 Keycloak 인증을 적용하는 설정 예시입니다. AgentCore Runtime 배포 시 사용한 create-agent-runtime 명령에 --authorizer-configuration 파라미터를 추가합니다.

aws bedrock-agentcore-control create-agent-runtime \
  --region ap-northeast-2 \
  ...(앞선 배포 명령과 동일한 파라미터 생략)... \
  --authorizer-configuration '{
    "customJWTAuthorizer": {
      "discoveryUrl": "https://idp.internal.example.com/realms/agentcore/.well-known/openid-configuration",
      "allowedClients": ["agentcore-client"],
      "privateEndpoint": {
        "managedVpcResource": {
          "vpcIdentifier": "vpc-xxxxxxxx",
          "subnetIds": ["subnet-xxxxxxxx", "subnet-yyyyyyyy"],
          "securityGroupIds": ["sg-xxxxxxxx"],
          "endpointIpAddressType": "IPV4"
        }
      }
    }
  }'

privateEndpoint에 managedVpcResource를 지정하면 AgentCore가 해당 VPC/서브넷에 VPC Lattice Resource Gateway(서브넷 당 ENI 1개)를 자동 생성하고 수명주기를 관리합니다.
보안 그룹 설계 – securityGroupIds는 Resource Gateway ENI에 부착됩니다. 이 보안 그룹에서 ALB로의 아웃바운드(443)를 허용하고, ALB의 보안 그룹에서는 이 보안 그룹으로부터의 인바운드(443)을 허용합니다.
AgentCore Gateway를 생성할 때도 같은 구조의 authorizer를 적용합니다. 이 때 allowedClients는 호출 주체에 맞춰 달라집니다.
- AgentCore Runtime의 authorizer – 사용자가 호출하므로 사용자용 클라이언트(예: agentcore-client)를 허용합니다.
- AgentCore Gateway의 authorizer – AgentCore Runtime이 호출하므로 AgentCore Runtime의 클라이언트(예: agentcore-runtime)를 허용합니다.

참고로 Agent가 외부 리소스 접근을 위해 토큰을 받아오는 outbound OAuth credential provider에서도, IdP의 token 엔드포인트가 프라이빗이라면 같은 privateEndpoint 블록을 그대로 사용할 수 있습니다.

3.2.3 필요한 IAM 권한

Managed 모드에서는 AgentCore Runtime이나 AgentCore Gateway 생성 명령 하나로 서비스 연결 역할(Service-Linked Role)과 Resource Gateway의 ENI까지 함께 만들어집니다. privateEndpoint가 포함된 AgentCore Runtime 이나 AgentCore Gateway를 생성하는 IAM 주체에는 다음 권한이 필요합니다.

iam:CreateServiceLinkedRole – 최초 구성 시 AgentCore가 서비스 연결 역할(AWSServiceRoleForBedrockAgentCoreIdentity)을 자동 생성하는 데 필요합니다. 이후 Lattice 리소스의 생성/관리는 이 역할이 담당합니다.
ec2:CreateNetworkInterface – Resource Gateway가 지정한 서브넷에 ENI를 생성할 때 필요합니다.

구성이 프라이빗하게 동작하는지는 간단히 증명할 수 있습니다. Discovery URL이 인터넷에서 도메인 해석조차 되지 않는 상태에서 유효한 토큰 서명 검증이 성공한다면, AgentCore Identity가 privateEndpoint 경로로 VPC 안에 들어와 JWKS를 조회했다는 직접적인 증거입니다. 위조 토큰이나 토큰 없는 호출이 401로 거부되는 것까지 확인하면 검증이 실제 수행되고 있음을 교차 확인할 수 있습니다.

3.3 AgentCore Gateway – 온프레미스 MCP 서버 연결

앞선 호출 흐름의 7번이 이 섹션의 주제입니다. AgentCore Gateway가 타겟으로 등록된 사내 MCP 서버를 호출하는 경로를 privateEndpoint로 구성합니다. AgentCore Gateway 생성 시의 인증 설정은 앞 섹션에서 다루었으므로, 여기서는 타겟 연결과 모드 선택, 그리고 AgentCore Gateway를 프라이빗하게 호출하는 경로를 살펴봅니다.

3.3.1 온프레미스 MCP 서버를 타겟으로 연결

Gateway 타겟을 생성할 때 MCP 서버의 엔드포인트와 함께 privateEndpoint 를 지정합니다.

aws bedrock-agentcore-control create-gateway-target \
  --region ap-northeast-2 \
  --gateway-identifier <gateway-id> \
  --name onprem-mcp \
  --target-configuration '{
    "mcp": {
      "mcpServer": { "endpoint": "https://mcp.internal.example.com/mcp" }
    }
  }' \
  --private-endpoint '{
    "managedVpcResource": {
      "vpcIdentifier": "vpc-xxxxxxxx",
      "subnetIds": ["subnet-xxxxxxxx", "subnet-yyyyyyyy"],
      "securityGroupIds": ["sg-xxxxxxxx"],
      "endpointIpAddressType": "IPV4"
    }
  }'

호출 시점에 트래픽은 VPC Lattice Resource Gateway가 고객 서브넷에 생성한 ENI를 통해 VPC로 들어온 뒤, VPC 라우팅(Direct Connect/VPN)을 따라 사내 MCP 서버까지 사설 네트워크로만 전달됩니다.
보안 그룹 설계는 AgentCore Identity 섹션과 동일합니다. securityGroupIds는 Resource Gateway의 ENI에 부착되므로 MCP 서버(또는 앞단 ALB)로의 아웃바운드(443)을 허용하고, MCP 서버 측에서는 이 보안그룹으로부터의 인바운드를 허용합니다.
TLS 요건도 동일합니다. MCP 서버 엔드포인트는 HTTPS여야 하며, 사설 인증서를 사용 중이라면 ACM 퍼블릭 인증서를 연결한 internal ALB를 앞단에 둡니다.

3.3.2 managed 모드와 self-managed 모드 선택 기준

두 모드는 privateEndpoint 블록에 무엇을 지정하느냐로 갈립니다. managedVpcResource 를 지정하면 managed 모드, selfManagedLatticeResource를 지정하면 self-managed 모드입니다.

콘솔에서 Gateway 타겟 생성 시의 VPC Security 설정 – API의 privateEndpoint 블록에 해당하며, managed와 self-managed가 본문의 두 모드입니다.

구분	managed	self-managed
설정	VPC, 서브넷, 보안 그룹만 지정하면 AgentCore가 Lattice 리소스를 생성/관리	Resource Gateway와 resource configuration을 직접 생성한 뒤 ARN으로 참조
가시성	resource configuration이 서비스 측에 보관되어 고객 계정에서 조회되지 않음(계정에 남는 것은 Resource Gateway와 ENI)	resource configuration의 조회/태깅/정책/감사 기능
크로스 어카운트	미지원 – MCP서버가 다른 계정에 있다면 VPC 피어링이나 Transit Gateway로 우회	AWS RAM 공유로 직접 지원
재사용	privateEndpoint를 지정한 리소스 단위로 개별 생성	resource configuration 하나를 여러 AgentCore Gateway, AgentCore Runtime, credential provider가 재사용

단일 계정이라면 타겟이 온프레미스에 있더라도 managed 모드로 충분하며, 이 글의 예시도 managed 모드입니다. 반면 MCP 서버가 다른 계정에 있거나, 네트워크 팀이 Lattice 리소스를 직접 통제/감사해야 하는 환경이라면 self-managed 모드를 선택합니다.

3.3.3 AgentCore Runtime의 AgentCore Gateway 호출도 프라이빗하게

호출 흐름 6번, 즉 AgentCore Runtime이 AgentCore Gateway를 호출하는 구간이 남았습니다. AgentCore Gateway 호출은 AgentCore Runtime과 별도의 엔드포인트 서비스(com.amazonaws.<region>.bedrock-agentcore.gateway)를 사용하므로, 앞서 구성한 AgentCore Runtime용 VPC Endpoint만으로는 이 구간이 프라이빗해지지 않습니다.

앞서 설명한대로, AgentCore Runtime을 VPC 모드로 배포할 경우 AgentCore Runtime에서의 아웃바운드 트래픽은 VPC 내의 ENI을 통해 전달됩니다. 이로 인해 AgentCore Runtime이 배포된 VPC에 gateway용 인터페이스 VPC 엔드포인트를 추가로 생성하고 프라이빗 DNS를 활성화하면, VPC 모드 AgentCore Runtime의 ENI에서 나가는 AgentCore Gateway 호출(<gateway-id>.gateway.bedrock-agentcore.<region>.amazonaws.com)이 VPC 안에서 엔드포인트의 사설 IP로 해석되어 인터넷을 경유하지 않습니다. 사내 클라이언트가 AgentCore Gateway를 직접 호출하는 아키텍처라면, AgentCore Runtime 호출 경로와 같은 패턴으로 온프레미스 DNS 연동까지 확장하면 됩니다.

AgentCore Runtime용과 AgentCore Gateway용 인터페이스 VPC 엔드포인트 – 서로 다른 엔드포인트 서비스를 사용하므로 각각 생성해야 합니다.

4. 예시로 살펴보는 프라이빗 Amazon Bedrock AgentCore 호출 흐름

예시를 통해서 프라이빗 Amazon Bedrock AgentCore 호출 흐름을 살펴봅니다. 프라이빗하게 구성되어 있는 Agent에게 아래의 질문을 요청하고, 각 단계별 로그를 살펴보며 전체 흐름을 살펴봅니다.

5. 마치며

엔터프라이즈 기업의 보안 요구사항을 준수하기 위해 AWS VPC 내 또는 온프레미스에 위치한 LLM, 사내 IdP, 사내 MCP 세 가지 자산을 인터넷에 노출하지 않고 Amazon Bedrock AgentCore와 연동하는 방법을 다뤘습니다. 핵심은 AgentCore Runtime의 VPC Mode를 통한 배포 방식과, AgentCore Identity 와 AgentCore Gateway의 VPC Lattice Resource Gateway를 통한 privateEndpoint 구성입니다. 이를 통해 규제 산업의 엔터프라이즈 고객도 기존 사내 자산을 그대로 활용하면서 Amazon Bedrock AgentCore 기반의 AI Agent 환경을 안전하게 구축할 수 있습니다.

AWS 기술 블로그