AWS What's New Digest

Appearance

2026年09月02日 ​

[General] AWS User Experience Customization (UXC) is now available in all commercial AWS Regions ​

概要 ​

AWS User Experience Customization (UXC) が全ての商用AWSリージョンで利用可能になりました。アカウントのカスタムカラー設定や、AWS Management Console に表示するサービス・リージョンの制御を各リージョンからCLI/SDK/CloudFormationで管理できます。

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

UXC は管理者がアカウント単位でコンソールの見た目と表示項目をカスタマイズできる機能で、カスタムアカウントカラーの設定や、コンソールに表示するサービスおよびリージョンの表示/非表示制御が可能です。これまでは US East (N. Virginia, us-east-1) のみで提供され、プログラムから管理する際はそのリージョンをターゲットにする必要がありました。本拡張により、商用AWSリージョンの任意のリージョンから AWS CLI、AWS SDK、または AWS CloudFormation を使って設定を管理できるようになり、既存のインフラ自動化（IaC）ワークフローに統合しやすくなっています。UXC の利用に追加料金は発生しません。なお「商用リージョン」の拡張であり、AWS GovCloud や AWS China のリージョンは対象外となる点に注意してください。また、コンソール表示を隠す設定は UI の表示制御に留まり、サービスへのAPIアクセスや権限自体を変更するものではないため、権限設計とは別に考える必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: アカウント管理者、クラウド運用チーム、SRE、セキュリティ/ガバナンス担当者
  • 利用シーンまたは効果: 企業ブランディング（カスタムカラー）や、不要サービスの非表示による運用ミス低減、複数リージョンにまたがるインフラ自動化ワークフローへの統合
  • 運用効果: 以前のように単一リージョン（us-east-1）へAPIコールを集中させる必要がなくなり、管理の分散化と自動化が容易になることで運用負荷とレイテンシが低減される

技術的な注意点 ​

  • IAM権限: UXC の設定を変更するには該当するコンソール/API操作を許可するIAM権限が必要です。管理者ロールや専用ポリシーで権限を付与してください（具体的なAPI/アクション名はドキュメントで確認）。
  • リージョン制限: 今回は商用 AWS リージョン全域が対象です。AWS GovCloud（us-gov-）および中国リージョン（cn--*）は対象外のままです。
  • コスト: UXC 自体に追加料金は発生しません。ただし、設定管理を自動化するために実行する CLI/SDK/API コールや CloudFormation スタック運用に伴う関連サービスのコストは別途発生する可能性があります。
  • 表示とアクセスの違い: サービスをコンソールから非表示にしても、そのサービスのAPIアクセス権限やリソースアクセス制御は変更されません。権限管理は IAM 等で別途対応してください。
  • 伝播・セッション: 設定反映には短時間の伝播遅延が生じる可能性があり、既存のコンソールセッションでは再ログインやページの再読み込みが必要になることがあります。

参考情報 ​

[General] AWS Lambda now supports SnapStart for container image functions ​

概要 ​

AWS Lambdaがコンテナイメージでパッケージされた関数に対してSnapStartをサポートしました。これにより、初回起動（コールドスタート）時間を数秒からサブ秒まで短縮できます。

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

SnapStartはデプロイ時に初期化済みの実行環境のスナップショットを取得してキャッシュし、以降の呼び出しでそのスナップショットから復元することでコールドスタートを回避する仕組みです。今回の拡張で、従来はマネージドランタイム（Python/.NET/Java）のみ対応していた機能が、コンテナイメージでデプロイされた関数にも適用可能になりました。コンテナイメージ関数は大きな依存関係（最大10GB）や組織のコンテナ基準に合わせたデプロイに使われますが、イメージのレイヤー取得やランタイム・アプリ初期化に数秒かかることがありました。SnapStartを有効にすると、これらの初期化をデプロイ時に行いスナップショット化するため、遅延の大幅な低減が期待できます。SnapStartはオプトインで、AWSコンソール、API、CLI、CloudFormation、SAM、CDK、各種SDKから有効化できます。AWS提供のLambda用ベースイメージ（Java 11+/Python 3.12+/.NET 8+）を使う場合は.zipアーカイブと同等の挙動になりますが、それ以外のベースイメージ（例: Node.js、Rubyやカスタムベース）については開発者ガイドを参照してください。SnapStartは全ての商用リージョンで利用可能ですが、Asia Pacific (New Zealand) と Asia Pacific (Taipei) を除きます。課金に関しては別途SnapStart用の料金があるため料金ページを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Lambdaでコンテナイメージを使っている開発者、MLエンジニア、API開発チーム
  • 利用シーンまたは効果: レイテンシが重要な推論（MLインファレンス）、インタラクティブAPI、バーストトラフィック時のスケールアップに伴う応答遅延低減
  • 運用効果: コールドスタートによるレスポンスタイム悪化を抑制でき、ユーザ体験の改善やスケーラビリティの向上につながる
  • 導入負荷: 既存のコンテナ関数に対してオプトインで有効化可能。互換性テストや初期化コードの確認が必要

