AWS What's New Digest

Appearance

2026年01月30日 ​

[General] Announcing increased 1 MB payload size support in Amazon EventBridge ​

概要 ​

Amazon EventBridge のイベントペイロード上限が従来の 256 KB から 1 MB に拡大されました。これにより、分割・圧縮・外部ストレージ化なしで、よりリッチなイベントを単一で送信できます。

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

EventBridge のイベント本文（ペイロード）サイズ上限が 256 KB → 1 MB に引き上げられました。これは PutEvents / PutEventsBatch を使って送信される各イベント単位のサイズ上限の変更で、従来はペイロードを分割したりS3等に置いて参照する設計が必要だったケースで、1 件のイベントに大容量の JSON や LLM プロンプト、テレメトリ、機械学習出力などのリッチデータを含められるようになります。PutEventsBatch のエントリ数上限（最大 10 件など）や API の呼び出しレートなど既存のスループット制約は維持されます。機能は商用 AWS リージョンのほとんどで利用可能ですが、Asia Pacific (New Zealand)、Asia Pacific (Thailand)、Asia Pacific (Malaysia)、Asia Pacific (Taipei)、Mexico (Central) など一部リージョンでは未対応です（完全な一覧は AWS Regional Services List を参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: イベント駆動アーキテクチャを利用する開発者、アーキテクト、データチーム、SRE/運用チーム
  • 利用シーン: LLM プロンプトや生成結果の送受信、複雑な機械学習推論出力の配送、センサーやテレメトリなどリッチなコンテキストを含むイベントの一括送信
  • 運用効果: イベント分割や外部ストレージ参照の設計が不要になり、アーキテクチャが簡素化。イベント数や呼び出し回数を抑えつつ詳細なコンテキストを伝搬できるため、開発・運用工数の削減やリアルタイム処理の簡便化が期待できる

技術的な注意点 ​

  • IAM権限: PutEvents, PutEventsBatch などイベント送信に必要な権限を持つこと（既存の権限モデルは変わりません）
  • リージョン制限: 多くの商用リージョンで利用可能だが、Asia Pacific (New Zealand)、Asia Pacific (Thailand)、Asia Pacific (Malaysia)、Asia Pacific (Taipei)、Mexico (Central) など一部リージョンは未対応。最新の対応状況は AWS Regional Services List を確認してください
  • コスト: EventBridge はイベント単位で課金されるため、ペイロードを大きくするとデータ転送や受信側の処理コスト、ネットワークレイテンシに影響する可能性があります。大容量ペイロードを大量に送るワークロードではコスト面を評価してください
  • 宛先サービス互換性: EventBridge 自体は 1 MB をサポートしても、ルールでルーティングされる受信先（SNS、SQS、他のサードパーティ統合、カスタムエンドポイント等）は各サービスのメッセージサイズ制限を持つ場合があります。受信先の制限を必ず確認してください
  • API/SDK/バッチ制約: PutEventsBatch のエントリ数上限（例: 最大 10 件）は引き続き有効です。クライアント側ライブラリや自前のバリデーションが旧制限（256 KB）を仮定している場合はアップデートや検証が必要です
  • 互換性: サーバーレス関数や中間処理（Lambda、API Gateway、Kinesis 等）へ中継する場合、それらのペイロード/呼び出し制限や同時実行性に与える影響を評価してください

参考情報 ​

[Bedrock] Amazon Bedrock now supports server-side custom tools using the Responses API ​

概要 ​

Amazon BedrockのResponses APIで、サーバー側カスタムツール（OpenAI API互換エンドポイント経由）を直接呼び出せるようになりました。これにより、LambdaやAWS提供ツールを使ってリアルタイムなマルチステップ操作をAWSアカウント内のガバナンス下で実行できます。

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

