AWS What's New Digest

Appearance

2026年07月16日 ​

[Backup] AWS Backup extends logically air-gapped vault support to six additional AWS Regions ​

概要 ​

AWS Backup の論理的にエアギャップされた（logically air-gapped）ボールトが、さらに6つの AWS リージョン（台湾、マレーシア、ニュージーランド、タイ、メキシコ（セントラル）、カナダ西部（カルガリー））で利用可能になりました。イミュータブルかつ隔離されたバックアップをデフォルトでロック・暗号化して保存できます。

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

論理的エアギャップボールトは、削除や改変ができない（イミュータブル）状態でバックアップを保持するための AWS Backup の機能です。今回の拡張により、上記6リージョンでも以下の操作が可能になります：

  • ボールトへの直接バックアップ保存（immutable, locked by default）
  • AWS 管理キー（AWS owned keys）または顧客管理キー（Customer-Managed Keys, CMK）による暗号化
  • アカウント間・リージョン間でのバックアップのコピー
  • AWS Resource Access Manager (RAM) を使ったボールトの共有によるリカバリ操作
  • アカウント侵害時のアクセス保護を目的としたマルチパーティ承認（Multi-party approval）機能 利用開始は AWS Backup コンソール、AWS CLI、SDK 経由で可能です。対象リージョンや機能の対応状況、料金は公式ドキュメント／料金ページを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データ保護担当者、バックアップ管理者、セキュリティ／コンプライアンス担当者
  • 利用シーン: 規制対応（法的保持要件）、ランサムウェア対策、重要データの長期保存やクロスアカウント復旧シナリオ
  • 運用効果: イミュータブルなバックアップにより誤削除や改ざんリスクを低減し、アカウント侵害時でも復旧パスを確保できる
  • リージョン影響: 追加6リージョンで直接利用可能になり、これら地域のユーザーはデータ主権や低レイテンシ運用の恩恵を受けられる

技術的な注意点 ​

  • IAM権限: AWS Backup の操作権限に加えて、顧客管理キー（CMK）使用時は KMS 関連（kms:Encrypt/kms:Decrypt/kms:CreateGrant/kms:DescribeKey など）の権限が必要です。RAM で共有する場合は RAM の権限も確認してください。
  • リージョン制限: 今回6リージョンへ拡張されたものの、全リージョンで利用可能になったわけではありません。完全な対応リージョン一覧は公式ドキュメントで確認してください。
  • コスト: バックアップ保管料、クロスリージョンコピーやデータ転送費用、KMS の API 利用料（CMK を使用する場合）などが発生する可能性があります。料金ページで見積もりを確認してください。
  • 運用上の注意: イミュータブル／ロック設定は復元以外での削除を制限するため、意図しない長期保管やコスト増につながらないようライフサイクル設計を行ってください。
  • 導入手順: コンソール／CLI／SDK のいずれかでボールトを作成し、必要に応じて CMK の設定、RAM による共有、マルチパーティ承認設定を行ってください。
  • 互換性: 一部のバックアップソースやサードパーティ製品との連携挙動はドキュメントで確認が必要です。特にクロスアカウント復旧やコピー時のアクセス権周りに注意してください。

参考情報 ​

[Backup] AWS Backup extends restore testing support to six additional AWS Regions ​

概要 ​

AWS Backup の復元テスト機能が6つの追加リージョンで利用可能になりました。復元計画の自動実行とRTO計測により、ディザスタリカバリ（DR）／事業継続（BCP）の確認を容易にします。

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

追加リージョン：Asia Pacific (Taipei)、Asia Pacific (Malaysia)、Asia Pacific (New Zealand)、Asia Pacific (Thailand)、Mexico (Central)、Canada West (Calgary)。

機能概要：復元テストは、ストレージ、コンピュート、データベースにわたるサポート対象リソースの復元プロセスを自動化して定期実行できます。復元テストプランを作成すると、リカバリポイントの自動選択、スケジュールによる復元実行、復元ジョブ完了時間を復旧時間目標（RTO）と比較して計測することが可能です。これにより、復旧手順の有効性を定量的に評価し、規制・コンプライアンス要件や内部運用基準に対する証跡取得が容易になります。

利用開始方法：AWS Backup コンソール、AWS CLI、または AWS SDKs から設定・実行できます。サポートされるサービス／リージョンの完全な一覧や詳細な挙動（どのリソースが復元テスト対象か、復元時に作成される一時リソースの扱いなど）は公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: バックアップ／DR／BCP を担当する SRE・クラウド運用者・コンプライアンス担当者
  • 利用シーン: 定期的な復元テストの自動化（復元プラン作成、リカバリポイント自動選択、スケジュール実行、RTO との比較測定）
  • 運用効果: DR 準備状況の定量評価、復元手順の検証と改善、規制・監査向けの証跡取得が容易になり、復旧にかかる時間の可視化で運用リスクを低減

技術的な注意点 ​

  • IAM権限: AWS Backup の操作権限に加え、復元先リソース（例: EC2、RDS、EBS、EFS 等）に対する復元実行権限やロール（例: AWSBackupServiceRole 等）の設定を事前に確認してください
  • リージョン制限: 本アップデートは指定の6リージョンでの利用開始。その他リージョンや各リージョンでの個別サービス対応状況はドキュメントで確認してください
  • サポート対象リソース: 記事では「ストレージ、コンピュート、データベース」を対象としていますが、具体的なサービス（RDS、EBS、EC2、EFS、DynamoDB など）の対応はドキュメントを参照してください
  • コスト: 復元テストは一時的なリソース起動（インスタンス、ストレージ使用、スナップショット作成等）を伴うため、通常の課金が発生します。テスト頻度やターゲット設定に応じたコスト見積りを行ってください
  • 運用注意: 復元テストが本番環境へ影響を与えないように、ネットワーク設定（VPC、サブネット、セキュリティグループ）、ターゲット環境の分離、データ消去要件などを事前に確認・設計してください

