AWS What's New Digest

Appearance

2026年05月22日 ​

[Clean Rooms] AWS Clean Rooms now supports mutable payment configurations for collaborations ​

概要 ​

AWS Clean Roomsでコラボレーション作成後も細かな支払い（ペイメント）設定を変更できるようになりました。SQL、PySpark、ML（学習・推論）、合成データ生成などのコスト種別ごとに、許可された支払者を指定・変更できます。

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

今回のアップデートにより、既存のコラボレーションに対して「ファインチグレイン（細粒度）」な支払い構成を変更（mutable payment configurations）できるようになりました。主な機能は以下です。

  • コスト種別ごとの支払者指定：SQLクエリ、PySparkジョブ、機械学習のトレーニング／推論ジョブ、合成データ生成といった各コストカテゴリごとに、どのコラボレーションメンバーが費用を負担するかを指定可能。
  • 変更リクエストと承認ワークフロー：支払者の追加・削除は "change request" を通じて行い、コラボレーションメンバーの承認が得られて初めて有効になります。ガバナンスと透明性を保てます。
  • 複数支払者のサポート：SQLおよびPySpark分析では複数の許可支払者を登録でき、分析実行時に支払者を選択して実行可能です。MLジョブや合成データ生成は記事記載の範囲では複数支払者の明言がなく、個別扱いの可能性があります。
  • 運用例：製薬企業と医療機関のコラボレーションで、複雑な分析は製薬企業が負担し、簡易なSQL解析は医療機関が負担するといった役割分担が運用可能になります。 この機能は、AWS Clean Roomsが提供する“データを明示的に開示・コピーせずに共同分析する”仕組みと連携し、支払責任の柔軟な割当てを実現します。変更はコンソールおよびAWS SDK/API経由での操作が想定され、請求は指定したアカウントに対して発生します。利用可否はリージョンに依存するため、AWS Regions表で対応状況を確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データプロダクトチーム、SRE/運用チーム、データパートナー（共同分析を行う企業・組織）
  • 利用シーンまたは効果: パートナー間での費用負担を細かく分配したい共同分析（例：複雑な機械学習は発注企業が負担、簡易分析はデータ提供者が負担）により、コラボレーション開始後も柔軟に支払いルールを調整可能
  • 運用効果: 支払責任の明確化とガバナンス強化により、コスト争点の早期解消と共同実験のスピードアップが期待できる
  • コスト管理への影響: 分析実行時に支払者を選択できるため、コスト配分ポリシーに沿った請求管理が可能（請求先アカウントの確認・調整が必要）
  • ガバナンス: 変更リクエストとメンバー承認が必須なため、合意形成のトレーサビリティが確保される

技術的な注意点 ​

  • IAM権限: 支払い設定の変更や承認は専用の権限が必要になる可能性があります。該当API/コンソール操作に必要なIAMポリシーを事前に確認してください
  • 変更ワークフロー: 支払者の追加／削除は "change request" による承認プロセスを経るため、関係者の合意が得られる運用ルールを整備してください
  • 複数支払者の制限: SQLとPySpark分析は複数の許可支払者をサポートしますが、MLトレーニング／推論や合成データ生成については記事時点で複数支払者の明示がないため、単一請求先の想定や動作確認が必要です
  • 請求・コスト配分: 選択した支払者のAWSアカウントに料金が課金されます。AWS Organizationsやコスト配分タグ、請求アカウント設定との連携を事前に確認してください
  • リージョン制限: AWS Clean Rooms自体の提供リージョンに依存します。利用前に対応リージョンを確認してください（リージョン未対応の場合は機能が利用できません）
  • API/コンソール: 変更はコンソールだけでなくAWS SDK/APIで自動化可能です。自動化する場合は承認フローの実装や通知設計を検討してください
  • コスト: 支払い責任を変更しても総コストは変わりませんが、請求先の違いによりアカウント毎のコスト負担や割当が変化します。予算アラートや請求アラートの設定を推奨します

参考情報 ​

[Secrets Manager] AWS Secrets Manager adds managed external secrets support for Datadog vended keys and Snowflake Programmatic Access Tokens ​

