AWS What's New Digest

Appearance

2026年06月24日 ​

[General] Amazon Neptune now supports AWS CloudFormation for global databases ​

概要 ​

Amazon Neptune がグローバルデータベースの作成・管理を AWS CloudFormation（AWS::Neptune::GlobalCluster リソース）でサポートしました。マルチリージョンのグラフデータベース構成をコード化して CI/CD に組み込めます。

変更内容・新機能の詳細 ​

新しい CloudFormation リソースタイプ AWS::Neptune::GlobalCluster により、Neptune のグローバルデータベース（プライマリの読み書きクラスタ＋最大5つの読み取り専用セカンダリクラスタ）をテンプレートで定義・デプロイできます。Neptune のストレージサブシステムを介した低レイテンシ複製を利用する構成を Infrastructure as Code として管理できるため、構成をソース管理やパイプラインに組み込み、自動化されたデプロイ・変更管理が可能になります。一般的な利用は、リージョン横断の低レイテンシ読み取り、ディザスターリカバリ（DR）、データ主権要件への対応、書き込みを集中させて読み取りを分散する高可用性グラフ設計などです。この記事は、当該機能が Neptune のグローバルデータベースをサポートするすべてのリージョンで利用可能であることを示しています。CloudFormation での具体的なプロパティや利用方法は公式の AWS::Neptune::GlobalCluster のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、DevOps/プラットフォームエンジニア、SRE、クラウドアーキテクト
  • 利用シーン: マルチリージョンでの低レイテンシ読み取り、災害復旧の自動化、データ居住地要件対応、グローバルなグラフ検索やリードスケールアウト
  • 運用効果: テンプレート化により再現性のあるデプロイ、CI/CD 統合による変更管理の自動化、手動ミス低減と標準化
  • 導入コスト: 複数リージョンに跨るクラスタ運用は追加のインスタンス・ストレージ費用とリージョン間データ転送料が発生する可能性
  • 制限事項: セカンダリクラスタは読み取り専用で最大5クラスタまで、プロモーションやフェイルオーバーの運用フローは別途確認が必要

技術的な注意点 ​

  • リソースタイプ: AWS::Neptune::GlobalCluster を使用して CloudFormation テンプレートで定義します（公式ドキュメントでプロパティを確認してください）
  • IAM権限: CloudFormation が Neptune グローバルクラスタ作成・更新・参照できるように適切な IAM 権限（neptune:CreateGlobalCluster 等）を付与してください
  • リージョン制限: 本機能は Neptune グローバルデータベースをサポートするリージョンで利用可能です。利用前に対象リージョンでのサポート状況を確認してください
  • 既存リソースの取り扱い: 既存のリージョンクラスタをグローバルクラスタに紐付ける場合や CloudFormation へインポートする際の制約があるため、ドキュメントで import/associate の手順を確認してください
  • 運用（フェイルオーバー/プロモーション）: CloudFormation は主に構成管理・デプロイ自動化を担います。リージョン間のプロモーションや運用時のフェイルオーバー手順は API/コンソール/運用手順を別途用意する必要があります
  • コスト: マルチリージョン構成は追加のインスタンス・ストレージとリージョン間データ転送によりコスト増加します。設計時に見積もりを行ってください
  • 互換性: CloudFormation の新しいリソースはテンプレートの更新や Rollback 挙動に影響する場合があるため、テスト環境での検証を推奨します

参考情報 ​

[CloudWatch] Amazon CloudWatch now supports tags on dashboards ​

概要 ​

Amazon CloudWatchのダッシュボードにタグ付けが可能になりました。ダッシュボードごとに最大50個のキー値ペアタグを割り当てて整理・分類・アクセス制御できます。

変更内容・新機能の詳細 ​

