AWS Control Tower 리전 제약 조건에서 Amazon Bedrock 크로스 리전 추론 기능 활용 지침

“이 게시글은 AWS Artificial Intelligence Blogs의 ‘Enable Amazon Bedrock cross-Region inference in multi-account environments by Satveer Khurpa‘ 를 번역 및 편집 하였습니다”

Amazon Bedrock의 크로스 리전 추론 기능은 조직이 최적의 성능과 가용성을 유지하면서 AWS 리전 전반에 걸쳐 파운데이션 모델(FM)에 액세스할 수 있는 유연성을 제공합니다. 그러나 일부 기업은 규정 준수 요구사항을 충족하기 위해 서비스 제어 정책(SCP) 또는 AWS Control Tower를 통해 엄격한 리전 액세스 제어를 구현하여 의도치 않게 Amazon Bedrock의 크로스 리전 추론 기능을 차단하게 됩니다. 이로 인해 조직은 보안 제어와 AI 기능 활용 사이에서 균형을 맞춰야 하는 도전적인 상황에 직면하게 됩니다.

이 게시물에서는 다른 AWS 서비스에 대한 광범위한 리전 제한을 유지하면서 Amazon Bedrock 크로스 리전 추론을 특별히 허용하도록 리전 액세스 제어를 수정하는 방법을 살펴봅니다. SCP 수정 및 AWS Control Tower 구현 모두에 대한 실용적인 예제를 제공합니다.

크로스 리전 추론 이해하기

온디맨드 모드에서 모델 추론을 실행할 때, 서비스 할당량이나 사용량이 많은 시간대에 요청이 제한될 수 있습니다. 크로스 리전 추론은 여러 리전에 걸쳐 컴퓨팅 자원을 활용하여 예상치 못한 트래픽 급증을 원활하게 관리할 수 있게 해줍니다. 크로스 리전 추론을 통해 여러 리전에 트래픽을 분산시켜 더 높은 처리량을 달성할 수 있습니다.

많은 조직이 다음과 같은 방법으로 리전 액세스 제어를 구현합니다.

AWS Organizations의 SCP(서비스 제어 정책)
AWS Control Tower 제어
사용자 지정 AWS Identity and Access Management(IAM) 정책

이러한 제어는 일반적으로 보안, 규정 준수 또는 비용 관리 이유로 특정 리전의 모든 서비스에 대한 액세스를 거부합니다. 그러나 이러한 광범위한 거부는 Amazon Bedrock이 크로스 리전 추론을 통해 해당 리전의 모델에 액세스해야 할 때 제대로 작동하지 못하게 합니다.

크로스 리전 추론의 작동 방식 및 SCP와의 상호작용

Amazon Bedrock의 크로스 리전 추론은 추론 요청에 대한 자동 크로스 리전 라우팅을 가능하게 하는 강력한 기능입니다. 이 기능은 특히 온디맨드 추론 모드를 사용하는 개발자에게 유용한데, Amazon Bedrock으로 구동되는 애플리케이션에서 들어오는 트래픽 급증을 효과적으로 관리하면서 높은 처리량과 성능을 달성할 수 있는 원활한 솔루션을 제공하기 때문입니다.

크로스 리전 추론을 통해 개발자는 수요 변동을 수동으로 예측할 필요성을 줄일 수 있습니다. 대신 시스템이 여러 리전에 걸쳐 트래픽을 동적으로 라우팅하여 최적의 리소스 활용과 성능을 유지합니다. 중요한 점은 크로스 리전 추론이 가능한 경우 연결된 Amazon Bedrock API 소스 리전을 우선시하여 지연 시간을 최소화하고 전반적인 응답성을 향상시킨다는 것입니다. 이 지능적인 라우팅은 개발 팀의 지속적인 감독 없이도 애플리케이션의 안정성, 성능 및 효율성을 향상시킵니다.

크로스 리전 추론은 핵심적으로 두 가지 주요 개념에 따라 작동합니다: 소스 리전과 이행 리전입니다. 소스 리전(발생 리전이라고도 함)은 클라이언트가 처음에 추론 요청을 호출하는 곳입니다. 반면 이행 리전은 실제로 대규모 언어 모델(LLM) 호출 요청을 처리하는 리전입니다.