参考情報 ​

[Control Tower] AWS Control Tower Account Factory for Terraform now re-applies customizations when accounts move between OUs ​

概要 ​

AWS Control Tower の Account Factory for Terraform (AFT) が、アカウントを別の OU に移動した際に自動でカスタマイズを再適用できるようになりました。これにより、手動トリガーの運用負荷と設定ドリフトのリスクを低減できます。

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

今回のリリースでは、AFT の設定で aft_customization_triggers = ["account_move"] を設定することで、組織単位（OU）間でアカウントが移動した際に自動的にカスタマイズ（グローバル／アカウントレベル）を再適用する機能が追加されました。再適用ワークフローはブートストラップ（bootstrap）やプロビジョニング工程をスキップし、グローバルおよびアカウントレベルのカスタマイズのみを実行するため高速に完了します。個別アカウント単位で自動再適用を除外したい場合は、account_skip_customization_triggers = "true" を設定して除外できます。併せて、Terraform Cloud / Enterprise のワークスペース命名に関するカスタム変数サポートの追加、AFT ロギングバケットに対するアクセス制御の強化、大規模な AWS Enterprise Support 登録に対するスケーリング改善が含まれています。利用するには AFT を最新リリースにアップグレードする必要があります。

影響範囲・利用シーン ​

  • 対象ユーザー: AWS Control Tower と Account Factory for Terraform を運用するクラウド／セキュリティ／SRE チーム
  • 利用シーン: OU ベースのコンプライアンスやセキュリティベースラインを適用している組織で、アカウント移動直後に該当 OU の設定を自動的に反映したい場合
  • 運用効果: アカウント移動時の手動オペレーション削減、設定ドリフトの低減、OU ベースの準拠状態の即時回復が可能
  • スケーラビリティ影響: 大規模組織での OU 操作自動化により AFT の Terraform 実行回数が増える可能性があるため、Terraform Cloud/TFE の実行制限や課金モデルを確認する必要あり

技術的な注意点 ​

  • 設定: aft_customization_triggers = ["account_move"] を AFT の設定に追加して有効化します
  • 個別除外: account_skip_customization_triggers = "true" を個別アカウントに設定して自動再適用を無効化可能です
  • ワークフロー挙動: 再適用は bootstrap と provisioning フェーズをスキップし、global と account レベルのカスタマイズのみ実行します（必要な場合は手動でフル実行が必要）
  • IAM権限: AFT が Organizations、Control Tower、Account、S3（ログバケット）、STS 等に対する適切な権限を持っていることを確認してください（アップグレードで権限変更がある場合があります）
  • Terraform Cloud/TFE: カスタムワークスペース命名変数のサポート追加に伴い、ワークスペース命名ルールや API トークン、実行制限を見直してください。Terraform Cloud の有料プラン利用によるコスト増の可能性あり
  • ログ/アクセス制御: AFT ロギングバケットのアクセス制御が強化されているため、既存のバケットポリシーやクロスアカウントアクセス設定の調整が必要になる場合があります
  • アップグレード: 本機能を利用するには AFT の最新リリースへアップグレードする必要があります。リリースノートで破壊的変更やマイグレーション手順を確認してください
  • リージョン制限: 本機能は AFT が提供されるすべての AWS リージョンで利用可能です（ただし組織のリージョン設定やサービス可用性は確認してください）
  • テスト推奨: 本番組織で有効化する前にステージング環境で自動再適用の影響（実行頻度、実行時間、権限、ログ出力量）を検証してください
  • コスト: AFT による追加の Terraform 実行や Terraform Cloud の利用による課金が発生する可能性があります

参考情報 ​

[General] Amazon CloudWatch Logs announces intelligent tiering for storage ​

概要 ​

Amazon CloudWatch Logsがインテリジェントストレージティアリングをサポートしました。アクセス頻度に応じてログを自動でStandard、Infrequent Access、Archive Instant Accessの3つのストレージ層に分類し、低コストで長期保持できるようになります。

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

新しいIntelligent-TieringはCloudWatch Logsの保存層を自動で管理します。CloudWatchはログへのアクセスパターンを監視し、30日間アクセスのないデータをInfrequent Accessに、90日間アクセスのないデータをArchive Instant Accessに自動的に再分類します。古いデータにアクセスするとそのデータは自動的にStandard層に昇格し、30日間Standardとして扱われます。各ティア間でのクエリ体験は同一で、ユーザーはデータをCloudWatchからエクスポートしたりフィルタして別管理する必要がなく、ネイティブに長期保持と即時検索を両立できます。設定はアカウントレベルで有効化でき、AWS Management Console、AWS SDK、AWS CLIから操作可能です。導入により多数の冗長ログや長期保持が必要なログを低コストでCloudWatchに集約でき、複数ストレージの運用負荷を削減してMTTR短縮につながります。現在、商用リージョンではほとんどで利用可能ですが、Middle East (Bahrain) と Middle East (UAE) では未対応です。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE/運用チーム、セキュリティ/監査担当、ログ分析者
  • 利用シーン: 高ボリュームで詳細なデバッグログや監査ログを長期保持する必要があるケース（例: コンプライアンス監査、フォレンジック、レトロスペクティブ分析）
  • 運用効果: 複数のストレージを管理する必要がなくなり、ログ収集から検索・アラートまでを単一ツールで完結。MTTR短縮や運用負荷低減が期待できる
  • コスト影響: ストレージコストは自動で低コスト層へ移行するため総保管コスト削減が見込める（ただしアクセスパターン次第で効果は変動）
  • 可用性/パフォーマンス: Archive Instant Accessは即時アクセスを目的としているためクエリの復旧待ち時間は発生しにくい（標準のクエリ体験を維持）

