2026/4/9 9:00:00 ~ 2026/4/10 9:00:00 (JST)

最近の発表

Amazon Bedrock now supports cost allocation by IAM user and role

Amazon Bedrockは、AWSのコストと使用状況レポート2.0（CUR 2.0）とコストエクスプローラーで、IAMユーザーやIAMロールなどのIAMプリンシパルによるコスト配分をサポートするようになりました。これにより、お客様はユーザー、チーム、プロジェクト、およびアプリケーション全体にわたる Bedrock モデルの推論コストを理解し、帰属させることができます。\n 今回の発表により、お客様はIAMユーザーとロールにチーム、プロジェクト、コストセンターなどの属性をタグ付けし、それらをコスト配分タグとして有効化し、Cost ExplorerのタグまたはCUR 2.0の行項目レベルでBedrockモデルの推論コストを分析できるようになります。まず始めに、請求とコスト管理コンソールで IAM ユーザーとロールにタグを付け、コスト配分タグとして有効化してください。次に CUR 2.0 データエクスポートを作成し、「発信者 ID (IAM プリンシパル) 割り当てデータを含める」を選択するか、Cost Explorer でタグでフィルタリングします。 この機能は、Amazon Bedrock が利用できるすべての AWS 商用リージョンで利用できます。詳細については、「コスト配分に IAM プリンシパルを使用する」ドキュメントを参照してください。Amazon Bedrock を使い始めるには、Amazon Bedrock のドキュメントをご覧ください。

Amazon OpenSearch Service supports Managed Prometheus and agent tracing

Amazon OpenSearch Service では、メトリクス、ログ、トレース、AI エージェントトレースを 1 つのインターフェイスにまとめた統合オブザーバビリティエクスペリエンスが提供されるようになりました。このリリースでは、Amazon Managed Service for Prometheus とのネイティブ統合と包括的なエージェントトレーシング機能が導入され、プレミアムオブザーバビリティプラットフォームによる法外なコストと、断片化されたツールによる運用の複雑さという 2 つの課題が解決されました。サイト信頼性エンジニア、DevOps エンジニア、プラットフォームエンジニアリングチームは、コストのかかるデータの重複や、複数のツール間での絶え間ないコンテキスト切り替えなしに、オブザーバビリティスタックを統合できるようになりました。\n OpenSearch UI のオブザーバビリティワークスペースのログやトレースとともに、ネイティブ PromQL 構文を使用して、データを重複させずに Prometheus メトリクスを直接クエリできるようになりました。REDメトリクス（レート、エラー、期間）とOpenTelemetry GenAIセマンティック規約を使用したAIエージェントトレーシングを利用した新しいアプリケーション監視ワークフローを組み合わせることで、運用チームはツールを切り替えることなく、スロートレースをアプリケーションログに関連付けたり、Prometheusメトリックをサービスダッシュボードに重ねたり、LLMエージェントの実行を追跡したりできます。このライブクエリアーキテクチャは、優れた運用性を維持しながら、プレミアムプラットフォームと比較して大幅なコスト削減を実現します。

新しい統合オブザーバビリティエクスペリエンスは、米国東部（バージニア北部、オハイオ）、米国西部（北カリフォルニア、オレゴン）、アジア太平洋（香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京）、ヨーロッパ（フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム）、カナダ（中部）、南米（サンパウロ）の20のAWSリージョンでOpenSearch UIで利用できます。

詳細については、OpenSearch Service のオブザーバビリティドキュメントとダイレクトクエリのドキュメントをご覧ください。

Amazon S3 Lifecycle pauses actions on objects that are unable to replicate

Amazon S3 Lifecycle では、レプリケーションに失敗したオブジェクトに対する有効期限切れアクションと移行アクションが防止され、ライフサイクルルールで定義されたアクションを使用してレプリケーション設定や権限の変更を調整できるようになりました。\n 権限やレプリケーション設定が正しくないと、オブジェクトがレプリケートされない可能性があります。この変更により、定義したライフサイクルルールのいずれかに一致していても、S3 ライフサイクルはレプリケーションに失敗したオブジェクトを期限切れにしたり、移行したりしなくなります。レプリケーション設定または権限を修正したら、S3 バッチレプリケーションを使用して以前に失敗したオブジェクトをレプリケートできます。レプリケーションが成功すると、S3 Lifecycle は設定されたルールに従ってこれらのオブジェクトを自動的に処理します。

