はじめに

AWSの基礎力をつけるためにAWS What's Newを毎日目を通す事を始めました。
最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。
個人的な理解なので、実際の情報は原典をあたってください。

AWS Billing and Cost Management MCPサーバーの発表

投稿日: 2025年08月22日

何ができるようになったのか

AWSは、請求とコスト管理のためのモデルコンテキストプロトコル（MCP）サーバーをリリースしました。このサーバーはAWS LabsのGitHubリポジトリで公開されており、顧客が選択したAIエージェントやアシスタントを使用して、過去の支出分析、コスト最適化機会の発見、新規ワークロードのコスト見積もりを行うことを可能にします。

何が嬉しいのか

これまでAWSコンソール上のAmazon Q Developerで利用可能だったAIによるコスト分析・最適化機能が、Q Developer CLIツール、Kiro IDE、Visual Studio Code、Claude Desktopといった、顧客が利用している任意のMCP互換AIアシスタントで利用できるようになります。これにより、使い慣れたツール上で高度なコスト管理が実現できます。また、専用のSQLベース計算エンジンにより、大量のデータに対しても信頼性の高い、再現可能な計算（期間比較や単価分析など）が容易になります。

これまでとどう変わるのか

これまで
- AIを活用したコスト分析や最適化機能は、主にAWSコンソール内のAmazon Q Developerを通じて提供されていました。
これから
- 顧客が使用している任意のMCP互換AIアシスタントから、請求とコスト管理の機能にアクセスできるようになります。これにより、より柔軟で統合されたFinOpsプラクティスが可能になります。

具体的なユースケース

過去および将来のコストと使用状況データの分析
コスト最適化の機会の特定
AWSのサービス料金の理解
コスト異常の検出
期間ごとの変動やユニットコストメトリクスといった、信頼性の高い計算の実行
Q Developer CLI、Kiro IDE、Visual Studio Code、Claude Desktopなどの好みのAIアシスタントとの統合

Amazon RDS for Db2がリードレプリカをサポート開始

投稿日: 2025年08月22日

何ができるようになったのか

Amazon Relational Database Service (RDS) for Db2で、リードレプリカがサポートされるようになりました。データベースインスタンスに対して最大3つのリードレプリカを追加し、読み取り専用アプリケーションをサポートするために使用できます。

何が嬉しいのか

プライマリデータベースインスタンスに過度な負荷をかけることなく、読み取り専用のクエリを実行できます。また、リードレプリカを昇格させて読み書き操作をサポートすることで、ディザスタリカバリ（DR）にも活用できます。

これまでとどう変わるのか

これまで
- RDS for Db2にはリードレプリカ機能がなく、読み取りクエリもプライマリインスタンスに向ける必要がありました。これにより、読み取り負荷が高い場合にプライマリのパフォーマンスに影響が出る可能性がありました。
これから
- 読み取りクエリをリードレプリカに分散させることで、プライマリインスタンスの負荷を軽減できます。レプリカはプライマリと同一または異なるリージョンに設置可能です。

具体的なユースケース

レポート作成ツールや分析ダッシュボードなど、読み取り負荷の高いアプリケーションのクエリをリードレプリカにオフロードする。
別のリージョンにリードレプリカを配置し、災害対策のスタンバイ系として利用する。

Amazon EC2 R7gインスタンスがアフリカ（ケープタウン）で利用可能に

投稿日: 2025年08月22日

何ができるようになったのか

Amazon Elastic Compute Cloud (Amazon EC2) R7gインスタンスが、AWSアフリカ（ケープタウン）リージョンで利用できるようになりました。

何が嬉しいのか

AWS Graviton3プロセッサを搭載しており、AWS Graviton2プロセッサと比較して最大25%高いコンピューティングパフォーマンスを提供します。
AWS Nitro System上に構築されており、効率的で柔軟、かつ安全なクラウドサービスが利用できます。
同等のEC2インスタンスと比較して、同じパフォーマンスで最大60%少ないエネルギー消費で済むため、クラウドの二酸化炭素排出量を削減できます。
ベアメタルを含む9つの異なるインスタンスサイズが利用可能で、スケーラビリティが向上します。
最大30Gbpsのネットワーク帯域幅と、最大20GbpsのAmazon Elastic Block Store (EBS) への帯域幅を提供します。