今回の更新により、PutDashboard APIがオプションの Tags パラメータを受け付けるようになり、新規ダッシュボード作成時にタグを最大50件まで付与できます。既存ダッシュボードには TagResource、UntagResource、ListTagsForResource API を用いてタグの追加・削除・一覧取得が可能になりました。CloudFormationでもダッシュボードのタグを管理できるようになっています。タグはキー=値のペアで、チーム・プロジェクト・環境などでダッシュボードをグループ化したり、AWS Resource Explorerでタグによるフィルタリングを行ったり、IAMポリシーの条件（aws:ResourceTag/<タグキー> など）を使って属性ベースのアクセス制御（ABAC）を実装するために利用できます。本機能は追加料金なしで、CloudWatchが提供されている全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE/運用チーム、DevOpsエンジニア、プラットフォーム/運用基盤チーム、セキュリティ/ガバナンス担当者
  • 利用シーン: ダッシュボードをチーム・プロジェクト・環境別に整理して検索・表示する（Resource Explorerでのフィルタリング）
  • 利用シーン: IAMポリシーでタグを条件にしてダッシュボード単位のアクセス制御（ABAC）を行う
  • 運用効果: 大規模環境で多数のダッシュボードを効率的に管理でき、権限分離やコスト管理・所有者追跡が容易になる
  • 可観測性改善: チーム別ダッシュボード集約により運用対応の迅速化や責任範囲の明確化が可能

技術的な注意点 ​

  • IAM権限: cloudwatch:PutDashboard、cloudwatch:TagResource、cloudwatch:UntagResource、cloudwatch:ListTagsForResource 等の権限が必要です。タグ条件でABACを使う場合は aws:ResourceTag/<タグキー> を条件キーとして使用します。
  • リージョン制限: CloudWatchが利用可能な全リージョンで利用可能とアナウンスされていますが、利用前に対象リージョンで有効化済みか確認してください。
  • コスト: タグ付与自体に追加料金は発生しませんが、タグに基づく管理・検索やCloudFormationの利用に伴う通常のAPI/CloudFormationコストは考慮してください。
  • タグ上限: ダッシュボードあたり最大50個のタグ（キーと値のペア）です。タグキー・タグ値の一般的な制限（長さ・文字種）に従います。
  • API/SDK対応: PutDashboard の Tags パラメータと TagResource/UntagResource/ListTagsForResource がダッシュボードARNを受け付けるようになりました。既存のスクリプトやIaCでAPIバージョンやパラメータの互換性を確認してください。
  • CloudFormation: CloudFormationリソースでダッシュボードの Tags を設定可能になっています。既存のスタックやテンプレートを更新する際は差分に注意してください。
  • 注意点: タグはメタデータであり、削除や変更は容易に行えるため、ガバナンス（命名規約、所有者タグの運用ルール）を設けて運用してください。

参考情報 ​

[General] Amazon CloudWatch Logs supports managed syslog ingestion ​

概要 ​

Amazon CloudWatch Logsがマネージドなsyslog受信に対応しました。ネットワーク機器やLinuxサーバからエージェント不要で直接CloudWatch Logsへsyslogを送信・解析できます。

変更内容・新機能の詳細 ​

本機能により、ファイアウォール、ルーター、スイッチ、Linuxサーバなどからのsyslogメッセージを、TCP／TCP+TLS／UDPでアカウント内のVPCエンドポイントへ直接送信できるようになりました（エージェント不要）。サポートするsyslogフォーマットはRFC 5424、RFC 3164、Cisco FTD/ASAで、受信したメッセージは自動的にパースされ、facility、severity、hostname、application nameなどの構造化フィールドが抽出されます。これによりカスタムパースパイプラインの構築が不要となり、Logs Analyticsでseverityやhostnameで即時クエリしてセキュリティ調査や接続障害のトラブルシュートが可能です。利用開始にはVPCエンドポイントの作成とネットワーク機器側での送信先指定（エンドポイントのIP/DNS）および必要なネットワーク設定（ルート、セキュリティグループ、ACL等）が必要です。提供リージョンは商用リージョンの大半で利用可能ですが、Middle East（UAE・Bahrain）および Israel（Tel Aviv）は未対応です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク管理者、セキュリティチーム、SRE/運用チーム
  • 利用シーン: ファイアウォールやルーターのsyslogを中央集約してセキュリティイベント調査／接続障害のトラブルシュートに利用
  • 運用効果: エージェント配備・維持の手間を削減し、ログ収集の運用負荷を低減。自動パースによりクエリ作成と問題検出を迅速化
  • 導入効果: 分散環境でもログ収集を標準化でき、ログパイプラインの複雑さとコストを抑制可能