概要 ​

AWS Secrets ManagerのManaged External Secrets機能が拡張され、DatadogのAPIキー／Applicationキー／サービスアカウント用の管理者認証情報ペアと、SnowflakeのProgrammatic Access Tokens（PAT）の自動ローテーションに対応しました。これにより、Secrets Managerからサードパーティ発行の認証情報を自動的に管理・回転できます。

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

Managed External SecretsはAWS Secrets Managerがサードパーティサービスとファーストクラスに統合され、顧客が外部サービス発行のシークレットをSecrets Manager上で自動ローテーションできる機能です。今回の拡張で以下が可能になります。

  • Datadog: API keys、Application keys、ならびにサービスアカウント向けの管理者資格情報ペア（admin credential pairs）のローテーションをSecrets Manager側で管理可能。これにより、Datadogへのキー発行／無効化／新規発行の操作をSecrets Managerが自動実行します。
  • Snowflake: Programmatic Access Tokens（PATs）のローテーションをSnowflakeのネイティブ認証機構を使って実施可能。ローテーション時に既存トークンと新トークンの共存を許す"grace period"（猶予期間）を設定でき、アプリケーションの切替をシームレスに行えます。

これらは既存のBigID、Confluent Cloud、MongoDB Atlas、SalesforceのManaged External Secrets統合に追加されたもので、Datadog/Snowflake向けの統合はSecrets ManagerのManaged External Secretsをサポートするすべてのリージョンで利用可能です。実装面では、Secrets Managerが外部API（Datadog/Snowflake）への呼び出しを実行して鍵の作成・取り消し・更新を行い、シークレットの値を更新して自動ローテーションフローを完結させます。

影響範囲・利用シーン ​

  • 対象ユーザー: セキュリティ/プラットフォーム/クラウドエンジニア、SRE、およびDatadogやSnowflakeを運用するアプリケーション開発チーム
  • 利用シーン: Datadog監視のAPI/Applicationキー管理、サービスアカウントの管理者認証情報の定期ローテーション、Snowflakeのプログラム的アクセスに使うPATの自動更新と安全な配布
  • 運用効果: 手動更新やカスタムLambdaの維持が不要になり、秘密情報の有効期限管理と鍵の廃止が自動化されることで漏えいリスクと運用負荷を低減
  • 可用性/レイテンシ: 管理対象シークレットの更新は外部API呼び出しに依存するため、対象サービスのAPI応答やレート制限がローテーションの成功に影響する可能性あり
  • セキュリティ効果: シークレットの短期化（短い有効期間）と自動ローテーションにより資格情報の横展開リスクを低減

技術的な注意点 ​

  • IAM権限: Secrets Managerのシークレット作成・更新・ローテーション（例: secretsmanager:RotateSecret、secretsmanager:GetSecretValue、secretsmanager:PutSecretValue 等）と、必要に応じてサービス連携用のサービスロール設定が必要です。詳細はドキュメントを確認してください。
  • 第三者権限: Datadog側はキーの作成/削除が行える管理権限（またはサービスアカウントの管理権限）、Snowflake側はPAT発行権限を持つアカウント/ロールの準備が必要です。初回のシークレット登録時に対象の認証情報を提供する必要があります。
  • リージョン制限: 記事発表時点では「AWS Secrets ManagerのManaged External Secretsをサポートするすべてのリージョン」で利用可能です。詳細な対応リージョンはドキュメントで確認してください。
  • grace period（猶予期間）: Snowflake PATのローテーションでは猶予期間を設定可能。アプリケーションが新しいトークンへスムーズに移行できるよう、猶予期間を適切に設定してください。未設定や短すぎると認証エラーが発生する可能性があります。
  • ローテーション頻度とスケジュール: Secrets Manager上でローテーションスケジュールを設定できます。外部APIのレート制限やサービス側ポリシーを考慮して頻度を設定してください。
  • コスト: Secrets Managerのシークレット保持・API呼び出しに伴う通常の料金が発生します。加えて外部サービス側のAPI利用や発行回数に起因する制限や課金がある場合は別途考慮が必要です。
  • 既存ワークフロー移行: 既にカスタムLambda等でローテーションを実装している場合、切替手順やロールバック計画を整備してから移行してください。
  • 監査/ログ: ローテーション操作はCloudTrail等で記録されます。監査要件がある場合はログ収集設定を確認してください。

