AWS What's New Digest

Appearance

2026年10月01日 ​

[Corretto] Amazon Corretto 8 September 2026 Patch Updates ​

概要 ​

Amazon Corretto 8 のパッチアップデート (8u504) が公開され、tzdata 2026d の更新が含まれます。Corretto は無償の OpenJDK 配布で、ダウンロードや各種パッケージリポジトリで入手可能です。

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

2026年9月30日付で Amazon Corretto の長期サポート版 OpenJDK (Corretto 8u504) が利用可能になりました。本パッチは主に tzdata 2026d のタイムゾーンデータ更新を含んでおり、夏時間（DST）や地域別のタイムゾーンルールの変更に対応します。Corretto は複数プラットフォーム向けの本番運用対応 OpenJDK ディストリビューションで、Corretto 27/25/21/17/11/8 など各バージョンが Corretto ホームページからダウンロードできます。Linux 環境では apt、yum、apk の各リポジトリを設定してパッケージ管理経由で更新を取得可能です。tzdata の更新は Java の java.time および従来の日時APIの挙動に影響するため、影響範囲の確認とアプリケーションの再起動が必要になる場合があります。

影響範囲・利用シーン ​

  • 対象ユーザー: Java 8 (Corretto 8) を本番またはステージングで利用している開発者・SRE/運用チーム
  • 利用シーン: タイムゾーン依存のスケジューリング、ログタイムスタンプ変換、グローバルな取引やレポート処理など時間情報を正確に扱うアプリケーション
  • 運用効果: 最新の tzdata を反映することで地域ごとの DST やタイムゾーンルール変更によるズレや誤処理を防止可能
  • 互換性影響: Corretto 8 のマイナーパッチのため基本的にバイナリ互換は維持されるが、tzdata による時間計算の挙動変化はあり得るため事前に回帰確認が推奨される
  • 入手/更新方法: Corretto の公式ダウンロード、もしくは apt/yum/apk リポジトリ経由で自動配布・適用が可能

技術的な注意点 ​

  • IAM権限: Corretto のダウンロード/インストール自体に特別な AWS IAM 権限は不要。AWS Systems Manager 等で自動配布する場合は該当する IAM 権限が必要
  • リージョン制限: Corretto の配布にリージョン制限は基本的にないが、使用するパッケージリポジトリや社内ネットワークの制約を確認すること
  • コスト: Corretto 自体は無償提供。ただし更新作業に伴う運用工数やアプリ再起動による短時間の影響（ダウンタイム）に注意
  • 再起動: tzdata 更新は JVM のプロセス内にキャッシュされる可能性があるため、タイムゾーン反映のために Java アプリケーションの再起動を行ってください
  • テスト: ステージング環境で tzdata 更新後の日時処理（スケジューラ、バッチ、ログ生成、タイムスタンプ変換等）を回帰テストすること
  • 互換性: 本リリースは Java SE 8 互換のパッチリリース。API の破壊的変更は想定されないが、外部ライブラリやネイティブ連携部分の動作確認を推奨
  • 署名/GPG: リポジトリ経由で導入する場合は提供される公開鍵でパッケージ署名を検証してください

参考情報 ​

[S3] Amazon S3 Object Lock variable retention with event holds is now available in AWS GovCloud (US) Regions ​

概要 ​

Amazon S3 の Object Lock による「イベントホールド＋可変リテンション」機能が AWS GovCloud (US-East, US-West) リージョンで利用可能になりました。将来のイベント発生をトリガーに保持期間を開始するWORM保護が可能になります。

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

イベントホールド（event hold）は、オブジェクトに「保持期間（duration）」を付与したままホールド状態に置くことで、将来発生するイベント（例：契約完了、監査終了）をトリガーとして保持期間のカウントを開始できる機能です。使い方の流れは次の通りです：

  • オブジェクトにイベントホールドとその後に適用したいリテンション期間を設定する。ホールドが有効な間はオブジェクトは保護され、削除や変更は制限される。
  • イベントが完了したらホールドを解除する。解除時に指定したリテンション期間が発動し、その期間分S3がWORM（Write Once Read Many）保護を継続する。 この挙動は「リーガルホールド」とは異なり、リーガルホールドは解除と同時に保護が終了しますが、イベントホールドは解除後に指定した保持期間を確保するため、イベントに基づく保持義務を満たしつつ不要に長くデータを残すことを避けられます。 技術的要件・影響点の概要：Object Lock バケットでの利用（バケット作成時にObject Lock有効化が必要）およびバージョニングが必須。API/SDKでは PutObjectRetention / PutObjectLegalHold 等を利用してホールドとリテンションを操作します。AWS GovCloud (US-East) と GovCloud (US-West) で利用可能で、Cohasset Associates により SEC Rule 17a-4(f), FINRA Rule 4511, CFTC Regulation 1.31 対応の評価が行われています。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制対応が必要な金融機関、政府機関、コンプライアンス担当者およびSRE/運用チーム
  • 利用シーン: 契約完了・監査終了などの“将来発生するイベント”をトリガーにして開始する保持ポリシーの適用（イベント発生前は不要な長期保存を避けるケース）
  • 運用効果: イベントベースのリテンション要件に準拠しつつ、不要な長期保存を削減できるためストレージコストとコンプライアンスリスクの最適化が可能

技術的な注意点 ​

  • IAM権限: PutObjectRetention、GetObjectRetention、PutObjectLegalHold、GetObjectLegalHold 等の S3 権限が必要（細かい権限は運用ポリシーで調整してください）
  • バケット要件: Object Lock はバケット作成時に有効化する必要があり、バージョニングが必須です（既存バケットへの後付けは不可）
  • リテンションモード: Compliance モードでは保持期間を短縮できず、Governance モードでは特定の権限を持つユーザーであれば上書き・解除が可能です。イベントホールドはこれらと組み合わせて利用されます
  • リージョン制限: 本機能は AWS GovCloud (US-East) および AWS GovCloud (US-West) で利用可能です。他リージョンに適用する場合は既存のグローバル対応状況を確認してください
  • コスト: 保持期間が延びることに伴うストレージ料金は発生します。不要な長期保持を避けられるとはいえ、解除後のリテンション期間分は課金対象になります
  • 互換性/API/ツール: AWS SDK、CLI、S3 REST API（PutObjectRetention / PutObjectLegalHold）で操作可能。ライフサイクルルールやクロスリージョンレプリケーションとの影響を事前に検証してください
  • コンプライアンス評価: Cohasset Associates による SEC/FINRA/CFTC 関連規制での評価が行われていますが、実際の規制適合性は各組織のコンプライアンス判断が必要です

参考情報 ​

[Security Hub] AWS Security Hub introduces remediation plans to prioritize and fix security exposures ​

概要 ​

AWS Security Hubは、共通の根本原因を持つ複数のセキュリティ検出をまとめて扱う「remediation plans（修復プラン）」を導入しました。単一のリソース修正で関連する複数の脆弱性や過誤設定を一度に軽減・解決できます。

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

Remediation plansは、同じ根本原因を共有する関連する findings をグループ化し、優先度（Critical/High/Medium/Low）、影響評価、詳細な手順を含む修復ガイダンスを提供します。手順は複数の出力形式（AWS CLI、Terraform、CloudFormation、Python、CDK）で例示されており、運用者が既存のIaCやスクリプトへ容易に組み込めます。Security Hubは自動的に各プランを“リスク削減量”に基づいて優先付けし、最も効果の大きい修復を上位表示します。さらに、remediation plansはAPI経由で取得可能なため、AIエージェントや自動化ツール（SOAR、CI/CDパイプライン、運用スクリプト等）がプログラム的に読み取り・実行し、環境全体に対する自動修復を行えます。全リージョン（Security Hubが利用可能なリージョン）で利用可能で、AWS Security Hub Essentialsプランでは追加料金なしで利用できます。実際に修復アクションを実行する際は、該当するAWSサービス（IAM、SSM、CloudFormation等）に対する実行権限やそれぞれのサービスの利用料金が発生する点に注意が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ運用チーム、クラウドセキュリティエンジニア、SRE、DevOps
  • 利用シーンまたは効果: 多数の関連する検出を根本原因単位でまとめて修復することで、修復工数削減と優先度の高いリスク軽減に集中可能
  • 運用効果: 最もリスクを削減できる修復プランを優先提示するため、手戻りの少ない効率的な対応が可能になり、MTTR（平均修復時間）短縮と誤検知対応の工数削減が期待される
  • 自動化適合性: APIでプランを取得できるため、AIエージェントや自動化パイプライン経由でのプログラム的修復が可能
  • コスト影響: Security Hub上の機能自体はEssentialsプランで追加費用なし。ただし、修復実行時に利用する各AWSサービスの実行・リソースコストは別途発生する可能性あり

技術的な注意点 ​

  • IAM権限: Security Hubからremediation plansを取得する読み取り権限および、実際に修復を行う場合は対象サービス（例: IAM、SSM、CloudFormation、EC2など）に対する適切な実行権限が必要
  • リージョン制限: Security Hubが利用可能なすべてのリージョンで利用可能（リージョン単位で有効化されていることを確認）
  • コスト: Remediation plans機能はEssentialsプランで追加費用なし。ただし、プランに記載された修復アクションを実行するときの各サービス利用料やリソース作成費用は別途発生
  • 互換性・ツール要件: 提供されるサンプルはCLI、Terraform、CloudFormation、Python、CDK等だが、利用するTerraformプロバイダやCDK/SDKのバージョンが環境と合致しているか事前確認を推奨
  • 自動化実行の注意: プログラム的に修復を適用する場合は変更の自動反映とロールバック、承認ワークフロー（オンサイト承認やチケット連携）を設計し、誤った自動修復がサービス停止を招かないようにすること