技術的な注意点 ​

  • IAM権限: VPCエンドポイント作成、CloudWatch Logsへの書き込み権限など適切なIAMロール/ポリシーが必要です
  • リージョン制限: ほとんどの商用リージョンで利用可能ですが、Middle East (UAE)、Middle East (Bahrain)、Israel (Tel Aviv) では未対応です
  • コスト: CloudWatch Logsの受信・保管・クエリ（Logs Insights/Logs Analytics）に対する料金が発生します。データ量に応じた課金と長期保存時のストレージコストを見積もってください
  • ネットワーク設定: VPCエンドポイントを介して受信するため、ルート、セキュリティグループ、ネットワークACLで受信ポートと送信元を許可する必要があります。オンプレ機器から送信する場合は、適切な接続（VPN/Direct Connect等）経路の確保が必要です
  • プロトコル/フォーマット: TCP、TCP+TLS、UDPをサポート。RFC 5424／RFC 3164／Cisco FTD/ASA形式に対応しています。TLSを利用する場合は送信機器側のTLS設定／互換性を確認してください
  • エージェント: エージェントレスで動作しますが、既存のエージェントと並行利用する場合は重複送信に注意してください
  • ログ管理: 自動パースで抽出されるフィールドはデフォルトのセットです。追加のフィールド抽出やカスタム変換が必要な場合は、CloudWatch Logsの追加機能や別ツールでの処理が必要になることがあります

参考情報 ​

[SageMaker] SageMaker Notebook Instances now support G6e instance types ​

概要 ​

Amazon SageMaker のノートブックインスタンスで EC2 G6e インスタンスタイプが利用可能になりました。NVIDIA L40s（各GPU 48GB）を最大8基、第三世代 AMD EPYC を搭載し、G5 比で最大2.5倍の性能を提供します。

変更内容・新機能の詳細 ​

G6e インスタンスは最大8基の NVIDIA L40s Tensor Core GPU（各 GPU 48 GB）と第3世代 AMD EPYC プロセッサを組み合わせた構成をサポートし、EC2 G5 インスタンスと比較して最大約2.5倍の推論／トレーニング性能を提供します。SageMaker ノートブックインスタンス上で対話的にモデルのデプロイ検証や、生成系AIのファインチューニングなどのインタラクティブなトレーニング／実験ワークロードに利用できます。大規模言語モデル（最大約13Bパラメータ）や画像・映像・音声生成用の拡散モデルの実行・評価に適しており、SageMaker Studio の JupyterLab や CodeEditor と連携して開発できます。提供リージョンは米国東部（N. Virginia、Ohio）、米国西部（Oregon）、アジアパシフィック（東京）、中東（ドバイ）、欧州（フランクフルト、スウェーデン、スペイン）です。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、データサイエンティスト、AIリサーチャー、SRE/運用チーム
  • 利用シーンまたは効果: 対話的なモデル開発・検証（LLMのプロトタイピング、ファインチューニング、拡散モデルの生成実験）、デプロイ前の性能評価や小〜中規模バッチトレーニング
  • 運用効果: より短時間でのトレーニング・推論実行により開発サイクル短縮と実験回数増加が可能
  • スケーラビリティ: 最大8GPU構成によりGPUメモリや演算能力が大きく向上し、13Bクラスのモデルが単一ノートブック上で検証しやすくなる
  • リージョン影響: 指定リージョンでのみ利用可能なため、ワークロードやデータ所在リージョンに応じた設計が必要

技術的な注意点 ​

  • IAM権限: SageMaker ノートブックインスタンスの作成・起動、関連するEC2/ELB/IM関連の権限（必要に応じて）を付与してください
  • リージョン制限: 利用可能リージョンは米国東部（N. Virginia、Ohio）、米国西部（Oregon）、アジアパシフィック（東京）、中東（ドバイ）、欧州（フランクフルト、スウェーデン、スペイン）に限定されています
  • コスト: G6e は高性能 GPU インスタンスのため、利用時間に応じてコストが高くなります。実験時はスポットインスタンスや停止／スケールダウン運用でコスト管理を検討してください
  • ドライバ／ソフトウェア: NVIDIA L40s に対応する CUDA、cuDNN、NVIDIA ドライバの互換性を確認してください。SageMaker 提供のカーネルやコンテナイメージを利用することで環境整備が簡素化されます
  • SageMaker Studio / ノートブック差異: 発表は SageMaker ノートブックインスタンス向けですが、ドキュメントに従い JupyterLab / CodeEditor を Studio やノートブックで設定可能です。Studio のインスタンスタイプ対応状況は別途確認してください
  • サービスクォータ: 同リージョンでの GPU インスタンス上限（サービスクォータ）に注意し、必要なら増枠申請を行ってください
  • モデル制約: 記載例として単一ノードで最大約13Bパラメータモデルの検証が想定されていますが、実際の可能サイズはバッチサイズ・精度（fp16/混合精度）・メモリ最適化に依存します

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore Memory now supports cross-account access ​