技術的な注意点 ​

  • IAM権限: SnapStartの有効化・管理にはLambda関数の更新権限が必要です（通常のデプロイ権限で対応）。CloudFormation/SAM/CDKでのデプロイ時はテンプレートの権限を確認してください
  • リージョン制限: 商用リージョンで有効（例外: Asia Pacific (New Zealand) と Asia Pacific (Taipei) は未対応）
  • コスト: SnapStartは追加料金が発生する可能性があります。利用前にLambdaのSnapStart料金ページで確認してください
  • 互換性/注意事項: スナップショットはデプロイ時点の初期化状態を保存するため、初期化時に生成された一時的な認証情報、ソケット、ファイルハンドル、ランタイム固有の状態などはそのまま復元されます。グローバル変数や静的初期化での副作用がある場合、期待しない挙動やセキュリティ問題が生じる可能性があるため、初期化処理はハンドラ内で行う／再初期化処理を追加するなど設計見直しを推奨します
  • ランタイム互換性: AWS提供のLambdaベースイメージでJava 11+/Python 3.12+/.NET 8+は.zipアーカイブと同等の扱い。Node.jsやRubyなどのAWSベースイメージやカスタムベースイメージは追加の注意点や設定があるため開発者ガイドを参照してください
  • テスト/検証: 実運用前にコールドスタート・ウォームスタートの挙動を計測して差分を確認し、エッジケース（認証・外部接続・初期化処理）をテストしてください
  • 導入手段: Console、API、AWS CLI、CloudFormation、SAM、CDK、各種SDKからオンにできます
  • 制限: コンテナイメージの上限（10GB）は引き続き適用。その他のLambda制限（メモリ、タイムアウト等）は変わりません

参考情報 ​

[Sagemaker Studio] Amazon SageMaker Unified Studio CI/CD adds notebook promotion and AI-assisted manifest generation ​

概要 ​

Amazon SageMaker Unified Studio (SMUS) の CI/CD ツールキットに、(1) AIエージェントによるデプロイ用マニフェスト自動生成機能と、(2) ネイティブなノートブック昇格（promotion）機能が追加され、プロジェクトから本番までの移行を迅速化するとともにベストプラクティスのデフォルトを維持します。

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

AI-assisted manifest generation:

  • 新しい generate-bundle-manifest エージェントスキルは、プロジェクトの接続情報、ストレージ、ワークフローを解析して即利用可能なデプロイマニフェストを生成します。
  • 生成されるマニフェストは最小権限（least-privilege）を意識したIAM設定の推奨を行い、ハードコーディングされたリソース識別子を環境変数へ置換、カタログ取り扱いのオプトインなど安全なデフォルトを設定します。
  • チームはこのスキルを自らのエージェントに取り込み、開発→検証→本番アカウント間でのパッケージング／昇格手順を標準化できます。

Native notebook promotion:

  • CI/CD ツールキットが SMUS のネイティブノートブックをコードやワークフロー、カタログ資産と一緒に昇格（promote）可能になりました。
  • 昇格はインプレース同期モデルを採用し、初回デプロイ時にノートブックを作成、以降のデプロイでは既存ノートブックを更新して実行履歴（run history）を保持します。
  • プロジェクト内の全ノートブックを昇格するか、特定のノートブックIDを指定して選択的に昇格できます。
  • dry-run モードでは S3 接続性、必要な IAM 権限、ノートブック数などを検証して問題を事前に検出できます。
  • 既存の bundle / deploy / destroy / dry-run コマンドと統合されており、現在のパイプライン構造を変更する必要はありません。

共通:

  • 両機能ともオープンソースで提供され、Amazon SageMaker Unified Studio が提供されているリージョンで利用可能です。
  • 導入は GitHub の CICD-for-SageMakerUnifiedStudio リポジトリおよび関連ドキュメントを参照して開始します。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、MLエンジニア、MLOps/プラットフォームチーム
  • 利用シーン: 開発→テスト→本番へのモデル／ノートブック昇格パイプラインの自動化、デプロイ用マニフェストの標準化とセキュアな設定の自動適用
  • 運用効果: マニフェスト作成工数の削減とヒューマンエラー低減、ノートブックのバージョン管理と実行履歴保持によるリリース信頼性向上
  • 開発効率: 開発チームはマニフェスト作成や手動のノートブック移行作業から解放され、反復サイクルを短縮できる
  • ガバナンス: 最小権限の推奨や環境変数置換でセキュリティ標準を一貫適用しやすくなる

