AWS What's New Digest

Appearance

2026年06月09日 ​

[Bedrock] AWS announces Claude Fable 5, the first generally available Mythos-class model ​

概要 ​

AWSでClaude Fable 5（Mythosクラスの安全対策付きモデル）が一般提供（GA）になりました。高度な長時間の知識作業やコーディング自動化に強く、企業向けの運用を想定した安全機能を備えています。

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

Claude Fable 5はMythosレベルの性能を持ちながら、安全性を高めるための分類器（safety classifiers）やガードレールを組み込んだ形でAWS上で一般提供されます。ベンチマークでは最先端の性能を示し、長時間にわたる複雑な知識作業や自律的なコーディングタスクを介入なしで継続実行できる点が特徴です。モデルはプロフェッショナル用途（金融、法務、マーケティング、セールス、データ、エンジニアリング等）を想定しており、自ら評価ハーネスを作成したり、学習に基づくスキルの自己更新、作業結果の検証を行ってから出力するなど、より高い自律性と信頼性を目指しています。

AWS上での利用方法は2つあります。1) Amazon Bedrock経由：AWSインフラ内にデータを保持し、Bedrockの統合サービスとしてClaude Fable 5へアクセス可能。BedrockはAWS管理のGuardrails、Knowledge Bases、リージョンごとのデータ居住性（data residency）などの機能を提供します。2) Claude Platform on AWS（Anthropic運用）：Anthropicのネイティブプラットフォーム体験を維持しつつ、AWSの請求・認証と統合して利用できます。

注意点として、同じ基礎モデルから安全分類器を外した「Claude Mythos 5」は、現在Mythosプレビューアクセスを持つ限定的な顧客向けに提供されています。Fable 5はより広範な顧客向けに安全策を組み込んでGA提供されたモデルです。

影響範囲・利用シーン ​

  • 対象ユーザー: AIを本番運用する企業のSRE/MLプラットフォームチーム、アプリケーション開発者、データサイエンティスト、ドメイン専門家（金融・法務など）
  • 利用シーン: 長時間におよぶ知識検索・整理、複雑なコーディング自動化、ドメイン固有のレポート作成やレビュー、プロセス自動化ワークフローの実行
  • 運用効果: 人手による中間チェックを減らし、より複雑なタスクの自動化が可能になるため開発速度と業務効率が向上。Bedrock経由ではAWS管理のガードレールとデータ居住性でコンプライアンス要件との親和性が高まる
  • 制限事項: Mythos（安全分類器なし）のフル性能を必要とするケースは現状限定的なアクセスに留まり、追加の審査や契約が必要になる可能性がある

技術的な注意点 ​

  • IAM権限: Amazon BedrockやClaude Platformへのアクセスには該当するIAMロール/ポリシーが必要。Bedrock APIや関連サービス（Secrets Manager、S3等）へのアクセス権を事前に用意してください
  • リージョン制限: Claude Fable 5の提供はリージョンごとに異なります。利用前にBedrockの地域対応状況を確認してください
  • コスト: 大規模・長時間の実行を想定したモデルのため、推論コスト（時間/トークン課金）や関連ストレージ・ログ取得のコスト増が見込まれます。BedrockとClaude Platformで課金体系が異なることがあります
  • データ取り扱い・プライバシー: Bedrock経由はAWSインフラ内で処理され、データ居住性制御が可能。Claude Platform（Anthropic運用）を利用する場合はAnthropicのデータ取り扱いとAWS側の認証・請求の挙動を確認してください
  • モデル差分: Claude Fable 5は安全分類器を含むGA向けモデル。安全分類器を除いたClaude Mythos 5は限定顧客向けで、アクセスには追加条件が存在します
  • 運用上の注意: 長時間自律実行タスクはチェックポイント設計、タイムアウト／リトライ戦略、出力検証の仕組みを組み込むことを推奨します

参考情報 ​

[Backup] AWS Backup support for Amazon EKS is now available in the AWS European Sovereign Cloud (Germany) Region ​

概要 ​

AWS Backup が Amazon EKS の保護を AWS European Sovereign Cloud (Germany) リージョンでサポート開始しました。ポリシーベースの自動バックアップ、保持管理、イミュータブルボールト、クロスリージョン／クロスアカウント複製などが利用可能になります。

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

本拡張により、AWS Backup を使って当該ドイツ主権クラウド内の Amazon EKS クラスター全体、特定の namespace、あるいは個別の永続ボリューム（PV）を中央管理されたエージェント不要の方法で保護できます。主な機能は以下のとおりです。

  • ポリシーベースでのバックアッププラン作成（スケジュール、保持期間の管理、ライフサイクル）
  • イミュータブル（改変不可）バックアップボールトの利用による改ざん耐性
  • クロスリージョン／クロスアカウントコピーにより災害対策や分離された保管が可能
  • エージェント不要で Kubernetes API と連携し、クラスターのリソース定義（マニフェスト）と永続ボリュームのスナップショットを取得
  • 既存のカスタムスクリプトやサードパーティ製ツールの代替として中央管理を実現 また、復旧はクラスター単位、namespace単位、PV単位で行え、クラスターアップグレード前のスナップショット取得やコンプライアンス要件への対応に適しています。

影響範囲・利用シーン ​

  • 対象ユーザー: EKS を運用するクラウドエンジニア、SRE、プラットフォームチーム、コンプライアンス担当者
  • 利用シーン: クラスター全体の DR 対策、特定 namespace の定期バックアップ、永続ボリューム（データベース等）のスナップショット取得、クラスターアップグレード前の保護
  • 運用効果: バックアップの自動化と中央管理により運用作業を簡素化し、復旧時間短縮、コンプライアンス遵守やデータ改ざん対策（イミュータブルボールト）を実現