参考情報 ​

[Transfer Family] AWS Transfer Family now supports custom CloudWatch log groups for managed workflows ​

概要 ​

AWS Transfer Family のマネージドワークフローで、ワークフロー単位のカスタム CloudWatch Logs ロググループを選択できるようになりました。これによりワークフローごとにログを分離したり、複数ワークフローのログを1つに集約して可視化できます。

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

新機能により、Transfer Family コンソールまたは API でワークフローを作成または更新する際に、そのワークフロー専用の CloudWatch Logs ロググループを指定できます。指定したロググループにのみワークフロー実行ログが配信されるため、従来必要だったサーバー単位のログ用ロールに依存する必要はありません（サーバーのログ設定を選択しない場合）。ワークフローのログは既存の構造化された JSON 形式を維持し、CloudWatch Logs Insights によるクエリやメトリクス作成が可能です。複数ワークフローを同一ロググループへ送ることで、統合されたダッシュボードや集計メトリクスを容易に作成できます。既存ワークフローは現状のログ設定を引き続き使用します。機能は Transfer Family のマネージドワークフローを提供する全リージョンで利用可能です。ロググループの作成や権限設定は、ワークフロー作成時に適切に行ってください（必要に応じて CloudWatch Logs の書き込み権限が必要）。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE／運用チーム、セキュリティ担当、データエンジニア、Transfer Family を利用するアプリケーション開発者
  • 利用シーン: ワークフロー単位での障害解析や監視（個別ログの分離）、関連ワークフロー群のログを1つにまとめて集計ダッシュボードを作成する場合
  • 運用効果: ワークフロー毎のログ分離により問題切り分けが高速化され、共有ロググループ利用で横断的なメトリクス集計・可視化が容易になる
  • 既存ワークフローへの影響: 既存ワークフローは現行のログ設定を維持。個別ロググループを適用するにはワークフローの更新が必要
  • セキュリティ/コンプライアンス: ロググループごとのアクセス制御（IAM ポリシー）や保持期間設定で、監査要件に合わせた運用が可能

技術的な注意点 ​

  • IAM権限: ワークフロー作成者／運用者は CloudWatch Logs の書き込み・作成権限（例: logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents、logs:DescribeLogGroups）が必要になる場合があります。ロググループ作成を許可しない場合は事前にロググループを作成して権限を付与してください
  • リージョン制限: Transfer Family のマネージドワークフローを提供する全リージョンで利用可能。マネージドワークフロー自体が利用できないリージョンでは未対応です
  • コスト: CloudWatch Logs の受信・保存・Logs Insights クエリに対する通常の課金が発生します。ログ量増加や長期保存に伴うコスト影響を考慮してください
  • ログ形式: ワークフロー実行ログは従来どおり構造化 JSON で出力され、CloudWatch Logs Insights でクエリ可能です
  • 既存設定: ワークフローでロググループを未指定の場合はサーバーのロールベースログ設定が継続して適用されます。既存ワークフローは自動で切り替わりません
  • クロスアカウント: 別アカウントのロググループへ送信する場合は追加の権限設定やサポート可否の確認が必要です（事前確認を推奨）
  • 運用設定: ログの保持期間（retention）、アクセス制御（IAM ポリシー）およびインデックスやメトリクス作成の設計を見直してください

参考情報 ​

[Glue] AWS Glue Data Catalog now supports table optimization, statistics, and crawlers for Apache Iceberg V3 ​

概要 ​

AWS Glue Data CatalogがApache Iceberg Version 3（V3）テーブル向けにテーブル最適化、統計収集、クローラーによる検出機能をサポートしました。これによりV3テーブルの自動保守、クエリ性能向上、S3上のテーブル発見が容易になります。

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

主な追加機能は以下の通りです。

  • テーブル最適化: GlueのTable OptimizationでIceberg V3テーブルのコンパクション（binpack）、ソート、Z-order（空間局所性を高めるソート）といった最適化戦略が利用可能になりました。これらにより小さなファイルの統合やクエリでのスキャン量削減が可能です。また、期限切れスナップショットの削除やオーファンファイル（参照されていない古いデータファイル）の削除によりストレージコストを削減できます。

  • 統計情報（NDV等）: V3テーブルに対してNDV（Number of Distinct Values：重複排除後の値の個数）などの列統計を生成できます。分析エンジン（クエリプランナー）はこれらの統計を利用して適切な実行計画を作成し、ジョイン戦略や集約計画の性能が向上します。統計生成はV3のデータ型（variant、geospatial、ナノ秒精度タイムスタンプなど）をサポートします。

  • Glueクローラーによる検出・登録: GlueのクローラーがS3上のIceberg V3テーブルを検出してGlue Data Catalogへ登録できるようになりました。登録されたメタデータはV3互換のクエリエンジン（例: Athena/Trino等、各エンジンのV3対応状況に依存）で利用可能です。

  • 対応データ型と互換性: V3の新しいデータ型（variant、地理空間型、ナノ秒精度タイムスタンプ等）を含むテーブルで動作します。これらの機能はGlue Data Catalogで既に提供されているテーブル最適化、統計、クローラー機能が利用可能なすべてのリージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データレイク運用チーム、SRE、分析エンジニア
  • 利用シーンまたは効果: 大量の小ファイルが生成されるIceberg V3データレイクのファイルコンパクションとレイアウト最適化によりクエリI/O削減、クエリ性能向上、ストレージコスト削減が期待できる
  • 運用効果: Glueクローラーによる自動検出でメタデータ管理が簡素化され、統計（NDV等）の自動生成でクエリプランの精度が向上してリソース効率が改善される

技術的な注意点 ​

  • IAM権限: Glueの最適化・統計・クローラーを実行するためにGlueおよびS3への読み書き権限、必要に応じてIAMロールの付与が必要です（GlueServiceRole等）。
  • リージョン制限: Glue Data Catalogのテーブル最適化・統計・クローラーが提供されているリージョンで利用可能です。一部リージョンで未提供の場合がありますので事前に対応リージョンを確認してください。
  • コスト: 最適化・統計収集はバックエンドでSparkなどの処理を実行するため、Glueジョブ実行やデータスキャンに応じた料金が発生します。ストレージ削減は期待できますが、操作実行コストを考慮してください。
  • 互換性: 機能はIceberg V3テーブル向けです。V1/V2テーブルや各クエリエンジンのV3互換性によっては期待どおりに動作しない可能性があります（クエリエンジン側のV3サポートを確認）。
  • データ型対応: variant、geospatial、ナノ秒精度タイムスタンプなどV3固有のデータ型をサポートしますが、クエリエンジン側で同一のデータ型サポートが必要です。
  • 最適化の挙動: Z-orderやソート最適化は適切なキー選定が重要です。Z-orderはクラスタリング効果を高めるが、キー選定や並び替えコストを考慮する必要があります。
  • 統計の性質: NDVは近似推定（アルゴリズムに依存）となる場合があります。統計更新の頻度とタイミングを運用ルールで設計してください。
  • データ整合性とロック: 大規模なコンパクションやスナップショット削除はトランザクションや一貫性に影響を与える可能性があるため、実行タイミングや並列実行の制御（ロック/ガバナンス）を検討してください。

参考情報 ​

[Budgets] AWS Budgets now supports email verification for notification subscribers ​

概要 ​

AWS Budgetsが新しいメール購読者に対してメール確認(verification)を行うようになりました。新規に通知先メールアドレスを追加すると、受信側の確認を経て初めて予算アラートが配信されます。

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

AWS Budgetsは、予算通知に追加された新しいメールアドレスに検証メールを送信し、受信者が検証リンクをクリックして確認するまでそのアドレスには通知を送らない仕様になりました。検証メールのリンクはAWS Management Consoleを開き、確認が完了すると該当アドレスが通知を受け取れるようになります。コンソール上では各サブスクライバーの検証ステータスが表示され、未確認のアドレスに対しては検証メールの再送オプションが利用可能です。通知の配信基盤はAWS User Notificationsであり、受信者はいつでもオプトアウトできます。検証は2026-09-30以降に追加されたメールアドレスに適用され、既に既存の予算に登録済みのアドレスは影響を受けません。機能はすべてのAWSリージョンで利用可能ですが、AWS GovCloud (US) リージョンおよび中国リージョンでは未対応です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドコスト管理者、FinOpsチーム、SRE/運用チーム、組織内で予算通知を管理する担当者
  • 利用シーンまたは効果: 予算超過時のメールアラート送信で意図しない受信者への送信を防止し、受信者確認により連絡先の正当性を担保できる
  • 運用影響: API/自動化で新規メールを追加するワークフローでは、受信者の確認を待たないと通知が届かないため、初回通知が漏れるリスクがある。事前に受信者の確認を促すか、SNS/他チャネル併用を検討することが望ましい

技術的な注意点 ​

  • IAM権限: 予算の作成・編集や通知先の追加を行うため、Billing/Budgetsに関する操作権限が必要（コンソール操作権限や該当のBudgets API権限を持つこと）
  • リージョン制限: すべてのAWSリージョンで利用可能だが、AWS GovCloud (US) リージョンおよび中国リージョンでは未対応
  • 既存サブスクライバー: 既に登録済みのメールアドレスは影響を受けず、再確認の必要はない
  • 検証フロー: 新規追加メールには検証メールが送信され、受信者がメール内のリンクをクリックするとAWS Management Consoleで確認処理が完了する。コンソールでステータス確認と再送が可能
  • 配信経路・オプトアウト: 通知はAWS User Notifications経由で配信され、受信者はいつでもオプトアウト可能
  • 自動化影響: Infrastructure as Codeやスクリプトで一時的な通知先を追加する場合、確認待ちにより通知が届かないことがあるため確認プロセスをワークフローに組み込むか代替の通知手段を用いること
  • コスト: 検証メール自体による追加課金は想定されないが、通知着信の不足による運用コストや対応コストが発生する可能性がある