概要 ​

Amazon Bedrock AgentCore Memoryがクロスアカウントアクセスをサポートしました。メモリリソースと消費側エージェントを複数のAWSアカウントにまたがって構成できるようになります。

変更内容・新機能の詳細 ​

今回のアップデートにより、AgentCore Memoryのメモリリソースにリソースベースポリシーを付与することで、別アカウントのプリンシパルがメモリのデータプレーンAPIを呼び出せるようになります。具体的には、消費アカウントのプリンシパルはフルメモリARNを参照してイベントの作成、メモリレコードの書き込み／取得、セマンティックサーチなどを実行できます。さらに、メモリの配信先（Amazon S3、Amazon SNS、Amazon Kinesis Data Streams）を別アカウントに設定し、ペイロードやイベントを他アカウントのS3バケット／SNSトピック／Kinesisストリームへ配信可能です。クロスアカウントアクセスは、メモリリソースにリソースベースポリシーをアタッチして構成します。利用開始や設定手順は「Cross-account memory access（Amazon Bedrock AgentCore Developer Guide）」を参照してください。機能は、AgentCore MemoryがサポートされるすべてのAWSリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチアカウント構成でLLMメモリを共有したいアプリ開発者、プラットフォーム運用者、組織のSRE/クラウドアーキテクト
  • 利用シーン: セントラルアカウントでメモリを管理し複数プロダクト／アカウントから参照する共有メモリアーキテクチャ、組織横断の会話履歴共有、別アカウントの分析パイプラインへイベントストリームを送る構成
  • 運用効果: メモリ管理の一元化と分離されたワークロードの統合が可能になり、データ再利用性と運用効率が向上します
  • セキュリティ／ガバナンス: リソースベースポリシーで細かくアクセス制御できるため、最小権限の原則に基づく運用が行えます

技術的な注意点 ​

  • IAM権限: メモリリソースにリソースベースポリシーを設定し、消費側プリンシパルにデータプレーンAPI呼び出し権限を付与する必要があります（フルメモリARNを参照）。
  • 配信先リソースのポリシー: S3バケットポリシー、SNSトピックポリシー、Kinesisストリームのアクセスポリシーを受け入れ側アカウントで適切に設定する必要があります。
  • KMS／暗号化: S3にSSE-KMS等で保存する場合、クロスアカウントアクセス用にKMSキーの使用許可（Encrypt/Decrypt/GenerateDataKey等）を付与する必要があります。
  • リージョン制限: AgentCore Memoryがサポートされるリージョンで利用可能です。未サポートリージョンでは利用できません。
  • コスト: 複数アカウント間のデータ配信に伴うデータ転送料金、S3保存、SNS/Kinesisのリクエストおよびストリーミング料金が発生する可能性があります。
  • 運用／監査: クロスアカウントAPI呼び出しや配信イベントはCloudTrailやS3アクセスログ等で監査・監視を行ってください。
  • 実装注意: プリンシパルはフルARNでリソースを参照する必要があります。リソースベースポリシーのテストを事前に行い、最小権限でのアクセスを確認してください。

参考情報 ​

[Omics] AWS HealthOmics now supports ephemeral storage for private workflows ​

概要 ​

AWS HealthOmicsがプライベートワークフロー向けにタスク単位のエフェメラル（一次）ストレージをサポートしました。各ワークフロータスクに専用のローカルボリューム（/tmp）が割り当てられ、スクラッチI/Oの分離による安定した実行性能とコスト削減を実現します。

変更内容・新機能の詳細 ​