技術的な注意点 ​

  • IAM権限: AWS Backup の操作と EKS リソースアクセスに必要な IAM ロール／ポリシーを設定してください（バックアップ用サービスロール、KMS キーアクセス等）。
  • CSI/ストレージ要件: 永続ボリュームのスナップショットはストレージプラグイン（CSI スナップショットなど）のサポートに依存します。利用中のストレージクラス/ドライバがスナップショットをサポートしていることを確認してください。
  • KMS/暗号化: バックアップの暗号化やイミュータブルボールト利用時は KMS キーのキー ポリシーとアクセス権を適切に設定する必要があります。
  • リージョン制限: 本機能は AWS European Sovereign Cloud (Germany) リージョンで新たに利用可能になったもので、他リージョンの展開状況は別途確認してください。
  • クロスリージョン／クロスアカウント: 複製先リージョン/アカウントでも AWS Backup を有効化し、必要な権限設定と KMS キー準備が必要です。
  • コスト: バックアップ保存（スナップショットストレージ）、クロスリージョン転送、復元時のリソース再作成などに対する追加コストが発生します。料金体系を事前に確認してください。
  • 互換性／復元注意: 復元先クラスターでは同等の CSI ドライバやストレージクラスが必要になる場合があります。リストア手順と依存関係（ストレージドライバ、Kubernetes バージョン等）を事前に検証してください。

参考情報 ​

[Emr] Run Interactive Workloads on Amazon EMR Serverless with Spark Connect ​

概要 ​

Amazon EMR ServerlessがSpark Connectを使ったインタラクティブセッションに対応しました。ノートブックやIDEから永続的なSparkコンテキストで対話的にSparkアプリを開発・実行でき、セッション単位の監視・デバッグ・コスト可視化が可能になります。

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

Spark Connectのクライアント–サーバーアーキテクチャを利用して、ローカルの開発環境（SageMaker Unified Studio、Jupyter、Visual Studio Codeなど）とEMR Serverless上で稼働するSparkインフラを分離します。インタラクティブセッションはセルやスクリプトを跨いで持続するSparkコンテキストを提供するため、ローカルPython実行とリモートのSpark操作を同一環境でシームレスに混在させられます。これにより、アドホックなデータ探索、逐次的なデバッグ、インクリメンタルなPySpark開発といったワークフローが容易になります。観測性はリアルタイムのSpark UI、履歴追跡のためのSpark History Server、そしてEMRコンソール／API／CLI／SDKによるセッション管理を通じて提供されます。料金・利用状況はセッション単位で細かく可視化されます。機能はEMR release 7.13で利用可能で、EMR Serverlessが提供されている全リージョンで有効です（SageMaker Unified Studio側の体験は対応リージョンに依存します）。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、データエンジニア、機械学習エンジニア、SRE／運用チーム
  • 利用シーン: ノートブックやIDEでの対話的なデータ探索、ステップ実行によるデバッグ、ローカルでのPySpark開発→本番デプロイ前の検証
  • 運用効果: セッション単位の監視と課金可視化によりコスト管理がしやすくなり、対話的ワークフローでの反復開発・トラブルシューティングが高速化される

技術的な注意点 ​

  • IAM権限: EMR Serverlessのセッション作成・管理、ジョブ実行に必要なIAM権限（emr-serverless:*系）およびSageMaker連携時の適切な実行ロールを事前に設定してください
  • リージョン制限: EMR Serverlessが利用可能な全リージョンでEMR release 7.13を通じて提供されますが、SageMaker Unified Studioとの統合体験は対応リージョンに依存します
  • EMRリリース/互換性: 本機能はEMR release 7.13以降で利用可能です。利用前にクラスタ/アプリケーションでリリースバージョンを確認してください
  • ネットワーク設定: VPC内でのアクセス制御（サブネット、セキュリティグループ、ルート設定）や必要に応じたVPCエンドポイントを整備してください。Spark UIやHistory Serverへのアクセス経路も確認が必要です
  • コスト: EMR Serverlessの通常の課金（実行時間とリソース消費）に基づき課金されます。セッションが稼働している時間・リソースがコストに直結するため、不要なセッションは停止または終了してください

参考情報 ​

[Cost Explorer] AWS Cost Explorer launches intelligent cost explanations powered by Amazon Q ​

概要 ​

AWS Cost Explorerに「Analyze with Amazon Q」が追加され、Cost Explorerの任意のレポートをワンクリックでAmazon Q（Developer）に解析させ、コスト傾向、主要なコスト要因、異常検出などの詳細な説明を受け取れる機能が利用可能になりました。解析は設定したフィルタと期間をそのまま利用し、対話的に深掘りできます。

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

新機能『Analyze with Amazon Q』は、Cost Explorerで表示中のビュー（フィルタ、グルーピング、期間など）をそのままコンテキストとしてAmazon Qに渡し、チャットパネル上で自動的にコスト分析を生成します。出力には過去のコスト傾向分析、将来予測に基づく説明、または混在期間に対する両方の説明が含まれ、トップのコストドライバー、疑わしいスパイクや異常、最適化の候補などが示されます。ユーザーは生成された説明に対してフォローアップ質問を行うことで、会話コンテキストが維持されたまま追加の切り口（特定サービス、タグ、アカウント、リージョン別など）で掘り下げられます。これにより以前必要だった複数フィルタや手作業の調査を大幅に短縮できます。なお、AWSは本機能を全ての商用リージョンで追加料金なしで提供すると明記しています。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドコスト管理者、FinOpsチーム、SRE/運用チーム、開発チームリーダー
  • 利用シーン: 費用レポートのワンクリック分析（コスト増加の原因調査、タグ別コスト分析、予測と実績の差分確認、異常検出）
  • 運用効果: 手動検索や複数フィルタ検証の工数削減、異常や最適化候補の早期発見、意思決定の迅速化

技術的な注意点 ​

  • IAM権限: Cost Explorerへのアクセス権（ce系の閲覧権限）と、Amazon Qを利用するための適切な権限が必要です。組織での権限ポリシー確認を推奨します。
  • リージョン制限: 全ての商用AWSリージョンで利用可能とされています（記事時点）。リージョンごとの可用性はコンソールで確認してください。
  • コスト: 記事では『追加料金なし』とありますが、Cost Explorer自体や既存のCost and Usageデータを利用するコスト構成、また組織での大量のインタラクションに伴う間接的な運用コストは考慮してください。
  • データ取り扱い: Amazon QはあなたのCost Explorerコンテキスト（フィルタや期間、コストデータ）を解析に使用します。機密扱いのタグやアカウント情報が含まれる場合は組織のデータ共有ポリシーを確認してください。
  • 前提: Cost Explorerが有効であること、該当の請求/コストデータが利用可能であることが前提です。予測関連の説明は予測ウィンドウやデータ粒度に依存します。