これまでとどう変わるのか

これまで
- アフリカ（ケープタウン）リージョンでは、Graviton3プロセッサを搭載した高性能・高効率なR7gインスタンスを利用できませんでした。
これから
- アフリカ（ケープタウン）リージョンのユーザーはR7gインスタンスを起動できるようになり、ワークロードに対してより高いパフォーマンス、優れたエネルギー効率、およびスケーラビリティの恩恵を受けることができます。

具体的なユースケース

記事には具体的なユースケースの記載はありませんが、R7gのようなメモリ最適化インスタンスは、一般的にオープンソースデータベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリを大量に消費するワークロードに適しています。

Amazon RDS for PostgreSQLが遅延読み取りレプリカをサポート開始

投稿日: 2025年08月22日

何ができるようになったのか

Amazon RDS for PostgreSQLで、遅延読み取りレプリカがサポートされるようになりました。これにより、レプリカデータベースがソースデータベースから遅延する最小時間を指定できます。この機能は、誤ったテーブルの削除や意図しないデータ変更といった人為的ミスによるデータ損失から保護するための時間的バッファを作成します。

何が嬉しいのか

データ保護の強化: 人為的なミスによるデータ損失のリスクを低減できます。
迅速な復旧: 災害復旧シナリオにおいて、従来のポイントインタイムリストア操作よりも高速なリカバリが可能です。これは特に大規模なデータベースで効果を発揮します。

これまでとどう変わるのか

これまで
- 人為的なミスや論理的なエラーからデータを復旧するには、ポイントインタイムリストアを実行する必要がありました。これは、特に大規模なデータベースでは数時間かかる可能性がありました。
これから
- 問題のある変更がレプリカに適用される前にレプリケーションを一時停止し、特定の位置までレプリケーションを進めてから、そのレプリカを新しいプライマリデータベースとして昇格させることができます。これにより、復旧時間が大幅に短縮されます。

具体的なユースケース

オペレーションミスからの回復: 運用者が誤って重要なテーブルを削除してしまった場合に、その変更が遅延レプリカに反映される前にレプリケーションを停止し、削除直前の状態に迅速に復旧させる。
論理データ破損からの保護: バグを含んだアプリケーションがデプロイされ、データが意図せず変更された場合に、その変更がレプリカに伝播するのを防ぎ、迅速に正常な状態に戻す。

チャッピーにポイントインタイムリストアと比較してもらいました。

観点	遅延リードレプリカ	ポイントインタイムリストア (PITR)
復旧速度	ほぼ即時（レプリケーション停止→昇格するだけ）	数時間かかることもある（大規模DBでは特に）
必要な操作	レプリケーションの停止＋昇格	バックアップからリストア＋再構築
保護できる障害の種類	ヒューマンエラー、論理的なデータ破損	ヒューマンエラー、論理的・物理的障害
コスト	レプリカ維持のコスト（常時稼働）	バックアップ保持のコスト（通常より安い）
データの鮮度	遅延分だけ古い（例: 30分前の状態）	任意の時点を選べるが復旧に時間がかかる
利用シナリオ	迅速な復旧が必要な論理障害対応	より柔軟に時点を指定して復旧したい場合

Amazon BedrockでAnthropicのClaudeモデルがCount Tokens APIをサポート

投稿日: 2025年08月22日

Original Article

何ができるようになったのか

Amazon BedrockでCount Tokens APIが利用可能になりました。これにより、推論を実行する前に、特定のモデル（現時点ではAnthropicのClaudeモデル）に送信するプロンプトや入力のトークン数を確認できるようになりました。

何が嬉しいのか

コスト管理の向上: API呼び出し前にトークン数を確認できるため、コストをより正確に予測できます。
使用量の最適化: トークン制限を事前に管理し、予期せぬスロットリング（使用制限）を回避することで、使用量を最適化できます。
効率的なプロンプト設計: プロンプトがモデルのコンテキスト長の制限内に収まるか事前に確認できるため、より効率的なプロンプトの最適化が可能になります。

これまでとどう変わるのか

これまで
- 推論を実行するまで、プロンプトの正確なトークン数が分からず、コスト予測が困難でした。
- モデルのコンテキスト長を超えてしまい、エラーが発生することがありました。
これから
- 推論前にCount Tokens APIを呼び出すことで、プロンプトのトークン数を正確に把握できます。
- これにより、コスト管理が容易になり、コンテキスト長のエラーを未然に防ぐことができます。