参考情報 ​

[CloudWatch] Amazon CloudWatch Logs Insights adds new query commands and functions ​

概要 ​

Amazon CloudWatch Logs Insights のクエリ言語に13個の新しいコマンド／関数が追加され、ログの文字列操作、エンコード／デコード、非JSONフォーマットの解析、地理距離計算などがより簡単かつ効率的に行えるようになりました。

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

追加された機能は以下の通りです。string/number 関数: round(数値の丸め)、startswith/endswith(文字列のプレフィックス／サフィックス判定)、case(大文字小文字変換や条件付き変換)、regex_replace(正規表現による置換)、haversine(緯度経度からの距離計算)。エンコード／デコード: urlencode/urldecode、base64encode/base64decode（Base64 ペイロードをインラインでデコード／エンコード可能）。解析／分析コマンド: parse logfmt（logfmt 形式をフィールドにパース）、expand（ネストされた JSON 配列を個別レコードに展開）、relevantfields（高カードinality のロググループから“関連性の高い”フィールドを自動抽出）。これにより、例として「文字列プレフィックスでの高速フィルタリング」「ログ内の Base64 ペイロードをクエリ内でデコードして構造化」「logfmt やネスト配列の簡易パースでフィールド集約」「緯度経度からの距離算出を用いた位置ベース分析」などが容易になります。これらのコマンド／関数はすでに全ての商用 AWS リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE/運用チーム、セキュリティアナリスト、データエンジニア、アプリ開発者
  • 利用シーンまたは効果: ログの前処理や解析をクエリ内で完結させることで、外部処理を減らし迅速にインサイトを得られる（例: Base64 デコードして直接フィールド抽出、logfmt をパースしてメトリクス化、位置データからの距離計算による異常検知）
  • 運用効果: クエリ回数やパイプラインの簡素化により運用工数が削減され、問題発見までの時間短縮とトラブルシューティングの効率化が期待できる
  • 分析効果: 高カードinality のロググループでも relevantfields により重要フィールドを素早く特定でき、探索的分析の初動が速くなる

技術的な注意点 ​

  • IAM権限: CloudWatch Logs Insights のクエリ実行には logs:StartQuery, logs:GetQueryResults, logs:DescribeLogGroups 等の適切な CloudWatch Logs 権限が必要です（組織ポリシーを確認してください）
  • リージョン制限: 追加機能は全商用リージョンで利用可能と発表されていますが、特殊な GovCloud/China リージョンには別途確認が必要です
  • コスト: Logs Insights のクエリはスキャンしたログ量やクエリ実行回数に基づく課金モデルです。expand による配列展開や重い正規表現（regex_replace）は処理負荷とスキャン量増加でコスト上昇やクエリ時間増加の要因になります
  • パフォーマンス: 大規模データ/高カードinality に対しては正規表現や複雑な解析を乱用するとレイテンシが高くなるため、フィルタを先に適用して処理対象を絞る設計を推奨します
  • データ互換性: base64decode でバイナリや非 UTF-8 データを扱う場合、期待する文字列変換が得られないことがあるため注意してください
  • 仕様注意: haversine 関数は緯度経度を度（degrees）で受け取り数値型であることを想定します。入力値の正規化（型変換／NULL 処理）を事前に行ってください

参考情報 ​

[Ec2] Amazon EC2 C7i-flex, M7i-flex & M7i instances now available in Asia Pacific (Hyderabad) region ​

概要 ​

Amazon EC2のC7i-flex、M7i-flex、M7iインスタンス（カスタム第4世代Intel Xeon/Sapphire Rapids搭載）が、アジアパシフィック（Hyderabad）リージョンで利用可能になりました。AWS専用カスタムプロセッサにより、既存世代比や他クラウドの同等CPUと比べて性能・価格性能が向上しています。

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

