マルチアカウント環境で HAQM Bedrock クロスリージョン推論を有効化する

(本記事は 2024/03/27 に投稿された Enable HAQM Bedrock cross-Region inference in multi-account environments を翻訳した記事です。)

HAQM Bedrock のクロスリージョン推論機能により、最適なパフォーマンスと可用性を維持しながら、AWS リージョン間でファンデーションモデル（FM）にアクセスする柔軟性が組織に提供されます。しかし、一部の企業ではコンプライアンス要件に従うため、サービスコントロールポリシー（SCP）や AWS Control Towerを通じて厳格なリージョンアクセス制御を実装しており、これが意図せずに HAQM Bedrock のクロスリージョン推論機能をブロックしてしまうことがあります。これにより、組織はセキュリティ制御と AI 機能の利用のバランスを取る必要がある難しい状況に直面します。

本記事では、他の AWS サービスに対する広範なリージョン制限を維持しながら、HAQM Bedrock のクロスリージョン推論を特別に許可するようにリージョンアクセス制御を変更する方法について説明します。SCP の変更と AWS Control Tower の実装の両方について、実践的な例を提供します。

クロスリージョン推論について

オンデマンドモードでモデル推論を実行する場合、サービスクォータや使用量のピーク時に制限を受ける可能性があります。クロスリージョン推論を使用すると、異なるリージョンのコンピュートを活用して、予期せぬトラフィックの急増をシームレスに管理できます。クロスリージョン推論により、複数のリージョン間でトラフィックを分散し、より高いスループットを実現できます。

多くの組織は以下を通じてリージョンアクセス制御を実装しています：

• AWS Organizations の SCP
• AWS Control Towerのコントロール
• カスタム AWS Identity and Access Management( IAM ) ポリシー

これらのコントロールは通常、セキュリティ、コンプライアンス、またはコスト管理の理由で、特定のリージョンのすべてのサービスへのアクセスを拒否します。しかし、これらの広範な拒否は、クロスリージョン推論を通じてそれらのリージョンのモデルにアクセスする必要がある場合に、HAQM Bedrock が適切に機能することも妨げてしまいます。

クロスリージョン推論の仕組みと SCP との相互作用

HAQM Bedrock のクロスリージョン推論は、推論リクエストを自動的にクロスリージョンでルーティングできる強力な機能です。この機能は、オンデマンド推論モードを使用する開発者にとって特に有益です。HAQM Bedrock を利用したアプリケーションで、より高いスループットとパフォーマンスを実現し、トラフィックの急増を効果的に管理するためのシームレスなソリューションを提供するためです。

クロスリージョン推論により、開発者は需要の変動を手動で予測する必要がなくなります。代わりに、システムが動的に複数のリージョン間でトラフィックをルーティングし、最適なリソース利用とパフォーマンスを維持します。重要なのは、クロスリージョン推論が可能な場合、接続された HAQM Bedrock API のソースリージョンを優先することで、レイテンシーを最小限に抑え、全体的な応答性を向上させることです。このインテリジェントなルーティングにより、開発チームの継続的な監視を必要とせずに、アプリケーションの信頼性、パフォーマンス、効率性が向上します

クロスリージョン推論の核となる概念は、ソースリージョンとフルフィルメントリージョンの2つです。ソースリージョン（発信元リージョンとも呼ばれる）は、クライアントが最初に推論リクエストを呼び出すリージョンです。一方、フルフィルメントリージョンは、実際に大規模言語モデル（LLM）の呼び出しリクエストを処理するリージョンです。

クロスリージョン推論は、HAQM が顧客に最高の推論体験を提供するために継続的に進化させている独自のカスタムルーティングロジックを採用しています。このルーティングメカニズムは意図的にヒューリスティックベースで、高可用性の提供を主な目的としています。デフォルトでは、可能な場合はソースリージョンでリクエストを処理しようとしますが、必要に応じて他のリージョンにシームレスにリクエストをルーティングできます。このインテリジェントなルーティングは、最適な判断を行うために、リージョンの容量、レイテンシー、可用性などの要因を考慮します。