この変更は、AWS 中国、AWS GovCloud (米国) リージョンを含む 37 の AWS リージョンの既存および新規の S3 ライフサイクル設定すべてに自動的に適用されます。現在、この変更をデプロイ中であり、近日中にデプロイを完了する予定です。詳細については、S3 ライフサイクルのドキュメントと S3 レプリケーションのトラブルシューティングドキュメントをご覧ください。

Amazon RDS Blue/Green Deployments now supports Amazon RDS Proxy

Amazon RDS Blue/Green デプロイメントは Amazon RDS プロキシをサポートするようになり、DNS 伝播の遅延をなくすことで、スイッチオーバー中のアプリケーションリカバリを迅速に行えるようになりました。Blue/Green Deployments では、フルマネージド型のステージング環境 (グリーン) が作成され、本番環境での変更をデプロイしてテストできるとともに、現在の本番データベース (Blue) を安全に保ちながら、本番環境の変更をデプロイしてテストできます。準備が整ったら、新しい実稼働環境に切り替えることができ、アプリケーションは設定を変更せずに直ちにアクセスできるようになります。\n 単一リージョン構成の Blue/Green Deployment の切り替え中、RDS プロキシはデータベースインスタンスをアクティブに監視し、Green 環境がいつ新しい実稼働環境になるかを検出します。これにより RDS Proxy は接続を Green 環境にすばやくリダイレクトできるため、アプリケーションのリカバリを迅速に行うことができます。ドライバーを変更したり、既存のアプリケーション設定を変更したりする必要はありません。 Amazon RDS プロキシを使用した Amazon RDS ブルー/グリーンデプロイメントは、RDS プロキシが利用可能なすべての商用 AWS リージョンで、MySQL 互換の Amazon Aurora、PostgreSQL 互換の Amazon Aurora、MySQL 用の Amazon RDS、PostgreSQL 用の Amazon RDS、および MariaDB 用 Amazon RDS で利用できます。 数回クリックするだけで、Amazon RDS コンソールまたは Amazon CLI から RDS ブルー/グリーンデプロイメントを使用してデータベースを更新できます。詳細については、Amazon RDS ドキュメントの「ブルー/グリーンデプロイメントの概要」を参照してください。

AWS Marketplace announces the Discovery API for programmatic access to catalog data

本日、AWS Marketplace は Discovery API を発表しました。これにより、SaaS、AI エージェントとツール、AMI、コンテナ、機械学習モデルなど、AWS Marketplace カタログ全体の製品および価格情報にプログラムでアクセスできるようになります。\n Discovery API を使用すると、購入者はカタログデータを社内ポータルに埋め込んだり、調達ツールに最新の価格設定やオファー条件を盛り込んだり、ベンダー評価ワークフローを合理化したりできます。売り手とチャネルパートナーは、商品リスト、公開価格、非公開オファーの詳細を自社のWebサイトやストアフロントで直接表示できるため、顧客がパートナー体験を離れることなく閲覧、比較、購入に移ることができます。 この API では、公開オファーと非公開オファーの製品説明、カテゴリ、価格設定、オファー条件にアクセスできるので、組織が AWS Marketplace を通じてソフトウェアをどのように発見して調達するかに応じたエクスペリエンスを構築できます。 AWS Marketplace Discovery API は、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびヨーロッパ (アイルランド) で利用できます。 AWS アカウントの IAM 権限を設定し、AWS SDK を通じて API を呼び出すことから始めることができます。詳細については、AWS マーケットプレイスディスカバリー API リファレンスを参照してください。

AWS Agent Registry for centralized agent discovery and governance is now available in Preview

Amazon Bedrock AgentCore から利用できる AWS エージェントレジストリは、現在プレビュー段階にあります。これは、組織内のエージェント、ツール、スキル、MCP サーバー、カスタムリソース用のプライベートで管理されたカタログおよび検出レイヤーです。これにより、チームは自分の AI 環境を完全に可視化できるようになり、既存の機能を再構築する代わりに既存のエージェントやツールを発見できるようになります。レジストリには、AgentCore コンソール UI や API (AWS CLI、AWS SDK) を介してアクセスすることも、ビルダーが IDE から直接クエリを実行したり呼び出したりできる MCP サーバーとしてアクセスすることもできます。レジストリは IAM ベースと OAuth (カスタム JWT) ベースのアクセスの両方をサポートしています。\n チームはコンソールまたは API を使用して手動でリソースを登録することも、URL ベースの検出を使用してツールスキーマや機能の説明などのメタデータをライブの MCP サーバーまたはエージェントエンドポイントから自動的に取得することもできます。記録は承認ワークフローを経て、管理者は発見される前に記録を承認できます。また、レジストリを既存の承認ワークフローに接続してガバナンスポリシーを適用できます。AWS CloudTrail では、すべてのレジストリへのアクセスと管理アクションの完全な監査証跡が提供されるため、コンプライアンスとセキュリティ監視が確実に行われます。発見のため、レジストリにはセマンティック検索とキーワード検索の両方が用意されているため、開発者はユースケースを自然言語で説明することでエージェントをすばやく見つけることができます。

