AWS Bedrock 모델 가용성 구축: AI Routing Discovery를 며칠에서 몇 분으로 단축
Source: Salesforce Engineering
Engineering Energizers Q&A – Spotlight on Scott Chang
Principal Engineer, AI Infrastructure – Agentforce 360
What is your team’s mission in building Bedrock Model Availability for Agentforce?
팀의 핵심 사명은 안정적이고 탄력적이며 안전한 인프라를 제공하여 Agentforce 360 뒤에 있는 AI 서비스들을 지원하고, 운영 우수성에 집중하는 것입니다.
- 대규모 언어 모델(LLM) 기반 워크로드가 빠르게 확장·진화함에 따라, 기반 인프라의 신뢰성은 고객 경험에 직접적인 영향을 미칩니다.
- 모든 운영 조건에서 모델 라우팅, 가용성 및 폴백 동작이 예측 가능하고 안전하도록 보장하는 것이 필수적입니다.
Bedrock Model Availability 기능은 이러한 운영 우수성에 대한 집중에서 탄생했습니다. 모델 라우팅을 정적 설정이 아니라 자동화, 가시성, 가드레일을 포함하는 인프라 기능으로 구축함으로써 다음과 같은 견고한 기반을 만들었습니다:
- 탄력성 강화
- 운영 위험 최소화
- 정확성이나 컴플라이언스를 해치지 않으면서 Agentforce가 새로운 모델을 신속히 도입 가능
What scalability constraints did Agentforce’s rapid regional expansion introduce for tracking model and endpoint availability?
Agentforce는 다중 계정 AWS 아키텍처를 사용하여:
- 지역별 분리 유지
- 데이터 거주 요건 충족
- 서비스 할당량 관리
글로벌 확장으로 인해 플랫폼은 30개 이상의 AWS 계정을 다양한 지역에 걸쳐 운영하게 되었습니다. 각 계정마다 기본 모델에 대한 라우팅 설정이 필요해지면서 가용성 관리가 대규모 작업으로 변했습니다.
추가적인 과제
- 새로운 지역이 추가되는 동시에 모델 제공업체가 새로운 옵션을 출시(대부분 오리건이나 버지니아와 같은 허브에서 먼저)합니다.
- 각 모델은 지역 내 또는 전역 엔드포인트와 같은 서로 다른 추론 프로파일을 가질 수 있으며, 용량 변동에 따라 프로파일이 바뀝니다.
수동으로 추적하는 것은 곧 불가능해졌습니다. 엔지니어들은 모델을 찾고, 프로파일을 확인하고, 매 릴리즈마다 복잡한 라우팅 구성을 업데이트하는 데 수시간을 소비했습니다.
해결책: 세 가지 AWS API를 통해 가용성 데이터를 수집하는 자동화 시스템.
- 지역별 AWS Lambda 함수가 데이터를 수집하고 이를 CloudWatch 커스텀 메트릭으로 게시합니다.
- 이 메트릭은 내부 모니터링 도구와 단일 Grafana 대시보드에 전달됩니다.
- 엔지니어들은 이제 실시간으로 지역 및 ID별 활성 모델 엔드포인트를 확인할 수 있습니다.
결과: 탐색 시간이 며칠에서 몇 분으로 단축되었습니다.
What correctness and compliance constraints arose when incorrect endpoints were deployed to production?
잘못된 엔드포인트를 배포하면 다음과 같은 문제가 발생할 수 있습니다:
- 추론 트래픽이 예상치 못한 지역이나 존재하지 않는 엔드포인트로 라우팅 → 지연 증가 또는 장애 발생.
- 데이터 거주 요건을 위반하여, 특정 지역·국가 내에 데이터를 보관해야 하는 고객에게 문제가 생김.
이러한 실패가 고객에게 직접 노출되지 않도록, 팀은 외부 LLM 제공업체와 협업하여 결정론적 베이스라인 폴백 메커니즘을 구현했습니다:
- 베이스라인 지역(예: 버지니아, 오리건, 프랑크푸르트)을 항상 사용 가능한 Bedrock 용량 영역으로 지정.
- 기본 엔드포인트가 HTTP 오류를 반환하거나 사용 불가능해지면 트래픽을 자동으로 이 베이스라인으로 재라우팅.
- 기본 라우팅 로직을 폴백 경로와 분리하여, 오래되었거나 잘못된 구성 데이터가 장시간 장애를 일으키지 않도록 함.
이 설계는 실제 운영 환경에서 정확성, 신뢰성, 컴플라이언스를 크게 향상시킵니다.
What routing and resiliency constraints affected latency, capacity, data residency, and availa
Source:
bility when traffic was sent to the wrong geographic region?
Cross‑region routing introduces several nuanced challenges:
| Constraint | Impact |
|---|---|
| Latency | Minor compared to overall LLM inference time, but still adds overhead when traffic traverses long distances. |
| Capacity | Unintended traffic can overload production capacity in regions not sized for the load, leading to throttling or failures. |
| Data residency | Violates client‑mandated jurisdictional limits (e.g., EU data must stay in the EU). |
| Availability | Unexpected routing can cause service degradation or outages in both source and destination regions. |
How the system addresses these limits
- Layered routing – Primary routing selects the optimal endpoint; a deterministic fallback handles failures.
- Real‑time availability metrics – CloudWatch and Grafana provide instant visibility into endpoint health and capacity.
- Compliance‑aware routing tables – Regions are tagged with residency constraints; the router respects these tags when selecting endpoints.
- Capacity‑aware throttling – The system monitors regional load and can divert traffic to baseline regions before capacity is exhausted.
Together, these mechanisms ensure that traffic is always directed to a correct, compliant, and capacity‑sufficient endpoint, preserving latency targets and meeting regulatory obligations.
Model Routing & Inference Profiles
AWS‑managed inference profiles provide in‑region, in‑country, and global failover options to handle capacity constraints. At the same time, LLM Gateway runs its own failover logic: it detects error signals and reroutes traffic to predefined backup endpoints. Together, these mechanisms ensure that routing decisions simultaneously respect latency, capacity, data residency, and availability.
Model routing integrated with Inference Profile increased resiliency.
What automation constraints limited how quickly Agentforce could adopt newly available AWS Bedrock models?
Before automation, routing updates were a cumbersome, multi‑step manual process:
- Discover model availability.
- Identify the appropriate endpoints.
- Update configuration files.
- Create pull requests.
- Redeploy services.
Each step introduced delays and opportunities for error, extending onboarding timelines to several days.
The Bedrock Model Availability capability removed these bottlenecks. The team now automatically:
- Collects, normalizes, and exposes all routing‑critical data.
- Presents the data on a Grafana dashboard for a single pane of glass view of model availability across regions.
A single‑pane‑of‑glass dashboard reduced operational time from days to minutes.
Impact
- Discovery time dropped from ≈ 3 days to under 10 minutes.
- Future plans aim for full automation, eliminating routing‑configuration delays entirely.
- What once took up to 7 days (discovery → deployment) will become effectively instantaneous, with dynamic updates propagating automatically at the service level.
This shift transforms routing from a manual operational task into a scalable infrastructure capability that evolves at Agentforce’s own pace.
자세히 알아보기
- 연결을 유지하세요 — Talent Community에 참여하세요!
- 우리의 Technology and Product 팀을 탐색하여 어떻게 참여할 수 있는지 알아보세요.