技術的な注意点 ​

  • IAM権限: マニフェスト生成・デプロイには S3、SageMaker、IAM、（必要に応じて）カタログや関連サービスに対する作成/更新権限が必要。最小権限のポリシー設計を確認してください。
  • リージョン制限: SMUS が提供されているリージョンで利用可能。該当リージョンでの提供状況を事前に確認してください。
  • コスト: 新規ノートブック作成や更新に伴うストレージ（S3）費用、SageMaker ノートブックインスタンス/Kernel/Studio の実行料金が発生する可能性があります。CI/CD 実行頻度に応じたコスト影響を評価してください。
  • 互換性/導入影響: 既存の pipeline 構造の変更は不要ですが、CI/CD ツールキットと既存 IAM ポリシーや S3 バケットポリシーの整合を取る必要があります。
  • 検証推奨: dry-run 機能で事前検証を行い、S3接続／IAM権限／ノートブック数などを確認してから本番デプロイしてください。
  • OSS利用: 機能はオープンソースで提供されるため、リポジトリのコードレビュー、カスタマイズやライセンス（MIT等の有無）を確認してください。

参考情報 ​

[Rds For Sql Server] Amazon RDS for SQL Server supports additional SQL trace flags ​

概要 ​

Amazon RDS for SQL Serverが、データベースパラメータグループを通じて有効化できる18個の追加SQLトレースフラグをサポートしました。これによりクエリ最適化やDDL/レプリケーションなどエンジン挙動の細かな調整が可能になります。

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

トレースフラグはSQL Serverエンジンの動作を変更する低レベルのスイッチで、今回RDS for SQL Serverで新たにサポートされた18個（647, 652, 1448, 3654, 4138, 4139, 7745, 8285, 8780, 9432, 9481, 9492, 9592, 11024, 11042, 12502, 12618, 12656）は、クエリプラン生成（カーディナリティ推定や自動プラン修正）、DDL性能、可用性グループのレプリケーション、Query Storeの挙動調整、既知のエンジン不具合の回避などのシナリオに対応します。これらはRDSのDBパラメータグループで設定し、対象のDBインスタンスに適用して有効化します。注意点として、トレースフラグはエンジンのコア動作を変えるため、本番適用前に非本番環境で十分な検証が必要です。フラグによってはメモリ使用量やパフォーマンス、クエリ実行計画に影響を与える可能性があります。利用可能リージョンは、RDS for SQL ServerがサポートされているすべてのAWSリージョンです。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者（DBA）、パフォーマンスエンジニア、SRE/運用チーム
  • 利用シーン: クエリプラン問題の回避やチューニング、DDL処理最適化、可用性グループ周りのレプリケーション調整、Query Store挙動のカスタマイズ、不具合ワークアラウンドの適用
  • 運用効果: 特定ワークロードに対するパフォーマンス改善や安定性向上が期待できる一方で、誤設定は逆に性能悪化やリソース増大を招くため、検証と段階的導入が重要

技術的な注意点 ​

  • IAM権限: DBパラメータグループの変更やDBインスタンスへの適用には rds:ModifyDBParameterGroup や rds:ModifyDBInstance 等の権限が必要です
  • リージョン制限: RDS for SQL Serverがサポートされている全リージョンで利用可能です（リージョン差異がある場合はリージョンのRDS対応状況を確認してください）
  • コスト: トレースフラグ自体に追加料金はありませんが、フラグ適用によるCPU／メモリ使用増やI/O増加でインスタンスサイズやストレージを増強する必要が生じるとコストに影響します
  • 適用手順／再起動: パラメータグループを更新してDBインスタンスに適用します。フラグや設定の種類によっては再起動が必要になる場合があるため、適用前に影響範囲を確認してください
  • 検証とバックアップ: 本番適用前にステージング環境で十分な負荷試験とクエリプラン比較を行い、事前にバックアップ（スナップショット等）を確保してください
  • SQL Serverバージョン依存: 一部のトレースフラグはSQL Serverのバージョンやエディションに依存する可能性があります。フラグの意味と対象バージョンを確認してください
  • 監視: フラグ適用後はCPU/メモリ/ディスクI/O、Query Storeや実行計画の変化をCloudWatchやSQL ServerのDMVで監視し、ロールバック方針を用意してください

参考情報 ​

[Aiml] Amazon Quick now lets you build custom apps with natural language - ​

概要 ​

Amazon Quickが一般提供開始され、自然言語で要件を記述するだけでコード不要のカスタム業務アプリを短時間で作成できるようになりました。既存のSalesforce、Jira、Asana、ServiceNow、Microsoft 365、Google Workspace、データベースやデータウェアハウスなどと直接接続し、リアルタイムでデータを反映します（Plus/Professional/Enterprise顧客向け、2026-09-01開始）。

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