技術的な注意点 ​

  • IAM権限: アカウントレベルのCloudWatch Logs設定を変更できる権限が必要。コンソール/SDK/CLIでの有効化操作を許可するポリシーを準備してください（CloudWatch Logsの管理操作権限）
  • リージョン制限: 全ての商用リージョンで利用可能（例外: Middle East (Bahrain) と Middle East (UAE) では未対応）
  • コスト: ストレージ階層ごとに料金が異なります。長期保持によるストレージ費削減が期待できる一方で、アクセス頻度が高いデータは頻繁に昇格してコスト効果が薄れる可能性があります。料金ページで試算してください
  • 有効化方法: アカウントレベルで有効化（AWS Management Console / AWS SDKs / AWS CLI）— ロググループ個別での設定可否は現在の仕様を確認してください
  • コンプライアンス/保持ポリシー: 規制や監査要件に基づく保持ポリシーと整合性が取れるか確認してください。自動移行による保存場所の変化が要件に影響しないか検討が必要です
  • データアクセス/復元: Archive Instant Accessは即時クエリ可能を目的としていますが、アクセス時の挙動（プロモーション期間30日など）を理解した上で運用設計してください
  • ログライフサイクル: 既存の保持期間設定やエクスポート/転送ワークフローとの重複や影響を事前に確認してください

参考情報 ​

[Mq] Amazon MQ now supports configurable storage for RabbitMQ brokers ​

概要 ​

Amazon MQ for RabbitMQのブローカーに対して、インスタンスタイプと独立してEBSディスク容量を指定できるようになりました。M7gクラスター（RabbitMQ 4.2以降）で、用途に応じた容量を5GB刻みで設定できます。

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

これまではブローカーのストレージサイズがインスタンスサイズに依存していたのに対し、今回のアップデートにより、RabbitMQ M7gブローカー（バージョン4.2以降、クラスタデプロイのみ）でEBSディスクのサイズをインスタンスと切り離して指定できるようになりました。指定可能な容量は、M7gのデフォルト値からインスタンスサイズに応じた最大値までで、5GB刻みで設定可能です。Storage Sizeは AWS コンソール、AWS CLI、AWS CloudFormation、または AWS CDK を使って新規作成時または更新時に指定でき、設定は次回ブローカーの再起動時に適用されます。ストレージ料金は標準の Amazon MQ ストレージ課金が適用されます。機能は Amazon MQ for RabbitMQ を提供している全ての商用リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: RabbitMQを運用するクラウドエンジニア、SRE、メッセージングワークロードのコスト／性能最適化を行うチーム
  • 利用シーン: 高スループットや大規模メッセージ保持が必要なワークロードで、ストレージを増やしてメッセージ保持量やパフォーマンスバッファを確保する場面。逆に小規模ワークロードでインスタンスを変えずにストレージを抑えてコスト最適化する場面。
  • 運用効果: ストレージとインスタンスサイズを独立して調整できるため、コストの最適化およびワークロードに合わせたRight-sizeが可能。再起動で適用されるため、メンテナンス計画を立てればダウンタイムを最小化できる。

技術的な注意点 ​

  • 対応条件: RabbitMQ M7g ブローカー、バージョン4.2以降、クラスタデプロイメントのみ対応
  • 適用タイミング: ストレージ変更は次回ブローカー再起動時に反映されます。再起動によるサービス影響を考慮してメンテナンスウィンドウで実施してください
  • 容量指定: M7gのデフォルト値からインスタンスサイズに応じた最大値まで、5GB刻みで指定可能。具体的な最大値はインスタンスサイズに依存するためドキュメントで確認してください
  • 縮小/拡張の注意: EBSの特性やAmazon MQの実装により容量の縮小制限や手順がある場合があります。運用前に公式ドキュメントで縮小可否や手順を確認してください
  • 課金: 指定したディスクサイズに基づき、標準のAmazon MQストレージ料金が発生します。コスト影響を事前に見積もってください
  • IAM権限: ブローカー作成・更新に必要なAmazon MQ関連の権限（例: CreateBroker/UpdateBroker等）を付与してください。CloudFormation/CDK/CLIから操作する場合はそれらを実行するロール/ユーザーに同等の権限が必要です
  • リージョン制限: Amazon MQ for RabbitMQ を提供している商用リージョンでは利用可能ですが、利用前に対象リージョンのサポート状況を確認してください
  • その他リソース制限: EBSやアカウントのボリューム/容量クォータ、インスタンスのI/O性能（EBS最適化やスループット）を確認し、必要に応じてEBS/EC2クォータの引き上げを行ってください

参考情報 ​

