AWS ConfigがBedrock AgentCore/SageMaker系9リソースに対応：AI基盤の設定監査で確認すべきこと
このテーマをもう少し広げて見るなら、Amazon Bedrock AgentCore RuntimeのInteractive Shellsとは：AIエージェントを端末から調査・デバッグする前に確認すべきこと と AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計 も合わせて確認してください。ConfigでRuntimeEndpointなどを監査する前に、AgentCore Runtimeを現場でどう調査・デバッグするかをつなげて確認できます。
3行まとめ
Amazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMaker AI系のリソースがAWS Configで追跡しやすくなりました。
all resource typesを記録している環境では、新しい対象リソースも記録範囲に入る可能性があります。
resource type名の暗記より、recorder、rules、aggregators、Region、費用とノイズの見積もりを先に確認します。
新モデル発表ではなく、AI基盤の設定変更をあとから説明しやすくするための運用更新として読むのが実務的です。
AWSは2026年6月3日、AWS ConfigがAmazon Bedrock、Amazon Bedrock AgentCore、Amazon SageMaker AI系の9リソースに対応したと発表しました。
すでにAWS Configで全リソース記録を有効にしている環境では、新しい対象リソースが自動的に追跡されるため、AI基盤の変更履歴を取りやすくなる一方で、configuration itemsやルール評価の増加も確認が必要です。
導入企業が最初に見るべきなのは、対象リソース名の暗記ではなく、Config recorderの記録方針、Config rulesとaggregatorsの適用範囲、東京を含む利用リージョン、費用とノイズの見積もりです。
今回の発表は、生成AIそのものの新モデル発表ではありません。けれど、Bedrock AgentCoreやSageMaker AIを使ってAIエージェント、評価基盤、推論エンドポイント、MLOpsパイプラインを本番に近づけているチームには、かなり実務寄りの更新です。
これまで「AIエージェントが何をできるか」に注目していた読者は、ここで一段だけ視点を変える必要があります。エージェントを作れることと、エージェント基盤の設定変更を組織として追えることは別です。AWS Configの対象が広がったということは、Bedrock AgentCoreやSageMaker AIの一部リソースを、設定監査、変更履歴、ルール評価、組織横断の棚卸しに載せやすくなった、という意味を持ちます。
Amazon Watch Japanでは、すでに<a href="https://amzn-watch.blog.mo-gmo.com/amzn-27-step-functions-agentcore-reasoning-step/" rel="noopener">AWS Step FunctionsのAgentCore推論ステップ</a>や<a href="https://amzn-watch.blog.mo-gmo.com/amzn-22-sagemaker-ai-multiturn-rl-agents/" rel="noopener">SageMaker AIのマルチターンRL</a>を取り上げてきました。今回の記事は、その「作る・動かす」側ではなく、「記録し、見つけ、評価し、あとから説明できるようにする」側の確認メモです。
なお、Amazon Watch JapanはAmazon.com, Inc.およびその関係会社とは非提携の独立ブログです。この記事はAWSサービスの利用判断を助けるための整理であり、投資助言や売買推奨ではありません。
対応した9リソースをAI基盤の運用単位で見る
Resource Type Valueは省略せずに扱うと、Config rulesやaggregatorでの確認対象を取り違えにくくなります。
AWS What’s Newで発表された新しいAWS Config対応リソースは、次の9種類です。
| サービス領域 | Resource Type Value | 運用上の見方 |
|---|---|---|
| Amazon Bedrock | AWS::Bedrock::FlowAlias | Bedrock Flowの切り替え点、環境別alias、リリース経路の変更を追う |
| Amazon Bedrock AgentCore | AWS::BedrockAgentCore::Evaluator | エージェント評価の設定や対象の変更を追う |
| Amazon Bedrock AgentCore | AWS::BedrockAgentCore::GatewayTarget | AgentCore Gatewayが接続する外部ツール/API側の変更を追う |
| Amazon Bedrock AgentCore | AWS::BedrockAgentCore::OnlineEvaluationConfig | 本番または準本番での継続評価設定を追う |
| Amazon Bedrock AgentCore | AWS::BedrockAgentCore::RuntimeEndpoint | エージェント実行面のendpoint変更、公開状態、接続境界を追う |
| Amazon SageMaker AI | AWS::SageMaker::Cluster | 学習・推論・開発基盤の計算リソース変更を追う |
| Amazon SageMaker AI | AWS::SageMaker::Endpoint | 推論エンドポイントの構成変更や本番影響を追う |
| Amazon SageMaker AI | AWS::SageMaker::ModelPackageGroup | モデル配布、承認、ライフサイクルの変更を追う |
| Amazon SageMaker AI | AWS::SageMaker::Pipeline | 学習、評価、デプロイのMLOps手順変更を追う |
BedrockではFlowAliasが監査対象に入る
根拠
AWS::Bedrock::FlowAliasは、Bedrock Flowを環境やリリース単位で切り替える読者にとって重要です。Flowそのものを作る段階では、実行結果やモデル選定に目が行きがちです。しかし本番運用では、「どのaliasが、どのflowやversionを指しているか」「誰がいつ切り替えたか」「検証済みの経路だけを使っているか」が問題になります。
Configで設定状態を記録できるようになると、alias変更を単なる手作業の記憶ではなく、監査可能な変更履歴として扱いやすくなります。特に、プロンプトやツール構成を含むAIワークフローを段階的にリリースするチームでは、FlowAliasの変更が利用者体験に直結する可能性があります。
AgentCoreでは実行、接続、評価の境界を見る
確認項目
AgentCore側では、Evaluator、GatewayTarget、OnlineEvaluationConfig、RuntimeEndpointが新しく対象に入っています。これは、AIエージェントを「1つのアプリ」として見るよりも、実行環境、外部ツール接続、評価設定、endpointという運用単位で分けて見る更新です。
RuntimeEndpointは、エージェントがどこで呼ばれ、どのように接続されるかに関係します。GatewayTargetは、エージェントが利用する外部APIやツール接続の入口です。EvaluatorとOnlineEvaluationConfigは、エージェント品質をどう測るか、どの環境で継続評価するかに関係します。
注意点
ここで注意したいのは、AWS Configは「エージェントが実行時に何を考えたか」を見るサービスではないことです。プロンプト、ツール呼び出しの詳細、実行中のエラー率、トレースは、CloudTrail、CloudWatch、AgentCore Observabilityなどと役割を分けて確認する必要があります。Configで見るのは、あくまで設定状態とその変更履歴です。
SageMaker AIでは本番推論とMLOpsの変更履歴を見る
評価基準
SageMaker AI側では、Cluster、Endpoint、ModelPackageGroup、Pipelineが対象です。SageMaker Endpointは本番推論に直結しやすく、変更の影響範囲が大きいリソースです。EndpointConfig、variant、暗号化、VPCまわり、タグ、所有者などの変更は、障害対応や監査であとから説明できる形にしておきたい領域です。
ModelPackageGroupは、モデルの承認、共有、配布の管理に関係します。Pipelineは、学習、評価、デプロイの再現性を担う部分です。Clusterは計算基盤やコストに関わります。つまり今回のSageMaker AI側の対応は、モデルを作るだけでなく、モデルをどの手順で本番に出し、どの基盤で動かし、どの変更を許容したかを追うための土台になります。
まずConfig recorderの記録対象を確認する
- 1記録方針を確認
全リソース記録、将来の対応リソースを含める方針、特定リソース記録、除外指定のどれかを確認します。
- 2対象アカウントとRegionを見る
どのAWSアカウントとRegionでAWS Configが有効か、東京リージョンを含めて整理します。
- 3集約範囲を見る
delivery channel、S3 bucket、SNS topic、Config aggregatorの集約対象を確認します。
- 4既存ルールの影響を見る
Config rulesやconformance packsが新リソースを評価対象に含めるかを確認します。
- 5変更頻度を見積もる
直近のAI関連リソースの作成、削除、変更がどの程度あるかを確認します。
全リソース記録では自動追加を前提に、特定リソース記録では追加漏れを前提に確認すると判断しやすくなります。
AWSの発表では、すでにAWS Configでall resource typesの記録を有効にしている場合、今回の新しいリソースも自動的に追跡されるとされています。これは便利ですが、読者の環境によって意味が変わります。
本番アカウントで全リソース記録を使っているなら、AI基盤の新しい変更履歴が自然に残る可能性があります。一方、検証アカウントでAI関連リソースを頻繁に作成・削除しているなら、記録量やルール評価が増えるかもしれません。特定リソースだけ記録しているなら、今回の9リソースを追加しない限り、期待した棚卸しに載らない可能性があります。
全リソース記録の環境では自動追加を前提に見る
条件
まず確認したいのは、Config recorderがどの記録方針になっているかです。全リソース記録、現在および将来の対応リソースを含める方針、特定リソースだけを含める方針、あるいは除外指定を使っている方針では、今回の発表後に起きることが違います。
確認項目
全リソース記録の環境では、今回の9リソースが自動で記録対象に入る前提で、次を確認します。
- どのAWSアカウントとRegionでAWS Configが有効か
- delivery channelがどのS3 bucketやSNS topicに流しているか
- Config aggregatorがどのアカウントとRegionを集約しているか
- 既存のConfig rulesやconformance packsが新リソースを評価対象に含めるか
- 直近30日程度でAI関連リソースの作成、削除、変更がどの程度あるか
注意点
この確認は、発表を見た直後に本番へ新ルールを入れるためではありません。まずは「いつの間にか記録対象が増えている」「いつの間にか評価数が増えている」を避けるための棚卸しです。
特定リソース記録の環境では追加漏れを見る
条件
コストやノイズを抑えるために、特定リソースだけを記録している環境もあります。その場合、今回の9リソースが公式にAWS Config対応になっても、自社のrecorder設定に含めなければ記録されません。
特にAI基盤専用アカウント、MLOpsアカウント、データサイエンス検証アカウントでは、SageMaker EndpointやPipelineだけを入れるのか、AgentCore RuntimeEndpointやGatewayTargetまで入れるのかを分けて判断したほうがよさそうです。PoC段階のすべてを本番並みに記録すると、見たい変更よりも雑音が多くなります。逆に本番に近いAIエージェント基盤なのにGatewayTargetやRuntimeEndpointを外すと、あとから外部接続や公開面の説明が弱くなります。
Daily recordingとContinuous recordingを分けて考える
評価基準
AWS Configには、変更が起きるたびに記録するContinuous recordingと、1日単位で最新状態を記録するDaily recordingがあります。AI基盤では、どちらか一方を機械的に選ぶより、変更頻度と監査の必要性で分けるのが現実的です。
本番推論に直結するSageMaker Endpointや、外部ツール接続の境界になりやすいAgentCore GatewayTarget、RuntimeEndpointは、変更が起きたタイミングを細かく追いたくなる場面があります。一方、検証用のPipelineや評価設定の試行錯誤まで常に細かく記録すると、費用と通知ノイズが先に増えることがあります。
最初の判断基準はシンプルです。障害対応、セキュリティ監査、リリース承認に使うリソースは細かく見る。実験の作り直しが多く、あとで説明する必要が薄いリソースは、まず棚卸しから始める。この線引きを、AI基盤のアカウント設計と一緒に見直します。
AI基盤では何をConfig rulesで見たいのか
Config rulesは設定条件の逸脱検知に向いています。実際の応答内容、実行ログ、評価結果はCloudTrail、CloudWatch、AgentCore Observabilityなどと分けて見ます。
AWS Configが対応したからといって、すぐに大量のConfig rulesを作る必要はありません。むしろ最初にやるべきなのは、「このリソースで検知したい逸脱は何か」を言語化することです。
| 対象 | 見たい設定 | 検知したい逸脱 | 補うべきサービス |
|---|---|---|---|
| AgentCore RuntimeEndpoint | 公開状態、所有タグ、接続境界 | 未承認のendpoint作成、環境タグ漏れ | CloudTrail、CloudWatch |
| AgentCore GatewayTarget | 接続先、ツール境界、認可設定 | 未承認APIへの接続、検証用targetの残存 | CloudTrail、AgentCore Observability |
| AgentCore Evaluator / OnlineEvaluationConfig | 評価対象、合格基準、環境 | 本番前評価の無効化、古い評価設定 | CloudWatch、評価レポート |
| SageMaker Endpoint | 推論構成、VPC、暗号化、variant | 未承認モデルの配備、公開境界変更 | CloudTrail、SageMakerログ |
| SageMaker ModelPackageGroup | 承認状態、共有範囲、ライフサイクル | 未承認モデルの昇格、共有範囲の拡大 | CloudTrail、Model Registry |
| SageMaker Pipeline | 学習・評価・デプロイ手順 | 承認ステップの迂回、環境差分 | CodePipeline、CloudTrail |
RuntimeEndpointとGatewayTargetは境界変更を見る
確認項目
AgentCore RuntimeEndpointとGatewayTargetで最初に見たいのは、境界の変更です。endpointがどの環境に属しているか、どの所有者タグを持つか、どの接続先を向いているか、意図しない公開や検証用接続が残っていないかを見ます。
AIエージェントは、外部ツールやAPIとつながるほど便利になります。その便利さは、同時に監査ポイントを増やします。GatewayTargetが変われば、エージェントが使える外部機能が変わる可能性があります。RuntimeEndpointが変われば、呼び出し面や運用境界が変わる可能性があります。
注意点
ここでConfig rulesが向いているのは、タグ、所有者、環境、承認済み設定、許可された接続先のような「設定として表せる条件」です。実際にそのエージェントがどの入力にどう応答したかは、Configだけで完結させないほうが安全です。
EvaluatorとOnlineEvaluationConfigは品質管理の変更を見る
評価基準
EvaluatorやOnlineEvaluationConfigは、AIエージェントの品質管理に近いリソースです。どの評価が本番前ゲートになっているか、どのモデルやエージェントを対象にしているか、オンライン評価がどの環境で有効かを追います。
本番リリース前に評価を通す運用を作っていても、評価設定そのものが無効化されたり、対象から外れたりすれば、品質ゲートは形だけになります。Configで設定変更を追えるようになると、「評価をしたか」だけでなく、「評価を要求する仕組みが保たれているか」を確認しやすくなります。
SageMaker EndpointとModelPackageGroupはモデル配布の変更を見る
根拠
SageMaker Endpointは、利用者や業務アプリに近い場所にあります。Endpointの構成変更は、性能、費用、可用性、モデル品質に影響します。ModelPackageGroupは、モデルの承認や共有に関係します。
この2つでは、未承認モデルの昇格、環境タグの欠落、共有範囲の拡大、暗号化やVPC設定の変更、古いモデルの残存などを見たいところです。CloudTrailで「誰が操作したか」を見て、Configで「設定状態がどう変わったか」を見る。この組み合わせが、MLOpsの監査では基本になります。
PipelineとClusterは再現性と計算基盤を見る
確認項目
SageMaker Pipelineは、学習、評価、デプロイの順序や条件を表します。Pipelineが変わると、モデルを本番へ出す手順そのものが変わることがあります。Clusterは、計算基盤、性能、費用に関係します。
AI開発では、Pipelineを素早く変えること自体は悪いことではありません。ただし、本番に近いPipelineでは、承認ステージ、評価ステージ、データ境界、モデル登録先、失敗時の扱いが変わっていないかを確認したくなります。Configは、その変更履歴を残す土台として使えます。
Aggregatorsで組織横断に棚卸しする
- 1AI基盤アカウントを集約
AI基盤OUや生成AI検証用アカウント群を先にaggregatorの対象にします。
- 2存在とタグを棚卸し
対象リソースの数、変更頻度、所有者タグ、不要な検証リソースの残存を確認します。
- 3環境ごとに基準を分ける
本番では境界変更を厳しく見て、PoCでは棚卸しと所有者確認から始めます。
- 4役割分担を明確にする
Configは設定状態、CloudTrailはAPI操作、CloudWatchやAgentCore Observabilityは実行時情報を見る役割に分けます。
Aggregator対応は横断棚卸しに効きますが、AIエージェントの出力品質やプロンプト履歴までConfigで見えるわけではありません。
今回のAWS発表では、新しく対応したリソースがConfig rulesとConfig aggregatorsでも利用できるとされています。単一アカウントで見るだけなら、まずはConfig consoleやCLIで十分かもしれません。しかし、AI基盤が複数アカウントに広がっている企業では、aggregator対応のほうが効いてきます。
たとえば、開発アカウント、検証アカウント、本番アカウント、データ基盤アカウント、AI基盤管理アカウントが分かれている場合、SageMaker EndpointやAgentCore GatewayTargetがどこに存在するかを横断で見たい場面があります。全社のAI利用状況を把握したいとき、個別アカウントに入って手作業で探す運用はすぐにつらくなります。
AI基盤アカウントだけを最初の集約対象にする
条件
最初からOrganizations配下の全アカウントに同じ見方を適用すると、例外が多くなりがちです。おすすめしやすい順序は、AI基盤OUや生成AI検証用アカウント群を先に集約し、そこで対象リソースの数、変更頻度、タグの状態、不要な検証リソースの残存を確認する流れです。
本番アカウントでは、GatewayTargetやEndpointの境界変更を厳しく見る。PoCアカウントでは、まず棚卸しと所有者タグの確認にとどめる。こうした粒度差をつけると、Config rulesの評価数も、運用チームの例外対応も抑えやすくなります。
Config、CloudTrail、CloudWatchの役割を分ける
注意点
Config aggregatorは便利ですが、ConfigだけでAI基盤の監査が完結するわけではありません。
AWS Configは、リソースの設定状態と変更履歴を見るためのサービスです。CloudTrailは、誰がどのAPI操作をしたかを見るために使います。CloudWatchやAgentCore Observabilityは、実行時のメトリクス、ログ、トレース、評価結果を見るために使います。
この役割分担を本文で明確にしておくことは大切です。Config対応が広がったからといって、エージェントの出力品質やプロンプト履歴までConfigで見えるようになった、と読むのは危険です。今回見えるようになったのは、運用上の設定変更を管理しやすくするための面です。
コストとノイズを増やさない設計にする
対象リソースの作成、変更、削除が記録されます。短命リソースが多い検証環境では増加しやすくなります。
新リソースをConfig rulesの対象に入れると評価回数が増える可能性があります。
組織ルールに広げる前に、誤検知や例外申請が運用を圧迫しないかを確認します。
S3、SNS、Lambdaなど、delivery channelや通知、評価処理に関係する費用も合わせて見ます。
最初は棚卸し、次にタグや承認済み接続先の逸脱検知、最後に本番AI基盤向けの組織ルールへ広げます。
実際の費用はRegion、記録頻度、ルール数、評価回数、conformance pack数、周辺サービスの使い方で変わります。
AWS Configの料金ページでは、主な課金要素としてconfiguration items、AWS Config rule evaluations、conformance pack evaluationsが説明されています。さらに、利用形態によってはS3、SNS、Lambdaなど周辺サービスの費用も関係します。
今回の対応拡大は、監査の見える範囲を広げる更新です。ただし、見える範囲が広がるということは、記録される設定項目や評価対象が増える可能性があるということでもあります。
configuration itemsが増える場面
上振れしやすい条件
configuration itemは、リソースの設定状態を記録する単位です。新しいリソースが記録対象になれば、その作成、変更、削除が記録される可能性があります。
本番で数個のEndpointやRuntimeEndpointを慎重に運用しているだけなら、増加は小さいかもしれません。一方、AI開発チームが日々Endpointを作り直したり、Pipelineを頻繁に更新したり、評価設定を試行錯誤したりしている検証環境では、想像以上に記録量が増えることがあります。
特に短命リソースが多い環境では、便利な自動記録が費用とノイズの両方に効きます。まずは直近のリソース作成頻度を見て、全リソース記録を続けるのか、対象リソースを分けるのかを判断します。
rule evaluationsとconformance packsを急に増やさない
段階的な評価基準
Config rulesやconformance packsは、設定状態を評価するために使います。今回の新リソースを対象に入れれば、評価回数が増える可能性があります。
最初から「すべてのAgentCore/SageMakerリソースに厳密なルールをかける」と決めるより、段階的に進めるほうが現実的です。第1段階は棚卸し。第2段階は所有者タグ、環境タグ、承認済み接続先のような分かりやすい逸脱検知。第3段階で、本番AI基盤向けのconformance packや組織ルールへ広げる。こうした順番にすると、誤検知や例外申請に運用が飲まれにくくなります。
料金単価は公式ページで再確認する
確認項目
この記事では、具体的な請求額を固定しません。AWS Configの単価や対象範囲は変わる可能性があり、Region、記録頻度、ルール数、評価回数、conformance pack数、周辺サービスの使い方で実際の費用が変わるためです。
読者が実務で確認するなら、AWS Config pricingページを見たうえで、次を見積もり項目にします。
- 対象Region
- 記録対象リソース数
- Continuous recordingかDaily recordingか
- Config rulesの数と評価頻度
- conformance packsの有無
- Aggregatorで集約するアカウントとRegion
- 設定履歴を保存するS3や通知に使うSNSなどの周辺費用
費用を抑えることだけを目的にすると、あとから必要な変更履歴が残っていないことがあります。逆にすべてを細かく記録すると、見たい逸脱が埋もれることがあります。AI基盤では、この中間を設計することが大切です。
実アカウントでの確認手順
- 1RecorderとRegionを確認
対象アカウントとRegionでAWS Configが有効か、ap-northeast-1を含めて確認します。
- 2記録対象を確認
全リソース記録、特定リソース記録、除外指定、aggregator側の集約Regionを見ます。
- 3対象リソースを発見
SageMaker EndpointやAgentCore系リソースがConfig上で見えるかをResource Type Valueで確認します。
- 4見えない理由を切り分け
対象Region、記録開始時刻、IAM権限、recorderの対象指定、リソースの存在を順番に確認します。
- 5変更履歴と評価数を試す
検証アカウントで1つの対象リソースを作成、変更、削除し、configuration timelineと既存ルールへの影響を見ます。
Configに載ることだけでなく、載った変更をセキュリティチームやMLOpsチームが読める粒度かどうかを確認します。
公式発表を読んだあと、実アカウントで最初に確認する流れはそれほど複雑ではありません。ただし、本番でいきなりルールを増やすのではなく、記録設定、対象Region、リソース発見、変更履歴、評価数の順で小さく見ます。
RecorderとRegionを確認する
確認項目
まず、AWS Configが対象アカウントとRegionで有効になっているかを確認します。東京リージョンで利用する読者は、ap-northeast-1でConfig recorderが動いているか、対象リソース自体がそのRegionで利用可能か、AWS ConfigのResource Coverage by Regionで扱えるかを分けて見ます。
確認に使うコマンド例は次のようなものです。実行結果そのものを記事に貼る必要はありません。見るべきなのは、記録対象、状態、対象Regionです。
aws configservice describe-configuration-recorders --region ap-northeast-1
aws configservice describe-configuration-recorder-status --region ap-northeast-1全リソース記録なのか、特定リソース記録なのか、除外指定があるのかを確認します。組織横断で見ている場合は、aggregator側の集約Regionも合わせて確認します。
対象リソースがConfig上で見えるかを確認する
切り分け条件
次に、実際に対象リソースが発見されるかを確認します。たとえばSageMaker Endpointがある環境なら、次のような確認ができます。
aws configservice list-discovered-resources \
--resource-type AWS::SageMaker::Endpoint \
--region ap-northeast-1AgentCore系リソースについても、公式ドキュメントのResource Type Valueをそのまま使い、表記を省略しないことが大切です。RuntimeEndpoint、GatewayTarget、OnlineEvaluationConfigのような表記は、サービス画面で見慣れた名称と完全に同じ感覚で扱うと間違えやすいことがあります。
リソースが見えない場合は、すぐに「対応していない」と判断せず、対象Region、記録開始時刻、IAM権限、recorderの対象指定、リソースが本当に存在するかを順番に確認します。
変更履歴とルール評価を小さく試す
評価基準
本番に広げる前に、検証アカウントで1つの対象リソースを作成、変更、削除し、AWS Configのconfiguration timelineにどのように出るかを確認します。これで、監査に使える粒度で履歴が残るか、期待したタグや設定項目が見えるか、既存ルールが意図しない評価を増やしていないかを見られます。
AI基盤では、変更そのものが多くなりがちです。Configに載るから安心、ではなく、Configに載った変更を人間が読めるか、セキュリティチームやMLOpsチームが扱える粒度になっているかを確認します。
導入判断の分岐
対象リソースの数、所有者タグ、環境タグ、期限タグを棚卸しし、どのチームが何を試しているかを把握します。
RuntimeEndpoint、GatewayTarget、SageMaker Endpoint、ModelPackageGroupを優先し、外部接続、公開境界、モデル承認、VPC設定を見ます。
aggregatorで横断棚卸しを行い、本番OU、検証OU、個人検証アカウントで評価基準と例外管理を分けます。
AI基盤では、実験速度と統制のバランスがそのまま運用負荷に出ます。すべての環境に同じ厳しさを当てる必要はありません。
今回の更新を受けて、すべての読者が同じ対応をする必要はありません。利用段階ごとに、確認の深さを変えるのが自然です。
まだPoCなら棚卸しからでよい
条件
PoC段階なら、まずは対象リソースがどれだけ作られているかを見ます。所有者タグ、環境タグ、期限タグがないリソースを見つけるだけでも価値があります。いきなり厳格なConfig rulesを入れるより、どのチームがどのAgentCore/SageMakerリソースを試しているかを把握するほうが先です。
本番利用が近いなら境界と承認を優先する
確認項目
本番利用が近いなら、RuntimeEndpoint、GatewayTarget、SageMaker Endpoint、ModelPackageGroupを優先して見ます。外部接続、公開境界、モデル承認、環境タグ、暗号化、VPC設定、承認済みデプロイ経路が確認対象です。
この段階では、Config rulesを「違反を罰する仕組み」として始めるより、「本番前に見落としを減らす仕組み」として始めるほうが受け入れられやすいはずです。
組織展開済みならaggregatorと例外管理を見る
評価基準
すでに複数アカウントでAI基盤を展開しているなら、aggregatorで横断棚卸しを行い、例外管理の運用を先に決めます。全アカウントに同じルールを入れると、検証アカウントの例外が増えすぎることがあります。
本番OU、検証OU、個人検証アカウントで評価基準を分け、どの逸脱は即対応、どの逸脱は週次棚卸し、どの逸脱は期限付き許容にするのかを決めます。AI基盤では、実験速度と統制のバランスがそのまま運用負荷に出ます。
まとめと次に読むなら
全リソース記録か、特定リソース記録かを確認します。
今回の9リソースが対象Regionと実アカウントで見えるかを確認します。
GatewayTarget、RuntimeEndpoint、SageMaker Endpointなどを優先して見ます。
Config rulesやconformance packsを急に増やしすぎていないかを確認します。
Config、CloudTrail、CloudWatch、AgentCore Observabilityの役割を混同していないかを確認します。
作れるAIエージェントやモデルが増えるほど、設定変更と接続先をあとから説明できる状態が重要になります。
AWS Configの新しい9リソース対応は、Bedrock AgentCoreやSageMaker AIを使うチームにとって、地味ですが重要な運用更新です。作れるAIエージェントやモデルが増えるほど、どの設定がいつ変わったのか、どの接続先が許可されているのか、どの評価設定が本番前ゲートになっているのかを説明する力が必要になります。
今回まず確認したいのは、次の5点です。
- 自社のConfig recorderが全リソース記録か、特定リソース記録か
- 今回の9リソースが対象Regionと実アカウントで見えるか
- GatewayTarget、RuntimeEndpoint、SageMaker Endpointなど本番影響の大きいリソースを優先しているか
- Config rulesやconformance packsを急に増やしすぎていないか
- Config、CloudTrail、CloudWatch、AgentCore Observabilityの役割を混同していないか
AWSの生成AI関連発表は、モデル、エージェント、開発体験に注目が集まりがちです。しかし本番利用では、監査と説明責任の地味な整備が効いてきます。今回のAWS Config対応は、その整備を進めるための合図として読むのがよさそうです。
次に読むなら
参照した主な情報源
- AWS What’s New「AWS Config now supports 9 new resource types」（2026年6月3日発表、2026年6月6日確認）
https://aws.amazon.com/about-aws/whats-new/2026/05/aws-config-new-resource-types/
- AWS Config Developer Guide「Supported Resource Types for AWS Config」（2026年6月6日確認）
https://docs.aws.amazon.com/config/latest/developerguide/resource-config-reference.html
- AWS Config Developer Guide「Recording AWS Resources with AWS Config」（2026年6月6日確認）
https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html
- AWS Config pricing（2026年6月6日確認）
https://aws.amazon.com/config/pricing/
- Amazon Bedrock AgentCore Developer Guide「Overview」（2026年6月6日確認）
https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html
- AWS Config Developer Guide「Resource Coverage by Region Availability」（2026年6月6日確認）
https://docs.aws.amazon.com/config/latest/developerguide/what-is-resource-config-coverage.html
更新履歴
- 2026年6月6日: AWS What’s New、AWS Configの対応リソース一覧、記録設定ドキュメント、料金ページ、Bedrock AgentCore概要を確認して初稿を作成しました。
- 今後の確認項目: Supported Resource Typesの表記、Resource Coverage by Region、AWS Config pricing、AgentCore系Resource Type Valueに変更があれば更新します。