参考情報 ​

[Emr] Serverless Storage on Amazon EMR Serverless now supports terabyte-scale shuffle ​

概要 ​

Amazon EMR Serverlessがジョブあたりのシャッフル容量上限を従来の200GBから最大1TBに拡張し、メモリ不足時のディスクスピル（spill）対応を追加しました。これによりテラバイト級のApache Sparkワークロードの信頼性と本番移行のしやすさが向上します。

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

Amazon EMR Serverlessは、構成やクラスター管理を行わずにオープンソースのビッグデータフレームワーク（例: Apache Spark）を実行できるサービスです。本アップデートにより、ジョブあたりのシャッフル（shuffle）操作で最大1TBまでサポートされるようになりました（従来は200GB）。これに加え、メモリ集約型処理時にデータをディスクへオフロードする“spill”機能が導入され、結合（joins）、集計（aggregations）、ソート（sort）など大量の中間データを生成する処理でのジョブ成功率が改善されます。利用には emr-7.14、emr-spark-8.1 以降のランタイムが必要で、Amazon EMR Serverless が提供されている18リージョンで利用可能です。大規模なテーブル結合や高カーディナリティの集計といった、テラバイト級データセットを扱うプロダクションワークロードの移行・実行が容易になります。詳細なリージョン対応状況や適用上限は公式ドキュメントを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データサイエンティスト、SRE/運用チーム
  • 利用シーン: 大規模テーブル結合（マルチテラバイト）、高カーディナリティの集計、複雑なソートやジョインを伴うSparkバッチ/ETL処理
  • 運用効果: メモリ不足でのジョブ失敗を減らし、本番移行の信頼性が向上。クラスター管理不要のままテラバイト規模の処理が実行可能になり、運用負荷とインフラ管理の簡素化が期待できる

技術的な注意点 ​

  • IAM権限: EMR Serverlessでジョブを起動/管理するためのAPI権限（例: emr-serverless:StartJobRun 等）およびS3アクセス、CloudWatch Logs/メトリクス出力権限を事前に確認してください
  • リージョン制限: 本機能はAmazon EMR Serverlessが提供されている18リージョンで利用可能です。利用可否と地域ごとの適用上限は公式ドキュメントを参照してください
  • EMRランタイム/互換性: emr-7.14 および emr-spark-8.1 以降のランタイムが必要です。利用前にアプリケーションのランタイム設定を確認してください
  • コスト: シャッフルでディスクへスピルすることによりI/Oおよび一時ストレージ利用が増える可能性があります。これに伴う課金影響（例: ストレージ/IO系の課金や関連サービスの利用増）を評価してください
  • 設定／チューニング: spark.sql.shuffle.partitions やタスク並列度、メモリ関連のSpark設定で最適化を検討してください。スピル発生時のパフォーマンス低下を考慮し、事前に代表的なワークロードで検証してください
  • 監視／ログ: CloudWatch メトリクスとジョブログでスピル頻度、シャッフルI/O、タスクの失敗／再試行を監視し、ボトルネック把握に役立ててください
  • その他の制限: ジョブあたりのシャッフル上限は1TBですが、アカウント／リージョン単位の他の制限やサービスの仕様変更がある可能性があるため、最新ドキュメントで適用制限を確認してください

参考情報 ​

[Route 53] Announcing DNS analytics and insights for Route 53 Global Resolver and DNS Firewall ​

概要 ​

Route 53 Global Resolver と DNS Firewall が、ネイティブな Amazon CloudWatch 統合による DNS アナリティクスとインサイト機能を提供開始しました。DNS クエリパターンの可視化、DNS Firewall ルールの効果測定、異常検知、パフォーマンス最適化が可能になります。

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

新機能は CloudWatch Metrics および Contributor Insights と連携し、DNS クエリログの検索・分析、特定パターン（例: ブロックされたクエリ、DNS 応答コード）に対するメトリックフィルタ作成、アラーム設定をサポートします。Route 53 の Global Resolver と DNS Firewall コンソールには新たに "Analytics" タブが追加され、両サービスの解析結果へ一元的にアクセスできます。たとえば VPC ごとのブロック済みクエリ数を計測するメトリックフィルタを作成し、1時間あたり10件を超えた場合にアラームを発報する、といった自動化が可能です。解析は、該当リージョンで CloudWatch、Global Resolver、DNS Firewall が利用可能であれば利用でき、解析に必要なメトリクスはユーザーがオプトインして有効化します。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク管理者、セキュリティチーム、SRE、クラウド運用者
  • 利用シーン: DNS トラフィック監視、DNS Firewall ルール効果の評価、疑わしいクエリの検出とインシデント対応、VPC 単位のブロック傾向の可視化
  • 運用効果: ルールのチューニングや誤検知の早期発見、攻撃や広域障害の迅速な検知と通知による対応時間短縮
  • スケーラビリティ: CloudWatch ベースのため既存のメトリクス/アラームフレームワークに統合しやすく、大規模環境でも集計・アラートが可能

技術的な注意点 ​

  • IAM権限: Analytics を有効化/閲覧するには Route53 Resolver/DNS Firewall と CloudWatch/Logs の権限が必要です（例: route53resolver のクエリログ関連権限、cloudwatch:GetMetricData、cloudwatch:PutMetricAlarm、logs:DescribeLogGroups など）。
  • リージョン制限: CloudWatch、Route 53 Global Resolver、DNS Firewall が利用可能なリージョンで使用できます。リージョンごとのサービスサポート状況は公式ドキュメントで確認してください。
  • コスト: CloudWatch の標準料金が適用されます。オプトインしたメトリクス、Contributor Insights の料金、CloudWatch Logs の取り込み/保管料金やカスタムメトリクスの料金が発生する可能性があります。コスト試算を行ってから有効化してください。
  • ログ設定: DNS クエリ解析はログの収集/オプトインが前提です。Resolver のクエリログ（または DNS Firewall のログ）を CloudWatch Logs に送信する設定が必要な場合があります。
  • 運用上の注意: メトリクスフィルタのしきい値やアラート条件は環境に合わせて調整してください。高頻度のメトリクス化はコストとノイズの原因になります。

参考情報 ​

[Iam Identity Center] AWS IAM Identity Center extends multi-Region support to more AWS Regions ​

概要 ​

AWS IAM Identity Center（旧AWS SSO）がマルチリージョン対応を追加のAWSリージョンに拡張しました。プライマリリージョンからオプトインした追加リージョンへID・権限情報を自動複製でき、可用性と運用柔軟性が向上します。

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

主な変更点と挙動の技術的概要:

  • マルチリージョン複製: IAM Identity Centerはプライマリリージョンからオプトインした追加リージョンへ、アイデンティティ（ディレクトリ情報または外部IdPの連携情報）、エンタイトルメント（アカウント・ロール、アプリケーションへの割当）、及び関連メタデータを自動で複製します。
  • 対応範囲: 商用のデフォルト有効リージョンに加え、オプトイン方式の追加リージョン、さらにAWS GovCloud (US) および AWS China パーティション内のリージョン間でも複製が可能になりました（パーティション間の複製は行われません）。
  • インスタンス要件: 組織用インスタンス（organization instance）で、アイデンティティソースが外部IdPまたはIAM Identity Centerディレクトリである場合に利用可能です。
  • 暗号鍵要件: 複製を行うにはマルチリージョン対応のカスタマー管理型KMSキー（CMK）が必要です。新規インスタンス作成時はワンクリックでマルチリージョン対応を有効化でき、その際にCMKが作成されます。既存インスタンスではAWS KMSでマルチリージョンCMKを作成し、Identity Centerに設定する必要があります。
  • 運用と可用性: プライマリリージョンで障害が発生しても、追加リージョンに既にプロビジョニングされたエンタイトルメントを使ってユーザーはAWSアカウントへアクセスを継続できます。アプリケーション管理者は通常のデプロイワークフローで追加リージョンへアプリケーションを展開でき、ID管理は引き続きプライマリリージョンで行えます。
  • コストと制限: IAM Identity Center自体に追加料金は発生しませんが、マルチリージョンCMKの保管・利用に対する通常のAWS KMS料金が適用されます。利用可能な具体的リージョン一覧は "AWS Capabilities by Region" を参照してください。
  • 参照ドキュメント: AWSは「Using IAM Identity Center across multiple AWS Regions」や「AWS applications that you can use with IAM Identity Center」などの詳細ドキュメントを提供しています。

影響範囲・利用シーン ​

  • 対象ユーザー: IAM Identity Center を利用しているクラウド運用者、SRE、IAM/セキュリティ担当者、アプリケーション管理者
  • 利用シーン: リージョン障害に備えたアクセス耐障害性の向上、データ主権やレイテンシ要件に合わせたアプリケーションとIDのリージョン配置、GovCloud/Chinaパーティション内での冗長構成構築
  • 運用効果: プライマリリージョン障害時でも追加リージョンでの既存エンタイトルメントによりユーザーアクセスを維持できるため業務継続性が向上する
  • デプロイ効果: アプリケーション管理者は既存のデプロイ手順で追加リージョンに展開可能。ID管理は中央（プライマリ）で継続でき、運用の一元化とローカル可用性の両立が可能
  • 制約: すべてのAWSアプリケーションが追加リージョン展開をサポートするわけではないため、対応可否は事前確認が必要