[Ec2] Amazon EC2 G7e instances now available in additional regions ​

概要 ​

Amazon EC2の新しいG7eインスタンス（NVIDIA RTX PRO 6000 Blackwell Server Edition搭載）が、追加リージョン（欧州フランクフルト・ストックホルム、アジア太平洋ムンバイ）で利用可能になりました。G6e比で最大2.3倍の推論性能を提供し、大規模モデルやグラフィックス+AIを必要とするワークロード向けの高性能GPUインスタンスです。

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

G7eインスタンスはNVIDIA RTX PRO 6000 Blackwell Server Edition GPUを最大8基搭載し、各GPUあたり96GBのメモリを備えます。CPUは第5世代Intel Xeonで、最大192 vCPU、ネットワーク帯域は最大1600 Gbpsに対応します。G7eはG6eに比べて推論性能が最大2.3倍（記事による）で、LLM（大規模言語モデル）、エージェント型AI、マルチモーダル生成AI、物理シミュレーション系AI、空間コンピューティングやグラフィックスとAIを組み合わせるワークロードに最適化されています。マルチGPU環境向けにNVIDIA GPUDirect Peer to Peer (P2P) をサポートし、複数GPU間の通信を高速化します。さらに、マルチGPUのG7eインスタンスはEFAを用いたNVIDIA GPUDirect RDMAをEC2 UltraClustersでサポートし、小規模マルチノード構成のレイテンシ削減とスループット改善が可能です。購入形態はオンデマンド、スポット、Savings Plansに対応。利用はAWS Management Console、CLI、SDKから開始できます。利用可能リージョンは米国西部（オレゴン）、米国東部（バージニア北部、オハイオ）、欧州（スペイン、ロンドン、フランクフルト、ストックホルム）、アジア太平洋（東京、ソウル、ムンバイ）です。

影響範囲・利用シーン ​

  • 対象ユーザー: 機械学習エンジニア、AIリサーチャー、グラフィックス/空間コンピューティング開発者、HPC担当者
  • 利用シーン: LLMのトレーニング/推論、マルチモーダル生成モデルの推論・デプロイ、リアルタイムエージェント/ロボティクス制御、3Dレンダリング＋AI処理の同時実行
  • 運用効果: 推論性能の向上（G6e比最大2.3x）によりレイテンシ低減やスループット増加が期待でき、GPUDirectやEFA利用でマルチGPU／マルチノード性能が改善されるため、より大規模・分散型ワークロードの効率化が可能

技術的な注意点 ​

  • リージョン制限: 追加でフランクフルト（eu-central-1）、ストックホルム（eu-north-1）、ムンバイ（ap-south-1）で利用可能。全リージョンでの展開状況は変動するため都度確認してください
  • ドライバ/ソフトウェア: 最新のNVIDIAドライバ、CUDA、cuDNN等の互換性確認が必要。Blackwell世代GPUの特性に合わせたソフトウェア最適化を推奨します
  • EFA/GPUDirect: マルチノードで低レイテンシを得るにはEFA対応構成（EC2 UltraClusters）が必要。EFA利用時は対応AMI・カーネル・ドライバ要件を満たす必要があります
  • インスタンスタイプ/クォータ: G7eの特定サイズや数のクォータ制限があるため、事前にサービスクォータの確認と引き上げ申請を検討してください
  • コスト: 大容量GPUインスタンスのため時間あたりコストは高め。スポットやSavings Plansの活用でコスト最適化可能ですが、スポットは中断リスクに注意が必要です
  • IAM権限: EC2の起動、EFAやVPC関連リソース作成権限など、必要なIAMポリシーを事前に確認してください
  • ネットワーク/帯域: 最大1600 Gbpsの高帯域を活かすため、ENI・VPC設定やアプリケーション層のネットワーク設計を検討してください
  • 制約（注意）: 記事で言及のない細かな仕様（インスタンスサイズの命名、AMIの推奨イメージ、GPUのMIGサポート可否など）は公式インスタンスページ／ドキュメントで確認してください

参考情報 ​

[RDS] Amazon RDS and Aurora now support R8g and M8g database instances in additional AWS Regions ​

概要 ​

Amazon RDS と Amazon Aurora が AWS Graviton4（R8g）および M8g インスタンスタイプのサポートを追加リージョンで拡張しました。これにより、より多くのリージョンで高い vCPU 数と DDR5 メモリ、改善されたネットワーク／EBS 帯域を利用でき、Graviton3 比で性能と価格性能が向上します。

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

