みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。

「スキーマ変更は利用の少ない深夜に、フェイルオーバー試験は休日に。」データベースを止めないための調整に、エンジニアの時間が少しずつ削られていく。そんな場面に直面することはありませんか。9/14(月) 14:00 から麻布台ヒルズで開催する「Amazon Aurora DSQL Day Tokyo」では、こうした運用調整からエンジニアを解放する分散 SQL データベース Amazon Aurora DSQL について、来日するプロダクトマネージャーと日本のスペシャリスト SA が、技術詳細から適用判断のポイントまでを解説します。IVRy 様、MIXI 様、東京海上日動システムズ様など、実際に本番システムで採用されたお客様の生の知見を聞ける現地開催イベントです。深夜や休日の調整にあてていた時間をサービス開発に使えるようになるための第一歩としてご活用いただけます。参加には事前登録が必要ですので、ぜひ上記のリンクからお申し込みください。

それでは、先週の主なアップデートについて振り返っていきましょう！

2026年8月24日週の主要なアップデート

• 8/24(月)
  • Amazon Connect Customer がエージェントの音声およびチャット会話からの情報抽出に対応
    Amazon Connect Customer (旧 Amazon Connect) の会話分析に、生成 AI による情報抽出機能が追加されました。音声およびチャットの会話から、口座番号や予約 ID などの発話どおりの値 (verbatim) と、問い合わせ理由や約束したネクストステップなどの推論による値 (derived) を構造化データとして自動取得できます。抽出は機密情報のマスキング前の生データに対して実行されるため、録音や文字起こしから機密情報を秘匿しつつ、業務に必要な値だけを取り出せます。抽出結果は After Contact Work 中のエージェント画面、コンタクト検索、API、Kinesis Data Streams、S3 出力ファイルで利用でき、メール送信、タスク作成、ケース作成などのルールアクションにも直接渡せます。東京リージョンを含む対応リージョンで利用できます。
  • Amazon EKS がクラスターあたり複数の外部 OIDC ID プロバイダーをサポート
    Amazon EKS が、1 つのクラスターに複数の外部 OpenID Connect (OIDC) ID プロバイダーを関連付けられるようになりました。Kubernetes 1.32 以降のクラスターでは最大 10 個のプロバイダーを関連付けられます。従業員、契約社員、CI/CD システムなど、認証基盤が分かれているユーザー層をそれぞれのプロバイダーで直接認証できるため、Dex や Keycloak のような中間 ID ブローカーの運用や、単一プロバイダーへのユーザー統合が不要になります。追加料金はなく、Amazon EKS が利用可能なすべての AWS リージョンで利用できます。
  • Amazon ECS がエージェント接続に障害のあるコンテナインスタンスを自動検出・修復
    Amazon ECS が、コンテナインスタンス全体のエージェント接続を継続的にモニタリングし、エージェント接続に障害のあるコンテナインスタンスを自動的に検出、修復するようになりました。これにより、検出されないまま残るワークロード障害を減らし、アプリケーションの可用性を高められます。EBS ボリューム劣化、ホストの熱イベント、ネットワーク障害などで ECS エージェントとコントロールプレーン間の接続が切断されると、新しいヘルスチェックタイプ AGENT_CONNECTIVITY として検出されます。検出後の動作はコンピューティングオプションによって異なり、AWS Fargate と Amazon ECS Managed Instances では、タスクのドレイン、代替キャパシティの起動、障害インスタンスの登録解除までを ECS が自動で行います。一方 ECS on EC2 では自動修復は行われず、EventBridge に配信されるヘルス変更イベントをもとに、ユーザー自身がインスタンス置き換えワークフローを構築します。