Amazon Quickはノーコードの自然言語ベースアプリ作成サービスです。ユーザーが「こういうプロジェクトトラッカーが欲しい」「顧客ダッシュボードを作って」などと記述すると、Quickが実働する接続済みアプリを生成します。特徴は以下の通りです。

  • 自然言語インタフェース: 要件をテキストで指示すると、UI、データ接続、ロジックを自動生成・デプロイします。
  • リアルタイム接続: Salesforce、Jira、Asana、ServiceNow、Microsoft 365、Google Workspace、各種データベースやデータウェアハウス等と直接接続し、基データの変更をそのままアプリに反映します。
  • 既存の認証・認可ポリシー準拠: 組織のIDプロバイダやアクセス制御を尊重して接続・公開が行われます（SSO/OAuth/サービスアカウント等を想定）。
  • 迅速な公開と共有: 作成したアプリは特定ユーザーや組織全体と即座に共有可能で、要望が変われば自然言語で追加要件（AI機能の追加、デザイン変更、別システムとの連携など）を指示して更新できます。
  • 運用事例: プレビュー期間では、New York Lifeが学習・コンプライアンス統合ポータルを構築、Amazon Quickチームは複数システムからの手動データ集約を置き換えるリーダーシップ用アプリを構築しました。
  • 利用条件: 2026年9月1日より Plus、Professional、Enterprise プランの顧客が利用可能。詳細は Apps in Quick の Getting-started ガイド参照。

影響範囲・利用シーン ​

  • 対象ユーザー: プロダクトマネージャー、業務担当者（営業/財務/人事）、SRE/運用チーム、アナリストなどの非エンジニアを含むビジネスユーザー
  • 利用シーンまたは効果: スプレッドシートや断片的ツールの置換、プロジェクトトラッキング、顧客ダッシュボード、eラーニング/トレーニングポータル等を短時間で立ち上げ、複数システムからのデータ統合を自動化
  • 運用効果: 手動データ集約やコーディング工数の大幅削減、データのリアルタイム可視化による意思決定の高速化、組織内でのアプリ共有によるスケール効果

技術的な注意点 ​

  • IAM権限: 各コネクタ（Salesforce等）やデータソースに接続するための認証情報/権限を事前に用意し、最小権限の原則で設定してください。組織のID連携（SSO/OAuth/サービスロール）設定が必要です。
  • リージョン制限: 公開記事ではリージョンの詳細が明記されていません。利用前に利用可能リージョンを公式ドキュメントで確認してください。
  • コスト: Quick自体の利用はプラン（Plus/Professional/Enterprise）提供範囲に依存します。追加でコネクタ利用料やデータ転送（特にクロスリージョン）のコスト、保存・実行に伴う料金が発生する可能性があるため見積りを確認してください。
  • データ保護: 機密データや規制対象データを扱う場合はデータ分類・マスキング・DLP方針を適用し、データの取り込み・保存場所（リージョン/アカウント）を確認してください。
  • ネットワーク/コネクタ: オンプレミスDBやプライベート環境への接続は、VPCエンドポイントやプロキシ設定、ファイアウォールルールの調整が必要になる場合があります。接続方式と認証フローを事前に検証してください。
  • スケーラビリティ/制限: プレビュー事例は業務アプリの置換に成功していますが、大量データや高頻度更新のワークロードでは事前検証が必要です。APIコール数や同時編集などの制限を確認してください。

参考情報 ​

[Deadline Cloud] AWS Deadline Cloud now supports sharing job bundles ​

概要 ​

AWS Deadline Cloudがジョブバンドルの共有機能をサポートしました。キューにバンドルを公開することで、ファイルを手動で配布することなくレンダージョブテンプレートをチーム間で簡単に再利用できます。

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

ジョブバンドルは、ジョブテンプレート、パラメータ、アセット参照を含む、Deadline Cloudへ提出するジョブ定義のパッケージです。今回の機能追加により、Submitter（GUI）または新しいCLIコマンドからバンドルをキューへ直接“公開（publish）”でき、公開されたバンドルはそのキューへアクセス権を持つユーザー全員に即時利用可能になります。共有バンドルは可搬なアーカイブ形式でパッケージ化され、キューが現在使用しているジョブ添付ファイル用のAmazon S3バケットに格納されるため、追加のインフラや設定は不要です。ユーザーはキュー上で共有されたバンドルを参照できるほか、自分のローカルファイルシステムや過去のジョブ提出履歴からもバンドルを参照・選択可能です。選択前にバンドル名、説明、実行ステップ、パラメータをプレビューできるため、アーティストやパイプライン担当者は標準化された「そのまま提出できる」テンプレートを容易に利用できます。CLIコマンドにより、バンドルの公開・一覧・取得・削除などを自動化スクリプトに組み込めるため、パイプラインとの連携が容易です。本機能はDeadline Cloudが利用可能なすべてのAWSリージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: VFX/アニメーション/ゲーム/シミュレーションのレンダーパイプライン担当者、アーティスト、SRE/運用チーム
  • 利用シーンまたは効果: 標準化されたレンダージョブテンプレートの配布（パイプライン→アーティストへのテンプレート配布、自動化スクリプトによるテンプレート公開）
  • 運用効果: 手動でのファイル共有工数を削減し、テンプレートのバージョン管理と再利用性を向上。提出ミスの低減とオンボーディングの迅速化に寄与
  • 開発/CI統合: CLIを使ってバンドルの公開・更新をCI/CDに組み込み、リリース時に標準ジョブテンプレートを自動的に配信可能
  • コスト影響: 共有バンドルはキューのS3バケットに保存されるため、S3のストレージおよびリクエストコストが発生する可能性がある