技術的な注意点 ​

  • IAM権限: マルチリージョンCMKの作成・設定にはKMSを操作する権限（CMK作成・管理・設定）が必要です。Identity Centerの管理には既存のIdentity Center管理権限が必要です
  • リージョン制限: オプトイン方式の追加リージョンおよび GovCloud/China パーティション内のリージョンが対象。パーティション間（例: 商用リージョン ↔ GovCloud/China）での複製は行われません。利用可否は "AWS Capabilities by Region" で確認してください
  • コスト: IAM Identity Center の機能自体に追加料金はありませんが、マルチリージョンCMKの作成・保管・API利用に対して標準の AWS KMS 料金が発生します
  • データレジデンシー/コンプライアンス: ID情報や権限情報が追加リージョンに複製されるため、規制要件やデータ主権の観点での影響を事前に評価してください
  • 既存インスタンスの手順: 既存インスタンスは手動でマルチリージョンCMKを作成し、IAM Identity Centerに設定する必要があります。新規作成時はワンクリックでCMK生成と有効化が可能です
  • アプリ互換性: すべてのAWSアプリケーションが追加リージョンでのデプロイに対応しているわけではありません。対象アプリは公式リストで確認してください
  • 注意点がない場合: 特になし

参考情報 ​

[Secrets Manager] Improve your secrets security posture with actionable recommendations in the AWS Secrets Manager console ​

概要 ​

AWS Secrets ManagerがAWS Recommended Actionsフレームワークと統合され、シークレットごとにコンソール上で文脈に応じた実行可能なセキュリティ改善案（推奨事項）を表示できるようになりました。これにより回転設定や暗号化キーの見直しなどをコンソールから直接確認・対応しやすくなります。

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

今回の機能は、Secrets Managerコンソール内で各シークレットに対する「Recommended Actions」の推奨事項を表示するものです。表示される推奨内容はシークレットの状態に依存して動的に生成され、例えば以下のような項目が含まれます：シークレットに対する自動回転（rotation）が未設定の場合の回転設定推奨、デフォルトのサービス提供キーではなく顧客管理型キー（Customer Managed Key, CMK）を使用するようにする暗号化の推奨、シークレットのポリシーやタグなど設定改善の提案など。推奨事項はシークレット一覧や詳細画面に表示され、該当する推奨に従ってコンソール内から設定変更やリンク先の操作に進めます。本機能は追加料金なしで、Secrets Managerが提供されているすべてのAWS商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ担当者、クラウド/プラットフォームエンジニア、SRE、アプリケーション開発者
  • 利用シーン: シークレット管理のベストプラクティス適用（自動回転の有無確認、キー管理ポリシーの改善、アクセス許可や構成の見直し）
  • 運用効果: コンソール上で推奨を一元的に確認できるため、設定漏れの早期発見と対応が容易になりセキュリティ姿勢（security posture）が改善される
  • セキュリティへの影響: 適切な回転・暗号化キー運用・アクセス制御によりシークレット漏えいリスクが低減される
  • コスト影響: 機能自体は追加費用なし。ただし、顧客管理型KMSキーの利用（CMK作成・管理）や自動回転の実装による運用リソース増加、KMS呼び出しに伴うKMS利用料金が発生する可能性がある

技術的な注意点 ​

  • IAM権限: 推奨事項の表示や実行にはSecrets Managerの読み取り権限（例: secretsmanager:ListSecrets, secretsmanager:DescribeSecret）や、実際に設定を変更する場合は対応する書き込み権限が必要です。KMSキーの変更を行う場合はkms:DescribeKeyやkms:CreateKey/kms:EnableKeyRotationなどKMS関連権限が必要になることがあります。
  • リージョン制限: Secrets Managerが提供されているすべてのAWS商用リージョンで利用可能とされています。GovCloudや中国リージョンなど商用リージョン外のリージョンについては別途確認してください。
  • コスト: 推奨機能自体に追加料金はありません。だたし、CMKの作成・管理、KMS API呼び出し、シークレット回転Lambdaの実行や関連リソースの使用は別途料金が発生する場合があります。
  • 運用上の注意: 推奨事項はあくまで提案です。設定変更（例: 回転の有効化やキー変更）は本番影響を与える可能性があるため、事前テストとロールバック手順の準備を行ってください。
  • 監査/ログ: コンソールからの操作やAPIによる変更はCloudTrailで記録されます。変更履歴の追跡と監査を設定してください。

参考情報 ​

[Workspaces] Amazon WorkSpaces Core Managed Instances adds support for NVIDIA Blackwell GPU ​

概要 ​

Amazon WorkSpaces Core の Managed Instances が NVIDIA RTX PRO 4500 Blackwell（Graphics G7）を搭載した G7 インスタンスをサポート開始しました。グラフィックス指向ワークロードで従来の G6 比で最大2.1倍の性能向上を提供します。

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

Graphics G7 は NVIDIA RTX PRO 4500 Blackwell Server Edition GPU（各 GPU に 32GB の GDDR7）と Intel Xeon 6 プロセッサを組み合わせたインスタンスファミリーです。G6 世代比で最大 2.1x のグラフィックス性能向上、メモリ帯域は 2.67x の高速化により、より大規模で複雑な 3D シーンや高解像度レンダリング、リアルタイム視覚化が可能です。提供されるインスタンスサイズは 1〜8 GPU をサポートする 6 種類で、vCPU は 8〜192、システムメモリは 32GB〜768GB の範囲です。Linux と Windows をサポートし、BYOL（Bring Your Own License）にも対応します。初期提供リージョンは 米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（スペイン）で、順次追加リージョンが拡大予定です。WorkSpaces Core Managed Instance の作成時に G7 タイプを指定するか、WorkSpaces Core のパートナーソリューション経由で G7 インスタンスタイプを選択して利用を開始できます。

影響範囲・利用シーン ​

  • 対象ユーザー: グラフィックス重視のデスクトップ仮想化を必要とするプロフェッショナル（CAD/CAM、3Dアーティスト、科学可視化、ビデオ編集、AI支援デザイン）
  • 利用シーンまたは効果: 高解像度レンダリングや大規模3Dモデルのインタラクティブ操作、リアルタイム視覚化、GPUアクセラレートされたクリエイティブ/解析ワークロードのクラウド移行
  • 運用効果: ローカル高性能ワークステーションからクラウドへの移行によりスケーラブルなリソース割当てと集中管理が可能になり、短時間で高性能環境をプロビジョニングできる
  • コスト影響: 高性能 GPU を搭載するためインスタンス単価は上位となり、利用時間・GPU数に応じたコスト最適化（スポット利用、スケールダウン、適切なインスタンスタイプ選定）が重要
  • リージョン適用範囲: 現時点では限定リージョンでの提供（US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Europe (Spain)）、必要に応じて対応リージョンの拡大を確認する必要あり

技術的な注意点 ​

  • IAM権限: WorkSpaces Core および Managed Instances の作成/管理に必要な IAM 権限（WorkSpaces、EC2、VPC、IAM ロールの作成権限など）を事前に確認・付与してください
  • リージョン制限: 初期提供は米国・欧州の限定リージョンのみ。東京などの他リージョンでは未対応のため、利用前に対象リージョンを確認してください
  • コスト: G7 は高性能 GPU インスタンスのため時間課金は高め。長時間利用や複数GPU利用では料金が大きくなるため、予算試算と価格オプション（オンデマンド／リザーブド／Saving Plans）の検討を推奨します
  • OS/ライセンス: Linux と Windows をサポート。Windows や一部アプリケーションは BYOL（持ち込みライセンス）ポリシーや追加ライセンスが必要になる場合があるため、利用ソフトウェアのライセンス要件を事前に確認してください
  • 互換性: GPU ドライバやプロフェッショナルアプリケーション（CAD、レンダラー等）の Blackwell 世代対応状況を確認し、必要に応じてドライバ更新やアプリ側設定の検証を行ってください
  • ネットワーク/ストレージ: 大規模データセットや高フレームレート配信ではネットワーク帯域・ストレージ IOPS の要件が高くなるため、VPC 設計や接続（Direct Connect/VPN）・ストレージ性能を検討してください

参考情報 ​

[Developer Tools] AWS CLI now supports bulk skill updates and version checks for the Agent Toolkit for AWS ​

概要 ​

AWS CLIにAgent Toolkit for AWS向けの新コマンドが追加され、インストール済みのエージェントスキル一覧を一括で確認・更新できるようになりました。これにより多数のスキルを管理する環境でのバージョン維持が容易になります。

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

追加された主なコマンドは以下の2つです。

  • aws agent-toolkit check-skill-updates: ローカル（または環境にインストールされた）すべてのエージェントスキルを、スキルレジストリ上の最新バージョンと比較し、どのスキルが古いかを報告します（現在のバージョンと最新バージョンなどの情報を返す想定）。
  • aws agent-toolkit update-skill --all: レジストリ上で新しいバージョンが存在するすべてのスキルを一括で更新します。個別にupdateコマンドを繰り返す必要がなくなります。

Agent Toolkit for AWSの構成要素（AWS MCP Server、agent skills、plugins）についてもCLIからインストール、検索、設定が可能な既存機能にこれらが追加されています。これまで各スキルを個別に確認・更新していた運用が自動化・効率化され、特にサーバーレス、ストレージ、ネットワーキング、分析など多数のスキルを導入しているチームで有効です。

利用にあたってはAWS CLIバージョン2.37.0以上が必要です。AWS MCP Serverは現時点で米国東部（バージニア北部）と欧州（フランクフルト）リージョンで提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE、プラットフォーム/DevOpsチーム、エージェント（Kiro、Claude Code、Codex、Cursorなど）を運用する組織
  • 利用シーン: 多数のagent skillを導入している環境でのバージョンチェックと一括更新（定期メンテナンス、リリース後の即時パッチ適用、セキュリティ/ガイダンスの最新化）
  • 運用効果: 手動で個別更新する工数削減、スキルの陳腐化防止、エージェントが常に最新のガイダンスで動作することによる品質向上と問題発生リスク低減