• 8/25(火)
  • AWS Lambda 関数が IAM リソースベースポリシーをフルサポート
    AWS Lambda 関数が、IAM リソースベースポリシーをフルサポートしました。これにより、プラットフォーム管理者やセキュリティチームは、IAM の機能をフルに活用してきめ細かなアクセス許可を定義できるようになります。従来は AddPermission API でプリンシパルごとに Allow ステートメントを 1 つずつ追加する方式で、使える条件キーも aws:SourceArn、aws:SourceAccount、aws:PrincipalOrgID の 3 種類に限られており、マルチアカウント環境などでの大規模な権限管理には柔軟性が不足していました。今回追加された PutResourcePolicy API では、複数プリンシパル・複数アクションを 1 つのポリシードキュメントにまとめられるほか、IAM 条件キーをフルに活用して送信元 IP やプリンシパルタグに基づくアクセス制限が可能になります。
  • AWS Batch が Amazon ECS Managed Instances をサポート
    AWS Batch のコンピューティング環境として Amazon ECS Managed Instances (ECS MI) を選択できるようになり、GPU を使うジョブや計算負荷の高いバッチワークロードを AWS 管理のインフラで実行できるようになりました。これまで GPU を使うジョブや 32 vCPU / 244 GiB を超えるジョブは EC2 コンピューティング環境が必要で、AMI の更新やインスタンスの管理を利用者側で担う必要がありましたが、本アップデートによりこうしたインフラ管理なしで GPU インスタンスを利用できます。料金は EC2 インスタンス料金に加えてインスタンスタイプごとの管理料金が発生します。AWS Batch が利用可能なすべての AWS リージョンでサポートされます。
• 8/26(水)
  • AWS Backup が Amazon DocumentDB のクロスリージョンバックアップコピーと論理的エアギャップボールトを 9 リージョンで追加サポート
    AWS Backup が、Amazon DocumentDB バックアップのクロスリージョンコピーと論理的エアギャップボールト (Logically Air-gapped Vault) への保管を、香港、ジャカルタ、メルボルン、大阪、スペイン、ストックホルム、チューリッヒ、ケープタウン、テルアビブの 9 リージョンで追加サポートしました。バックアッププランまたはオンデマンドコピージョブにより、これらのリージョンとの間で DocumentDB バックアップをコピーできます。また、論理的エアギャップボールトはデフォルトでロックされた不変ストレージであり、AWS RAM でボールトを共有して別アカウントから復旧できるほか、アカウント侵害時にはマルチパーティ承認 (Multi-party approval) でボールトへのアクセスを保護できます。日本のユーザーにとっては大阪リージョンが対象に含まれた点が重要で、東京 – 大阪間の国内完結型 DR 構成を DocumentDB でも構築できます。
  • Mountpoint for Amazon S3 がメモリ使用量の制御機能を追加
    Mountpoint for Amazon S3 の v1.24.0 で、メモリ使用量を制御する機能が追加されました。新しい –memory-target オプションでメモリ使用量の目標値を MiB 単位で指定できるほか、指定しない場合は実行環境 (システム全体または cgroup によるコンテナのメモリ上限) を自動検出し、その 95% をデフォルト値として使用します。これまで Mountpoint はプリフェッチなどの動作によりメモリ使用量が使用パターンに応じて増加し、ML トレーニングや分析ワークロードなどメモリを多く使うアプリケーションと同居させると、パフォーマンスや安定性の問題を引き起こすことがありました。今回の機能により、Amazon EKS などメモリ割り当てが厳格なコンテナ環境でも Mountpoint を安定して運用できます。
  • Amazon Connect Customer がエージェントスケジュールで計画外シュリンケージをサポート
    Amazon Connect Customer のエージェントスケジューリング機能で、計画外シュリンケージを入力できるようになりました。遅刻ログインや急な病欠など、事前にスケジュールへ組み込めないエージェントの不在率の想定をアップロードすると、スケジュール済みヘッドカウント、ネットスタッフィング、予測サービスレベルなどのメトリクスが即座に再計算されます。WFM 管理者はスケジュール上の人員不足を事前に把握し、対策を打てるようになります。