参考情報 ​

[Compute Optimizer] AWS Compute Optimizer now supports idle recommendations for six additional resource types ​

概要 ​

AWS Compute Optimizerがアイドル（未使用）リソース検出の対象を拡張し、DynamoDB（Provisioned）、ElastiCache（Redis と Valkey）、MemoryDB、DocumentDB（プロビジョンド／サーバーレス）、WorkSpaces、SageMakerエンドポイントに対して未使用検出と推定コスト削減を提示できるようになりました。

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

今回の拡張により、Compute Optimizerはさらに6種類のリソースタイプで「アイドル」推奨を生成します。各リソースタイプについて、Compute OptimizerはCloudWatchなどの利用状況メトリクスを一定期間（ユーザーが設定可能なルックバック期間）で分析し、サービス固有のシグナル（例：DynamoDBの消費キャパシティ、キャッシュのヒット率やアクティブ接続数、CPU使用率、SageMakerエンドポイントへの呼び出し数など）を元に稼働実績が低く事実上未使用と判断されるリソースを特定します。検出されたアイドルリソースはコンソール上に詳細な利用状況メトリクスと推定削減額とともに表示され、変更を行う前に評価できるようになっています。組織単位ではCost Optimization Hubから全アカウントのアイドル推奨を確認でき、同一リソースに対する他の推奨（リサイズ等）との重複を除いた推定節約額が合成表示されます。推奨の取得はAWS Management Console、AWS CLI、AWS SDKから可能です。リージョン対応状況はAWSのリージョン表を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド費用最適化を行うSRE/運用チーム、コスト管理者、プラットフォーム/インフラ担当者
  • 利用シーン: 未使用または稼働が低いデータベースやキャッシュ、Workspace、SageMakerエンドポイントの検出によるコスト削減検討
  • 運用効果: 未使用リソースの早期発見により不要料金の削減、オーガニゼーション単位での一括可視化による効率的なコスト最適化ワークフロー構築
  • 意思決定支援: 利用状況メトリクスと推定節約額が提示されるため、削除・停止・サイズ変更などのアクション判断がしやすくなる
  • 組織運用: Cost Optimization Hubにより複数アカウントでの重複計算を回避し、統合的な節約見積が可能

技術的な注意点 ​

  • IAM権限: Compute Optimizerがリソース情報とCloudWatchメトリクスを読み取れるよう、適切なIAM権限（サービス連携ロールの有効化、リソース記述・メトリクス読み取り権限）が必要です。組織ビュー利用時は組織に対するCompute Optimizerのアクセス許可設定も確認してください。
  • リージョン制限: 全リージョンで利用可能とは限りません。対応リージョンはAWSのリージョン表で確認してください。
  • コスト: Compute Optimizerの推奨自体に追加課金は一般にありませんが、分析で参照するCloudWatchの詳細モニタリングやカスタムメトリクスの利用、推奨に基づくリソース変更（データ移行や再作成）には別途コストが発生する可能性があります。
  • ルックバック期間: ルックバック期間はワークロード特性に合わせて調整してください。短すぎると誤検出、長すぎると短期の使用停止を見逃す可能性があります。
  • データ整合性: DocumentDBやStatefulなデータストアを停止・削除する前にデータ保持・バックアップ要件を必ず確認してください。
  • ベンダー差異: 記事はElastiCacheの2つのエンジン（記事原文の表記）を対象としています。各エンジンで評価されるシグナル（キャッシュヒット率、接続数等）は異なりますので、推奨の詳細を個別に確認してください。

参考情報 ​

[Msk] Amazon MSK Express Brokers now support automatic topic creation with Kafka Streams ​

概要 ​

Amazon MSK Express BrokersがKafka Streamsのための内部トピック（ステート用・リパーティション用）をアプリ起動時に自動作成する機能をサポートしました。これにより、Kafka StreamsアプリをExpress Brokers上でデプロイする際の事前トピック作成作業が不要になります。

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

Kafka Streamsはステートフル処理のために内部で changelog トピックや repartition トピックを利用します。従来、MSK Express Brokers上でKafka Streamsアプリを動かす場合、これらのトピックを手動で命名・事前作成しておく必要がありました。本アップデートにより、アプリケーション起動時に必要な内部トピックが自動的に作成されるようになり、デプロイ手順と運用負荷が軽減されます。MSK Express Brokersは1ブローカーあたり最大で従来比3倍のスループット、スケールアップが最大20倍高速、リカバリ時間が90%短縮される設計で、今回の自動トピック作成はこれらの高性能・高速スケール特性を活かしてKafka Streamsのステートフル処理を容易にします。追加の設定は不要で、本機能はMSK Express Brokersが利用可能な全リージョンで本日より利用可能です。詳細はAmazon MSK Developer Guideを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Kafka Streamsアプリケーションを利用する開発者、データエンジニア、プラットフォーム/SREチーム
  • 利用シーン: ステートフルなストリーム処理（state store/changelog、repartitionなど）を伴うKafka StreamsアプリのCI/CDや本番デプロイ
  • 運用効果: 手動での内部トピック事前作成が不要になり、デプロイの自動化とミス低減、導入時間短縮、運用負荷の軽減が期待できる

技術的な注意点 ​

  • ACL／認可: クラスターでKafka ACLが有効な場合は、アプリケーション（実行ユーザー/プリンシパル）にトピック作成権限が必要です。権限が不足すると自動作成は失敗します。
  • トピック設定: 自動作成される内部トピックはKafka Streamsの要求に基づくデフォルト設定またはBroker側のデフォルトが適用されます。パーティション数やレプリケーション因子、保持ポリシーなど特定の設定が必須の場合は、事前にトピックを手動作成してください。
  • 互換性: 一般的なKafka Streamsクライアントは内部トピックを自動生成しますが、古いクライアントやカスタム設定を使う場合は動作確認を行ってください。
  • リージョン制限: 本機能はMSK Express Brokersが利用可能なすべてのリージョンで利用可能です。Express Brokers自体が未対応のリージョンでは利用できません。
  • コスト: 本機能自体に追加料金は明示されていませんが、自動で作成されるトピックによるストレージ使用量やIOが増える場合があるため、ストレージコストやモニタリングは注意してください。
  • 運用上の注意: 内部トピックの命名規則やライフサイクル（たとえば削除やリテンションの管理）を運用ポリシーに組み込んでおくと、不要トピックの増加や容量管理問題を防げます。