各ワークフロータスクはデフォルトで追加費用なしに16 GiBのエフェメラルストレージを受け取り、/tmpにマウントされます。必要に応じてWDL、Nextflow、CWLのワークフロー定義内で指示子を使ってタスクごとのエフェメラルストレージ容量を最大3,072 GiBまで増加できます。実行時にはStartRun APIを使って有効化可能です。エフェメラルボリュームはすべて暗号化され（サーバ側暗号化）、タスク終了時に自動削除されるため一時データは残りません。これにより、ゲノム配列アライメント、BAMソート、バリアントコールなど大量の一時データを生成するバイオインフォマティクス処理で、共有ランストレージのI/O競合を避けてより一貫したスループットと短いランタイムが期待できます。サービスはHIPAA対応可能なAWS HealthOmicsの一機能として提供され、利用可能リージョンは US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Singapore, Seoul) です。料金はデフォルト分は無料で、増量分は料金表に従います。

影響範囲・利用シーン ​

  • 対象ユーザー: バイオインフォマティクス研究者／データ解析者、パイプライン開発者、SRE/運用チーム
  • 利用シーンまたは効果: 大容量の一時ファイルが発生する処理（配列アライメント、BAMソート、バリアントコール等）でI/O競合を回避し、ジョブ実行時間を短縮
  • 運用効果: タスク単位でスクラッチI/Oが分離されるため、共有ストレージの性能変動に起因する遅延が減り、パフォーマンスの予測性が向上
  • コスト影響: デフォルトの16 GiBは追加費用なしだが、容量を増やすと追加料金が発生する可能性があり、総ストレージコストとI/O効率のトレードオフを評価する必要あり
  • セキュリティ/コンプライアンス: ボリュームは暗号化され、タスク終了時に自動削除されるため、機密性の高い一時データの管理が容易（HIPAA適格な環境での利用に適合）

技術的な注意点 ​

  • IAM権限: StartRun等のHealthOmics実行APIやワークフロー指定を行うための適切なIAM権限が必要。ワークフロー実行ロールがエフェメラルストレージ設定を許可していることを確認してください
  • リージョン制限: 利用可能リージョンは記事記載の通り（US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Singapore, Seoul)）。他リージョンでは未提供の可能性あり
  • コスト: デフォルトで16 GiBは追加料金なし。容量を増やした場合は追加課金が発生するため、事前にAWS HealthOmicsの料金ページで単価を確認してください
  • データ永続性: エフェメラルストレージは一時領域であり、タスク終了時にデータは削除されるため永続保存には向かない。重要データは明示的に共有ストレージやS3等へ移す必要あり
  • マウントポイント/互換性: 各タスクのローカルボリュームは /tmp にマウントされる。WDL/Nextflow/CWLでの指定方法に従って一時ファイル配置を調整してください
  • 最大値/設定方法: タスクあたり最大3,072 GiBまで指定可能。増量はワークフロー定義の指示子またはStartRun APIで設定
  • 暗号化: すべてのエフェメラルボリュームは暗号化される（追加の設定が不要な場合が多いが、組織の暗号化ポリシーに合わせて確認してください）

参考情報 ​

[Cognito] Amazon Cognito now supports customer managed key for encryption at rest ​

概要 ​

Amazon Cognito のユーザープールが、保存時暗号化（encryption at rest）において AWS KMS のカスタマー管理キー（CMK）を利用できるようになりました。これにより組織は暗号鍵のライフサイクルとアクセス制御を自前で管理でき、データガバナンス要件を満たしやすくなります。

変更内容・新機能の詳細 ​

従来は AWS 所有鍵（AWS owned keys）がデフォルトでユーザープールデータの暗号化に使われますが、今回の更新で AWS KMS のカスタマー管理キー（Customer managed keys）を指定できるようになりました。CMK を用いるとキーの作成、ポリシー設定、無効化・削除、ローテーションなどを組織側で管理できます。ユーザープール作成時に CMK を指定するか、既存のユーザープールを更新して CMK を適用可能です。KMS の監査機能（CloudTrail によるキー使用ログ）を併用することで、誰がいつキーを使ってデータにアクセスしたかを可視化できます。利用可能なユーザープールのプランは Essentials と Plus で、Cognito 側に追加料金は発生しませんが、KMS の標準料金は適用されます。設定は AWS Management Console、AWS CLI、AWS SDK から行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/コンプライアンス担当者、クラウド/アイデンティティ運用者、SRE
  • 利用シーン: 規制対応（鍵管理要件）、内部監査対応、キーの一括無効化によるデータアクセス遮断（退職者や委託先対応）
  • 運用効果: 暗号鍵ポリシーを組織ルールに合わせて適用でき、CloudTrail と組み合わせてキー使用の監査証跡が取得可能
  • コスト影響: Cognito の機能利用に追加料金は発生しないが、KMS CMK の API 呼び出しやキー保管に対する標準の AWS KMS 料金が適用される
  • 利用上の制約: CMK は KMS のリージョンごとのリソースのため、ユーザープールと同一リージョン内のキーを使用する必要がある点に注意