今回追加されたインスタンスは以下の特徴を持ちます。カスタム第4世代Intel Xeon（Sapphire Rapids）を採用し、他クラウドで使われている同等x86ベースIntelプロセッサと比較して最大で約15%の性能向上をうたっています。C7i-flexおよびM7i-flexは、C6i/M6iと比べて最大で約19%の価格性能（price-performance）改善を提供し、最も一般的なサイズ（large〜16xlarge）をカバーするため、計算リソースを常時フルに使わないWeb/アプリサーバ、仮想デスクトップ、バッチ処理、マイクロサービス等の一般的ワークロードに対して費用対効果が高い設計です。M7iはM6i比で最大約15%の価格性能改善を実現し、最大48xlargeまでの大容量サイズと、metal-24xl / metal-48xlの2つのベアメタルサイズを提供します。これらベアメタルサイズはIntelのハードウェアアクセラレータ（Data Streaming Accelerator: DSA、In-Memory Analytics Accelerator: IAA、QuickAssist Technology: QAT）を内蔵しており、データ操作のオフロードや暗号化/圧縮などの処理を効率化できます。Hyderabadリージョンでの即時利用が可能で、より大きなサイズや継続的な高CPU使用率のワークロード（ゲームサーバ、CPUベースのML、ビデオ配信など）に適しています。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドインフラ担当者、SRE、アプリケーション開発者、ゲーム/ストリーミング事業者、CPU中心のMLエンジニア
  • 利用シーンまたは効果: Web/アプリサーバ、仮想デスクトップ、バッチ処理、マイクロサービスでのコスト効率向上／高CPU負荷のゲームサーバ、CPUベースML、ビデオストリーミングでの大規模インスタンス利用
  • 運用効果: 同等世代比での価格性能改善によりインスタンス数削減や処理時間短縮によるコスト最適化が期待できる。ベアメタルとIntelアクセラレータにより暗号化・圧縮・ストリーミングなどの処理をオフロード可能で、レイテンシやスループットの改善につながる

技術的な注意点 ​

  • リージョン制限: 本リリースはAsia Pacific (Hyderabad)での提供開始。他リージョンでは未提供の場合あり。リージョンごとの提供状況は確認が必要です。
  • AMI/ドライバ: ベアメタルやアクセラレータ（DSA/IAA/QAT）を利用する場合、対応するカーネル／ドライバ／ユーザーランドライブラリが必要です。公式ドライバやIntel提供のソフトウェアを導入してください。
  • ベアメタル特性: ベアメタルはハイパーバイザを介さないため、隔離やセキュリティ要件、ハードウェアへの直接アクセスを考慮した運用が必要です。
  • インスタンス上限（クォータ）: 新インスタンス投入時はアカウントのインスタンス数クォータやvCPUクォータに注意し、必要に応じてAWSサポートに引き上げを依頼してください。
  • 互換性: 既存のC6i/M6iからのリフト＆シフトは多くの場合容易ですが、ベアメタルやアクセラレータを利用する場合はアプリケーション側で対応が必要になることがあります。
  • コスト: 『価格性能』は改善を示す指標ですが、実際の請求額は選択したインスタンスタイプ、稼働時間、EBS/ネットワーク利用、リージョンの単価に依存します。導入前にベンチマークとコスト試算を推奨します。
  • IAM権限: 新インスタンスの起動やベアメタル利用には通常のEC2起動権限に加え、必要に応じてIAMポリシーの確認が必要です。

参考情報 ​

[SageMaker] SageMaker Unified Studio automates Glue connector provisioning for cross-subnet job retries ​

概要 ​

Amazon SageMaker Unified Studioが、ドメインVPCに定義された複数サブネットに対してGlueコネクタの自動プロビジョニングを行い、サブネット障害時にGlueジョブを別サブネットで自動リトライできるようになりました。これによりデータパイプラインの可用性とSLA遵守が向上します。

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