従来、BedrockはConverse、Chat Completions、Responses APIでクライアント側ツール利用をサポートしていましたが、今回の更新でResponses APIにおけるサーバー側ツール呼び出しが可能になりました。サーバー側ツールではクライアントを経由せずにBedrockが直接ツール（カスタムのAWS Lambda関数や、Amazonが提供するnotes/taksなどの組み込みツール）を呼び出します。これにより、ウェブ検索、コード実行、データベース更新などのマルチステップな処理を、企業のセキュリティ・コンプライアンス・ガバナンス枠内で一貫して実行できます。現時点ではOpenAI互換のGPT OSS 20Bおよび120Bモデルで利用可能で、対応リージョンは米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、アジア太平洋（東京）、アジア太平洋（ムンバイ）、南米（サンパウロ）、欧州（アイルランド）、欧州（ロンドン）、欧州（ミラノ）です。その他リージョンおよびモデルは順次対応予定です。導入にはBedrockのResponses APIエンドポイントと、ツールとして登録するLambda関数やAWS提供ツールの設定が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリ開発者、AI/MLエンジニア、SRE、エンタープライズITガバナンス担当者
  • 利用シーン: リアルタイムな検索と照合を含むマルチステップワークフロー（例: ユーザ問い合わせの自動調査→DB更新→チケット作成）、コード実行やオンプレ/クラウドリソース操作を組み込んだチャットボット、組織内データに対する挙動を制御したAIエージェントの実装
  • 運用効果: クライアント側に機密ロジックを置かず中央で一元管理できるためセキュリティとコンプライアンス管理が容易になり、クライアント実装の簡素化と遅延削減、運用監査の一元化が期待できる

技術的な注意点 ​

  • IAM権限: BedrockからLambdaや他のAWSサービスを呼び出すための適切なIAMロール/ポリシー設定（リソースベースポリシーやInvoke権限等）を準備してください
  • リージョン制限: 現時点での対応リージョンは記事記載の9リージョン（米東（バージニア北部）、米東（オハイオ）、米西（オレゴン）、アジア太平洋（東京/ムンバイ）、南米（サンパウロ）、欧州（アイルランド/ロンドン/ミラノ））。他リージョンは順次対応予定です
  • 対応モデル: 初期対応はGPT OSS 20Bおよび120Bのみ。追加モデルは今後対応予定です
  • Lambda/ネットワーク: ツールとして登録するLambdaが外部アクセスを必要とする場合はVPC設定やNAT、セキュリティグループ等を確認してください。実行時間やメモリなどLambdaの制約に注意
  • セキュリティ・ガバナンス: サーバー側で機密データが処理されるためログ、暗号化、監査（CloudTrail等）、データ保持ポリシーを整備してください
  • コスト: Bedrockのモデル利用料金に加え、Lambda実行や関連するAPIコール、データ転送、ストレージ等の費用が発生します。ワークフローの呼び出し頻度と実行時間を考慮してください

参考情報 ​

[Cognito] Amazon Cognito introduces inbound federation Lambda triggers ​

概要 ​

Amazon Cognitoが「inbound federation Lambda trigger」を導入しました。外部SAML/OIDCプロバイダからのフェデレーション属性を認証フロー中にプログラムで変換・加工できるようになり、IDプロバイダ側の設定変更なしに属性の追加・上書き・抑止が可能です。

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

新しい inbound federation Lambda トリガーは、外部SAMLまたはOIDCプロバイダから受け取った属性（フェデレーション応答）をCognitoのユーザープールに保存する前にLambda関数で加工できる機能です。これにより、プロバイダから返される大きなグループ属性などが Cognito の属性文字数上限（1属性あたり2,048文字）を超えて認証フローを妨げる問題に対応できます。主な操作として属性の追加、既存値の上書き、特定属性の抑止（保存しない）などが可能で、新規フェデレーテッドユーザー作成や既存フェデレーテッドユーザープロファイル更新の前に適用されます。ホスト型UI（classic）および managed login を通した認証フローで動作し、全てのAmazon Cognito提供リージョンで利用可能です。設定は管理コンソール、AWS CLI、SDK、CDK、CloudFormationで、User Pool の LambdaConfig に新しいパラメータを追加することで有効化します。実装サンプルやベストプラクティスは Amazon Cognito Developer Guide を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 認証基盤を管理するID/セキュリティエンジニア、クラウドエンジニア、SRE
  • 利用シーン: 外部SAML/OIDCプロバイダと連携するアプリで、プロバイダ属性の調整（大きなグループ属性の分割や不要属性の削除、属性名の正規化など）を認証時に行いたい場合
  • 運用効果: IDプロバイダ側の設定変更なしにCognito側で属性整形が可能になり、属性サイズ上限による認証失敗の回避、不要属性の保存抑止によるユーザープロファイルの簡素化、カスタム属性値の自動付与による柔軟なアクセス制御が行えるようになります