크로스 리전 추론은 Amazon이 고객에게 최상의 추론 경험을 제공하기 위해 지속적으로 발전시키는 독점적인 맞춤형 라우팅 로직을 사용합니다. 이 라우팅 메커니즘은 의도적으로 휴리스틱 기반이며, 주로 높은 가용성 제공에 중점을 둡니다. 기본적으로 서비스는 가능한 경우 소스 리전에서 요청을 처리하려고 시도하지만, 필요에 따라 다른 리전으로 요청을 원활하게 라우팅할 수 있습니다. 이 지능적인 라우팅은 리전별 용량, 지연 시간 및 가용성과 같은 요소를 고려하여 최적의 결정을 내립니다.

크로스 리전 추론은 강력한 유연성을 제공하지만, 제대로 작동하려면 모든 잠재적 이행 리전의 모델에 대한 액세스가 필요합니다. 이 요구사항은 SCP가 크로스 리전 추론 기능에 상당한 영향을 미칠 수 있는 부분입니다.

크로스 리전 추론과 SCP 간의 중요한 상호작용을 강조하는 시나리오를 살펴보겠습니다. 다음 그림과 같이, 우리는 us-east-1과 us-west-2 두 개의 리전을 사용하고, AWS Organizations 또는 AWS Control Tower 제어를 통해 구현될 수 있는 SCP를 사용하여 다른 모든 리전을 거부했습니다.

워크플로우는 다음 단계로 구성됩니다.

사용자가 크로스 리전 추론 프로필을 사용하여 us-east-1 Amazon Bedrock 엔드포인트(소스 리전)에 추론 요청을 합니다.
Amazon Bedrock 휴리스틱 기반 라우팅 시스템이 요청 이행을 위해 사용 가능한 리전을 평가합니다.
us-west-2와 us-east-1은 SCP를 통해 Amazon Bedrock 서비스 액세스가 허용되지만, us-east-2는 SCP를 사용하여 거부됩니다.
이 단일 리전 제한(us-east-2)으로 인해 크로스 리전 추론 호출이 실패합니다.
다른 리전이 사용 가능하고 허용되더라도, 하나의 차단된 리전(us-east-2)이 있으면 요청이 실패합니다.
클라이언트는 작업을 수행할 권한이 없다는 오류를 받습니다.

이는 설계상 그렇게 되어 있습니다. 크로스 리전 추론 서비스는 요청을 최적으로 라우팅하는 능력을 유지하기 위해 모든 잠재적 이행 리전에서 추론을 실행할 수 있는 액세스 권한이 필요합니다. 다른 사용 가능한 리전이 있더라도, 잠재적 대상 리전이 SCP에 의해 차단되면 크로스 리전 추론 사용 시도가 실패합니다. 크로스 리전 추론을 성공적으로 구현하려면, 조직은 SCP가 대상 모델이 사용 가능한 모든 리전에서 Amazon Bedrock API 작업을 허용하도록 해야 합니다. 이는 필요한 모델이 호스팅되는 모든 리전을 식별하고, 이러한 리전에서 필요한 최소한의 Amazon Bedrock 권한을 허용하도록 SCP를 수정하며, 일부 리전이 주요 운영 영역이 아니더라도 모든 관련 리전에서 이러한 권한을 유지하는 것을 의미합니다. 다음 섹션에서는 크로스 리전 추론 기능을 가능하게 하는 SCP 수정 및 AWS Control Tower 구현에 대한 구체적인 지침을 제공할 것입니다.

사용 사례

샘플 사용 사례에서는 us-east-1과 us-west-2 리전을 사용합니다. 다른 모든 리전은 랜딩 존 거부(GRREGIONDENY)를 사용하여 거부됩니다. Amazon Bedrock을 사용할 수 있는 고객의 AWS 계정은 Sandbox라는 조직 단위(OU) 아래에 있습니다. 우리는 Sandbox OU 아래의 계정들이 크로스 리전 추론을 사용하여 Anthropic의 Claude 3.5 Sonnet v2 모델을 사용할 수 있게 하고자 합니다. 다음 스크린샷과 같이 이 모델은 us-east-1, us-east-2, us-west-2에서 사용 가능합니다.

현재 상태에서 사용자가 크로스 리전 추론을 사용하여 Anthropic의 Claude 3.5 Sonnet v2 모델을 사용하려고 하면, SCP가 작업을 거부한다는 오류 메시지가 표시됩니다.

Amazon Bedrock 크로스 리전 추론을 허용하도록 기존 SCP 수정하기

다중 계정 AWS 환경을 관리하기 위해 AWS Control Tower를 사용하지 않는 경우, Amazon Bedrock 크로스 리전 추론을 허용하도록 새 SCP를 생성하거나 기존 SCP를 수정할 수 있습니다.