AWS Agent Registry (プレビュー) は、AgentCore が利用可能な 5 つの AWS リージョン (米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、ヨーロッパ (アイルランド)、米国東部 (バージニア北部) で利用できます。レジストリの詳細はブログで学び、ドキュメントを使って詳しく調べてください。

Amazon OpenSearch Serverless now supports Zstandard (zstd) codec for index compression

Amazon OpenSearch Serverless は、インデックスストレージ用の Zstandard コーデックをサポートするようになりました。これにより、ストレージコストとクエリパフォーマンスの間のトレードオフをお客様がより細かく制御できるようになりました。今回の発表により、お客様は Zstandard 圧縮を設定して、デフォルトの LZ4 コーデックと比較してインデックスサイズを最大 32% 削減できるようになり、データ集約型ワークロードのマネージドストレージコストを下げることができます。\n Amazon OpenSearch Serverless で大規模なログ分析、オブザーバビリティパイプライン、時系列ワークロードを実行しているお客様は、データ量が多いためにストレージの効率性が大きなコスト要因となる Zstandard 圧縮から最も恩恵を受けることができます。Amazon OpenSearch サーバーレスでは、ZStandard 圧縮アルゴリズムを zstd と zstd_no_dict という 2 種類のモードで利用できます。お客様は圧縮レベルを調整して特定のニーズのバランスを取ることができます。低いレベル (レベル 1 など) ではインデックス作成のスループットとクエリレイテンシーへの影響を最小限に抑えながらストレージを大幅に節約でき、高いレベル (レベル 6 など) ではインデックスの速度は遅くなりますが、圧縮率は最大になります。

現在、Amazon OpenSearch サーバーレスがサポートされているすべての AWS リージョンで、標準コーデックのサポートが利用可能です。まずは、作成時にインデックス設定でこれらのコーデックを指定できます。詳細については、Amazon OpenSearch サーバーレスのドキュメントを参照してください。

Amazon EC2 Capacity Manager now supports tag-based dimensions

本日より、Amazon EC2 Capacity Manager はタグベースのディメンションをサポートし、EC2 リソースのタグを使用してキャパシティメトリックスをグループ化し、フィルタリングできるようになりました。EC2 Capacity Manager は、オンデマンドインスタンス、スポットインスタンス、キャパシティ予約のキャパシティ使用量をモニタリングし、最適化するのに役立ちます。今回の発表では、新しい組み込みディメンションとして Account Name も導入されました。\n 環境、チーム、コストセンターなど、最大 5 つのカスタムタグキーを有効にして、リージョン、インスタンスタイプ、アベイラビリティーゾーンなどの組み込みディメンションと併用することで、コンソールと API のタグ値でキャパシティメトリクスをグループ化してフィルタリングしたり、新しく作成された S3 データエクスポートにタグデータを追加列として追加したりできます。キャパシティマネージャーには、デフォルトでキャパシティマネージャーが提供する 4 つのタグ (EC2 Auto Scaling グループ名、EKS クラスター名、EKS Kubernetes ノードプール、Karpenter ノードプール) も含まれています。新しいアカウント名ディメンションにより、組織全体のクロスアカウントキャパシティデータを分析する際に、アカウントを簡単に識別できるようになりました。

この機能は、EC2 Capacity Manager が利用可能なすべての AWS リージョンで利用できます。開始するには、Capacity Manager の [設定] タブに移動して [タグキーの管理] を選択するか、AWS CLI を使用してください。詳細については、Amazon EC2 ユーザーガイドの「監視対象タグキーの管理」を参照してください。Amazon EC2 キャパシティマネージャーの詳細については、EC2 キャパシティマネージャーのドキュメントを参照してください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Big Data Blog

Containers

AWS for Industries

Artificial Intelligence

Networking & Content Delivery

AWS Storage Blog

Open Source Project

AWS CLI

Amplify for iOS

Amplify for Android

Karpenter