クロスリージョン推論は強力な柔軟性を提供しますが、適切に機能するためには、すべての潜在的なフルフィルメントリージョンのモデルにアクセスできる必要があります。この要件は、SCP がクロスリージョン推論の機能に大きな影響を与える可能性がある部分です。

以下の図で示すシナリオを見てみましょう。us-east-1 と us-west-2 の2つのリージョンを使用し、AWS Organizations または AWS Control Tower コントロールを使用して実装された SCP により、他のすべてのリージョンを拒否している状況を考えます。

ワークフローは以下のステップで構成されています：

ユーザーがクロスリージョン推論プロファイルを使用して、 us-east-1の HAQM Bedrock エンドポイント（ソースリージョン）に推論リクエストを行います。
HAQM Bedrock のヒューリスティックベースのルーティングシステムが、リクエスト処理に利用可能なリージョンを評価します。
us-west-2と us-east-1 は SCP を通じて HAQM Bedrock サービスへのアクセスが許可されていますが、us-east-2 は SCP により拒否されています。
この単一のリージョン制限（us-east-2）により、クロスリージョン推論の呼び出しが失敗します。
他のリージョンが利用可能で許可されていても、1つのブロックされたリージョン（us-east-2）が存在することにより、リクエストは失敗します。
クライアントはアクションを実行する権限がないことを示すエラーを受け取ります。

この動作は設計上のものです。クロスリージョン推論サービスは、リクエストを最適にルーティングする能力を維持するために、すべての潜在的なフルフィルメントリージョンで推論を実行するアクセス権が必要です。潜在的なターゲットリージョンのいずれかが SCP によってブロックされている場合、他の利用可能なリージョンがあったとしても、クロスリージョン推論の使用は失敗します。クロスリージョン推論を正常に実装するためには、組織は対象モデルが利用可能なすべてのリージョンで HAQM Bedrock API アクションを許可するように SCP を設定する必要があります。これは、必要なモデルがホストされているすべてのリージョンを特定し、これらのリージョンで必要最小限の HAQM Bedrock 権限を許可するように SCP を変更し、一部のリージョンが主要な運用ゾーンでない場合でも、関連するすべてのリージョンでこれらの権限を維持することを意味します。以降のセクションでは、クロスリージョン推論機能を有効にするための SCP の変更と AWS Control Tower の実装に関する具体的なガイダンスを提供します。

ユースケース

サンプルユースケースとして、us-east-1 と us-west-2 のリージョンを使用します。他のすべてのリージョンはランディングゾーン拒否（GRREGIONDENY）を使用して拒否されています。HAQM 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 がアクションを拒否しているというエラーが表示されます。

HAQM Bedrock クロスリージョン推論を許可するための既存の SCP の変更

AWS Control Tower を使用してマルチアカウント AWS 環境を管理していない場合は、新しい SCP を作成するか、既存の SCP を変更して HAQM Bedrock クロスリージョン推論を許可することができます。

以下は、特定のリージョンですべてのサービスへのアクセスを拒否しながら、Anthropic の Claude 3.5 Sonnet V2 モデルのクロスリージョン推論を通じた HAQM 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 環境でドリフトを引き起こす可能性があるため推奨されません。ただし、特定の AWS サービスを許可するためのいくつかのアプローチがあります。

前提条件

AWS Control Tower の最新バージョンを実行していることを確認してください。バージョン3.x未満を使用していて、AWS Control Tower 設定によってリージョンが拒否されている場合は、リージョン拒否設定を更新するために AWS Control Tower バージョンを有効にする必要があります。AWS Control Tower の 2.x から 3.x へのアップグレードに関する考慮事項を参照してください。

さらに、AWS Control Tower の Organization ダッシュボードにポリシードリフトが表示されず、OU とアカウントがコンプライアンスを満たしていることを確認してください。

オプション1：クロスリージョン推論のための既存のリージョン拒否 SCP の拡張

AWS Control Tower は、リージョンに基づいて AWS サービスへのアクセスを制限するための2つの主要なリージョン拒否コントロールを提供します：