具体的なユースケース

ユーザーからの入力を受け取るアプリケーションで、トークン数がモデルの制限を超える場合に、事前にユーザーへフィードバックを返す。
大量のテキストを要約・分析する際に、処理前にトークン数を確認し、コストの見積もりを立てる。
プロンプトを動的に生成するシステムで、最終的なプロンプトがコンテキスト長の制限内に収まるように調整する。

Amazon EKS、AWSおよびコミュニティアドオンの名前空間設定を有効化

投稿日: 2025年08月22日

Original Article

何ができるようになったのか

Amazon Elastic Kubernetes Service (Amazon EKS) で、AWSおよびコミュニティが提供するアドオンに対して、Kubernetesの名前空間（namespace）を設定できるようになりました。

何が嬉しいのか

アドオンのインストール時にカスタムの名前空間を指定できるようになったことで、EKSクラスター内でのアドオンオブジェクトの整理と分離が向上します。この柔軟性により、アドオンを組織の運用ニーズや既存の名前空間戦略に合わせることが可能になり、アドオンの構成をより細かく制御できます。

これまでとどう変わるのか

これまで
- アドオンをインストールする際、名前空間を自由に指定できず、アドオンはデフォルトの場所に配置されていました。
これから
- アドオンのインストール時に、任意の名前空間を指定できるようになります。一度インストールしたアドオンの名前空間を変更するには、アドオンを削除して再作成する必要があります。

具体的なユースケース

監視用アドオンをmonitoring名前空間に、セキュリティアドオンをsecurity名前空間にインストールするなど、アドオンの役割ごとに環境を分離して管理する。
複数のチームやプロジェクトが同じクラスターを利用するマルチテナント環境で、それぞれのアドオンを専用の名前空間に配置し、リソースや権限の分離を徹底する。
既存の運用ポリシーで定められた名前空間の命名規則や構成に、EKSアドオンを準拠させたい場合。

Amazon SageMaker Unified StudioがプロジェクトにS3ファイル共有オプションを追加

投稿日: 2025年08月22日

Original Article

何ができるようになったのか

Amazon SageMaker Unified Studioのプロジェクトで、コードファイルを共有するためのストレージオプションとして、従来のGitリポジトリに加えてAmazon Simple Storage Service (S3) バケットが選択できるようになりました。S3がデフォルトのオプションとなります。

何が嬉しいのか

Gitの操作に依存することなく、分析や機械学習のワークフローで共同作業が簡単になります。特に、Gitの管理よりも分析や機械学習の作業自体に集中したいデータサイエンスチームにとって、プロジェクトの成果物を共有するための共同ワークスペースを維持しやすくなるというメリットがあります。

これまでとどう変わるのか

これまで
- プロジェクト内のコードファイルを共有する方法は、主にGitリポジトリ（GitHub, GitLab, Bitbucket Cloud）に依存していました。
これから
- Gitリポジトリに加えてAmazon S3をファイル共有の選択肢として利用できるようになります。これにより、JupyterLab、Code Editor、SQLクエリエディタなど、SageMaker Unified Studio内のどのツールで作業していても、ファイルの一貫したビューが提供され、コードの作成、編集、共有が容易になります。

具体的なユースケース

Gitの複雑な操作を避けたいデータサイエンスチームが、分析や機械学習のモデル開発に集中しつつ、プロジェクトメンバー間でコードやノートブックを簡単に共有・共同編集する。

AWS Neuron SDK 2.25.0 の発表

投稿日: 2025年08月21日

元記事

何ができるようになったのか

AWS Neuron SDK 2.25.0が一般提供開始されました。このリリースには、推論ワークロードとパフォーマンスモニタリングに関する改善が含まれています。
主な新機能は以下の通りです。

推論における長いシーケンス処理のためのコンテキストおよびデータ並列処理のサポート
長いシーケンス処理のためのチャンク化されたアテンションのサポート
neuron-lsおよびneuron-monitor APIの更新（ノードアフィニティとデバイス使用率に関する詳細情報）
高速なテンソル操作のための自動エイリアシング（ベータ版）
分離されたサービングの改善（ベータ版）
Neuronでの推論およびトレーニングワークロード用のアップグレードされたAMIとDeep Learning Containersの提供