技術的な注意点 ​

  • IAM権限: AWS CLIからAgent Toolkit操作を行うための適切なIAM権限が必要です。実際のAPI/CLIアクションに対するポリシーはユーザーガイドで確認してください。
  • CLIバージョン: AWS CLI v2.37.0以上が必須です（古いCLIでは新コマンドが利用できません）。
  • リージョン制限: AWS MCP Serverは現時点で US East (N. Virginia) と Europe (Frankfurt) のみで提供されています。MCP Server依存の操作はこれらリージョンでのみ動作します。
  • ネットワーク/レジストリアクセス: check-skill-updates/update-skillはスキルレジストリへのアクセスが必要です。オフライン環境やインターネット遮断環境では実行できないか、追加手順が必要になります。
  • 互換性とテスト: update-skill --allは複数スキルを同時に更新するため、本番環境で実行する前にステージングで互換性テストを行ってください。スキルの更新による挙動変化や依存関係の影響に注意が必要です。
  • コスト: 直接的なAWSサービス課金は通常発生しませんが、更新ファイルのダウンロードに伴うネットワーク転送量やストレージ利用は発生する可能性があります。
  • バックアップ/ロールバック: 大規模更新前に現在のスキル構成のバックアップ方法（設定保存やバージョン固定手段）を確認しておくことを推奨します。
  • 対応エージェント: Kiro、Claude Code、Codex、Cursorなどの一般的なコーディングエージェント向けのスキル管理を想定しています。個別エージェント固有の互換性も確認してください。

参考情報 ​

概要 ​

Amazon S3 Vectorsがメタデータ事前フィルタリングをサポートしました。選択性の高いフィルタを使うと、フィルタ適用時の検索リコールが最大5倍向上し、パスやURL向けのプレフィックス演算子($startsWith)も追加されました。

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

メタデータ事前フィルタリングは、まずメタデータ条件を評価して該当するベクトル集合を絞り込んでから類似検索（ベクトル検索）を実行する方式です。これにより、従来の「近傍探索で候補を取ってからメタデータで絞る」方式でフィルタに該当するベクトルが候補に含まれなかった場合に起きていた漏れ（リコール低下）を大幅に改善できます。Amazon S3 Vectorsはまた、パスやURLのような値に対するプレフィックス一致を行う$startsWith演算子を追加しました。新しいベクターバケットに作成されるインデックスでは事前フィルタリングがデフォルトで有効になり、PutVectorsやQueryVectorsの既存の呼び出し方を変更する必要はありません。既存のインデックスに対しては、UpdateIndexMode APIでインプレースに切り替え可能です。QueryVectorsのクエリごとパラメータで、事前フィルタリングと従来の振る舞いを比較して検証してからインデックスを更新することもできます。今回の機能は追加コストなしで、S3 Vectors提供リージョン（商用リージョンと中国リージョン）で利用可能となります。導入は段階的デプロイ中で、CLI/SDK/コンソールから操作できます。

影響範囲・利用シーン ​

  • 対象ユーザー: RAG/エージェント/セマンティック検索を実装する開発者、MLエンジニア、検索プラットフォーム担当者
  • 利用シーン: テナント別フィルタ、ファイルパスやURLでの絞り込み、時間範囲やカテゴリなど厳密なメタデータ条件を付けた埋め込み検索
  • 運用効果: フィルタを用いた検索のリコールが最大5x向上し、検索結果の完全性と関連度が改善されることでRAGの応答品質向上や誤回答低減に寄与する

技術的な注意点 ​

  • IAM権限: UpdateIndexModeやQueryVectors/PutVectorsを使えるIAM許可（S3 Vectors関連のAPI権限）を確認してください
  • リージョン制限: 商用AWSリージョンおよびAWS中国リージョンで利用可能。段階的デプロイ中のため、すべてのリージョンで順次有効化されます
  • コスト: 機能自体に追加課金はありませんが、事前フィルタリングを利用したクエリ設計によりクエリ回数や計算リソースの発生傾向が変わる可能性があるため、モニタリングしてください
  • 既存インデックスの切替: 既存インデックスはUpdateIndexMode APIでインプレースに切替可能。切替前にQueryVectorsのクエリ単位パラメータで事前フィルタリングとの比較検証を推奨します
  • クエリ互換性: PutVectors / QueryVectors の呼び出し方法は変更不要。プレフィックス演算子は $startsWith の構文を利用します
  • パフォーマンス注意点: フィルタの選択性が高い場合に最も効果が大きいです。逆に非常に非選択的なフィルタでは事前フィルタリングの効果が限定的で、ワークロードによってはレイテンシやリソース消費の特性が変わるためベンチマークを推奨します
  • 監視と検証: クエリリコール、レイテンシ、コスト指標を事前後で比較し、想定どおりの改善が出ているか検証してください

参考情報 ​

[CloudWatch] Amazon Managed Grafana now supports creating Grafana 13.2 workspaces ​

概要 ​

Amazon Managed Grafana（AMG）で新規ワークスペース作成時にGrafana 13.2が選択可能になりました。Grafana 13.0〜13.2で追加されたGit Sync、Dynamic Dashboards、CloudWatchデータソースでのPromQLサポートなどの機能が利用できます。

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

本リリースにより、Amazon Managed Grafanaで作成するワークスペースにGrafana 13.2を指定できるようになりました。主な追加・強化点は以下のとおりです。

  • Git Sync（ダッシュボードをコード化）: ワークスペースをGitリポジトリと連携し、ダッシュボードの定義をリポジトリで管理できます。変更履歴の追跡、レビュー、ロールバックが可能になり、インフラ／ダッシュボードのコード管理（IaC的運用）が容易になります。

  • Dynamic Dashboards（動的ダッシュボード）: データや変数の状況に応じてレイアウトやパネル表示を動的に切り替える機能。条件に応じて表示を最適化することで、用途別・コンテキスト別にレスポンシブな可視化が作れます。

  • CloudWatchデータソースのPromQLサポート: Amazon CloudWatchデータソースプラグインでPrometheus Query Language（PromQL）を使用してクエリが可能になりました。これはCloudWatchがOpenTelemetry（OTLP）経由で取り込んだメトリクスに対して有効で、既存のMetric SearchやMetrics Insightsと並んで選択できます。

  • 可用性: Grafana 13.2は、Amazon Managed Grafanaが一般提供されているすべてのリージョンで利用可能です。

注意: 発表は「新規ワークスペースの作成時にGrafana 13.2が選べる」ことを示しており、既存ワークスペースの自動アップグレードについては記載がありません。ワークスペースのアップグレード手順や互換性はドキュメントを確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE、監視エンジニア、プラットフォーム／DevOpsチーム、ダッシュボード開発者
  • 利用シーン: ダッシュボードをGitで管理して変更履歴とワークフローを統制したい場合（Git Sync）
  • 利用シーン: ユーザやアプリケーションの状況に応じて自動的に表示を最適化する動的な可視化が必要な場合（Dynamic Dashboards）
  • 利用シーン: CloudWatchへOTLP経由で取り込んだメトリクスをPromQLでクエリしたい場合（PromQLサポート）
  • 運用効果: ダッシュボードのコード化によりレビュー／ロールバックが容易になり運用信頼性が向上。ダッシュボード設計の柔軟性が高まり、運用負荷・オペミスの低減が期待できる

技術的な注意点 ​

  • IAM権限: ワークスペース作成や管理にはAWS側で必要なIAM権限（AmazonManagedGrafana関連の権限）が必要です。既存のIAMポリシーを確認してください。
  • Gitリポジトリ認証: Git Syncを使う場合はリポジトリへのアクセス方法（SSH鍵やPersonal Access Tokenなど）を準備し、認証情報の管理方法を検討してください。企業のVCSプロバイダ利用時はアクセス制御ポリシーを確認します。
  • OTLP要件: CloudWatchでPromQLによるクエリを使うには、対象メトリクスがCloudWatchにOpenTelemetry（OTLP）経由で取り込まれている必要があります。OTLP経由での送信設定を確認してください。
  • 既存ワークスペース: 本発表は新規ワークスペース作成時のバージョン指定に関するもので、既存ワークスペースのアップグレード手順や互換性は別途確認が必要です。アップグレード時はダッシュボードやプラグインの互換性テストを推奨します。
  • コスト: Grafanaバージョン選択自体に直接の追加料金が発生するとは限りませんが、CloudWatchでのクエリ（Metrics InsightsやPromQL相当の処理）やOTLP経由の取り込み、外部Gitサービス利用に伴うコストが発生する可能性があります。料金ページで詳細を確認してください。
  • リージョン制限: 発表では「AMGが一般提供されているすべてのリージョンで利用可能」とありますが、利用前に対象リージョンでのサービス提供状況を確認してください。

参考情報 ​

[Bedrock] OpenAI GPT-6 Astra now supports UltraFast mode on Amazon Bedrock ​

概要 ​

Amazon BedrockでOpenAIのGPT-6 Astraに対してUltraFastモードが利用可能になりました。レイテンシ重視のワークロード向けのプレミアム速度層で、API推論が最大6倍、最大300トークン/秒のスループットを提供します。

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