R8g（AWS Graviton4）と M8g のサポート拡張に関する主な技術的内容:

  • R8g（Graviton4）: Amazon Aurora（MySQL/PostgreSQL 互換）および Amazon RDS for PostgreSQL、MySQL、MariaDB に対して Asia Pacific（Hyderabad, Melbourne, Malaysia）、Europe（London, Paris, Zurich）、AWS GovCloud (US‑East)、South America（Sao Paulo）、Mexico（Central）で一般利用開始（GA）。
  • M8g: Amazon RDS for PostgreSQL、MySQL、MariaDB に対して US West (N. California)、Asia Pacific（Mumbai, Sydney, Hong Kong, Seoul, Malaysia, Singapore）、Canada West (Calgary)、Europe（Zurich, Milan, Paris）、South America（Sao Paulo）、Africa（Cape Town）でサポート追加。
  • 性能／コスト: Graviton4 ベースのインスタンスは Graviton3 相当サイズと比べて最大で約40% の性能向上、オンデマンド価格で最大約29% の価格性能改善を提供（実際の改善はデータベースエンジン・バージョン・ワークロードに依存）。
  • インスタンス仕様（R8g の注目点）: 新たに 24xlarge と 48xlarge サイズを提供（最大 192 vCPU）、メモリ対 vCPU 比率は 8:1、最新の DDR5 メモリ搭載、強化ネットワーク帯域は最大 50 Gbps、EBS 帯域は最大 40 Gbps。Nitro システム上で動作。
  • 利用方法: Amazon RDS Management Console または AWS CLI から起動可能。各データベースエンジン・バージョンでの対応状況や料金は公式ドキュメントと料金ページを参照すること。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、クラウドアーキテクト、性能重視のアプリケーション開発者
  • 利用シーンまたは効果: CPU集約型ワークロード（分析処理、バッチ処理、並列クエリ）、メモリ集約型のキャッシュ／インメモリ処理、大規模な OLTP システムのスケールアップ、クラスタ統合によるコスト削減
  • 運用効果: 同一負荷での応答改善やインスタンス集約によるコスト削減、より大きな単一インスタンス（192 vCPU）による垂直スケーリングが容易に可能
  • 移行影響: 既存の Graviton3/別アーキテクチャからの変更では互換性確認と再ベンチマークが必要（エンジン/バージョンごとの挙動差に注意）

技術的な注意点 ​

  • IAM権限: インスタンス作成・変更には RDS の作成／修正権限が必要（Console/CLI の利用権限を事前に確認してください）
  • リージョン制限: 本発表は特定の追加リージョン向けであり、全リージョンで利用可能ではありません。利用前にリージョンごとのサポート状況を確認してください
  • コスト: インスタンスタイプ変更は料金に直接影響します。料金差や Reserved/Spot の有無を RDS 料金ページで確認してください
  • エンジン互換性: 全てのデータベースエンジン／バージョンで即サポートされるわけではありません。対象エンジン・バージョンは Aurora/RDS の各ドキュメントで確認してください
  • インスタンス変更時のダウンタイム: インスタンスタイプ変更は再起動が伴います。Single‑AZ だとダウンタイム、Multi‑AZ はフェイルオーバーで短い影響となります。メンテナンスウィンドウやアプリケーションのリトライ設計を検討してください
  • パフォーマンス差の注意: 記載の "最大40%" や "最大29%" はベンチマーク条件に依存します。実運用ではワークロード特性（I/O パターン、クエリ特性、接続数）による差異を事前検証してください
  • ストレージ/ネットワーク: R8g の強化されたネットワーク／EBS 帯域を活かすには、EBS ボリュームの種類や IOPS/スループット設定の見直しが必要な場合があります
  • 操作方法: Console/CLI から起動・変更可能。自動スケーリング（Aurora のオートスケールや RDS のオートメーション）との整合性を確認してください

参考情報 ​

[Aurora] Amazon RDS and Aurora expand R8gd and M8gd to additional Regions ​

概要 ​

Amazon RDS/AuroraでR8gdおよびM8gdインスタンスタイプが追加リージョンで利用可能になり、ローカルNVMeベースのストレージを使った「Optimized Reads」によって複雑なクエリやインデックス再構築のレイテンシが改善されます。Aurora PostgreSQLでは最大165%のスループット向上、最大120%の価格性能改善が見込まれます。

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

今回の拡張では、R8gdインスタンスが12リージョン、M8gdインスタンスが6リージョンで利用可能になりました。これらのインスタンスはローカルNVMeベースのSSDを用いて一時的なデータ（テンポラリテーブルや一時ファイル）とキャッシュの拡張領域を格納する「Optimized Reads」機能を提供します。Optimized Readsによりネットワーク越しのストレージアクセス（共有ブロックストレージ）を削減し、クエリレイテンシの低減、複雑クエリや並列処理、インデックス再構築の高速化が期待できます。特にAurora PostgreSQLの評価では、R8gd/M8gdがR6g比で最大165%のスループット改善および最大120%の価格性能改善を報告しています。

対応エンジン: Optimized ReadsはAmazon Aurora PostgreSQL、RDS for PostgreSQL、RDS for MySQL、RDS for MariaDBで利用可能です。Aurora PostgreSQLのI/O-Optimized構成では、メモリバッファキャッシュから追い出されたデータページをローカルNVMeにキャッシュすることで、後続の読み取りを高速化します。

導入方法: 既存のAurora/RDSインスタンスを変更（インスタンスタイプ変更）するか、新規にR8gd/M8gdインスタンスで作成することで有効化できます。管理コンソール、AWS CLI、SDKいずれからも操作可能です。

リージョン（今回追加された領域）:

  • R8gd: Europe (Ireland), Asia Pacific (Seoul), Asia Pacific (Malaysia), Europe (London), US West (N. California), Asia Pacific (Sydney), Canada (Central), Asia Pacific (Jakarta), Africa (Cape Town), Canada West (Calgary), South America (Sao Paulo), Asia Pacific (Hong Kong)
  • M8gd: Europe (Ireland), Asia Pacific (Malaysia), Europe (London), Asia Pacific (Sydney), South America (Sao Paulo), Canada (Central)