다음 코드는 특정 리전의 모든 서비스에 대한 액세스를 거부하면서 Anthropic의 Claude 3.5 Sonnet V2 모델에 대한 크로스 리전 추론을 통해 Amazon Bedrock 추론을 허용하는 기존 SCP를 수정하는 방법의 예시입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySpecificRegionAllowCRI",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-2"
        },
        "ArnNotLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0"
        }
      }
    }
  ]
}

이 정책은 지정된 리소스를 제외하고 us-east-2 리전의 모든 작업을 효과적으로 차단합니다. 이는 거부 기반 정책으로, 전체 권한 세트를 정의하기 위해 허용 정책과 함께 사용해야 합니다.

프로덕션 환경에 구현하기 전에 이 예제를 조직의 특정 요구사항 및 보안 요구사항에 맞게 검토하고 조정해야 합니다.

이러한 정책을 구현할 때 다음 사항을 고려하세요.

특정 요구사항에 맞게 리전 및 허용된 리소스를 사용자 지정
필요한 서비스나 작업을 의도치 않게 차단하지 않도록 환경에서 철저히 테스트
SCP는 루트 사용자를 포함하여 연결된 계정의 사용자 및 역할에 영향을 미친다는 점을 기억
서비스 연결 역할은 SCP의 영향을 받지 않으므로 다른 AWS 서비스가 AWS Organizations와 통합될 수 있음

AWS Control Tower를 사용한 구현

AWS Control Tower는 조직 전체의 권한을 관리하기 위해 SCP를 생성합니다. 이러한 SCP를 수동으로 편집하는 것은 AWS Control Tower 환경에서 드리프트(drift)를 발생시킬 수 있기 때문에 권장되지 않습니다. 그러나 특정 AWS 서비스를 허용하기 위해 취할 수 있는 몇 가지 접근 방식이 있으며, 이는 다음 섹션에서 설명합니다.

사전 요구 사항

AWS Control Tower의 최신 버전을 실행하고 있는지 확인하세요. 3.x 미만의 버전을 사용하고 AWS Control Tower 설정을 통해 리전이 거부된 경우, 리전 거부 설정을 업데이트하기 위해 AWS Control Tower 버전을 활성화해야 합니다. AWS Control Tower 2.x에서 3.x로의 업그레이드와 관련된 다음 고려사항을 참조하세요.

또한 AWS Control Tower의 조직 대시보드에 정책 드리프트(policy drifts)가 표시되지 않고 OU와 계정이 규정을 준수하는지 확인하세요.

옵션 1: 크로스 리전 추론을 위한 기존 리전 거부 SCP 확장

AWS Control Tower는 리전에 따라 AWS 서비스 액세스를 제한하기 위한 두 가지 주요 리전 거부 제어를 제공합니다:

GRREGIONDENY (랜딩 존 리전 거부 제어) – 이 제어는 특정 OU가 아닌 전체 랜딩 존에 적용됩니다. 활성화되면 지정된 리전 외부의 글로벌 및 리전별 서비스 작업에 대한 액세스를 거부합니다. 여기에는 AWS Control Tower를 사용할 수 없는 모든 리전과 거버넌스를 위해 선택되지 않은 모든 리전이 포함됩니다.
MULTISERVICE.PV.1 (OU 리전 거부 제어) – 이 구성 가능한 제어는 전체 랜딩 존이 아닌 특정 OU에 적용할 수 있습니다. 조직 단위에 대해 지정된 리전 외부의 글로벌 및 리전별 AWS 서비스에서 나열되지 않은 작업에 대한 액세스를 거부합니다. 이 제어는 구성 가능하며, AllowedRegions, ExemptedPrincipalARNs, ExemptedActions와 같은 하나 이상의 매개변수를 허용하여 이 OU에 속한 계정에 허용되는 작업을 설명합니다:
- AllowedRegions – OU가 운영할 수 있는 선택된 리전을 지정합니다. 이 매개변수는 필수입니다.
- ExemptedPrincipalARNs – 이 제어에서 면제되는 IAM 주체를 지정하여 특정 AWS 서비스를 전역적으로 운영할 수 있게 합니다.
- ExemptedActions – 이 제어에서 면제되는 작업을 지정하여 해당 작업이 허용되도록 합니다.

우리는 CT.MULTISERVICE.PV.1 제어를 사용하여 시나리오에 맞게 구성할 것입니다.