• 8/27(木)
  • Amazon Aurora DSQL が外部キー制約をサポート
    Amazon Aurora DSQL で、新規テーブルおよび既存テーブルに外部キー制約 (FOREIGN KEY) を定義できるようになりました。これまでアプリケーション側で実装する必要があった参照整合性のチェックを、データベース側に任せられます。参照先の行が削除・更新されたときの動作として、NO ACTION、RESTRICT、CASCADE、SET NULL、SET DEFAULT の 5 種類の参照アクションを指定できます。なお、Aurora DSQL はロックではなく楽観的同時実行制御 (OCC) によりコミット時に競合を検証する設計のため、競合時は直列化エラーが返り、アプリケーション側でのリトライ実装が前提になる点は外部キーの利用時も変わりません。
  • AWS Backup が Amazon FSx for NetApp ONTAP のクロスリージョンおよびクロスアカウントバックアップに対応
    AWS Backup で作成した Amazon FSx for NetApp ONTAP のバックアップを、別の AWS リージョンや別の AWS アカウントにコピーできるようになりました。コピーはバックアッププランによるポリシーベースの自動実行と、オンデマンドのコピージョブの両方に対応します。これまで AWS Backup では FSx for ONTAP バックアップのリージョン間・アカウント間コピーは非対応でしたが、今回の対応によりコピーを AWS Backup で一元管理できます。AWS Organizations と組み合わせることで、組織全体でコピーを自動化することも可能です。
  • Amazon Redshift が Agent Toolkit for AWS と統合、AI 支援によるデータウェアハウス管理に対応
    Amazon Redshift が Agent Toolkit for AWS と統合され、Claude Code、Kiro、Cursor などの AI コーディングエージェントから Redshift データウェアハウスおよびデータレイクの構築、クエリ、トラブルシューティング、Redshift への移行を実行できるようになりました。この統合は 2 つの要素で構成されます。ユーザーの認証情報を使って AWS API を実行する AWS MCP Server と、AI エージェントが Redshift のタスクを確実にこなせるよう検証済みの手順や参照情報をパッケージ化した Redshift skills です。導入は、利用中のエージェントに aws-data-analytics プラグインをインストールするだけで、MCP Server の設定と Redshift skills が 1 ステップでまとめてセットアップできます。
• 8/28(金)
  • Amazon CloudWatch agent が journald ログのサポートを追加
    Amazon CloudWatch agent が、systemd journal (journald) のログを直接読み取って Amazon CloudWatch Logs に送信できるようになりました。Amazon Linux 2023 のように systemd journal を主要なログ基盤とし、/var/log/messages などのテキストログをデフォルトでは書き出さないディストリビューションでも、ファイルへのエクスポート設定なしで OS ログを収集できます。systemd ユニット、journal 優先度、journal フィールドマッチ、正規表現の 4 種類のフィルターを送信前に適用できるため、取り込み量とコストを制御できます。すべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用できます。
  • Amazon Bedrock AgentCore Memory がきめ細かなアクセス制御をサポート
    Amazon Bedrock AgentCore Memory が、きめ細かなアクセス制御 (FGAC) に対応し、独自の認可ロジックを実装することなく、ユーザー単位・テナント単位のメモリ分離を強制できるようになりました。具体的には、Memory リソースの前段に OAuth (JWT) 認証を構成した AgentCore Gateway を配置し、Cedar ポリシー (AWS が開発したオープンソースの認可ポリシー言語) を適用することで、分離をインフラ層で強制します。従来はアプリケーションコードが actorId や namespace を正しく設定することに依存していた分離処理を、認証済みトークンのクレームに基づくポリシー評価に置き換えられます。基盤となる AgentCore Memory connector は、12 の Memory 操作を Cedar アクションとして公開します。
  • Amazon Bedrock AgentCore Memory がフレキシブルな namespace 変数をサポート
    Amazon Bedrock AgentCore Memory で、長期メモリの namespace テンプレートにカスタム変数を定義できるようになりました。従来は actorId、sessionId、memoryStrategyId の 3 つの組み込み変数しか使えませんでしたが、組織、テナント、チーム、環境といったアプリケーション固有の軸でメモリを分離できます。メモリリソースごとに最大 5 個のキーを定義し、CreateEvent API 実行時に値を渡すと、長期メモリ抽出時に namespace テンプレートへ代入されます。あわせて、IAM 条件キー bedrock-agentcore:namespaceVariable/<キー名> を使うと、書き込みパスでのテナント分離をポリシーで強制できます。AgentCore Memory が利用可能なすべての AWS リージョンで追加料金なしで利用できます。

それでは、また来週お会いしましょう！

著者について