技術的な注意点 ​

  • IAM権限: トリガー設定には Cognito と Lambda の更新権限（例: cognito-idp:UpdateUserPool、lambda:AddPermission 等）が必要です。Lambda関数側には Cognito が呼び出せるリソースベースポリシーを付与してください。
  • リージョン制限: 全てのAmazon Cognito提供リージョンで利用可能と明記されています（リージョン固有の差異は公式ドキュメントで確認してください）。
  • コスト: Lambda の呼び出し・実行時間に対する通常の課金が発生します。認証フローあたりのレイテンシ増加も考慮してください。
  • 属性サイズ制限: Cognito 側の制限（1属性あたり2,048文字）や保存可能な属性スキーマを考慮して変換を行ってください。大きな属性は分割・省略・ハッシュ化するなどの対策が必要です。
  • トリガー挙動とエラーハンドリング: Lambda がエラーやタイムアウトを返すと認証が失敗する可能性があります。タイムアウト、リトライ、入力検証、ログ出力（CloudWatch）を適切に設計してください。
  • 設定方法: User Pool の LambdaConfig に新しいパラメータを追加して有効化します。CloudFormation/CDK 経由で管理する場合はテンプレート/コードの更新が必要です。
  • 互換性: ホスト型UI（classic）と managed login をサポートしますが、カスタム認証フローや独自のホスト方法での動作は事前に検証してください。

参考情報 ​

[Govcloud Us] Amazon Keyspaces (for Apache Cassandra) introduces pre-warming with WarmThroughput for your tables ​

概要 ​

Amazon Keyspaces がテーブルの事前ウォーム（WarmThroughput）をサポートしました。新規・既存テーブルでピークトラフィック到来前にスループットを明示的に引き上げることで、スケール遅延やエラーを低減します。

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

WarmThroughput により、テーブル作成時またはテーブル更新時に期待するピークスループット（スループット目標値）を手動で指定できます。指定後の事前ウォーム処理は非同期かつ非破壊的に実行され、処理中も他のテーブル変更を継続可能です。機能はプロビジョンドおよびオンデマンド両方のキャパシティモード、さらにマルチリージョン複製テーブルにも対応します。通常は Keyspaces の自動スケーリングで負荷増加に対応しますが、アプリ起動やキャンペーン等の急激なトラフィック増加に対しては、事前ウォームであらかじめ目標スループットまで準備しておくことでスケール完了待ちによる遅延やエラー率上昇を防げます。事前ウォームは一度限りの課金が発生し、課金額は指定値とベースライン容量との差分に基づき算出されます。機能は AWS Commercial と AWS GovCloud (US) の Keyspaces 提供リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: Keyspaces を利用するアプリケーション開発者、SRE／運用チーム、データベース管理者
  • 利用シーンまたは効果: 新サービスローンチ、マーケティングキャンペーン、季節的イベントなど急激なトラフィック増加を予測できる場合に、事前にテーブルをピーク負荷へ準備してスルールレイテンシやエラーを削減
  • 運用効果: スケール完了待ちによるリクエスト失敗や遅延を低減し、リリース時やイベント時の可用性・信頼性を向上
  • コスト影響: 事前ウォームは一時的な追加課金が発生するため、コスト計画に組み込む必要がある

技術的な注意点 ​

  • IAM権限: テーブルの作成・更新および事前ウォーム実行に必要な Keyspaces 関連のIAM権限（テーブル操作権限）を付与してください。詳細はドキュメントで確認してください。
  • リージョン制限: AWS Commercial と AWS GovCloud (US) の Keyspaces 提供リージョンで利用可能。利用前に対象リージョンでの提供状況を確認してください。
  • コスト: 事前ウォームは一回限りの課金で、指定したスループット値とベースライン容量との差分に基づき課金されます。オンデマンド／プロビジョンドでの課金モデルの違いはドキュメントを参照してください。
  • 実行挙動: 事前ウォームは非同期に実行され、処理中もテーブルの他操作が可能ですが、ウォーム完了まで実際のピーク耐性が確保されない点に留意してください。
  • 互換性: プロビジョンド／オンデマンド両モードとマルチリージョン複製テーブルをサポートしますが、実際のベースラインや上限の計算ルールはドキュメントで確認してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026