UltraFastはGPT-6 Astra用のプレミアム速度ティアで、応答遅延を最小化することを目的としています。OpenAIの公表によれば、従来モードに比べ最大6×の高速化、最大300トークン/秒の推論スループットを実現します。Amazon Bedrockの推論エンジン上で提供されるため、本番環境で求められるパフォーマンス、セキュリティ、信頼性が確保されます。主な利用方法はAmazon Bedrockコンソールからの操作、またはサポートされているBedrock API（例: InvokeModelなど）を通じたプログラム的呼び出しです。既存のAWSコントロール（IAM、VPCエンドポイント、CloudTrailによる呼び出しログ等）を利用してアクセス制御や呼び出しの監査が可能です。リージョン、エンドポイント、利用可能な推論プロファイルや料金体系についてはAmazon Bedrockのドキュメントで確認する必要があります。Latency-sensitiveなリアルタイムコーディングアシスタント、対話型エージェント、顧客向けのインタラクティブ体験などで有効です。導入時はスループットとコストのトレードオフ、品質（応答の整合性）や同時実行性に関する検証を推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: リアルタイム性を重視するアプリ開発者、SRE/運用チーム、カスタマーエクスペリエンス担当
  • 利用シーンまたは効果: リアルタイムコーディングアシスタント、対話型エージェント、チャットベースの顧客応対など、低遅延で高速な応答が求められる用途で応答速度向上とユーザー体験の改善が期待できる
  • 運用効果: レイテンシ低下によりユーザー満足度向上とインタラクティブ処理のスループット増加が見込める
  • コスト影響: UltraFastはプレミアム速度ティアのため追加料金が発生する可能性が高く、トークン消費量やリクエスト頻度に基づくコスト試算が必要
  • リージョン: 利用可能リージョンはドキュメントで要確認（記事では「ドキュメント参照」と明記）。リージョン非対応の場合はフェイルオーバー設計が必要

技術的な注意点 ​

  • IAM権限: Bedrockのモデル呼び出し（例: InvokeModel）や関連ログ閲覧に必要なIAMポリシーを付与すること
  • リージョン制限: 記事はリージョン一覧を明記していないため、利用前にAmazon Bedrockドキュメントで対応リージョンとエンドポイントを確認すること
  • コスト: UltraFastはプレミアム速度層であるため通常より高い課金が発生する可能性がある。料金はリージョン・モデル・推論プロファイルごとに異なるため事前の試算推奨
  • 性能検証: レイテンシ、スループット（最大300トークン/秒）、同時接続時の挙動、品質（応答の整合性）をステージング環境で検証すること
  • 監査とログ: CloudTrailやBedrockの呼び出しログでモデル呼び出しを監査可能。アクセス制御、ログ保持ポリシー、機密データの取り扱いを設計すること
  • ネットワーク/セキュリティ: VPCエンドポイントや暗号化設定、機密データのトークナイズ・マスキング等の対策を検討すること
  • 互換性/APIs: コンソール操作のほか、サポートされるBedrock APIを介してプログラム的に利用可能。API仕様（パラメータ、タイムアウト、レート制限）を確認すること

参考情報 ​

[General] AWS Parallel Computing Service now supports scaling logs ​

概要 ​

AWS Parallel Computing Service (AWS PCS) が各計算ノードの状態遷移を記録する「スケーリングログ」をサポートしました。これによりノードの起動/登録/スケールダウン/起動失敗などの履歴を取得してスケーリング問題の診断が容易になります。

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

スケーリングログはクラスタ内の各計算ノードについて「1件の状態遷移」を記録します（例：インスタンスの起動、ノードの登録、スケールダウン、起動失敗とその理由）。ログの配信はオプトイン方式で、出力先として Amazon CloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehose を選択可能です。これにより、ノードがなぜターゲットサイズに到達しなかったか、容量不足で失敗した起動はどれか、特定ノードがいつ開始/停止したかといった調査が行えます。AWS PCS は Slurm を利用した HPC 環境をマネージドで提供するサービスであり、本機能は PCS が利用可能な全リージョンで有効です。導入方法や詳細設定は AWS PCS User Guide を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: HPC運用者、クラウドエンジニア、SRE、研究用クラスター管理者
  • 利用シーン: スケーリング失敗の原因調査（容量不足、起動失敗理由の特定）、ノード起動/停止の時系列追跡、監査ログ収集や容量計画の検証
  • 運用効果: トラブルシューティング時間の短縮、スケール挙動の可視化による運用改善、容量計画やコスト最適化の精度向上

技術的な注意点 ​

  • IAM権限: CloudWatch Logs（logs:CreateLogGroup, CreateLogStream, PutLogEvents）、S3（s3:PutObject 等）、Firehose（firehose:PutRecord/PutRecordBatch）などの適切な権限を付与する必要があります。PCS側にログ配信用のサービスロールが必要な場合があります。
  • 配送先設定: スケーリングログはオプトインで有効化し、CloudWatch Logs グループ、S3 バケット、または Firehose デリバリーストリームを指定して配信します。配信先での設定（ロググループ名、バケットポリシー、Firehose 宛先設定）を事前に構成してください。
  • コスト: CloudWatch Logs の取り込み/保存、S3ストレージとリクエスト、Firehose の転送・配信先費用が発生します。大量のノード・高頻度の遷移がある環境ではコストが増えるため保持期間やライフサイクルを設定してください。
  • リージョン制限: 本機能は AWS PCS が提供されている各リージョンで利用可能です。PCS 自体が未提供のリージョンでは利用できません。リージョンごとのサービス提供状況を確認してください。
  • ログ形式と量: 各エントリはタイムスタンプ、ノードID/インスタンスID、遷移タイプ、失敗理由などを含む想定です（正確なフィールドは User Guide を参照）。大規模クラスターではログ量が多くなるため、集約・フィルタリングや保持ポリシーを検討してください。
  • セキュリティ: S3 へ配信する場合はバケットポリシーと暗号化（SSE-S3/SSE-KMS）を設定、CloudWatch Logs でも KMS による暗号化やアクセス制御を適用してください。KMS を使う場合は追加の IAM 権限が必要です。
  • 有効化方法: 管理コンソール、API/CLI 等から設定可能な想定です。詳細な手順は User Guide を参照してください。

参考情報 ​

[Aurora] Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads ​

概要 ​

Amazon Aurora Serverless がスケーリングを高速化し、短時間で最大16 ACUを即時増加できるようになりました。ワークロードに応じて最大256 ACUまで自動で拡張し、完了後はゼロまでスケールダウンして従量課金となります。

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

今回のアップデートにより、Aurora Serverless はバースト時に現在のキャパシティに対して1秒以内に最大16 ACUを一括で追加できるようになり、その後の負荷増加に対して最大256 ACUまで継続的にスケールします。これにより短時間に大量の処理を発生させる agentic AI やバースト性の高い API、バッチ処理などで必要なキャパシティを迅速に確保できます。ワークロード終了時は自動でスケールダウンし、最小でゼロになるため、アイドル時間が長いユースケースではコスト効率が高くなります。機能はプラットフォームバージョン3および4のすべての Aurora Serverless クラスターでデフォルト有効です。プラットフォームバージョン1/2 の既存クラスターは、直接バージョン4へアップグレードすることで本改善の恩恵を受けられます。クラスターのプラットフォームバージョンは AWS マネジメントコンソールのインスタンス構成欄、あるいは RDS API の ServerlessV2PlatformVersion パラメータで確認できます。価格やリージョン対応状況は Aurora の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、AI/機械学習チーム、SRE/運用担当者
  • 利用シーンまたは効果: agentic AI やボースト性の高い API、バッチ/イベント駆動処理で短時間に必要な DB キャパシティを迅速に確保し、応答性を改善します
  • 運用効果: ピーク時のスロットリングや遅延の低減、アイドル期間のコスト削減（ゼロスケール）による総合的なコスト最適化
  • 移行影響: プラットフォーム v1/v2 を利用中の既存クラスターは v4 へのアップグレード検討が必要（ダウンタイムと互換性確認要）

技術的な注意点 ​

  • プラットフォームバージョン: この高速スケーリングはプラットフォーム v3/v4 でデフォルト有効。v1/v2 は v4 へアップグレードが必要です
  • 確認方法: コンソールのインスタンス構成欄、または RDS API の ServerlessV2PlatformVersion パラメータで確認可能
  • リージョン制限: 地域ごとの提供状況は Aurora の料金/リージョンページで確認してください（リージョンによっては未対応の可能性あり）
  • コスト: スケールアップ時の ACU 増分に対して課金が発生。スケールダウンでゼロになると課金は停止。ただし、永続ストレージ等は別途課金されます。料金詳細は公式料金ページを参照してください
  • 接続とリトライ: 高速なスケーリングでも接続の再確立や一時的なレイテンシ変化が発生する可能性があるため、接続プールやアプリ側のリトライ/バックオフ設計を推奨します
  • 互換性/エンジン: MySQL互換・PostgreSQL互換の各エンジンでの挙動やサポート状況はドキュメントで確認してください
  • IAM権限: クラスターの確認・アップグレードを行うには適切な RDS 管理権限（rds:DescribeDBClusters / rds:ModifyDBCluster 等）が必要です

参考情報 ​

[RDS] Amazon Aurora and RDS now support AMD-based R8a instances ​

概要 ​

Amazon Aurora と Amazon RDS で、5世代 AMD EPYC プロセッサ搭載の R8a インスタンスクラスが利用可能になりました。高いネットワーク／EBS 帯域と物理コアに対応する vCPU により、I/O 集約型やコア単位の性能が重要なデータベース負荷に適しています。

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