今回の機能追加により、SageMaker Unified StudioはドメインVPC設定で指定された複数のプライベートサブネット（異なるアベイラビリティゾーンに跨る設定を想定）に対して、AWS Glueがジョブリトライ時に使用するための接続（Glue Connection）を自動的に作成・管理します。管理者はドメイン作成時にVPCと複数サブネットを定義するだけで、以降作成される新しいプロジェクトに対して必要なコネクタが自動プロビジョンされます。これにより、一次サブネットでIPアドレス枯渇やAZの性能劣化などが発生してGlueジョブが失敗した場合でも、別サブネットに作成されたコネクタを使ってジョブを自動的にリトライし、ダウンタイムや手動介入を低減できます。ユーザー側の追加操作は初期のドメインVPC設定以外不要で、SageMaker Unified Studioが新規プロジェクト単位でコネクタを配備します。なお、記事では「すべてのAmazon SageMaker Unified Studio利用可能リージョンで提供」と明記されています。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、機械学習プラットフォーム運用者、SRE/運用チーム
  • 利用シーンまたは効果: ミッションクリティカルなETL/Glueベースのデータパイプラインで、サブネットやAZ障害発生時に自動的に別サブネットへジョブをリトライしてダウンタイムとSLA違反を低減
  • 運用効果: 手動でバックアップ接続を用意する手間が不要になり、新規プロジェクトの初期設定で高可用性構成が自動化されることで運用工数と人的ミスを削減

技術的な注意点 ​

  • IAM権限: SageMakerドメイン／サービスがGlueの接続を作成できるよう、関連するIAMロールにglue:CreateConnection、glue:GetConnection、glue:UpdateConnectionなどの権限（および必要に応じてiam:PassRole）が必要になる可能性があります。ドメイン作成時のロール設定を確認してください。
  • リージョン制限: 記事では「SageMaker Unified Studioが利用可能な全リージョンで提供」とされていますが、運用前に対象リージョンで機能が有効化されているか公式コンソール／ドキュメントで確認してください。
  • コスト: コネクタそのものの作成で直接の追加料金は想定されますが、別サブネットでのリトライによりGlueジョブの追加実行が発生すると、Glueの実行時間／リソースに対する通常の課金が発生します。ENI作成やデータ転送に伴うコストも考慮してください。
  • VPC／サブネット要件: ドメインVPCに複数のプライベートサブネットを事前に用意し、必要なルート、NATゲートウェイ／エンドポイント、セキュリティグループが適切に設定されていることを確認してください。Glueジョブがアクセスするリソース（RDS、S3（VPCエンドポイント）、内部API等）への接続経路も各サブネットで有効である必要があります。
  • 既存プロジェクトへの適用: 記事は「新しいプロジェクト」に対する自動プロビジョニングを明示しているため、既存プロジェクトについては自動でコネクタが追加されない可能性があります。既存環境には手動でコネクタを作成するか、プロジェクト設定の再作成を検討してください。
  • 監視・ログ: コネクタ作成やGlueジョブのリトライ挙動はCloudTrail／CloudWatch Logsで監視可能です。自動プロビジョニングの結果やリトライ発生時のログを監視・アラート設定しておくことを推奨します

参考情報 ​

[SageMaker] Amazon SageMaker AI now supports OpenAI-compatible APIs for inference endpoints ​

概要 ​

Amazon SageMaker InferenceがOpenAI互換APIをサポートし、OpenAI SDKやLangChainなど既存のツール／フレームワークでSageMakerエンドポイントをそのまま呼べるようになりました。エンドポイントURLを差し替えるだけで統合や認証の変更は不要です。

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