크로스 리전 추론을 사용하여 Amazon Bedrock 추론을 허용하는 IAM 정책이 포함된 IAM 역할을 생성합니다. 이 IAM 역할의 이름을 Bedrock-Access-CRI라고 지정하겠습니다. 이것은 나중에 사용할 것입니다. 이 IAM 역할은 Sandbox OU에 속한 AWS 계정에 생성됩니다.

 {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowBedrockInference",
            "Effect": "Allow",
            "Action": [
                "bedrock:InvokeModel",
                "bedrock:InvokeModelWithResponseStream"
            ],
            "Resource": [
                "arn:aws:bedrock:*:*:inference-profile/us.anthropic.claude-3-5-sonnet-20241022-v2:0",
                "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"
            ]
        }
    ]
}

랜딩 존 설정 페이지로 이동하여 설정 수정을 선택합니다.
리전(우리의 경우 us-east-2)을 활성화하고 다른 설정은 변경하지 않습니다.
랜딩 존 업데이트를 선택하여 변경 사항을 완료합니다.

업데이트는 조직의 크기에 따라 60분 이상 걸릴 수 있습니다. 이렇게 하면 랜딩 존 리전 거부 설정(GRREGIONDENY)이 업데이트되어 us-east-2 리전을 포함하여 해당 리전을 관리하게 됩니다.

랜딩 존 설정이 완료되면 조직 설정을 검토하여 OU 전체에서 AWS 계정에 대한 보류 중인 업데이트가 없는지 확인합니다. 보류 중인 업데이트가 있으면 업데이트를 완료하고 계정 상태가 등록됨으로 표시되는지 확인합니다.
AWS Control Tower 콘솔에서 탐색 창의 제어 라이브러리 아래에 있는 모든 제어를 선택하여 제어 목록을 확인합니다.
MULTISERVICE.PV.1을 찾아 정책을 선택하여 제어를 엽니다.
제어 작업을 선택한 다음 활성화를 선택하여 구성을 시작합니다.
OU 선택 페이지에서 이 제어를 적용할 OU를 선택합니다. 우리의 사용 사례에서는 Sandbox OU를 사용합니다.
다음을 선택합니다.

리전 액세스 지정 페이지에서 OU에 대한 액세스를 허용할 리전을 선택합니다. 우리의 사용 사례에서는 us-west-2와 us-east-1을 선택합니다.

us-east-2에서 모든 서비스를 거부하고 크로스 리전 추론을 통해 Amazon Bedrock 추론만 허용하려고 하기 때문에 us-east-2는 선택하지 않습니다.

다음을 선택합니다.
서비스 작업 추가 – 선택 사항 페이지에서 Amazon Bedrock 작업을 NotActions에 추가합니다. Amazon Bedrock InvokeModel 작업을 허용하기 위해 bedrock:Invoke*를 추가합니다.
다음을 선택합니다.

리전 액세스 지정 페이지에서 OU에 대한 액세스를 허용할 리전을 선택합니다. 우리의 사용 사례에서는 us-west-2와 us-east-1을 선택합니다.
구성을 검토하고 제어 활성화를 선택합니다.

제어가 활성화된 후 활성화된 OU, 계정, 아티팩트 및 리전 탭을 선택하여 구성을 검토할 수 있습니다.

이것으로 구성이 완료됩니다. 이전 단계에서 언급한 사용자 지정 IAM 역할(Bedrock-Access-CRI)을 사용하여 Amazon Bedrock 콘솔이나 API를 통해 Anthropic의 Sonnet 3.5 v2로 Amazon Bedrock 추론을 테스트할 수 있습니다.

세 개의 리전(us-east-1, us-east-2, us-west-2) 모두에서 크로스 리전 추론을 사용하여 Anthropic의 Sonnet 3.5 v2 모델에만 Amazon Bedrock 추론 호출을 할 수 있는 것을 볼 수 있습니다. us-east-2에서 다른 서비스에 액세스하려는 시도는 이전에 구성한 CT.MULTISERVICE.PV.1 제어로 인해 차단됩니다.

이러한 접근 방식을 따르면 드리프트를 발생시키거나 거버넌스 제어를 손상시키지 않고 AWS Control Tower에서 관리하는 권한을 안전하게 확장할 수 있습니다.

옵션 2: AWS Control Tower를 사용하여 거부된 리전을 활성화하고 SCP를 사용하여 조건부로 차단

이 옵션에서는 거부된 리전(us-east-2)을 활성화하고 크로스 리전 추론을 통한 Amazon Bedrock 추론을 허용하면서 us-east-2를 조건부로 차단하는 새로운 SCP를 생성합니다.