価格・対応バージョン: 料金や利用可能なエンジンバージョンは別途料金ページおよびAurora/RDSドキュメントで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、DBA、SRE、アプリケーション開発者
  • 利用シーンまたは効果: 複雑な分析クエリ、高スループットを要するOLTP/OLAP混在ワークロード、インデックス再構築や大量の一時テーブルを使用するバッチ処理でのクエリ遅延低減
  • 運用効果: ネットワークストレージアクセスを減らすことでクエリ応答時間が短縮され、インデックス作成/再構築の時間が短縮。コスト対効果の改善によりインスタンスサイズ見直しの余地が生まれる

技術的な注意点 ​

  • IAM権限: DBインスタンスの変更や作成には適切なRDS/AuroraのIAM権限が必要です（rds:ModifyDBInstance等）。
  • リージョン制限: 本発表は特定の追加リージョンへの拡張を示しており、全リージョンで未対応の可能性があります。利用前に対象リージョンでの提供状況を確認してください。
  • コスト: R8gd/M8gdは新しいインスタンスタイプで料金が異なります。Optimized Readsの利用はインスタンスタイプ選定に伴う追加コストの影響を受けるため、料金ページで確認してください。
  • エンジン互換性: インスタンスタイプの利用可否はDBエンジンとそのバージョンに依存します。事前にAuroraおよびRDSのドキュメントでサポートされるエンジン/バージョンを確認してください。
  • データ永続性: ローカルNVMeはエフェメラル（揮発的）ストレージであり、インスタンス停止・終了や障害時にはその内容は維持されません。Optimized Readsで格納されるのは一時データやキャッシュであり、永続データ（データベースの恒久的なファイル）は引き続きネットワークストレージに保持されます。
  • フェイルオーバー/リカバリ: ローカルキャッシュはインスタンス固有のためフェイルオーバー後は再構築されます。フェイルオーバー影響を評価し、必要に応じて運用手順を見直してください。
  • 事前検証: 本番導入前にステージング環境でワークロードを再現したベンチマーク（クエリパフォーマンス、キャッシュヒット率、フェイルオーバー挙動）を行ってください。

参考情報 ​

[Cognito] Amazon Cognito now supports importing users with password hashes ​

概要 ​

Amazon CognitoがCSVによるユーザーインポートでパスワードハッシュの取り込みをサポートしました。これにより、ユーザーをインポートした際に初回サインインでパスワードリセットを強制せず、既存の認証情報で即時ログインできるようになります。

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

CSVインポート時に、ソースシステムで生成したパスワードハッシュをCSVに含めてアップロードできるようになりました。インポート作成時にソースで用いたハッシュアルゴリズム（bcrypt、scrypt、Argon2id、PBKDF2 with SHA-256のいずれか）を指定します。ユーザーが初回サインインする際、Cognitoは入力されたパスワードを指定されたアルゴリズムでハッシュ化してインポート済みハッシュと照合し、認証を行います。インポートされたハッシュはCognito側に保存する前に追加の暗号保護（再ハッシュ化または暗号化）を受けます。操作はAWS Management Console、AWS CLI、またはAWS SDKから行えます。インポート処理は通常、CSVファイルのS3アップロード→ユーザーインポートジョブ作成→ジョブ開始、という流れで実行します。詳細なCSVのカラム仕様、ハッシュのフォーマットや必要なパラメータ（ソルト等）は開発者ガイドを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ID/認証移行を行うクラウドエンジニア、セキュリティ/運用担当者、SaaSプロダクトの運営者
  • 利用シーン: 既存ユーザーデータベースからAmazon Cognitoへユーザーを移行する際に、ユーザーにパスワードリセットを要請せずに既存パスワードでの即時ログインを実現
  • 運用効果: ユーザー体験を損なわずに移行可能。パスワードリセット対応コストやサポート問い合わせを削減可能
  • 移行シナリオ: レガシー認証システム（bcrypt/scrypt/Argon2id/PBKDF2を使用）からの段階的移行や一括移行に有用
  • セキュリティ影響: 生のパスワードを保持せずハッシュを移行することでリスク低減。ただしハッシュの取り扱い（S3アップロードやログ）には注意が必要

技術的な注意点 ​

  • IAM権限: ユーザーインポート操作には cognito-idp のインポート関連権限（例: CreateUserImportJob, StartUserImportJob, DescribeUserImportJob, StopUserImportJob 等）や、S3へのアップロード権限（s3:PutObject/GetObject）、ジョブで使用するロールに対する iam:PassRole が必要です。具体的な最小権限は導入前に確認してください。
  • リージョン制限: 記事発表時点では『Amazon Cognito が利用可能な全リージョン』でサポートされていますが、利用前にコンソールで対象リージョンのサポート状況を確認してください。
  • コスト: パスワードハッシュインポート自体に特別な追加料金は発表されていませんが、S3保存・データ転送・Cognitoの通常の利用コスト（MAUsなど）は発生します。インポート大規模実行時はS3/APIリクエストコストを見積もってください。
  • CSV/ハッシュ形式: CSVのカラム名、エンコーディング、ハッシュおよびソルトのフォーマット要件は開発者ガイドに従ってください。サポート外のハッシュ形式やパラメータ不整合があると認証失敗となり、結果的にパスワードリセットが必要になります。
  • セキュリティ運用: ハッシュを含むCSVは機密データです。S3のバケットポリシー、暗号化（SSE）、アクセスログ管理、短期間での削除等、取り扱いとオンプレミス側での同意取得／コンプライアンスを確認してください。
  • 検証推奨: 本番適用前に非本番環境で少数ユーザーを用いて、指定アルゴリズム・パラメータで認証フローが期待通り動作するか検証してください。