SageMaker InferenceがOpenAI互換のAPIエンドポイントを提供することで、OpenAI SDK、LangChain、Strands Agentsなどの既存ライブラリやストリーミングロジックをほぼ変更なしでSageMaker上のモデルに向けて利用できます。主な特徴は以下の通りです。

  • API互換性: 既存のOpenAI向けHTTP/SDK呼び出し（同期・ストリーミング含む）をエンドポイントURLの差し替えだけでそのまま利用可能。
  • 認証: AWS資格情報（IAMベース）を用いた認証を採用し、自動トークンリフレッシュにより既存のプロダクション運用フローを維持可能。
  • モデル運用の自由度: 任意のオープンソースモデルやファインチューニング済みモデルをデプロイでき、利用するGPUインスタンスタイプを選択可能。
  • ネットワークとセキュリティ: エンドポイントはVPC内で運用でき、データを社内ネットワークに閉じたまま推論が可能。
  • スケーリング: ワークロードに合わせたオートスケーリングポリシーを設定できるため、負荷に応じたスケーリングが行えます。
  • リージョン対応: 複数のリージョンで利用可能（後述のリージョン一覧参照）。 これにより、既存のアプリケーションやフレームワーク資産を活かしてSageMaker上のモデルを利用できるようになり、クラウドネイティブな運用（インスタンス選定、VPC制御、オートスケール）と開発者の生産性（既存ライブラリ再利用）の両立が図れます。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、MLプラットフォームチーム、アプリケーション開発者、SRE/運用チーム
  • 利用シーン: OpenAI互換クライアント（OpenAI SDK、LangChain、Strands Agents等）を使った推論を自組織のSageMakerエンドポイントへ移行・統合するケース（チャット/生成、埋め込み、ストリーミング応答など）
  • 運用効果: 既存コード・統合をほぼ変更せずにSageMakerのインフラ（カスタムGPU、VPC、オートスケーリング）を活用でき、データ主権と運用制御を維持しつつ開発生産性を向上できる

技術的な注意点 ​

  • IAM権限: InvokeEndpoint等のSageMaker呼び出し権限と必要なSTS権限が必要。既存のIAM認証フローへ統合されるため、権限設計は事前確認を推奨。
  • リージョン制限: 利用可能リージョンは US East (N. Virginia)、US West (Oregon)、US East (Ohio)、Asia Pacific (Mumbai)、Asia Pacific (Jakarta)、Europe (Ireland)、Europe (Frankfurt)、South America (São Paulo)、Asia Pacific (Tokyo)、Asia Pacific (Seoul)、Europe (London)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Canada (Central)。その他リージョンでは未対応の可能性あり。
  • コスト: SageMakerエンドポイントのインスタンス料金、データ転送料、ストレージ、オートスケーリングに伴う追加インスタンス費用が発生。OpenAIのAPI利用料は発生しないが、SageMaker利用料を見積もる必要あり。
  • ネットワーク/VPC: VPC内での運用が可能だが、クライアントからの接続経路（プライベート接続やNAT、VPCエンドポイント）を適切に設計する必要あり。
  • API互換性: 基本的なOpenAI APIパターン（同期呼び出し、ストリーミング等）に互換するが、細かなパラメータやエッジケースで差異が出る可能性があるため、既存のテストスイートで動作確認を行ってください。
  • ストリーミングとレート: ストリーミングAPIや高スループット時の接続維持、レート制限、タイムアウト設定はアプリ側とSageMakerの設定双方で調整が必要。
  • セキュリティ/データ保護: データはSageMaker内で処理されるが、ログやメトリクスの扱い、暗号化設定（KMS）やアクセスログの設定は確認してください。
  • オートスケーリング: オートスケーリングは利用可能だが、コールドスタート、スケールアップ遅延、最小/最大キャパシティの設計が必要。
  • SDK/フレームワーク互換: OpenAI SDKやLangChain等の既存フレームワークからの接続は想定されているが、フレームワークのバージョンや実装により追加設定が必要になる場合があります
  • モデル互換性: 任意のオープンソースモデルやカスタムモデルをデプロイ可能。ただしモデル出力のフォーマットがOpenAIの期待値と異なる場合は出力整形が必要になることがあります。

参考情報 ​

[Aurora] Amazon Aurora MySQL 8.4 is now generally available ​

概要 ​

Amazon Aurora MySQL 8.4 が一般利用可能になりました。Aurora はコミュニティ版MySQL 8.4（互換性は 8.4.7）に合わせたバージョン表記と自動パッチ管理を導入し、強化されたセキュリティ既定値やアップグレード前チェックなど運用の簡素化を提供します。

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