랜딩 존 설정 페이지로 이동하여 설정 수정을 선택합니다.
리전(우리의 경우 us-east-2)을 활성화하고 다른 설정은 변경하지 않습니다.
랜딩 존 업데이트를 선택하여 변경 사항을 완료합니다.

업데이트는 조직의 크기에 따라 60분 이상 걸릴 수 있습니다. 콘솔에서 이 업데이트의 상태를 모니터링할 수 있습니다.

랜딩 존 설정이 완료되면 조직 설정을 검토하여 OU 전체에서 AWS 계정에 대한 보류 중인 업데이트가 없는지 확인합니다. 보류 중인 업데이트가 있으면 업데이트를 완료하고 계정 상태가 등록됨으로 표시되는지 확인합니다.
AWS Control Tower 콘솔에서 탐색 창의 정책 아래에 있는 서비스 제어 정책을 선택합니다.
앞서 보여준 샘플 정책으로 새 SCP를 생성합니다. 이 SCP는 Anthropic의 Claude Sonnet 3.5 v2에 대한 CRI 프로필 ARN을 사용하여 Amazon Bedrock 추론을 허용하면서 us-east-2에 대한 모든 작업을 거부합니다.
특정 OU에 SCP를 적용합니다. 이 시나리오에서는 Sandbox OU를 사용합니다.

AWS Control Tower에서 생성한 기존 SCP를 수정하는 것이 아니라 새 SCP를 생성하기 때문에 AWS Control Tower 상태에서 드리프트가 발생하지 않습니다.

이제 Amazon Bedrock 콘솔이나 AWS 명령줄 인터페이스(AWS CLI)를 사용하여 몇 가지 추론 호출을 실행하여 업데이트를 테스트할 수 있습니다. 세 개의 리전(us-east-1, us-east-2, us-west-2) 모두에서 크로스 리전 추론을 사용하여 Anthropic의 Sonnet 3.5 v2 모델에만 Amazon Bedrock 추론 호출을 할 수 있는 것을 볼 수 있습니다. us-east-2에서 다른 AWS 서비스에 대한 액세스는 거부됩니다.

AWS Control Tower 사용자 지정을 통한 SCP 배포

사용자 지정 SCP를 추가하는 권장 방법은 AWS Control Tower용 사용자 지정(CfCT) 솔루션을 통하는 것입니다:

관리 계정에 CfCT 솔루션을 배포합니다.
사용자 지정 SCP가 포함된 구성 패키지를 생성합니다.

다음 스크린샷은 Anthropic의 Sonnet 3.5 v2 모델에 대한 크로스 리전 추론을 사용하여 Amazon Bedrock 호출을 허용하면서 특정 리전을 거부하는 예제 SCP를 보여줍니다.

정책을 정의하는 manifest.yaml 파일을 준비합니다.

다음 스크린샷은 Sandbox OU를 대상으로 하는 리소스를 정의하는 예제 manifest.yaml을 보여줍니다.

특정 OU에 사용자 지정 SCP를 배포합니다.

요약

Amazon Bedrock 크로스 리전 추론은 리전 전반에 걸쳐 파운데이션 모델을 사용하려는 조직에게 귀중한 유연성을 제공합니다. 서비스 제어 정책이나 AWS Control Tower 제어를 신중하게 수정함으로써, 광범위한 리전 액세스 제한을 유지하면서도 이 기능을 활성화할 수 있습니다.

이러한 접근 방식을 통해 다음과 같은 이점을 얻을 수 있습니다.

리전 액세스 요구사항에 대한 규정 준수 유지
Amazon Bedrock의 모든 기능 활용
기본 리전에서 모델에 액세스하여 애플리케이션 아키텍처 단순화

크로스 리전 추론에는 이 기능이 제공하는 장애 조치 기능을 포함하여 추가 비용이 발생하지 않습니다. 여기에는 관리, 데이터 전송, 암호화, 네트워크 사용 및 모델별 백만 토큰당 가격의 잠재적 차이가 포함됩니다. 소스 리전에서 개별 모델의 토큰당 동일한 가격을 지불합니다.

AI와 머신 러닝 기능이 계속 발전함에 따라, 보안 제어와 혁신 활성화 사이의 적절한 균형을 찾는 것은 조직에게 주요 과제로 남을 것입니다. 이 게시물에서 설명한 접근 방식은 이러한 특정 과제에 대한 실용적인 해결책을 제공합니다.

자세한 내용은 크로스 리전 추론으로 처리량 증가를 참조하세요.

AWS 기술 블로그