技術的な注意点 ​

  • IAM権限: Cognito が CMK を利用できるように、KMS キーポリシーまたは IAM ポリシーで cognito-idp.amazonaws.com（サービスプリンシパル）や必要なロールにkms:Encrypt、kms:Decrypt、kms:GenerateDataKey、kms:ReEncryptFrom/To、kms:DescribeKey 等の許可を与える必要があります
  • キーライフサイクル: キーを無効化または削除すると、そのキーで暗号化されたデータにアクセスできなくなるため、無効化・削除は慎重に行ってください（復旧が不可能になる場合があります）
  • 既存データの再暗号化: 既存のユーザープールデータが新しい CMK に自動で再暗号化されるかどうかは環境によって異なる可能性があるため、更新前に再暗号化挙動を確認し、必要なら移行手順を検討してください
  • キー回転: KMS の自動ローテーションはサポートされていますが、運用ポリシーと互換性を確認してください
  • CloudTrail/監査: KMS の使用は CloudTrail で記録可能です。監査要件がある場合は CloudTrail の設定とログ保存先（S3／Lake／ログ分析）を合わせて構成してください
  • リージョン制限: 特になし。ただし KMS キーはリージョン毎のリソースのため、ユーザープールと同一リージョンの CMK を使用する必要があります
  • コスト: Cognito 側の追加課金はないが、KMS の API 呼び出し・キー作成等の標準料金が発生します

参考情報 ​

[Bedrock] Automated Reasoning checks in Amazon Bedrock Guardrails add new policy refinement workflows ​

概要 ​

Amazon Bedrock GuardrailsのAutomated Reasoningチェックに、ポリシーを自動で改良する2つのワークフロー（反復的ポリシー改善、あいまいさ削減）が追加され、手作業を減らして検証精度を向上させます。

変更内容・新機能の詳細 ​

Automated Reasoningチェックは形式論理を用いて、ユーザー定義のポリシーに対して生成AIの応答がその要件を満たすか数学的に検証し、ハルシネーション検出や説明可能性を提供します。今回のアップデートでは「Iterative policy improvement（反復的ポリシー改善）」と「あいまいさ削減（ambiguity reduction）」の2つの自動改良ワークフローを導入しました。反復的改善は、既に作成した自然言語のテスト（ポリシーに対する期待応答例）を基に、システムがポリシーのどこをどのように修正すればテストを通過するかを推論してポリシー変更案を提示・適用します。あいまいさ削減ワークフローは、変数記述や型定義のあいまいな翻訳（モデルが複数の解釈を持つケース）を自動で明確化し、あいまいな解釈が起きる頻度を低減します。両ワークフローはAmazon BedrockのAPIとAWS Management Consoleから利用可能で、ポリシーページの「Refine policy」から開始できます。利用可能リージョンは、Automated Reasoning checksが提供されているすべてのAWSリージョンです。これらのワークフローにより、ポリシー定義の品質に依存する検証結果の再現性と信頼性が向上します。

影響範囲・利用シーン ​

  • 対象ユーザー: LLMガバナンス担当者、生成AIアプリ開発者、SRE/セキュリティ/コンプライアンスチーム
  • 利用シーンまたは効果: ポリシー検証の精度向上（ハルシネーション検出の信頼性向上）およびポリシー定義作業の自動化による運用負荷軽減
  • 運用効果: テストケースに基づく自動修正でポリシーの反復改善が迅速化され、あいまいな変数・型定義を自動で明確化することで誤検知・見落としを減らせる