参考情報 ​

[Documentdb] Amazon DocumentDB now supports engine minor version starting with 5.0.1 ​

概要 ​

Amazon DocumentDB（MongoDB互換）がエンジンのマイナー・バージョン管理をサポートし、最初のマイナーリリースとして 5.0.1 が利用可能になりました。集約演算子の拡張や接続数メトリクス、コマンド単位のCloudWatch指標などが追加されています。

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

マイナー・バージョン5.0.1では以下が導入されています：

  • 新しい集約演算子: $rand（乱数生成）、$pow（べき乗）、$dateToParts / $dateFromParts（日付の分解・再構成）。より柔軟な集約パイプラインが組めます。
  • アクティブ接続数メトリクス: インスタンスの現在の接続数を監視可能に。
  • CloudWatchでのコマンド粒度のパフォーマンス指標: find、insert、findAndModify、update 等のコマンドごとの実行指標が取得でき、クエリ別の負荷分析やボトルネック特定が容易になります。 技術的には、マイナー・バージョンは同一メジャーバージョン（5.0）の範囲内で機能追加・バグ修正を提供し、クラスタ作成時に5.0.1を指定するか、既存の5.0.0クラスタをAWS Management ConsoleまたはAWS CLIのmodify-db-cluster --engine-version 5.0.1で手動アップグレードできます。一度新しいマイナー・バージョンへ上げるとダウングレードはできません。また、5.0.0（LTS）から5.0.1へ移行するとLTSトラックから外れるため、アップグレード頻度の方針に注意が必要です。5.0が利用可能なすべてのリージョンで5.0.1が利用可能です。詳細やリリースノートは公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: データベース管理者、SRE、アプリケーション開発者、データ分析者
  • 利用シーン: 集約処理での高度なデータ変換（$dateToParts 等）、ランダム値を使った処理（$rand）、クエリ単位の性能監視とボトルネック解析（CloudWatchのコマンド指標）
  • 運用効果: コマンド単位のメトリクスにより問題の切り分けが容易になり、パフォーマンス改善施策の精度が向上します。接続数メトリクスでスケーリング判断の材料が増えます。
  • リスク/留意点: 5.0.1へアップグレードすると以前のマイナー・バージョンへ戻せないため、事前検証とバックアップが必須です。

技術的な注意点 ​

  • IAM権限: クラスタの変更にはdocdb:ModifyDBCluster等の適切な権限が必要です（コンソール／CLI経由ともに）。
  • ダウングレード: 一度マイナー・バージョンを上げると旧マイナーへ戻せません。テスト環境での検証とスナップショット取得を推奨します。
  • LTS（長期サポート）: 5.0.0(LTS)から5.0.1へ移行するとLTSトラックを外れるため、アップグレードポリシーを確認してください。
  • リージョン制限: 5.0が利用可能な全リージョンで5.0.1が提供されていますが、具体的なリージョン可否はリージョン毎に確認してください。
  • コスト: CloudWatchで細粒度のメトリクスを有効にするとメトリクス数増加に伴う課金が発生する可能性があります。
  • 運用手順: 本番適用前にステージングでクエリ互換性・パフォーマンス検証を行い、変更前にスナップショットを取得してください。

参考情報 ​

[Cloud Financial Management] AWS Savings Plans Purchase Analyzer now supports target coverage analysis ​

概要 ​

Savings Plans Purchase Analyzerに「ターゲットカバレッジ分析」が追加され、特定のオンデマンド支出割合をカバーするための購入量を推奨できるようになりました。過去の利用実績を使ってカバレッジ・コスト・利用率・想定節約額を比較・可視化できます。

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

ターゲットカバレッジ分析では、ユーザーが「オンデマンド支出のうち何％をSavings Plansでカバーしたいか」を指定すると、Purchase Analyzerが過去の使用状況を基に目標達成に必要な追加購入額を推奨します。推奨はカスタムのルックバック期間（過去の観測期間）や、有効期限が近い（更新されない）既存のSavings Plansを除外するオプションなどで調整可能です。結果はインタラクティブなチャートで比較表示でき、異なるカバレッジ目標間でのコスト、カバレッジ、利用率、想定節約額を比較できます。また、同分析はPurchase Analyzer APIからプログラム的に取得可能で、自動化やレポーティングワークフローに組み込めます。対象リージョンはPurchase Analyzerが提供されているすべてのAWSリージョンです。推奨は過去の実績に基づく推定であり、将来の利用変動や特定インスタンスタイプの移行等は結果に影響します。

影響範囲・利用シーン ​

  • 対象ユーザー: FinOpsチーム、クラウドコスト管理者、SRE、クラウドアーキテクト、経理/購買担当者
  • 利用シーン: 指定したカバレッジ目標に基づくSavings Plans購入計画の策定（例: オンデマンド支出の70%カバーを目標にした推奨購入額の算出）
  • 運用効果: 購入シナリオを比較して過剰購入や過少購入を削減。カバレッジ目標達成に向けた意思決定が迅速化され、予測可能なコスト削減を実現しやすくなる
  • コスト影響: 分析自体に課金の明示はないが、推奨に従ってSavings Plansを購入すると長期のコミットメントが発生し、月次支出構造が変化するため財務計画を調整する必要がある