技術的な注意点 ​

  • IAM権限: バンドルを公開/管理するにはDeadline Cloud上のキューへ公開する権限（キューへの書き込みやバンドル管理権限）および該当S3バケットへのPut/Get権限が必要です。具体的なポリシーは環境に合わせて確認してください
  • リージョン制限: この機能はDeadline Cloudが利用可能なすべてのAWSリージョンで提供されていますが、使用するキューが存在するリージョンで操作を行ってください
  • S3運用: 共有バンドルは既存のジョブ添付ファイル用S3バケットに保存されます。バケットの暗号化設定、ライフサイクルポリシー、バージョニング、バケットポリシー（アクセス制御）を確認し、誤削除や不要な保管によるコスト増を防いでください
  • CLI/クライアント: 新しいCLIコマンドを使用するには、Deadline Cloudクライアント/CLIのバージョンが対応していることを確認してください。古いクライアントでは公開/取得コマンドが使えない可能性があります
  • データ転送/コスト: バンドルのアップロード・ダウンロードはS3経由で行われるため、クロスリージョンのデータ転送が発生すると追加料金がかかります
  • アクセス制御: 公開されたバンドルはキューへのアクセス権を持つ全ユーザーが利用可能です。共有範囲を限定したい場合はキューのアクセス制御設定で制御してください

参考情報 ​

[CloudWatch] Amazon CloudWatch Database Insights now supports self-managed PostgreSQL ​

概要 ​

Amazon CloudWatch Database Insightsが自己管理のPostgreSQL（例: Amazon EC2上のインスタンス）をサポートしました。これによりRDS/Auroraと同じDatabase Insightsコンソールで自己管理DBのパフォーマンスと稼働状況を一元監視できます。

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

CloudWatch Database Insightsは、従来のAmazon RDS/Auroraに加えて、自己管理のPostgreSQLインスタンス（Amazon EC2上など）からもメトリクスとパフォーマンスデータを収集できるようになりました。収集はAmazon CloudWatchエージェントを用いて行い、Database Insightsのフリートビューに自己管理DBが表示されます。表示されるデータはデータベースロード（DB load）、待機イベント解析（wait event analysis）、クエリ単位の統計（query-level statistics）、ホストメトリクスなどのライブパフォーマンス情報を含みます。既存のDatabase Insightsのコンソール／ワークフローで、RDS/Auroraと同様に監視・トラブルシューティングが可能です。この記事の発表によれば、商用の全リージョン（AWS Commercial Regions）で利用可能です。導入手順や詳細設定は「Monitoring Self-Managed Databases in the Amazon CloudWatch User Guide」、料金はCloudWatchの料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: DB管理者、データベースエンジニア、SRE/運用チーム
  • 利用シーン: EC2上などで自己管理しているPostgreSQLのパフォーマンス監視・ボトルネック解析を、RDS/Auroraと同一のコンソールで一元的に行う場面
  • 運用効果: クエリレベルの統計や待機イベント解析により原因特定が高速化され、問題対応時間の短縮と運用負荷の低減が期待できる
  • 運用導入効果: 監視基盤の統合により監視運用の統一化（アラート、ダッシュボード、診断フローの共通化）が可能
  • 適用範囲: 商用リージョン内の自己管理PostgreSQL（EC2上）が対象。RDS/Auroraと同じ画面で並列監視できるため混在環境で有効