主な変更点は以下の通りです。

  • コミュニティ MySQL 8.4（互換性は MySQL 8.4.7）への対応とバージョン番号の整合化：Aurora 側のエンジンバージョンがコミュニティ版と一致するようになり、互換性の把握が容易になります。
  • パッチ管理の自動化：Aurora が基盤のパッチを代行して適用するため、日常運用でのパッチ適用負荷が低減されます。
  • リリース目標の明確化：主要バージョンはコミュニティ LTS リリースから 12 ヶ月以内、マイナーは各コミュニティマイナーから 3 ヶ月以内、Aurora LTS マイナーは各メジャーから 12 ヶ月以内で対応することを目標としています（詳細はリリースカレンダー参照）。
  • セキュリティ強化（新規クラスターの既定値）：TLS をデフォルトで強制（TLS 1.2 / 1.3 のみ許可）、新しいアカウントの既定認証プラグインは caching_sha2_password、パスワード検証ポリシーは DB クラスターパラメータグループでカスタマイズ可能。
  • アップグレード前チェックの自動化：自動化された事前チェックが互換性の問題を検出し、クラスターを停止する前に問題を把握できます。
  • アップグレード/移行パス：RDS Blue/Green Deployments、インプレースアップグレード、スナップショットからのリストア、外部 MySQL からの移行は AWS DMS や Percona XtraBackup を利用可能。
  • 公開リージョン：Aurora MySQL が利用可能な全リージョンで 8.4 が利用可能。
  • Aurora のその他の特徴（引き続き利用可）：スケール・トゥ・ゼロのサーバーレス、Aurora Global Database、I/O 最適化オプション、継続バックアップと組み込みセキュリティ。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、アプリケーション開発者、データベース移行担当者
  • 利用シーンまたは効果: 最新の MySQL LTS 互換性を利用した機能やセキュリティ強化の活用、既存 MySQL ワークロードの Aurora への移行・アップグレード
  • 運用効果: パッチ管理の自動化やアップグレード前チェックにより運用負荷とリスクが低減。Blue/Green を使えばダウンタイムを最小化してメジャーアップグレード可能
  • 互換性・移行影響: バージョン整合により互換性把握は容易になるが、アプリケーション側の認証方式（caching_sha2_password）やセキュリティ設定（TLS 制限）による事前検証が必要
  • 可用性/パフォーマンス: Aurora の既存機能（Global Database、I/O-Optimized 等）は引き続き利用可能。マイナー/メジャーのアップデートでクエリ挙動/パフォーマンス差が出る可能性があるため検証推奨

技術的な注意点 ​

  • IAM権限: アップグレードや Blue/Green 展開には RDS/Aurora 操作権限（rds:ModifyDBCluster, rds:CreateDBCluster, rds:Start/Stop など）が必要。DMS を使う場合は DMS の権限も確認
  • リージョン制限: Aurora MySQL が提供されている全リージョンで利用可能（ただし各リージョンでの新機能反映タイミングは異なる場合あり）
  • コスト: バージョン自体に追加料金は通常なし。ただし Blue/Green デプロイでは追加クラスター分のリソース費用、DMS を使った移行やスナップショット復元時のストレージ/データ転送コストが発生する可能性あり。パフォーマンス差によるインスタンスタイプの見直しでコスト変動がある点にも注意
  • 認証/セキュリティ: 新規クラスターは caching_sha2_password を既定とし、TLS は 1.2/1.3 のみ有効。既存クライアントの対応（ドライバ・コネクタのバージョン）を事前に確認
  • アップグレード手順: インプレースはダウンタイムを伴う可能性あり。ダウンタイム低減が必要なら Blue/Green を推奨。事前に自動アップグレード前チェックを実行して互換性問題を解消
  • 互換性チェック: アプリケーション互換性（SQL 構文、プラグイン、ストアドプロシージャ）とパフォーマンステストを本番移行前に必ず行う
  • バックアップ/ロールバック: メジャーアップグレード前にスナップショットを取得し、ロールバック手順を確立しておくこと
  • 特記事項: 自動パッチは運用を簡素化するが、パッチ適用タイミングの運用方針（自動 vs 手動）を確認・設定すること

参考情報 ​

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

Copyright © 2026