技術的な注意点 ​

  • IAM権限: BillingおよびPurchase Analyzerの表示/API呼び出しに必要な権限（組織環境では請求アカウントまたは適切なBillingアクセス権が必要）を事前に付与してください
  • リージョン制限: Purchase Analyzerが提供されているAWSリージョンで利用可能です。リージョン未対応の場合は利用できません
  • データ精度・ルックバック: 推奨は過去の使用データに基づく推定です。ルックバック期間を変更すると推奨結果が変わるため、季節性や最近の利用変化を考慮してください
  • 有効期限のあるSavings Plans: 「有効期限が近い既存プランを除外」するオプションを使うと、更新されないプランを考慮せずに新規購入量を算出できます。既存プランの更新方針に注意して評価してください
  • API/自動化: Purchase Analyzer APIでターゲットカバレッジ分析結果を取得可能。CI/CDやコスト自動化パイプラインへの組み込みが可能です
  • コスト: 分析自体に追加料金が明記されていない一方、推奨どおりにSavings Plansを購入するとコミットメントに基づく請求構造となるため、予算・キャッシュフローへの影響を確認してください
  • 推奨の性質: 表示される「想定節約額」は過去の利用に基づく推定値であり、将来の使用パターン変化やインフラ変更により実績は異なります

参考情報 ​

[RDS] PostgreSQL 19 Beta 1 is now available in Amazon RDS Database Preview Environment ​

概要 ​

Amazon RDSのプレビュー環境でPostgreSQL 19 Beta 1が利用可能になりました。RDSのフルマネージド環境でPostgreSQL 19の新機能（SQL/PGQによるネイティブなグラフクエリ、同時テーブル再構築、論理レプリケーション改善など）を評価できます。

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

Amazon RDS Database Preview Environment上でPostgreSQL 19 Beta 1をデプロイして事前評価が可能です。主な新機能は以下の通りです。

  • SQL Property Graph Queries (SQL/PGQ): 標準SQLの文法でグラフクエリ（関係性の横断やパターン照合）を記述できるネイティブなグラフクエリ機能。アプリケーション側で関係性処理を実装したり、別DBでグラフを保持して同期する必要が減ります。
  • 同時テーブル再構築（concurrent table repacking）: テーブルを再構築して未使用ストレージを回収する際に、ターゲットテーブルをプロダクションから切り離さずに実行できるため、通常のテーブル保守中もDBの可用性を維持できます。
  • 論理レプリケーションの改善: レプリカへのシーケンス値同期が自動化され、メジャーバージョンアップ時のカットオーバー後に手動でシーケンス調整する必要が減ります。また、論理レプリケーションをサーバ再起動なしで動的に有効化でき、計画停止時間を短縮できます。 加えて、RDSプレビュー環境固有の制約としてインスタンスは最長60日で自動削除される点、プレビュー環境で作成したスナップショットは同環境内でのみ利用可能な点、データの出し入れはpg_dump/pg_restore等のダンプ/ロードで行う必要がある点に注意してください。料金はUS East (Ohio) の価格設定が適用されます。これはあくまでBeta/プレビューの評価向けであり、本番運用前に互換性や拡張モジュールの動作確認が必須です。

影響範囲・利用シーン ​

  • 対象ユーザー: PostgreSQL管理者、DBA、データエンジニア、アプリケーション開発者
  • 利用シーン: ネイティブなグラフクエリを使った関係性分析（ソーシャルグラフ、推薦システム）、テーブルメンテナンス中の可用性確保、レプリケーションを使った段階的アップグレードの簡素化
  • 運用効果: シーケンス同期や動的な論理レプリケーションでダウンタイムを削減できる。SQL/PGQによりアプリ側の複雑な結合ロジックやデータ二重管理を減らせる
  • 制限/注意点: プレビュー環境のインスタンスは最大60日で自動削除、スナップショットはプレビュー環境内でしか復元できないため本番データ移行にはダンプ/ロードが必要

技術的な注意点 ​

  • 環境区分: プレビュー（評価）環境であり、GAリリース前のベータ機能が含まれます
  • データ永続性: インスタンスは最長60日で自動削除されます。スナップショットはプレビュー環境内でのみ使用可
  • データ移行: プレビュー外へ移行する場合はpg_dump/pg_restore等のダンプ/ロードを使用してください。スナップショットでの移行は不可
  • 互換性: 使用中の拡張（PostGIS等）がPostgreSQL 19と互換か事前検証が必要です
  • 稼働影響: 同時テーブル再構築は可用性を保ちますが、IO負荷や再構築時間はワークロードによって変動します
  • 論理レプリケーション設定: 動的有効化が可能だが、レプリケーション設定やパラメータ（pg_hba.conf的設定やパラメータグループ）は事前確認が必要
  • リージョン制限/料金: プレビュー環境はUS East (Ohio) の価格設定が適用されます。リージョンの提供状況は限定される可能性あり
  • 権限: RDSインスタンス作成・スナップショット操作・パラメータグループ編集などのIAM/RDS権限を事前に確認してください
  • コスト: プレビュー環境でもインスタンス料金が発生します。評価利用でもコストがかかる点に注意してください

参考情報 ​

[General] AWS Lambda Managed Instances expands to additional AWS Regions ​

概要 ​

AWS Lambda Managed Instances (LMI) が追加の商用リージョンに展開されました。LMI は管理された Amazon EC2 インスタンス上で Lambda 関数を実行できる機能で、EC2 の特殊ハードウェアや料金オプションを活かしつつ Lambda の運用性を維持します。

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

LMI は Lambda 関数を AWS が管理する EC2 インスタンス上で実行する仕組みです。インスタンスのライフサイクル管理、OS/ランタイムのパッチ適用、ルーティング、ロードバランシング、オートスケーリングをフルマネージドで提供し、開発者はコードに注力できます。各実行環境内で並列リクエスト処理が可能なためリソース利用効率と価格性能比を改善できます。さらに Compute Savings Plans や Reserved Instances といった EC2 の料金モデルを適用でき、長期で予測可能な負荷に対するコスト最適化が可能です。特殊なハードウェア（例：大容量メモリ、GPU、専用インスタンスタイプ）が必要なケースや、定常的なワークロードでのコスト最適化に適しています。導入手順は、まず VPC 設定、任意のインスタンス要件、スケーリングポリシーなどを定義する capacity provider を作成し、Lambda コンソール/API/IaC ツールから関数をその capacity provider にアタッチします。LMI は既存の Lambda イベントソースや Amazon CloudWatch、AWS X-Ray、AWS Config 等のツールとシームレスに統合されます。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバレス開発者、クラウドアーキテクト、SRE、コスト最適化を狙うインフラチーム
  • 利用シーンまたは効果: GPU や大容量メモリなどの特殊インスタンスが必要な関数の実行、定常または予測可能な高スループット処理のコスト削減（Savings Plans/RI の活用）
  • 運用効果: インスタンス管理負荷の低減により運用工数を削減し、アプリケーションコードに注力可能
  • コスト効果: EC2 料金モデルの活用で長期的コストが低減できる一方、基盤としての EC2 利用料は発生する
  • リージョン影響: ほぼ全商用リージョンで利用可能だが例外リージョンあり（詳細は下記）