技術的な注意点 ​

  • IAM権限: CloudWatchエージェントによるメトリクス/ログ送信およびDatabase Insights機能の利用に必要なIAMポリシーを付与する必要があります（詳細はドキュメント参照）。
  • エージェント: Amazon CloudWatch エージェントのインストールと適切な設定が必須です。エージェントのバージョンや設定ファイル（metrics/logs収集設定）を事前に確認してください。
  • PostgreSQL設定: クエリ単位の統計や一部の診断には追加の拡張（例: pg_stat_statements）や統計収集設定の有効化が必要となる場合があります。サポート対象のPostgreSQLバージョン／拡張については公式ドキュメントを確認してください。
  • ネットワーク/セキュリティ: エージェントからCloudWatchエンドポイントへのアウトバウンド通信を許可する必要があります。VPCエンドポイント（CloudWatch Logs/CloudWatch）を使った閉域構成にも対応可能ですが設定が必要です。EC2ロールやセキュリティグループを適切に設定してください。
  • リージョン制限: 発表では「全てのAWS Commercial Regionsで利用可能」となっています。AWS GovCloudや中国リージョンの対応状況は公式ドキュメントで確認してください。
  • コスト: Database Insightsの利用はCloudWatchの料金（メトリクス、ログ、Insightsの分析等）に影響します。データ送信量・保持期間・クエリ分析の利用状況により追加課金が発生するため、導入前に料金ページで見積もりを確認してください。
  • サポートされるバージョン: 詳細なサポート対象PostgreSQLバージョンや制限事項はドキュメントに記載されています。導入前に必ず確認してください。

参考情報 ​

[Kinesis] Amazon Kinesis Data Streams now supports a dry run feature to validate API requests ​

概要 ​

Amazon Kinesis Data StreamsがAPIリクエストを実行せずに検証できるDryRun機能をサポートしました。DryRunパラメータをtrueにすると、権限やリクエスト入力の検証のみを行い、実際のストリーム操作は行われません。

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

新しいオプションパラメータ「DryRun」をAPIリクエストに設定すると、Kinesisはリクエストが成功するかを実行せずに検証します。検証がすべて通ると、サービスはDryRunOperationExceptionを返し、「実行しなければ成功したであろう」ことを示します。検証に失敗した場合は通常のアクセス権限エラーや入力検証エラーが返ります。DryRunはPutRecord、PutRecords、GetRecords、GetShardIterator、SubscribeToShardの5つのAPIで利用可能で、Kinesis Data Streamsが提供されているすべてのAWSリージョンで有効です。これにより、以前行われていた「意図的に失敗させる」ような実運用ストリームへの悪影響を伴うテスト手法を置き換え、安全に権限と入力チェックを行えます。SDKやCLIは順次DryRunパラメータを受け付けるよう更新されるため、既存のクライアント実装にDryRunフラグを追加して利用できます。

影響範囲・利用シーン ​

  • 対象ユーザー: Kinesisストリームのプロデューサー／コンシューマー開発者、SRE/運用チーム、セキュリティ担当者
  • 利用シーン: 本番ストリームに書き込む前の権限確認、コンシューマの読み取り権限検証、デプロイ前のAPI入力チェック
  • 運用効果: 本番にデータを誤って書き込むリスクを排除し、権限不足・入力不備を事前に検出可能
  • 対応API: PutRecord、PutRecords、GetRecords、GetShardIterator、SubscribeToShard
  • 利用可能リージョン: Amazon Kinesis Data Streamsが提供されているすべてのAWSリージョン（記事時点）
  • コスト影響: DryRunは実際のデータ書き込みを行わないためデータ取り込み料金は発生しないはずだが、API呼び出しに伴うリクエストレートの影響やスロットリングは考慮する必要あり

技術的な注意点 ​

  • IAM権限: DryRunは権限検証を行うため、通常のAPI呼び出しに必要なKinesis権限（例: kinesis:PutRecord等）が関連します。呼び出し側に該当APIを呼ぶ権限がない場合、アクセス拒否エラーが返るため、権限設定の検証が可能です
  • リージョン制限: 記事ではKinesisが提供されている全リージョンで利用可能とされているが、実運用で利用するリージョンのドキュメント/コンソールでサポート状況を確認してください
  • コスト: DryRun自体はレコードを書き込まないためデータ取り込み課金は発生しません。ただしAPIリクエストに伴うレート制限やスロットリングの影響、関連するCloudWatchメトリクス/ログの増加による間接コストには注意してください
  • SDK/CLI互換性: SDKおよびAWS CLIはバージョンによってDryRunパラメータのサポート状況が異なります。最新のAPIリファレンスとSDKリリースノートでDryRun引数のサポートを確認してください
  • エラー挙動: 検証が成功するとDryRunOperationExceptionが返ります。検証に失敗した場合は従来通りAccessDeniedやInvalidArgumentなどのエラーが返るため、エラーハンドリングでDryRunOperationExceptionを成功シグナルとして扱う実装にしてください
  • 運用移行: 既存の「失敗するリクエストで検証する」手法は置き換えるべきです。CI/CDやデプロイ前のチェックにDryRunを組み込み、実データ送信を伴わない安全な検証を行ってください

参考情報 ​