GRREGIONDENY（ランディングゾーンリージョン拒否コントロール） – 特定の OU ではなく、ランディングゾーン全体に適用されます。有効にすると、指定されたリージョン以外のグローバルおよびリージョナルサービスでの操作へのアクセスを禁止します。AWS Control Tower が利用できないすべてのリージョンと、ガバナンス用に選択されていないすべてのリージョンが含まれます。
MULTISERVICE.PV.1（OU リージョン拒否コントロール）- 特定の OU に適用できる設定可能なコントロール OU の指定されたリージョン以外のグローバルおよびリージョナル AWS サービスでの未記載の操作へのアクセスを禁止します。このコントロールは設定可能であり、AllowedRegions、ExemptedPrincipalARNs、ExemptedActions など、1つまたは複数のパラメータを受け付けます。これらのパラメータは、この組織単位(OU)に属するアカウントに対して許可される操作を定義します。各パラメータの説明は下記の通りです。
- AllowedRegions：OU が操作を許可されるリージョンを指定（必須）
- ExemptedPrincipalARNs：このコントロールから除外される IAM プリンシパルを指定
- ExemptedActions：このコントロールから除外されるアクションを指定

以降では、CT.MULTISERVICE.PV.1コントロールを使用して、シナリオに合わせて設定していきます。

クロスリージョン推論を使用した HAQM Bedrock 推論を許可する 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-2 を選択します。 us-east-2 は選択しません。これは、us-east-2 ですべてのサービスを拒否し、クロスリージョン推論を通じた HAQM Bedrock 推論のみを許可したいためです。

「次へ」を選択します。
「サービスアクションの追加 – オプション」ページで、NotActions に HAQM Bedrock アクションを追加します。bedrock:Invoke* を追加して HAQM Bedrock InvokeModel アクションを許可します。
「次へ」を選択します。

「設定とタグの指定 – オプション」ページで、先ほど作成した IAM ロールを「除外されるプリンシパル」に追加し、「次へ」を選択します。

設定を確認し、「コントロールの有効化」を選択します。

コントロールが有効化された後、「有効化された OU」、「アカウント」、「アーティファクト」、「リージョン」タブで設定を確認できます。

これで設定は完了です。HAQM Bedrock コンソールまたは API を使用して、前述のカスタム IAM ロール（Bedrock-Access-CRI）を引き受けることで、Anthropic の Sonnet 3.5 v2 での HAQM Bedrock 推論をテストできます。

クロスリージョン推論を使用して、3つのリージョン（us-east-1、us-east-2、us-west-2）すべてから Anthropic の Sonnet 3.5 v2 モデルへの HAQM Bedrock 推論呼び出しのみが可能になっていることが確認できます。先ほど設定した CT.MULTISERVICE.PV.1コントロールにより、us-east-2 の他のサービスへのアクセスは引き続きブロックされます。

これらのアプローチに従うことで、AWS Control Tower のドリフトを引き起こしたり、ガバナンスコントロールを損なうことなく、AWS Control Tower で管理される権限を安全に拡張できます。

オプション2：AWS Control Tower を使用して拒否されたリージョンを有効にし、SCP を使用して条件付きでブロックする

このオプションでは、拒否されたリージョン（us-east-2）を有効にし、クロスリージョン推論を通じた HAQM Bedrock 推論を許可しながら、us-east-2 を条件付きでブロックする新しい SCP を作成します。

ランディングゾーン設定ページに移動し、「設定の変更」を選択します。
この場合 us-east-2 リージョンを有効にし、他の設定は変更せずに残します。
「ランディングゾーンの更新」を選択して変更を完了します。

更新には組織の規模に応じて60分以上かかる場合があります。コンソールで更新のステータスを監視できます。

ランディングゾーンのセットアップが完了したら、組織設定を確認し、OU 全体の AWS アカウントに保留中の更新がないことを確認します。保留中の更新が表示される場合は、更新を完了し、アカウントのステータスが「登録済み」と表示されることを確認します。
AWS Control Tower コンソールで、ナビゲーションペインの「ポリシー」の下にある「サービスコントロールポリシー」を選択します。
先ほど示したサンプルポリシーで新しい SCP を作成します。この SCP は、Anthropic の Claude Sonnet 3.5 v2 の CRI プロファイル ARN を使用した HAQM Bedrock 推論を許可しながら、us-east-2 のすべてのアクションを拒否します。
SCP を特定の OU に適用します。このシナリオでは、Sandbox OU を使用します。