技術的な注意点 ​

  • IAM権限: Capacity provider の作成・管理、Lambda 関数のアタッチ、EC2／ENI 操作、IAM:PassRole 等の権限が必要です。具体的権限は導入前にポリシーを確認してください。
  • リージョン制限: 商用全リージョンで利用可能になりましたが、Israel (Tel Aviv)、Middle East (Bahrain)、Middle East (UAE)、Asia Pacific (Auckland) では未提供です。
  • VPC設定: capacity provider 作成時に VPC サブネット・セキュリティグループを指定します。ENI 数や IP アドレス枯渇、NAT／ルーティングの要件に注意してください。
  • コスト: LMI 自体は EC2 ベースのため、インスタンス時間、EBS、ENI、データ転送等の EC2 関連料金が発生します。Savings Plans／Reserved Instances で割引可能ですが、見積もりを事前に行ってください。
  • 互換性／運用上の注意: 既存の Lambda イベントソース、CloudWatch、X-Ray、AWS Config と統合されます。各実行環境での並列処理により関数の実行分離やデバッグ方法に影響が出る可能性があるため、コールドスタート挙動やトレーシング設計を確認してください。
  • セキュリティ／パッチ: AWS が OS とランタイムのパッチを管理しますが、パッチ適用ポリシーやスケジュール、カスタムソフトウェアの導入可否（カスタム AMI の対応可否など）はドキュメントで確認してください。

参考情報 ​

[Application Migration Service] AWS Application Migration Service is now AWS Transform MGN ​

概要 ​

AWS Application Migration Service (MGN) が AWS Transform MGN に名称変更されました。名称変更は、MGN がエージェント型移行サービス「AWS Transform」の中核となる実績あるレプリケーションエンジンであることを明確にするためのものです。

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

技術的には既存のレプリケーション機能や認証・認可は維持されており、主な変更はブランド名と『AWS Transform』エコシステム内での位置づけの明確化です。ユーザーは2つのリホスト（rehosting）体験を選べます：

  • AWS Transform MGN コンソール経由: 既存の MGN と同様にブロックレベルの継続レプリケーション、レプリケーション設定、レプリケーションサーバ（Replication Server）管理、テスト/カットオーバー操作を直接制御できます。
  • AWS Transform エージェント型ワークフロー: エージェントがアプリケーションの検出、ウェーブ（移行バッチ）計画、ランディングゾーン／VPC やネットワーク作成、リホストまたはコンテナ化までの一連工程を代行し、移行作業の自動化と加速を図ります。 また、AWS Transform MGN は既存のコンプライアンス認証（FedRAMP High、HIPAA、PCI DSS、ISO、SOC 1/2/3 等）を継承しており、全商用リージョンおよび両 GovCloud (US) リージョンで利用可能です。既存の API、エージェント、データレプリケーションの挙動に大きな互換性の変更は報告されておらず、既存の移行手順は引き続き利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド移行を行うクラウドエンジニア、SRE、移行プロジェクトマネージャー、アプリケーション所有者
  • 利用シーン: 大量のサーバー/VM を段階的に AWS にリホストする移行、または移行を自動化してリフト＆シフト／コンテナ化を加速する場合
  • 運用効果: エージェント型ワークフローにより検出→計画→ランディングゾーン構築→リホストの一連作業を短縮でき、手動作業と人的ミスを削減
  • 移行戦略への影響: 既存の MGN ワークフローをそのまま使うか、エージェントによるフルオートメーションを採用するか選択肢が増加し、プロジェクトの規模と運用リソースに合わせた設計が可能
  • セキュリティ/コンプライアンス: 既存の主要なコンプライアンス認証を維持しているため、規制対応が必要なワークロードでも導入しやすい

技術的な注意点 ​

  • IAM権限: レプリケーション/カットオーバー操作には MGN 用の IAM ポリシーとロールが必要です。既存の権限設計を確認・適用してください
  • リージョン制限: 発表では「全商用リージョンおよび両 GovCloud (US) リージョンで利用可能」とされていますが、特定リージョンでの機能差異やロールアウト状況はドキュメントで確認してください
  • コスト: データ転送、レプリケーションサーバの EC2 コスト、ストレージ、テスト/運用中の追加リソースなどが発生します。エージェント型ワークフローによる自動化で作業工数は削減されますがサービス利用料や追加リソース費用を見積もってください
  • カットオーバー影響: リホスト時のダウンタイム設計は従来どおり必要です。テストカットオーバーで復旧手順とアプリ依存性を検証してください
  • エージェント/互換性: 既存 MGN エージェントと設定は基本的に互換ですが、エージェント型ワークフロー利用時は追加の自動化コンポーネント（検出・プランニング機能）を組み合わせるため、事前テストを推奨します
  • コンプライアンス/認証: FedRAMP High 等の認証は継承されていますが、組織の規程に応じて監査トレイルや設定を再確認してください

参考情報 ​

[General] Amazon Aurora DSQL now supports the JSONB data type with compression ​

概要 ​

Amazon Aurora DSQLがPostgreSQLのJSONBデータ型をサポートし、オプションで圧縮できるようになりました。これにより、リレーショナルデータと半構造化データを同じテーブルで扱いやすくなり、JSONBの大きなペイロードはデフォルトで圧縮されてストレージ効率が向上します。

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