参考情報 ​

[Msk] Amazon MSK Express Brokers adds support for Apache Kafka version 4.2 ​

概要 ​

Amazon MSK Express BrokersがApache Kafka 4.2をサポートしました。ELR（Eligible Leader Replicas）や新しいリバランスプロトコルなど、可用性と再配置性能の改善が含まれます。

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

MSK Express BrokersでApache Kafka 4.2が利用可能になりました。主な技術的改善点は以下の通りです：

  • ELR（Eligible Leader Replicas）強化：リーダー選出の正確性が向上し、パーティションの可用性が高まります（フェイルオーバー時の安定性改善）。
  • 新しいコンシューマリバランスプロトコル：コンシューマグループのリバランスがよりスムーズかつ高速に行われ、再均衡による処理停止時間やスループット低下を低減します。
  • Streams Rebalance Protocol：Kafka Streams向けにブローカー側の協調機能を拡張し、タスク割り当ての最適化と再配置の効率化を実現します。 また、MSK Express Brokers自体は設計上、従来よりブローカーあたり最大3倍のスループット、最大20倍のスケールアップ速度、リカバリ時間の90%短縮を目指すアーキテクチャを持ち、4.2のオープンソース由来の信頼性／性能改善が取り込まれています。新規クラスター作成時にバージョン4.2.xを選択するか、既存Express Brokersをインプレースのローリングアップデートで4.2へ移行できます。アップグレード時はMSKがブローカー再起動をオーケストレーションして可用性維持とデータ保護を行います。詳細な改良点・不具合修正はApache Kafka 4.2のリリースノートを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafkaを利用するアプリケーション開発者、データエンジニア、SRE／運用チーム
  • 利用シーンまたは効果: 高可用性が求められるメッセージング基盤、低レイテンシ／高スループットが必要なストリーム処理、Kafka Streamsを使った状態管理タスクの安定化
  • 運用効果: リーダー選出と再配置の改善によりフェイルオーバー影響が減少し、グループ再均衡時間の短縮でスループット維持が容易に
  • 移行効果: 新しいリバランス／Streamsプロトコルを活用することでスケーリングやアップデート時のサービス中断を抑制できる

技術的な注意点 ​

  • IAM権限: クラスター作成・アップグレードにはMSK関連のIAM権限（CreateCluster/UpdateCluster等）が必要です。ロールやポリシーを事前確認してください
  • リージョン制限: MSK Express Brokersが提供されている全リージョンで4.2は利用可能とされていますが、利用前に対象リージョンでのExpressオプション提供状況を確認してください
  • クライアント互換性: クライアントライブラリ（プロデューサ/コンシューマ/Kafka Streams）の互換性を確認してください。新しいリバランスやStreams Rebalanceの恩恵を受けるにはクライアント側の対応（ライブラリアップデートや設定変更）が必要な場合があります
  • アップグレード方法: 新規作成時はバージョン4.2.xを選択、既存クラスターはインプレースのローリングアップデートで移行可能。MSKがブローカー再起動をオーケストレーションしますが、アップグレード前にステージングで検証を推奨します
  • ダウンタイムと可用性: MSKのローリングアップデートは可用性維持を目的としますが、構成（ブローカー数・レプリケーション設定）によっては短時間の影響が出る可能性があります
  • コスト: バージョン変更自体に直接課金は発生しませんが、パフォーマンス向上によりスケール設計を見直すとインスタンス使用量やストレージ構成が変わりコストに影響する可能性があります
  • テスト/検証: 本番移行前に互換性テスト（プロデューサ/コンシューマ、Streamsアプリ、リバランス挙動）を実施してください
  • 特記事項: Apache Kafka 4.2の詳細な変更点・互換性情報は公式リリースノートで確認してください

参考情報 ​

[RDS] Amazon RDS now supports up to four storage modifications in 24 hours ​

概要 ​

Amazon RDSは、データベースインスタンスあたりロールイング24時間ウィンドウで最大4回までストレージ変更を実行できるようになりました。これにより、容量拡張やストレージタイプ／パフォーマンス調整をより短期間で柔軟に行えます。

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

今回の変更により、RDSインスタンスのストレージに対して「サイズの増加」「ストレージタイプの変更」「パフォーマンス（例: IOPS等）の調整」をロールイングの24時間間隔で最大4回まで行えるようになりました。各変更は“ストレージ最適化（storage optimization）”の完了後に次の変更を直ちに開始可能で、従来の6時間のクールオフ待機を待つ必要がなくなります。ストレージ変更自体はダウンタイムなし（オンライン）で適用され、アプリケーションは稼働を継続しながら容量や性能を拡張できます。ただし、最適化処理中はバックグラウンドI/Oが発生するため一時的な性能影響が出ることがあります。本機能は Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server の各エンジンで、全ての商用リージョンおよび AWS GovCloud (US) リージョンに自動有効化されています（Amazon Auroraは対象外）。

影響範囲・利用シーン ​

  • 対象ユーザー: RDSを利用するクラウドエンジニア、DBA、SRE、アプリケーション開発チーム
  • 利用シーンまたは効果: 突発的なデータ増加やワークロード急増時の即時容量拡張やIOPS増強により、サービスの継続性を保ちながらスケール対応できる
  • 運用効果: 従来の6時間待機が不要になり、短時間で複数回のストレージ調整が可能になることで運用対応力（アジリティ）が向上する