何が嬉しいのか

このアップデートにより、AWS InferentiaおよびTrainiumインスタンス上での推論ワークロードのパフォーマンスが向上し、より効率的なパフォーマンス監視が可能になります。特に、長いシーケンスを持つ大規模モデルの処理能力が向上し、開発者はデバイスの使用状況をより詳細に把握できるようになります。

これまでとどう変わるのか

これまで
- 長いシーケンスを持つモデルの推論処理には、特別な工夫や制限がありました。
- パフォーマンス監視ツールで得られるノードやデバイスに関する情報が限定的でした。
- テンソル操作の最適化は手動で行う必要がありました。
これから
- コンテキスト/データ並列処理やチャンク化アテンションがネイティブでサポートされ、長いシーケンスの処理が容易になります。
- neuron-lsやneuron-monitor APIを通じて、ノードアフィニティやデバイス使用率に関するより詳細な情報を取得できます。
- 自動エイリアシング機能（ベータ版）により、テンソル操作が高速化されます。

具体的なユースケース

AWS InferentiaおよびTrainiumインスタンスを使用した、大規模言語モデル（LLM）などのAI/MLモデルの推論実行
Neuronデバイス上での機械学習モデルのトレーニング
長文のドキュメント要約や分析など、長いシーケ- ンスデータを扱うアプリケーションの実行
Neuronデバイスのパフォーマンスと使用率を詳細に監視し、リソースの最適化を行うケース

NeuronとCUDAの違いを聞いてみました。

項目	GPU (NVIDIA + CUDA)	AWS Neuron SDK (Inferentia / Trainium)
提供元	NVIDIA	AWS
主なハードウェア	A100, H100, RTXシリーズなど	Inferentia (推論), Trainium (学習)
ソフトウェアスタック	CUDA, cuDNN, TensorRT	Neuron Compiler, Neuron Runtime, Neuron Tools
対応フレームワーク	PyTorch, TensorFlow, JAX など	PyTorch, TensorFlow, Hugging Face Transformers
利用場所	オンプレ/クラウド (AWS, GCP, Azureなど)	AWS クラウド専用
特徴	広く普及、豊富なエコシステム、高性能	AWS最適化、高いコスト効率、クラウドネイティブ
主な用途	汎用的なAI学習・推論	大規模モデルの学習・推論を低コストで運用
メリット	ツール・ライブラリが充実、広範なサポート	AWS環境で安価に大規模AIを動かせる
デメリット	GPU高騰・供給不足の影響を受けやすい	AWS専用、オンプレでは使えない

AWS IoT Coreがカスタマーマネージドキーをサポート開始

投稿日: 2025年08月21日

Original Article

何ができるようになったのか

AWS IoT Coreで、AWS Key Management Service (KMS) を利用したカスタマーマネージドキー (CMK) がサポートされるようになりました。これにより、IoT Coreに保存されているデータをユーザー自身の暗号化キーで暗号化することが可能になります。

何が嬉しいのか

この機能強化により、暗号化キーの作成、ローテーション、モニタリング、削除といったライフサイクル全体を、ユーザーがより詳細に制御できるようになります。また、IoTアプリケーションに影響を与えることなく、組織のセキュリティ要件を満たすのに役立ちます。

これまでとどう変わるのか

これまで
- データはAWSが管理するキーによって暗号化されており、ユーザーはキーのライフサイクルを直接管理できませんでした。
これから
- ユーザー自身の暗号化キー（CMK）を使用してデータを暗号化できるようになります。CMKを選択した場合、サービスが既存のデータを自動的に再暗号化し、IoTの運用を中断させることなく移行できます。

具体的なユースケース

厳格なセキュリティやコンプライアンス要件を持つ組織が、自社で暗号化キーを完全に管理・監査する必要がある場合。
独自のキーローテーションポリシーを適用するなど、暗号化キーのライフサイクルを細かく制御したい場合。

さいごに

個人的には「Amazon RDS for PostgreSQLが遅延読み取りレプリカをサポート開始」が刺さりました。遅延レプリカを立てるのでお金がかかり、札束で殴る系ですが、こういうレプリカを持って置けるとすぐに切り戻せていいですね。