AWS Control Tower によって作成された既存の SCP を変更するのではなく、新しい SCP を作成するため、AWS Control Tower の状態にドリフトは発生しません。

HAQM Bedrock コンソールのプライグラウンド機能、または AWS Command Line Interface（AWS CLI）を使用して、いくつかの推論呼び出しを実行してアップデートをテストできます。クロスリージョン推論を使用して、3つのリージョン（us-east-1、us-east-2、us-west-2）すべてから Anthropic の Sonnet 3.5 v2 モデルへの HAQM Bedrock 推論呼び出しのみが可能になっていることが確認できます。us-east-2 の他の AWS サービスへのアクセスは拒否されます。

AWS Control Tower のカスタマイズを使用した SCP のデプロイ

カスタム SCP を追加する推奨方法は、AWS Control Tower のカスタマイズ（CfCT）ソリューションを通じて行うことです：

管理アカウントに CfCT ソリューションをデプロイします。
カスタム SCP を含む設定パッケージを作成します。

以下のスクリーンショットは、Anthropic の Sonnet 3.5 v2 モデルのクロスリージョン推論を使用した HAQM Bedrock への呼び出しを許可しながら、特定のリージョンを拒否する SCP の例を示しています。

manifest.yamlファイルを準備し、ポリシーを定義します。

以下のスクリーンショットは、Sandbox OU をターゲットとしたリソースを定義する manifest.yaml の例を示しています。

カスタム SCP を特定の OU にデプロイします。

まとめ

HAQM Bedrock のクロスリージョン推論は、リージョン間で FM を使用しようとする組織に貴重な柔軟性を提供します。SCP や AWS Control Tower のコントロールを慎重に変更することで、より広範なリージョンアクセス制限を維持しながら、この機能を有効にすることができます。

このアプローチにより、以下が可能になります：

リージョンアクセス要件へのコンプライアンスの維持
HAQM Bedrock の全機能の活用
プライマリリージョンからモデルにアクセスすることによるアプリケーションアーキテクチャの簡素化

クロスリージョン推論に関連する追加コストはありません。この機能が提供するフェイルオーバー機能を含め、管理、データ転送、暗号化、ネットワーク使用、およびモデルごとの100万トークンあたりの価格の潜在的な差異も含まれます。ソースリージョンの個々のモデルと同じトークンあたりの価格を支払います。

AI と機械学習の機能が進化し続けるにつれて、セキュリティコントロールとイノベーション実現のバランスを取ることは、組織にとって重要な課題であり続けるでしょう。本記事で説明したアプローチは、この特定の課題に対する実践的なソリューションを提供します。

詳細については、「クロスリージョン推論によるスループットの向上」を参照してください。

作者情報

	Satveer Khurpa は、HAQM Web Services の HAQM Bedrock におけるシニアワールドワイドスペシャリストソリューションアーキテクトです。彼はクラウドベースのアーキテクチャに関する専門知識を活かし、様々な業界のクライアントに向けた革新的な生成 AI ソリューションの開発を行っています。Satveerの生成 AI 技術に関する深い理解により、新しいビジネス機会を開拓し、具体的な価値を生み出す、スケーラブルで安全かつ責任のあるアプリケーションの設計が可能となっています。
	Ramesh Venkataraman は、AWS サービスを使用して熱心にお客様の技術的な課題を解決に取り組むソリューションアーキテクトです。プライベートでは、Stack Overflow の質問へ回答することを趣味としています。
	Dhawal Patel は、AWS のプリンシパルマシンラーニングアーキテクトです。大手企業から中規模のスタートアップまで、分散コンピューティングと人工知能に関する課題に取り組んできました。自然言語処理やコンピュータビジョンなどの深層学習を専門とし、HAQM SageMaker を用いた高性能なモデル推論の実現をお客様支援しています。
	Sumit Kumar は、シアトルを拠点とする AWS Bedrock チームのプリンシパルテクニカルプロダクトマネージャーです。様々な分野で12年以上のプロダクトマネジメント経験を持ち、AI/ML に情熱を注いでいます。仕事以外では、旅行を愛し、クリケットやローンテニスを楽しんでいます。

HAQM Web Services ブログ