R8a は第5世代 AMD EPYC プロセッサを採用したデータベース向けインスタンスクラスです。各 vCPU が物理コアに対応する設計のため、ハイパースレッディング由来の変動が少なくコアあたりの性能が予測しやすくなります。ネットワーク帯域は最大75 Gbps、Amazon EBS 帯域は最大60 Gbps を提供し、高スループット・高 I/O レイテンシ要件のワークロードに適しています。全インスタンスは AWS Nitro System 上で動作し、第6世代 Nitro Card を採用しています。対応エンジンは Aurora PostgreSQL-Compatible Edition、Aurora MySQL-Compatible Edition、RDS for PostgreSQL、MySQL、MariaDB（各エンジンの対応バージョンは公式ドキュメントを確認してください）。利用可能リージョンは米国東部（北バージニア、オハイオ）、米国西部（オレゴン）、カナダ（中部）、アジアパシフィック（東京、台北）、欧州（アイルランド、フランクフルト、スペイン）です。コンソールまたは AWS CLI から作成・変更できます。既存インスタンスを R8a に変更する際は対象のエンジンバージョンがサポートされているか、かつ変更に伴う再起動やフェイルオーバーの影響を確認してください。料金はインスタンスタイプとリージョンに依存するため、Aurora および RDS の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: DB 管理者、SRE、データベースを多用するアプリケーション開発者およびアーキテクト
  • 利用シーンまたは効果: OLTP や高並列/高 I/O を要求するトランザクション処理、低レイテンシが求められる読み書き集約型ワークロード、コア単位の安定した単スレッド性能が重要な処理
  • 運用効果: 一貫したコア性能と高いネットワーク/EBS 帯域によりスループット向上やレイテンシ低減が期待できる。インスタンス選定の選択肢が広がることでコスト/性能の最適化が可能
  • 移行上の注意: 既存インスタンスをクラス変更する場合は再起動や短時間のダウンタイム、Multi-AZ の場合はフェイルオーバー影響を考慮する必要あり
  • リージョン: 利用可能リージョンは記事記載の範囲に限定（US East: N. Virginia, Ohio / US West: Oregon / Canada Central / APAC: Tokyo, Taipei / EU: Ireland, Frankfurt, Spain）

技術的な注意点 ​

  • IAM権限: DB インスタンスの作成・変更には rds:CreateDBInstance / rds:ModifyDBInstance 等の権限が必要。CLI/コンソール操作用の権限を事前に確認してください
  • リージョン制限: R8a は記事で列挙されたリージョンのみで利用可能。他リージョンでは未対応の可能性あり
  • エンジン互換性: 対応する Aurora / RDS のエンジンバージョンが存在することをドキュメントで必ず確認してください（エンジンとバージョンにより利用可否が異なります）
  • インスタンス変更時の影響: インスタンスクラス変更は再起動（Single-AZ でのダウンタイム）またはフェイルオーバー（Multi-AZ）を伴う可能性があるため、稼働時間ポリシーに合わせて計画してください
  • コスト: インスタンス料金はリージョン・インスタンスタイプ・購入オプション（オンデマンド / リザーブド / Savings Plans）に依存。導入前に価格比較と TCO 評価を行ってください
  • 検証推奨: 実運用導入前にベンチマーク（例: sysbench, pgbench 等）や読み書きプロファイリングで性能検証を行い、期待するスループット／レイテンシ達成を確認してください

参考情報 ​

[RDS] Amazon RDS now supports AMD-based M8a instances ​

概要 ​

Amazon RDS（PostgreSQL、MySQL、MariaDB）が AMD 第5世代 EPYC 搭載の M8a インスタンスをサポートしました。物理コアに対応する vCPU や高帯域（ネットワーク最大75 Gbps、EBS最大60 Gbps）を特徴とする新しい選択肢です。

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

M8a は第5世代 AMD EPYC プロセッサを採用したデータベースインスタンスファミリーで、各 vCPU が物理コアに対応するためコアごとの性能が安定します（SMT/ハイパースレッディングの影響が少ない設計）。高 I/O を要するワークロード向けにネットワーク帯域は最大75 Gbps、Amazon EBS 帯域は最大60 Gbps を提供します。インスタンスは AWS Nitro System 上に構築され、第6世代 Nitro Card を使用しているため、EBS/ネットワークの高スループットやセキュアな分離が実現されます。利用可能リージョンは US East（N. Virginia, Ohio）、US West（Oregon）、Asia Pacific（Mumbai, Tokyo, Hyderabad）、Europe（Ireland, Frankfurt, Spain）です。Amazon RDS 管理コンソールまたは AWS CLI で利用開始でき、対応するデータベースエンジン／バージョンは RDS ドキュメントで確認してください。料金は RDS の料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベースを運用するクラウドエンジニア、DBA、SRE、アプリケーション開発者
  • 利用シーンまたは効果: 高いネットワーク／EBSスループットや一貫した単コア性能が求められるトランザクション集約型・分析型DBワークロード（例：OLTP、バッチ処理、レポーティング、リードレプリカ集約）で性能向上が期待できる
  • 運用効果: インスタンスタイプの選択肢が増えることでコスト対性能の最適化が可能（物理コア対応のvCPUによりシングルスレッド性能やライセンス算定が有利なケースあり）、高I/O要件を持つサービスのスループット改善やレイテンシ低減に寄与

技術的な注意点 ​

  • エンジン互換性: 対応する PostgreSQL/MySQL/MariaDB のエンジンバージョンが限定されるため、導入前に RDS の互換性ドキュメントで確認してください
  • インスタンス変更時の影響: DB インスタンスのクラス変更は通常リブート（ダウンタイム）を伴います。マルチAZ構成やフェイルオーバー戦略を検討してください
  • IAM権限: インスタンス変更や作成には rds:ModifyDBInstance / rds:CreateDBInstance 等の適切な権限が必要です
  • リージョン制限: 現時点で利用可能なリージョンは発表済みの一覧に限られます（東京、ムンバイ、ハイデラバード 等が含まれる）。未対応リージョンでは利用できません
  • コスト: 新インスタンスは既存インスタンスと単価が異なる可能性があります。料金ページでオンデマンド・リザーブドの比較を行い、コスト試算を行ってください
  • バックアップ/スナップショット: インスタンスタイプ変更前にスナップショット取得を推奨します（リストアやロールバックに備えるため）
  • モニタリング: CPU/ネットワーク/EBS レイテンシ・スループットを CloudWatch で監視し、期待する性能が出ているかを検証してください

参考情報 ​

[Bedrock] Amazon Bedrock expands Claude models in-region support in the UK (London) ​

概要 ​

Amazon BedrockがAnthropicのClaude Opus 5.5とClaude Sonnet 5のin-region（リージョン内）推論を英国内（ロンドン：eu-west-2）でサポート開始しました。これにより、UK内でデータを処理する必要がある金融、医療、公共などの顧客が推論を国内に留めてスケール利用できます。

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

今回の拡張で、Amazon BedrockはLondon（eu-west-2）リージョンのbedrock-runtimeエンドポイントを通じてAnthropicのClaude Opus 5.5およびClaude Sonnet 5に対するin-region推論を提供します。ユーザーがeu-west-2でBedrockのランタイムを呼び出すと、推論リクエストおよび関連データの処理は呼び出したリージョン内で行われ、処理がリージョン外へ移動することはありません。これによりデータ主権や法規制（例：英国データ保護要件）に配慮した運用が可能になります。導入はAmazon Bedrockコンソール、またはBedrockのランタイムAPI／SDK経由で行い、既存のBedrockワークフローにこれらのモデルを組み込めます。最新のモデルごとのリージョン提供状況はAmazon Bedrockユーザーガイドの“Regional availability by models”を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 金融機関、医療機関、公的機関、データ主権を要求する企業およびUK内で運用するアプリケーション開発者
  • 利用シーン: UK内でのテキスト生成、要約、対話型AI、ドキュメント解析などの推論をリージョン内で行う必要があるユースケース
  • 運用効果: データがUK内で処理されるため法令遵守（データ主権、DPA等）対応が容易になり、レイテンシーやスループット面でリージョンローカルの恩恵を受けられる
  • スケーラビリティ: Bedrockのマネージドランタイムにより大規模な推論ワークロードをスケール可能（ただしレート制限やスループット設計は要確認）

技術的な注意点 ​

  • IAM権限: bedrockのランタイムを呼び出すための権限（例：bedrock:InvokeModel 等）や、必要に応じてKMS権限（kms:Decrypt等）を事前に設定してください
  • リージョン制限: 本発表はLondon（eu-west-2）におけるin-regionサポートです。その他リージョンでの提供状況はユーザーガイドで確認してください
  • データ残留/コンプライアンス: AWSは推論処理が呼び出しリージョン内で行われると明示していますが、最終的なコンプライアンス判断（規制当局への確認等）はユーザー側で行ってください
  • ネットワーク/VPC: プライベートアクセス（PrivateLink/インターフェースVPCエンドポイント等）やネットワーク構成の利用可否・設定はリージョンごとに異なるため事前確認を推奨します
  • コスト: Bedrockのモデル利用はリクエスト/トークンベースで課金されます。利用量やレイテンシ要件に応じたコスト試算を行ってください（追加料金が発生します）
  • API/SDK: bedrock-runtimeエンドポイント経由でのInvoke（ランタイム呼び出し）で利用します。SDKやCLIからの呼び出しパターンは公式ドキュメントを参照してください
  • モデル管理: 提供されるモデルはClaude Opus 5.5およびClaude Sonnet 5の特定バージョンです。モデル更新や新バージョンのリージョン展開は随時行われるため、モデル名とリージョン対応を確認してください
  • 注意点がない場合: 特になし

参考情報 ​

[Aurora] Aurora PostgreSQL now supports querying of Apache Iceberg and Parquet data ​

概要 ​