技術的な注意点 ​

  • IAM権限: rds:ModifyDBInstance などのストレージ変更を行う権限が必要です。Describe系権限（rds:DescribeDBInstances 等）もあると便利です
  • リージョン制限: 本機能は全ての商用リージョンおよび AWS GovCloud (US) に自動有効化。Amazon Aurora は対象外です
  • コスト: ストレージ容量の増加や高性能ストレージ（例: プロビジョンドIOPS）への変更は追加料金が発生します。請求はプロレートされる可能性があるため変更前に料金影響を確認してください
  • 変更回数制限: ローリング24時間ウィンドウで最大4回まで。上限を超える変更リクエストは拒否されます
  • 可用性・パフォーマンス: 変更はオンラインでダウンタイムを伴わない設計ですが、ストレージ最適化中はバックグラウンドI/Oが増え、一時的なレイテンシやスループット低下が発生する可能性があります
  • Multi-AZ挙動: Multi-AZ構成ではプライマリ／スタンバイ双方に適用されるため、適用順序や所要時間が単一AZと異なる場合があります
  • その他: 自動有効化済みのため特別な設定は不要。運用ポリシーとして24時間あたりの変更回数を考慮した計画を推奨します

参考情報 ​

[Glue] AWS Glue SAP OData connector and zero-ETL integrations are now available in AWS GovCloud (US) regions ​

概要 ​

AWS GlueのSAP ODataコネクタとZero‑ETL統合がAWS GovCloud (US‑West／US‑East)で利用可能になりました。DynamoDB、Salesforce、SAP ODataをソースに、Amazon RedshiftやAmazon S3などへ自動的にデータを複製できます。

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

今回のリリースにより、規制環境向けのAWS GovCloudリージョンでもGlueのSAP ODataコネクタとZero‑ETL統合が利用可能になりました。主なポイントは次の通りです：

  • サポートソース：Amazon DynamoDB、Salesforce、SAP OData（ODataサービスを公開するSAPシステムからデータ抽出）。
  • 対応先（例）：Amazon Redshift、Amazon S3、その他Glueがサポートするデスティネーション。
  • Zero‑ETLの特徴：AWSがフルマネージドでデータ取り込みを実行し、ノーコードのコンソール操作で初期ロードとその後の継続的な同期（最新レプリカの維持）が可能。カスタムETLパイプラインやミドルウェアを構築する必要を削減します。
  • SAP ODataコネクタの役割：SAPが公開するODataエンドポイントからスキーマとデータを抽出し、抽出ロジックや専用ミドルウェアの導入を不要にします。認証情報や接続先のAPI制限、ネットワーク経路さえ整えれば利用可能です。
  • 運用面：数クリックの設定で取り込みを開始でき、データレイク／データウェアハウスに継続的に最新データを取り込めるため、データサイロ解消や分析開始のリードタイムを短縮します。 利用開始はGlueコンソールから「新しいZero‑ETL統合」を作成してください。詳細はGlueのZero‑ETLドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 規制環境（米国政府向け等）のクラウド利用者、データエンジニア、SRE/運用チーム、BI/アナリティクスチーム
  • 利用シーン: DynamoDBやSalesforce、SAP（OData）からデータレイク（S3）やデータウェアハウス（Redshift）へ継続的にデータをレプリケートして分析基盤を構築・維持するケース
  • 運用効果: カスタムETLの設計・構築・保守工数を大幅に削減し、数週間単位の開発工数を節約。データの最新性を保ちながら、分析やレポート作成への着手を迅速化可能

技術的な注意点 ​

  • IAM権限: Glueコンソール操作用・GlueサービスロールにS3、Redshift、DynamoDBへのアクセス権限やSecretsManagerへのアクセスなど必要な権限を付与する必要があります
  • リージョン制限: 対象はAWS GovCloud (US‑West)およびAWS GovCloud (US‑East)での提供です。他リージョンでは利用可否を確認してください
  • ネットワーク/接続要件: SAPやSalesforceがオンプレ／プライベートネットワークにある場合はVPN/Direct Connectやプロキシ経由の接続設定が必要になることがあります。DynamoDBやS3へはVPCエンドポイントを利用することでインターネット経由を回避できます
  • 認証とシークレット管理: SAP ODataやSalesforce接続には認証情報（ユーザー/パスワード、OAuthトークン等）が必要です。AWS Secrets Managerなどで安全に管理してください
  • データ整合性とレイテンシ: Zero‑ETLは初期ロードとその後の継続的同期を提供しますが、レイテンシ要件や整合性（最終的整合性／順序保証など）は利用ケースで検証が必要です
  • スキーマ/変換の制約: Zero‑ETLは主にコピー/レプリケーションを目的としているため、複雑なデータ変換やビジネスロジックはGlue ETLジョブや別途の処理で実施する必要があります
  • コスト: Glueの使用料、データ転送（インターネット経由・クロスAZ/リージョン転送）、S3/Redshiftのストレージやクエリコストが発生します。利用規模に応じたコスト試算が必要です
  • サービス制限/スループット: ソースAPI（Salesforce、SAP OData等）のレート制限やDynamoDBの読み取りプロビジョニングに注意してください
  • コンプライアンス: GovCloudリージョンは特定の規制対応向けですが、組織のコンプライアンス要件（ログ保管、アクセス制御等）は別途確認してください

参考情報 ​

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

Copyright © 2026