[General] AWS Backup now supports protecting more than 1,000 Amazon S3 buckets per account ​

概要 ​

AWS Backupが1アカウントあたり1,000個を超えるAmazon S3バケットのバックアップと復元をサポートするようになり、アカウントに設定されたAmazon S3バケットクォータに合わせて保護対象を拡張しました。

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

従来、AWS Backup for Amazon S3はアカウントあたり最大1,000個のS3バケットまでしかサポートしていませんでした。本アップデートにより、アカウントに許可されたS3バケットクォータの範囲内で、一般的な用途のバケットをすべてAWS Backupでバックアップおよび復元できるようになります。既存のバックアッププランや設定は、デフォルトのAWS Backup管理ポリシーを使用している場合は変更不要でそのまま機能します。カスタムポリシーを利用している場合は、AWS BackupがS3にアクセスするために必要な追加のIAM許可をドキュメントに従って設定する必要があります。本機能はすべてのAWS商用リージョンおよびAWS GovCloud (US) リージョンで利用可能です。大量のバケットを保護する際は、バックアップストレージやAPIコールのコスト、バックアップジョブの同時実行/スループット、サービスクォータ（必要に応じて引き上げ申請）などを考慮してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用者、バックアップ管理者、コンプライアンス/ガバナンス担当者、マルチテナント/大規模組織のSREチーム
  • 利用シーン: 1アカウントで多数（1,000超）のS3バケットを運用している環境の統合バックアップ／復元、規制対応のための一括保護、マルチアプリケーション環境のデータ保護自動化
  • 運用効果: バケット数の上限に起因する未保護領域を解消し、バックアップ対象がS3クォータに合わせて一貫してカバーされることで運用負荷とサードパーティ依存の低減、コンプライアンス遵守の容易化が期待される

技術的な注意点 ​

  • IAM権限: デフォルトのAWS Backup管理ポリシーを利用している場合は変更不要。カスタムポリシーを使う場合は、AWS BackupがS3バケットとオブジェクトにアクセス・復元できるように必要なS3権限（ドキュメントに記載の権限セット）を付与してください。詳しくは公式ドキュメントを参照してください。
  • リージョン制限: 本機能はすべてのAWS商用リージョンおよびAWS GovCloud (US) リージョンで提供されています。AWS Chinaリージョン等、対象外のリージョンがある可能性があるため、自アカウントのリージョンでの提供状況はコンソールまたはドキュメントで確認してください。
  • コスト: 保護対象バケット／オブジェクトが増えると、AWS Backupのバックアップストレージ料金、S3のリクエスト／データ転送料金、復元時の料金が増加します。ライフサイクル、保存先（バックアップボールトやクロスリージョン保管）を設計してコスト管理してください。
  • サービスクォータ／スループット: 大量バケットのバックアップ実行では、バックアップジョブの同時実行数やAPIのスロットリングが影響する可能性があります。必要に応じてAWSサポートへクォータ引き上げを申請してください。
  • 既存設定との互換性: デフォルト管理ポリシーを使っている場合は既存のバックアッププランは変更不要で継続利用可能。ただしカスタムロール／ポリシーを利用している場合は権限確認を行ってください。

参考情報 ​

[Govcloud Us] Amazon Connect Customer dashboards now support compact mode ​

概要 ​

Amazon Connect Customer の分析ダッシュボードに「コンパクトモード」が追加され、ウィジェットのサイズやフォント、フィルター表示を縮小して画面あたりの情報密度を高め、監督者がスクロールなしでより多くの運用データを確認できるようになりました。

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

コンパクトモードはダッシュボードの表示オプションで、ウィジェットの高さや内部フォントサイズを縮小し、フィルター表示を最小化して利用可能な画面スペースを最大化します。これにより、例えば13インチノートPC上でもエージェント一覧ウィジェットの行数が増え、スクロール無しで全員を確認したり、非準拠（非アドヒアランス）エージェントを素早く発見することが可能になります。モードはダッシュボード上のトグルで切り替え可能で、表示上の変更に留まりバックエンドAPIやデータ取得ロジック自体には影響しません。コンパクトモードは Amazon Connect Customer を提供している全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンターのスーパーバイザー、運用管理者、リアルタイム監視担当者
  • 利用シーン: 小さな画面（ノートPCやタブレット）でのリアルタイム監視、エージェントの稼働状況やアドヒアランス確認、複数ウィジェットを同時に監視したい場合のダッシュボード運用
  • 運用効果: スクロールせずに多くの項目を一度に確認できるため、問題の早期発見・対応が可能になり監視効率が向上
  • 導入影響: UI表示の変更のみで既存のデータ取得やアラート/アクションの動作には影響しないが、可視性（フォント縮小）により読みやすさやアクセシビリティの確認が必要

