에이전트의 코드와 모델 설정을 변경할 때는 새 버전을 배포하고 정상적으로 응답하는지 확인해야 합니다. Amazon Elastic Kubernetes Service(Amazon EKS)와 GitOps로 애플리케이션을 운영하는 팀이라면, Amazon Bedrock AgentCore에 배포하는 에이전트도 같은 저장소와 배포 절차로 관리할 수 있습니다.
이 글에서는 기존 GitOps 환경을 사용해 Amazon Bedrock AgentCore Runtime에 에이전트를 배포하는 방법을 소개합니다. Helm 차트와 환경별 values를 Git에 기록하면 Argo CD가 Kubernetes 리소스로 적용하고, AWS Controllers for Kubernetes(ACK)가 해당 구성을 AWS API에 반영합니다. 플랫폼 팀은 Argo CD에서 배포 상태를 확인하고, 에이전트는 AgentCore Runtime에서 실행합니다.
실습에서는 AWS Cloud Development Kit(AWS CDK)로 기반 인프라를 구성하고, Strands Agents SDK로 작성한 에이전트를 Runtime에 배포합니다. 이후 Gateway 호출과 새 이미지 배포를 수행하고, Argo CD 상태와 API 응답에서 릴리스가 전환됐는지 확인합니다.
솔루션 개요
배포는 Git에 저장한 이미지 digest를 변경하는 것으로 시작합니다. Argo CD와 ACK가 새 구성을 Runtime에 적용하면, 배포 후 검증 Job이 Gateway를 호출해 예상한 릴리스가 응답하는지 검사합니다. 리소스가 준비됐는지와 실제 모델 호출이 성공했는지를 각각 확인합니다.
아키텍처와 리소스 소유권
그림 1. 배포 컨트롤러는 EKS에, 에이전트 실행 환경은 AgentCore에 배치합니다. 파랑은 관리와 배포, 초록은 요청 경로, 주황은 이미지, 보라는 로그와 관측을 나타냅니다. 관리용 ALB는 Argo CD 접속에 사용합니다. NAT, VPC endpoint, 관리자의 EKS API 접근 경로는 생략했습니다. 글로벌 교차 리전 추론을 사용하므로 모델 요청은 검증 리전인 us-east-1 외의 지원 리전에서도 처리될 수 있습니다.
관리 경로는 Git → Argo CD → Kubernetes 사용자 정의 리소스(CR) → ACK → AWS API 순서입니다. 실제 요청은 애플리케이션 → AgentCore Gateway → AgentCore Runtime → Amazon Bedrock 순서로 전달됩니다. 에이전트는 AgentCore Runtime에서 실행하므로, EKS에 에이전트용 Deployment나 ReplicaSet을 생성하지 않습니다.
같은 리소스를 서로 다른 도구가 수정하지 않도록 소유권을 나눕니다.
담당 도구
관리 대상
AWS CDK
VPC, EKS, ECR, IAM 역할, EKS add-on과 Pod Identity association
플랫폼 Helm 설치
AWS Load Balancer Controller, Argo CD, ACK, Argo Rollouts
Argo CD
에이전트 차트의 Runtime, Gateway, GatewayTarget, 검증 리소스
ACK
Kubernetes 선언에 대응하는 AWS AgentCore 리소스
Argo Rollouts
AnalysisRun과 실제 호출을 수행하는 검증 Job
플랫폼 설치 스크립트
관리용 Argo CD Ingress와 데모 인증서
기반 인프라는 두 가용 영역의 프라이빗 서브넷에 ARM64 m7g.large 노드 두 대를 배치합니다. 실습에서는 새 EKS 클러스터를 생성합니다. 기존 클러스터에 적용할 때는 컨트롤러의 중복 설치 여부를 확인하고, 네임스페이스와 Pod Identity 연결