Outposts 로컬 실행과 리전 서비스 연결을 구분하기

AWS와 같은 인터페이스는 모든 서비스를 로컬 제공한다는 뜻이 아니다

AWS Outposts는 일부 AWS 서비스를 온프레미스(on-premises)에서 실행하고, AWS 리전(Region)의 더 넓은 서비스와 연결한다. 로컬 앱(local application)이 리전의 서비스를 호출할 수 있다는 것과 모든 서비스의 계산을 로컬에서 수행한다는 것은 다르다. 따라서 Outposts가 AWS와 같은 인터페이스를 제공한다고 해서 모든 Bedrock 파운데이션 모델(foundation model, FM)이 로컬에서 실행된다고 해석하지 않는다. 특정 제공 방식의 지원 여부는 해당 제품 문서로 확인한다.

Outpost는 고객 사이트에 설치되지만 AWS 리전의 일부로 운영·관리되는 용량 풀(capacity pool)이다. 서비스 링크(service link)는 Outpost와 연결된 리전 사이의 통신 경로이며, 각 Outpost는 가용 영역(Availability Zone)과 리전을 확장한다. 로컬 데이터 처리 경로(data path)가 있어도 관리와 제어를 위한 경로(control path), 주변 서비스 의존성까지 모두 온프레미스로 옮겨지는 것은 아니다. 반대로 모든 로컬 요청이 반드시 리전으로 가는 것도 아니므로 서비스별 경로를 확인한다.

폼팩터·세대·서비스·리전을 함께 확인한다

주 근거의 리소스 표에서는 EC2 인스턴스와 ECS 클러스터를 랙·서버 양쪽에 표시하지만 EKS 노드·EBS·S3·RDS 등의 항목은 랙과 서버가 다르다. 제품 비교의 로컬 서비스 설명은 서버에 EC2/ECS/IoT Greengrass를 제시하며, 랙은 더 넓은 목록을 제시한다. 따라서 ‘AWS Outposts 지원’이라는 한 문장만으로 랙과 1U/2U 서버가 같은 서비스를 제공한다고 외우면 안 된다.

제품 비교 표에는 ElastiCache, EMR, Route 53 Resolver, Elastic Disaster Recovery를 1 세대 랙 한정으로 표시하는 각주가 있다. 가이드의 단순 랙 지원 여부와 결합할 때 세대 조건을 버리지 않는다. 사이트의 구체 용량, 인스턴스, 주문 가능성 및 실제 계정 이용 가능성도 별개다.

리전 표의 서울 행에 여러 서비스가 ‘예’로 보이더라도 이것이 Bedrock 전체 FM의 서울 Outposts 로컬 실행 증거는 아니다. 표가 다루는 항목과 제품 범위를 넘어서 확장할 수 없다. 특정 서비스가 로컬 실행인지, 지역 연결만 가능한지, 버전·세대별 추가 제한이 있는지를 해당 제품 상세에서 확인해야 한다.

온프레미스 추론은 실행 프로세스의 위치로 설명한다

자체 설계 해설로 두 경우를 구분한다.

로컬 앱에서 리전 모델 호출: Outposts의 애플리케이션이나 전처리(preprocessing) 프로세스가 리전의 모델 API를 호출한다. 앱이 로컬에 있어도 모델의 추론(inference)은 리전에서 수행될 수 있다. 요청에 포함된 데이터가 어느 위치로 전달되는지 확인한다.
로컬 컴퓨팅에서 모델 실행: 사용 권한을 확보한 모델 가중치(weights)와 호환 런타임(runtime)을 지원되는 로컬 컴퓨팅에 배치한다. 이때 필요한 모델 메모리, 가속기(accelerator), 컨테이너(container), 저장소와 네트워크, 업데이트 경로를 충족하는지 검증해야 한다.

두 번째 방식은 EC2나 컨테이너에 직접 모델을 호스팅(self-hosting)할 때 검토할 조건이다. 모든 FM의 가중치와 사용 권리, 관리형 런타임이 Outposts에 자동으로 제공된다는 뜻은 아니다. 모델 API를 이용할 권한과 가중치를 가져와 자체 호스팅할 권리도 구분한다. 이 교재는 특정 모델을 배치하거나 성능을 측정한 결과를 제시하는 것은 아니다.

이 문서에서 ‘모든 Bedrock FM이 Outposts에서 실행된다’는 주장을 채택하지 않는다. 다만 읽은 목록에서 Bedrock을 찾지 못했다는 이유로 ‘어떤 Bedrock 관련 온프레미스 상품도 절대 없다’고 단정하지도 않는다. 특정 모델·제공 방식의 로컬 실행 지원은 모델별 공식 제품 문서에서 확인해야 한다.

지원 조건과 문서 간 불일치

주 근거의 아시아 태평양 표는 오사카 RDS를 ‘아니요’로 표시하지만 뒤의 RDS 지원 리전 목록에는 오사카가 포함된다. 중동 UAE도 서비스 표와 뒤 RDS 목록이 다르게 보인다. 이를 임의로 해소하지 않았다. 구체 RDS 지원 판정은 서비스별 최신 한국어 상세 대조가 필요하다.
리소스 표에는 App Mesh도 등장하지만 그 행만으로 현재 서비스 수명 주기·신규 이용 가능성까지 검증했다고 말하지 않는다. 이 작업은 전체 서비스 상태 조사로 확대하지 않았다.
서비스 링크(service link)의 정의만으로 인터넷이나 리전 연결이 끊겼을 때 각 서비스가 얼마나 오래 동작할지 알 수는 없다. 단절 운영(disconnected operation)의 지속 조건은 추가 확인이 필요하다. 완전한 오프라인 운영이 가능하다거나 연결이 끊기면 모든 로컬 서비스가 즉시 정지한다고 단정하지 않는다.
공식 한국어 제품 페이지는 로컬 데이터 처리·레지던시 용도를 설명한다. 로그·백업·원격 모델 요청까지 전부 로컬이라는 법률·보안 보장을 뜻하지 않는다.
특정 파운데이션 모델(FM), GPU·가속기(accelerator), 하드웨어 세대에 맞는 온프레미스 추론(on-premises inference) 배치 절차와 Bedrock의 로컬 제공 모델 목록은 한국어 공식 문서에서 더 확인해야 한다. 이 설명은 실제 배포·주문·클라우드 실행을 검증한 결과가 아니다.

적용 범위: 위 제약과 예외를 적용 대상의 현재 공식 문서와 대조한다. 이 해설은 API 실행 성공이나 법적 준수를 보증하지 않는다.

공식 출처와 이어 읽기

용어 확인: 파운데이션 모델(foundation model, FM).