技術的な注意点 ​

  • IAM権限: ダッシュボード表示や表示設定を変更するには該当する Amazon Connect Customer の表示/管理権限（管理者またはダッシュボード権限）が必要です。詳しくは管理者ガイドで権限要件を確認してください。
  • リージョン制限: 記事によれば Amazon Connect Customer を提供している全リージョンで利用可能です。特定リージョン（GovCloudなど）の準拠要件や運用ポリシーは別途確認してください。
  • コスト: 表示オプションの追加による追加料金は発生しません（UIの表示変更のみ）。
  • ブラウザ互換性・表示: フォント縮小やウィジェット縮小により可読性が低下する可能性があります。利用環境（ブラウザ、画面解像度）で動作確認を行ってください。
  • アクセシビリティ: 小さいフォントや密な表示は視覚障害を持つユーザーにとって読みづらくなる可能性があります。必要に応じて通常モードと切り替えて運用してください。
  • カスタムウィジェット/埋め込みコンテンツ: カスタムレイアウトや外部埋め込み要素を利用しているダッシュボードではレイアウト崩れや表示重なりが発生する可能性があるため、切り替え後に確認してください。
  • 動作影響: コンパクトモードは表示レイヤーの変更であり、データ取得・API・アラートロジックには影響しません。ダッシュボードのデータ更新頻度やクエリ負荷も通常通りです。

参考情報 ​

[Mwaa] Amazon MWAA supports Apache Airflow version 3.3.1 ​

概要 ​

Amazon MWAA が Apache Airflow 3.3.1 をサポート開始しました。状態保持タスクやマルチ言語タスク（実験的）など、Airflow 3.3 系の新機能を MWAA 上で利用できます。

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

Apache Airflow 3.3.1 の主要機能が Amazon Managed Workflows for Apache Airflow (MWAA) で利用可能になりました。主な追加/改善点は以下の通りです。

  • Task と Asset State Store による状態の永続化: タスクはリトライや再実行間で永続的な状態を保持できるため、カーソル追跡や長時間実行ジョブのクラッシュからの安全な再接続（crash-safe reconnection）が可能になります。
  • Language Task SDK（実験的）: オーケストレーションは Python に保ちつつ、タスクロジックを Java または Go で記述できるため、既存の言語資産を活かした実装が可能になります（hints: experimental なため安定性やサポートの条件に注意）。
  • アセットパーティショニングの拡張、プラガブルなリトライポリシー、DAG 実行やタスクインスタンスに対する一括操作（bulk actions）などの運用性向上機能。
  • 上記に加え、安定性・セキュリティ・UI の改善が含まれるマイナーリリース（3.3.1）。

MWAA 上では新規に Airflow 3.3.1 環境を作成するか、既存の 3.2 以降の環境を AWS マネジメントコンソールから数クリックでアップグレードできます（サポート対象リージョンで提供）。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、ETL 開発者、SRE/運用チーム、組織内で Java/Go によるタスク実装資産を持つ開発チーム
  • 利用シーン: 長時間実行ジョブやセーブポイントが必要なワークフロー（カーソルトラッキング）、マルチ言語でのタスク実装を混在させたワークフロー、DAG/タスクの一括運用や高度なパーティショニングを必要とするデータパイプライン運用
  • 運用効果: タスクの耐障害性向上（リトライ/再実行時の状態維持）、異なる言語でのコード資産再利用による開発効率向上、DAG 管理負荷の低減と運用性の改善

技術的な注意点 ​

  • IAM権限: 環境の作成・アップグレードには MWAA 関連の IAM 権限が必要です。S3、CloudWatch Logs、ECR（プラグイン/依存関係を格納する場合）、KMS、VPC 関連権限も確認してください。
  • リージョン制限: 記事では「現在サポートされている Amazon MWAA リージョンで利用可能」とされています。利用前に MWAA ドキュメントで対応リージョンを確認してください。
  • 互換性: 既存の DAG、カスタムオペレータ、プラグイン、サードパーティ Provider の互換性確認が必要です。特に内部 API の変更や依存パッケージのバージョン差異が原因で動作が変わる可能性があります。
  • アップグレード手順: 本番環境アップグレード前にステージング環境で検証し、requirements.txt / constraints ファイル、プラグイン、カスタムコードをテストしてください。環境バックアップ（S3 に格納された DAG やプラグインのスナップショット）を推奨します。
  • 実験的機能: Language Task SDK は experimental と明記されています。商用利用や本番採用の前に安定性・サポート範囲を確認し、必要に応じてフォールバック戦略を用意してください。
  • コスト: バージョン変更自体で MWAA の料金体系が変わるわけではありませんが、長期的なタスク状態保持や追加の外部ストレージ/ログ出力によりストレージ・データ転送コストが増加する可能性があります。

参考情報 ​

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

Copyright © 2026