技術的な注意点 ​

  • IAM権限: Automated Reasoningチェックやポリシー改良を実行するためのBedrock/Guardrails関連のIAM権限（ポリシー編集、実行、ログ参照など）が必要です
  • リージョン制限: Automated Reasoning checksが未提供のリージョンでは利用不可です。新機能はAutomated Reasoning checks提供リージョンで有効です
  • コスト: 改良ワークフローの実行は計算リソースを消費するため、BedrockのAPI呼び出しや検証処理に関連する料金が発生する可能性があります
  • ポリシー互換性: 自動改良は既存のポリシー構造・変数名・型定義に変更を加えるため、適用後はポリシーの意図と副作用をレビューしてください
  • テスト品質: 反復的改善は与えた自然言語テストの品質に依存します。誤った/偏ったテストは不適切な改良を導く可能性があります
  • 監査とログ: 改良履歴やポリシー変更を追跡できるように、変更のログ保存とレビュー手順を整備してください

参考情報 ​

[General] Amazon CloudWatch launches OTel Container Insights for Amazon EKS ​

概要 ​

Amazon CloudWatchが「OTel Container Insights for Amazon EKS」を発表しました。OpenTelemetry準拠の受信器（cAdvisor、kube-state-metrics、NVIDIA DCGM）を使って30秒粒度でインフラ系メトリクスを収集し、PromQLエンドポイントや事前定義ダッシュボードで既存のPrometheus/Grafanaと容易に連携できます。

変更内容・新機能の詳細 ​

OTel Container Insights for Amazon EKSは、EKSクラスタのノード／Pod／ワークロードのインフラ指標をOpenTelemetry受信器（cAdvisor、kube-state-metrics、NVIDIA DCGM）を用いて30秒ごとの粒度で収集します。各メトリクスにはOpenTelemetryのセマンティックコンベンションとKubernetesラベルが付与されるため、ノード・Pod・ワークロードをまたいだ相関を単一のPromQLクエリで実行できます。事前構築されたダッシュボードによりクラスタヘルス、ノード性能、Podレベルのリソース使用状況を即座に可視化可能です。CloudWatchのPromQLエンドポイントを使えば既存のPrometheusやGrafanaダッシュボードを直接CloudWatchへ接続できます。導入はEKSコンソール、CloudWatch Observability add-on（v6.2.0以上）、Helm、CloudFormationから可能です。商用リージョンのほとんどで利用可能ですが、Middle East (UAE)、Middle East (Bahrain)、Israel (Tel Aviv)では未対応です。利用料金はCloudWatchの課金体系に従います（詳細は料金ページ参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: EKSを利用するSRE/プラットフォームエンジニア、DevOps、クラウド運用チーム
  • 利用シーン: 既存のPrometheusベース監視からCloudWatchへ移行／統合する場合、またはGPUを含むクラスタのインフラ監視（ノード・Pod・GPUメトリクス）
  • 運用効果: 単一のPromQLクエリでノード・Pod・ワークロード間の相関分析が可能になり、トラブルシューティング時間の短縮と運用可視性の向上が期待できる

技術的な注意点 ​

  • IAM権限: CloudWatch、EKS、Add-onのインストール・設定に関する適切なIAM権限が必要です（例: CloudWatchメトリクス閲覧・書き込み、EKSクラスタ操作権限など）。
  • アドオン/バージョン: CloudWatch Observability add-onを使う場合は v6.2.0 以上が必要です。HelmやCloudFormationでも導入可能です。
  • リージョン制限: ほとんどの商用リージョンで利用可能。ただし Middle East (UAE)、Middle East (Bahrain)、Israel (Tel Aviv) では未対応です。
  • コスト: 30秒粒度のメトリクス収集はメトリクス数とカードinalityを増やし、CloudWatchの課金（メトリクス受信、クエリ実行、ダッシュボード等）に影響します。詳細はCloudWatch料金ページを確認してください。
  • メトリクス/互換性: メトリクスはOpenTelemetryセマンティックコンベンションおよびKubernetesラベルに準拠しているため、PromQLベースの既存ルールやGrafanaダッシュボードとの互換性が高いですが、高カーディナリティなラベル設計には注意してください。
  • GPU監視: NVIDIA DCGM受信器を利用してGPUメトリクスを収集できます。ドライバ/ドキュメントの要件を満たす必要があります。

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026