概要
AWSでBedrockを使うとき、所属するControl Towerでリージョンが縛ってある場合、普通に使おうとしたら使えないって怒られました。
そんなときどうするか？っていう備忘録
apacだったり、globalだったりエンドポイントあるので。
jpエンドポイント使え？
この時は使えなかったし……！高いし……！
（2025年年末、年始くらいの情報を備忘録ついでにまとめてます）
結論
管理リージョンにリージョン追加して、OU単位のリージョン拒否コントロールでいい感じに権限絞ることにした
前提
AWS Control Tower配下でBedrock利用したアプリケーションを作っていた際にエラーが発生しました。
エラーをよくよく読んでみると、リージョンが使用不可能とのエラーが出てしまった。
現状AWSControlTowerで意図的に管理リージョンを絞っているので、それの影響の気がするが既存の権限をうまく維持したままどうすればいいか考えながらやってみた。
なぜそんなことが起きたか
Bedrockは通常、東京リージョン内で利用しても、モデルによってはほかのリージョンを内部的に使うらしい。
アプリ → [東京のBedrock] ┬ [ソウルのBedrock]
├ [シンガポールのBedrock]
└ [他リージョンのBedrock]
こうなった場合、管理リージョンとして東京以外を入れていない以上
そのまま動かすと割り振られ方によっては、エラーが返却されてしまう。
実際には、結構な頻度で東京外に飛んでいたようで、エラーも多かった。
実際に考えたり、実施したこと
いい感じにBedrockを東京リージョンだけで制限できないか
結論：利用のモデルによる
Claudeのsonnet等4.5周りは日本国内（東京・大阪）に閉じられる。
試してたのは昨年末から年始とかなのでsonnet4で開発もしてたからそのまま４使いたいなぁとかそんな頃の相談だった認識です
なので、少し情報が古いですが、今はjpエンドポイント普通にありますね。
セキュリティ的な制約でjpだけに絞ってほしいみたいな要望が多ければ、これからもjpエンドポイントは残り続けると思いますが、割高なので今後どうなるんでしょうねとは思う。計算リソースもなかなか大変そうだし
まだしばらくはjpエンドポイントあるとは思いますが、それ以外も使う人のために……
1.SCPでうまくやる方法
SCPでBedrockの特定リージョンへのアクセスを拒否する方法も考えた。
たとえば以下のようなSCPを作ればいけそうに見える。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyBedrockOutsideTokyoRegion",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": "ap-northeast-1"
}
}
}
]
}
ただし、これだとクロスリージョン推論の内部呼び出しまで制限してしまう可能性がある。
効くかどうか微妙なラインだったのでテストしてみたら、やっぱり弾かれた。
つまりSCPはちゃんと効いてしまうので、使うなら「全部Deny」ではなく、推論で使うリージョン（や推論プロファイルのARN）を例外として空けてやる必要がある。
また、意図せず他のBedrockの正常な利用まで壊してしまうリスクもあるので慎重に適用する必要がある。
が、まぁ理論上はちゃんと考えれば行ける。
Condition条件の例外リージョンを増やせばいい。
2.Control Towerを生かす
結論から言うと、これが一番しっくりきた方法だった。
さっきのSCPと何が違うかというと、全リージョンを一律Denyする素のSCPを自分で書くのではなく、クロスリージョン推論で使うリージョンだけ例外を空けた制御を、Control Towerのコントロールとして入れるという違い。
仕組みとしてはどちらもSCPだけど、Control Tower管理下のガードレールと整合が取れる形で入るぶん事故りにくい。
今回はControl Tower の管理リージョン設定とOU単位のリージョン拒否コントロールを組み合わせることにした。
実際にやったこと
-
管理リージョンにBedrockが利用するリージョンを追加する
- Control TowerのLanding Zone設定で、東京（ap-northeast-1）に加えてソウル（ap-northeast-2）やシンガポール（ap-southeast-1）など、クロスリージョン推論（apacプロファイル）で使われるリージョンを管理リージョンとして追加する。
- これにより、該当リージョンへのアクセスがControl Tower管理下に入り、エラーが解消される。
-
OU単位のリージョン拒否コントロールで行き先を絞る
- 管理リージョンを追加しただけだと、そのリージョンで全サービスが使えるようになってしまい権限が広がりすぎる。
- なので
[CT.MULTISERVICE.PV.1] Deny access to AWS based on the requested AWS Region for an organizational unitを有効化して、OU単位で絞った。
ここでポイントなのが、LZ単位のリージョン拒否コントロール（GRREGIONDENY）だとこれができない？ようだった。
あっちは「ホームリージョン＋追加リージョン以外を全部拒否」なので、手順1でソウル・シンガポールを足した時点で拒否対象から外れてしまう。追加したぶんを絞り直せない。
もしできたらごめんなさい
OU単位のほうは許可リージョンと例外を個別に指定できるので、「このOUは東京だけ。Bedrockの推論呼び出しだけは他リージョンも通す」が書ける。
制限対象外のリージョン： 東京、大阪、バージニア北部など
リージョン制限対象外とするAPI： bedrock:*とかbedrock-runtime:*とか
素のSCPを一から書くよりも、Control Towerのコントロールとして入れるほうがガードレールと整合性が取れるので運用的にも簡単かなと個人的には思いました。
どんなコントロールが用意されているかはControl Catalogで一覧できるし……
Control Catalog自体は一覧するだけで、実際に効かせるのはコントロールの有効化のほう。
よかった点
- 既存のOUやアカウントの権限設定を壊さずに済む
- Control Tower管理内で完結するので、後からの変更・確認がしやすい
- Bedrockの新しいモデルで使用リージョンが変わっても、管理リージョンの追加だけで対応できる
注意点
管理リージョンを追加するとControl Towerが該当リージョンでもプロビジョニング処理を走らせるため、初回適用に少し時間がかかる。
あと、追加したリージョンでもConfigのレコーディングが回るので、コストは増える前提で見積もっておいたほうがいい。
Globalの場合、すべてのリージョンに飛ぶ可能性があるらしいので、今回みたいな形にするか、いっそのことリージョン制限しないか等は考える必要あり。
感想
Control TowerやらOrganization環境やらは、1会社1個だったりも多いので、
なかなか構築だったり設定変更の機会が少ないのでちょっと情報が少ない。
AWSなので手段が複数ある中でどれが一番メリットが大きいかを考えながら決める必要があるので、調べたり聞いたりできない代わりに検証しながら試すのが楽しいけど大変ですねってお話。