Aurora PostgreSQL で Apache Iceberg および Parquet 形式のデータを、既存の PostgreSQL アプリケーションやツールから直接クエリできる機能が一般提供されました。ETL やデータ複製を行わずに、S3 や Glue カタログ上のデータレイクをそのまま参照できます。

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

本機能は PostgreSQL の外部テーブル（foreign table）を使って、S3 上の Iceberg テーブルや Parquet ファイル、S3 Tables、または AWS Glue Data Catalog に登録されたテーブルを参照できるようにします。クエリ実行時は PostgreSQL 内に組み込まれた高性能エンジン（DuckDB）を利用して Iceberg/Parquet データに対する列指向・プッシュダウン処理を行います。さらに、外部 Iceberg REST Catalog（IRC）互換カタログを AWS Glue Data Catalog を通じてフェデレーションし、データ移動なしにクエリ可能です。レイテンシが厳しいワークロード向けには、標準 SQL を用いて Iceberg/Parquet の外部データを Aurora のネイティブな PostgreSQL テーブルにマテリアライズ（取り込み）することも可能です。対応は Aurora PostgreSQL の 17.11、18.6 以降で、全ての商用リージョンと GovCloud (US) にて GA 提供され、追加の Aurora 利用料は発生しません。開始は RDS コンソールまたは任意の PostgreSQL クライアントから行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース/データレイク利用者、データエンジニア、BI/分析チーム、アプリケーション開発者、SRE
  • 利用シーン: データレイク（Iceberg/Parquet）と業務系データを結合した分析・レポート、BI ツールからの直接クエリ、自動化ワークフローへのリアルタイム参照
  • 運用効果: ETL やデータ複製の削減により開発・運用負荷が低下し、スキーマ変更時の手戻りを抑制。データの最新性を保ったまま分析が可能
  • コスト影響: Aurora の追加料金は不要だが、S3 の Get/Request/データ転送や Glue API 利用、クエリ実行時の S3 スキャンに伴うコストは発生。スキャン量削減のため Iceberg のパーティショニングやメタデータ活用が有効
  • リージョン: GA は全商用リージョンおよび GovCloud (US) で利用可能（記事時点）。ただしクロスリージョン S3/Glue 参照では追加遅延や転送料金に注意が必要

技術的な注意点 ​

  • IAM権限: Aurora が S3 と Glue Data Catalog（およびフェデレーション先カタログ）にアクセスできるように、適切な IAM ロール/ポリシーをアタッチする必要があります（S3 オブジェクト読み取り、Glue カタログ読み取り等）
  • Auroraバージョン: 対応は Aurora PostgreSQL 17.11、18.6 以降。該当バージョンであることを確認してください
  • データフォーマット互換性: Iceberg テーブルと Parquet ファイルが対象。Iceberg のカタログ配置（S3 メタデータ or external catalog）や一部高度な Iceberg 機能の対応状況は事前確認を推奨
  • パフォーマンス: DuckDB による列指向処理とプッシュダウン最適化があるものの、S3 上のデータスキャンがボトルネックになり得ます。低レイテンシが必要な場合はマテリアライズを検討してください
  • コスト: Aurora の追加料金はないが、S3 リクエスト/データ転送、Glue API 呼び出し、クエリ時のデータスキャン量に基づく料金が発生します。クエリプランと Iceberg のパーティション/メタデータでスキャン削減を行ってください
  • セキュリティ/ガバナンス: データアクセス制御は Glue カタログの権限制御や S3 バケットポリシー、KMS 暗号化設定などを組み合わせて管理してください
  • 運用設定: 外部テーブル作成やカタログフェデレーションの設定は RDS コンソールか通常の PostgreSQL クライアントで実行可能。詳細な SQL 構文やオプションは公式ドキュメントを参照してください
  • 制限事項: 一部の Iceberg/Parquet 機能（例: 特定のデータ型、カスタムファイルレイアウト、最新の Iceberg 機能）が未対応の可能性があります。移行前に検証を行ってください

参考情報 ​

[RDS] Amazon RDS for MySQL supports MySQL 26.7 in Amazon RDS Database Preview Environment ​

概要 ​

Amazon RDS for MySQL 26.7 が Amazon RDS Database Preview Environment で利用可能になりました。MySQL 26.7 は新しい YY.M カレンダーバージョニングを採用したイノベーションリリースで、バグ修正・セキュリティパッチに加え、Change Stream Applier などの新機能を含みます。

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

Amazon RDS のプレビュー環境で MySQL 26.7 の事前評価が可能になりました。MySQL 26.7 は YY.M（Year.Month）形式のバージョニングを初めて採用するイノベーションリリースで、主な新機能として Change Stream Applier（モジュール式のレプリケーション applier）を導入しています。Change Stream Applier は apply スループットの向上とバックログからの回復性能を改善することを目的としており、テストワークロードで有効です。加えて一般的なバグ修正とセキュリティパッチが含まれます。RDS Database Preview Environment のインスタンスは最大60日間保持され、自動的に削除されます。プレビュー環境で作成した DB スナップショットは同じプレビュー環境内でのみ復元可能で、外部（本番アカウントや他リージョン）への移行はできません。プレビュー環境の課金は US East (Ohio) リージョンの料金に準じます。詳細は MySQL 26.7 のリリースノートおよび Amazon RDS Database Preview Environment のドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者(DBA)、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: 新機能（Change Stream Applier）や互換性の検証、アプリケーションのリグレッションテスト、レプリケーション/バックログ回復の性能評価
  • 運用効果: 本番導入前に MySQL 26.7 の機能や既存アプリケーションとの互換性を検証でき、レプリケーションのスループット改善効果を確認して移行リスクを低減できる

技術的な注意点 ​

  • リージョン制限: プレビュー環境は US East (Ohio) の課金に準じる（利用可能リージョンが限定される可能性あり）。
  • 保持期間: プレビューインスタンスは最大60日で自動削除されるため、長期評価や本番移行には不向き。
  • スナップショット制限: プレビュー環境で作成した DB スナップショットは同プレビュー環境内でのみ使用可能。プレビューから本番環境へ直接移行することはできない。
  • 本番利用: プレビューは事前評価用であり、本番ワークロードでの利用は推奨されない。
  • コスト: プレビュー環境は課金が発生（US East (Ohio) の料金に準拠）。評価コストを見積もる必要あり。
  • 互換性: MySQL 26.7 は新しい YY.M バージョニングを採用。アプリケーションやレプリケーション設定の互換性テストを事前に実施することを推奨。
  • IAM権限: プレビュー環境の作成・管理に必要な RDS/IAM 権限を事前に確認すること（通常の RDS 操作権限が必要）。
  • バックアップ/監視: プレビュー環境の自動バックアップや監視設定・ログの取り扱いは通常環境と挙動が異なる可能性があるため、設定を確認すること。

参考情報 ​

[Cloudtrail] Uncover blind spots in AWS data plane operations with CloudTrail Event Coverage ​

概要 ​

AWS CloudTrailに新しいコンソール機能「Event Coverage」が追加され、アカウント／組織単位でデータプレーン（Data Events）のログ適用状況を可視化できるようになりました。サポートされるデータイベントソースのカバレッジ確認と、ダッシュボードからの直接サブスクライブが可能です。

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

Event CoverageはCloudTrailコンソール内の新しい視覚化機能で、環境内の各サービスおよびリソース種別に対してデータイベント（Data Events）が有効になっているか否かを一覧で確認できます。データイベントはS3のGetObject/PutObjectのようなデータプレーン操作を記録するもので、不正なデータアクセスやデータ流出などの検出に重要です。Event Coverageはサポートされる全データイベントソースを一箇所で表示し、カバレッジの欠落（ブラインドスポット）を素早く特定できます。さらに、ダッシュボードから直接データイベントのサブスクリプション（有効化）処理が行えるため、複数アカウントを管理する組織での追跡・修正作業を数クリックで完了できます。本機能はAWS CloudTrailがサポートされている全ての商用リージョンで利用可能です。詳細なデータイベントの取扱いやサポート対象はCloudTrailの公式ドキュメントを参照してください。例として、Amazon S3（オブジェクト操作）、AWS Lambda（関数呼び出しの記録）、Amazon DynamoDB（アイテムレベル操作）などがデータイベントの代表例です。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ／コンプライアンス担当者、クラウド／インフラエンジニア、SRE、組織管理者
  • 利用シーン: マルチアカウント環境でのデータアクセス監査、S3オブジェクトアクセスの不正検出、組織全体のログ収集ポリシー確認と一括有効化
  • 運用効果: ログ未取得による監視の盲点を迅速に発見でき、ダッシュボードから直接サブスクライブしてカバレッジを短時間で改善できるため、インシデント検出率とコンプライアンス遵守が向上する

技術的な注意点 ​

  • IAM権限: Event Coverageの表示・操作にはCloudTrailの読み取り／設定権限（例: cloudtrail:DescribeTrails, cloudtrail:GetEventSelectors, cloudtrail:PutEventSelectors など）および対象サービスのログ設定権限が必要です
  • 組織設定: 組織単位での可視化や一括設定を行う場合、AWS Organizationsの設定や委任された管理アカウントの構成が必要になる場合があります
  • コスト: データイベントの有効化は追加のCloudTrailデータイベント課金の対象となるため、対象サービス・リソース数による料金影響を事前に見積もってください
  • リージョン制限: この記事の通り、CloudTrailがサポートする全ての商用リージョンで利用可能です（リージョンごとのドキュメントで対応状況を確認してください）
  • 設定単位: データイベントはサービス／リソース単位（例: S3バケット単位）で設定されるため、細かなターゲティングが可能ですが、設定漏れに注意してください

参考情報 ​

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

Copyright © 2026