Aurora DSQLでPostgreSQL互換のJSONBデータ型が利用可能になりました。テーブル作成（CREATE TABLE）や変更（ALTER TABLE）時にJSONB型を指定して、システム設定メタデータ、APIパラメータ、イベントログなどの半構造化データを格納できます。JSONBはPostgreSQL標準のバイナリJSON表現のため、既存のJSONB依存のコードやツールとの互換性が期待できます。さらに、PostgreSQLの圧縮機構（記事ではデフォルトで有効と記載）により、大きなJSONBオブジェクトは圧縮保存され、ストレージ使用量を削減できます。リージョンごとの提供状況はAWS Region表で確認でき、最初は無料利用枠（AWS Free Tier）で試用可能です。導入前にはアプリケーションの互換性やインデックス／クエリの挙動を検証することを推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリケーション開発者、データベース管理者、SRE／運用チーム
  • 利用シーン: 半構造化データ（設定メタデータ、APIパラメータ、イベントログ等）をリレーショナルテーブルと併存して保存・検索するケース
  • 運用効果: JSONBの圧縮によりストレージ使用量と保存コストが低減される可能性があり、既存のPostgreSQLベースツールやORMを活用しやすくなる
  • マイグレーション影響: PostgreSQLのJSONBを利用する既存アプリケーションは比較的容易に移行できるが、インデックス構成やクエリパフォーマンスは検証が必要
  • 可用性/地域性: 提供リージョンによる差があるため、利用前にRegion表で対応状況を確認する必要あり

技術的な注意点 ​

  • IAM権限: クラスタ作成・変更やDDL実行に必要なRDS/Aurora関連のIAM権限（例: rds:CreateDBCluster、rds:ModifyDBCluster、rds-data:ExecuteStatement等）を確認してください
  • リージョン制限: リージョンによって未対応の可能性があるため、AWS Region表で対応状況を事前に確認してください
  • コスト: JSONBの圧縮でストレージコストは減少する可能性がありますが、圧縮/伸張に伴うCPU負荷やI/Oパターンの変化が発生するためパフォーマンスとコストのトレードオフを評価してください
  • 互換性: 基本的にはPostgreSQLのJSONB互換を謳っていますが、特定の関数・演算子や拡張、インデックス（例: GIN/GiST）の挙動は環境差があり得るので、本番移行前にアプリケーションテストとベンチマークを実施してください
  • パフォーマンス: 大きなJSONBドキュメントは圧縮でストレージ利得が見込めますが、検索頻度やインデックス設計によってはクエリ遅延が発生するため、適切なインデックスとクエリ最適化が必要です
  • スキーマ変更: 既存テーブルに対するALTERでの型変更や大規模なデータ変換はメンテナンスウィンドウやリソース影響（I/O/CPU）を伴う可能性があるため、事前に計画してください
  • バックアップ/レプリケーション: スナップショットやレプリケーションは通常通り機能しますが、圧縮によるストレージ挙動の違いがリストア時間や帯域に影響する場合があるため確認が必要です

参考情報 ​

[Cost Explorer] AWS now provides AI-powered cost investigations for cost anomalies ​

概要 ​

AWS Cost Anomaly DetectionにAmazon Qを使ったAIベースのコスト調査機能が追加され、検出したコスト異常の原因分析を数分で自然言語説明として提供します。これによりFinOpsや開発チームがアラートから対応までの時間を大幅に短縮できます。

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

検出されたコスト異常に対して「Investigate with Amazon Q」を選択すると、Amazon Qがコスト変動の根本原因を自動解析します。主な機能は以下の通りです。

  • 変動種別の判定: コスト変化が「使用量（usage）駆動」か「価格（rate）駆動」かを自動判定します。
  • 要因の特定: 影響しているサービス、アカウント、リージョンを列挙します。
  • CloudTrail相関: 使用量駆動の変化については、AWS CloudTrailのイベントやリソースアクティビティと突合し、該当APIコールやIAMプリンシパルに帰属させます。
  • 組織横断対応: 組織トレイル（Organization trail）がある場合、メンバーアカウント全体を自動で横断解析できます。
  • 対話的追跡: 結果に対してフォローアップの自然言語質問を行い、パターンの探索や特定リソースの深掘りが可能です。
  • 利用開始方法: AWS Billing and Cost ManagementコンソールのCost Anomaly Detectionで検出済み異常に対して「Investigate with Amazon Q」を選択します。
  • 利用可否と課金: 本機能自体はすべての商用リージョンで追加料金なしで利用可能。ただし、組織トレイルをAmazon CloudWatch Logsに配信している環境でのクロスアカウント調査は、スキャンしたデータ量に応じてCloudWatch Logs Insightsの標準料金が発生する場合があります。

影響範囲・利用シーン ​

  • 対象ユーザー: FinOpsチーム、クラウドコスト管理者、SRE/運用チーム、開発チーム
  • 利用シーンまたは効果: コスト異常アラートの迅速な原因特定（使用量増加か料金変動かの分類、関与するサービス/アカウント/リージョンの特定、CloudTrailイベントとの紐付け）
  • 運用効果: 手動でのログ突合やイベント調査に要する時間（数時間）を数分に短縮し、MTTRを改善して迅速に対応・是正アクションへ移行できる
  • 組織横断性: 組織トレイルを有効化していればメンバーアカウントを自動解析でき、マルチアカウント環境での原因追跡が容易になる

技術的な注意点 ​

  • IAM権限: Cost Anomaly Detection、Billingコンソール、Amazon Q、CloudWatch Logs/Logs Insights（クロスアカウント調査時）へのアクセス許可を持つ必要があります。最小権限を検討してください。
  • CloudTrail組織トレイル: 組織全体の横断調査を行うにはOrganization trailが設定され、必要に応じてCloudWatch Logsへ配信されていることが前提です。トレイル未設定だと解析はアカウント単位に制限されます。
  • リージョン制限: 本機能はすべての商用AWSリージョンで利用可能です（記事時点）。特殊リージョンやGovCloudなどは要確認。
  • コスト: 機能自体に追加料金はありませんが、組織トレイルをCloudWatch Logsに配信している場合、CloudWatch Logs Insightsのデータスキャン量に基づく標準課金が発生する可能性があります。
  • データ保護・プライバシー: 調査ではCloudTrailイベントや請求データが解析されます。機密情報の取り扱い、ログ保持期間、暗号化、アクセス制御ポリシーを確認してください。
  • 開始手順: Billingコンソール → Cost Anomaly Detection → 検出された異常を選択 → 「Investigate with Amazon Q」をクリックして解析を開始します。

参考情報 ​

[Connect] Amazon Connect Customer now offers AI agent trace details for self-service voice interactions ​

概要 ​

Amazon Connect Customerがセルフサービス音声対話向けにAIエージェントのトレース（ reasoningやアクションの逐次ログ ）を提供開始しました。これにより、各通話でAIがどのように判断・行動したかをConnectのUIで可視化できます。

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

新機能は、セルフサービスの音声インタラクションに対してAIエージェントの“ステップごとのトレース”を提供します。トレースはフルのトランスクリプトと並んでConnectのWeb UIから確認でき、エージェントがどのように推論したか（reasoning）、どのツールを呼び出したか、渡したパラメータ、タイムアウト発生の有無などを時系列で追跡できます。これにより、解決に失敗した対話について「誤った推論」「不適切なツール呼び出しパラメータ」「外部呼び出しのタイムアウト」など原因を特定しやすくなり、挙動検証や本番導入前のデバッグが容易になります。機能はAmazon Connect CustomerのAI AgentsがサポートされているすべてのAWSリージョンで利用可能です。詳細な操作方法や管理はAmazon Connect Customer Administrator Guideを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: コンタクトセンター運用者、AI/ボット開発者、SRE/品質保証チーム
  • 利用シーン: 音声セルフサービス（IVR/ボット）対話の不具合解析、会話フロー検証、エージェント挙動のレビュー
  • 運用効果: 問い合わせ未解決の原因特定が迅速化され、修正・再学習やフロー改善のサイクルが短縮される
  • ビジネス効果: 本番リスクの低減と顧客体験の向上（誤応答減少、平均対応時間の短縮）

技術的な注意点 ​

  • IAM権限: Connectの管理コンソール、トランスクリプト/ログ表示に必要なIAM権限を事前に確認・付与してください（例: Connect管理操作やログ閲覧権限）。
  • リージョン制限: Amazon Connect Customer AI Agentsがサポートされているリージョンで利用可能。未サポートのリージョンでは利用できません。
  • データ保持・プライバシー: トレースとトランスクリプトは保存・表示されるため、個人情報や通話内容の取り扱いに関するコンプライアンス（ログ保持ポリシー、マスキング、アクセス制御）を確認してください。
  • コスト: 記事で明示的な追加料金の記載はありませんが、トレース生成・保存・ログ転送に伴うストレージやAPIリクエストのコストが発生する可能性があります。請求に注意してください。
  • 前提設定: Amazon Connect CustomerのAI Agentsが有効化されている必要があります。管理者ガイドに従ってエージェント設定や必要なリソース（電話番号、フロー、連携ツール等）を準備してください。
  • 可視性の限界: 記録されるトレースの詳細レベルや保持期間は設定やサービスの仕様に依存します。詳細は管理者ガイドを確認してください。

参考情報 ​

[Redshift] Amazon Redshift reduces manual snapshot cost for Serverless and RG instances ​

概要 ​

Amazon Redshiftは、ServerlessおよびRGインスタンスの手動スナップショットに対する課金方式を変更し、スナップショット間で重複しないユニークなデータブロックに基づいてストレージを課金するようになりました。これにより、複数の手動スナップショットを保持する場合のコストが削減されます。

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

新しい課金モデルでは、各手動スナップショットのサイズ合計ではなく、スナップショット群にまたがって保存されているユニークなデータブロック（重複を排したブロック）の量に基づいてストレージ使用量が計測されます。結果として、同一データの重複を含む複数の手動スナップショットを保持しているときに、総ストレージ課金が大幅に削減される可能性があります。

  • 対象: Amazon Redshift Serverless および Amazon Redshift RG インスタンスの「手動スナップショット」に適用されます（自動スナップショットの課金動作は従来通り）。
  • 適用範囲: 既存の手動スナップショットと新規の手動スナップショットの両方に自動適用されます。
  • リージョン: Amazon Redshift Serverless と RG が利用可能なすべての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。 この変更により、より頻繁な手動スナップショット取得がコスト増を伴わずに可能になり、RPOを改善して強固なディザスタリカバリ戦略を構築しやすくなります。なお、クロスリージョンコピーやスナップショットのクロスアカウント共有など、コピー先での保存は別途課金されるケースがあり、リージョン間でのデータ重複排除の適用範囲は限定される可能性が高い点に注意してください。

影響範囲・利用シーン ​

  • 対象ユーザー: Redshift Serverless / RG を利用し、手動スナップショットでバックアップや長期保持を行っている開発者・SRE・データベース管理者
  • 利用シーン: 災害復旧のための複数世代の手動スナップショット保持、テスト用ステートの保存、長期アーカイブ目的でのスナップショット管理
  • 運用効果: スナップショット保管コストの削減により、より頻繁なスナップショット取得が現実的になり、RPOの改善や復旧戦略の強化が可能になる

技術的な注意点 ​

  • 適用対象: 本変更は「手動スナップショット」に対する課金モデルの変更です。自動スナップショットの挙動は従来通りです
  • 自動適用: 既存・新規の手動スナップショットに自動で適用され、ユーザー側での設定変更は不要です
  • クロスリージョン/コピー: クロスリージョンコピーや別アカウントへコピーしたスナップショットは別途保存されるため、重複排除の対象外または別課金となる可能性があります。クロスリージョン転送や保存に関する追加料金に注意してください
  • データ変更量: 課金はユニークなデータブロック量に基づくため、データ更新頻度やブロック単位での差分が多いワークロードではコスト低減効果が小さくなる場合があります
  • 暗号化と権限: スナップショットの暗号化設定やIAMによるスナップショット操作の権限は従来通り適用されます。課金モデル変更により追加のIAM権限は不要です
  • コスト可視化: 請求・コスト管理ツール（Billing Console / Cost Explorer / レポート）でスナップショットストレージの請求影響を確認することを推奨します
  • リージョン制限: Serverless と RG が提供されているリージョンで利用可能です。提供リージョン外では適用されません

参考情報 ​

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

Copyright © 2026