2026/6/11 9:00:00 ~ 2026/6/12 9:00:00 (JST)
最近の発表
[Amazon CloudWatch Application Signals now supports infrastructure, logs, and traces context for faster troubleshooting](https://aws.amazon.com/about-aws/whats-new/2026/06/cloudwatch-application-signals-supports infrastructure-logs-traces-context-for-faster troubleshooting/)
Amazon CloudWatch Application Signals では、アプリケーションマップにサービスヘルスランキングが導入され、サービス概要ページに新しいインフラストラクチャ、ログ、トレースタブが導入されました。これらの機能により、オペレーターは不健全なサービスをトリアージし、基盤となるコンピューティング環境の検査、ログスニペット、トレースの詳細を 1 か所で行うことができるため、ツールを切り替えることなく根本原因を簡単に見つけることができます。\n 顧客は Application Signals を使用して分散アプリケーションの状態を監視しますが、サービスが異常な理由を特定するには、多くの場合 CloudWatch に任せてインフラストラクチャデータを別々のツール間で相関させる必要がありました。アプリケーションマップでは、サービスが状態別にランク付けされ、Amazon EKS、Amazon ECS、AWS Lambda、Amazon EC2 のサービスノードにランタイムインジケーターが表示されるようになりました。また、コンピューティングとランタイム環境、そのコンポーネント、および関連するモニタリングツールへのディープリンクを含む厳選されたデフォルトメトリクスを表示する新しいインフラストラクチャタブも追加されました。さらに、サービス概要ページには [インフラストラクチャ]、[ログ]、[トレース] タブがあり、オペレーターがアプリケーションのコンテキストで問題を特定しやすくなっています。アプリケーションマップのヘルスランクのサービスと、新しいインフラストラクチャ、ログ、トレースタブに表示されるようになったため、オペレーターは最も劣化しているサービスを即座に特定し、コンピューティング環境を詳しく調べたり、エラーを生成するログスニペットや、遅くなったり失敗したりしているトランザクションを、すべてApplication Signalsから離れることなく調べることができます。これらの機能は Amazon EKS、Amazon ECS、AWS Lambda、Amazon EC2 で実行されているワークロードにまたがるため、チームは症状から根本原因まで数時間ではなく数分で移行できます。 これらの機能は Amazon CloudWatch アプリケーションシグナルがサポートされているすべての AWS リージョンで利用できます。この機能の詳細については、Amazon CloudWatch アプリケーションシグナルのドキュメントを参照してください。料金の詳細については、Amazon CloudWatch の料金表ページを参照してください。
Amazon Aurora now supports PostgreSQL major version 18
Amazon Aurora PostgreSQL 互換エディションは、バージョン 18.3 以降の PostgreSQL メジャーバージョン 18 をサポートするようになりました。このリリースでは、コミュニティによるクエリのパフォーマンスとデータベース管理が改善され、大量の整数の集合に対して高速でメモリ効率の高い集合演算を実行する新しい拡張である pg_roaringbitmap のサポートが導入されました。これにより、オーディエンスのセグメンテーション、タグベースのフィルタリング、権限チェックなどのユースケースを、アプリケーション層の処理なしでデータベース内で直接実行できるようになります。\n PostgreSQL 18 では B ツリースキップスキャンが導入されました。これにより、クエリのパフォーマンスが向上し、インデックスストレージとメンテナンスのオーバーヘッドが削減されます。メジャーバージョンアップグレードでは、オプティマイザ統計が保持されるようになったため、統計が再生成されるのを待たずに、アップグレード後すぐに一貫したクエリパフォーマンスが保証されます。ロジカルレプリケーションでは、大量のトランザクションを並行してストリーミングできるようになったため、レプリケーションの遅延が軽減され、ダウンストリームのシステムが常に最新の状態に保たれます。詳細については、Amazon Aurora PostgreSQL リリースノートを参照してください。 RDS Blue/Green デプロイ、インプレースアップグレード、スナップショットの復元など、いくつかのオプションを使用してデータベースをアップグレードできます。データベースインスタンスのアップグレードについて詳しくは、Amazon Aurora ユーザーガイドをご覧ください。Aurora PostgreSQL 18.3 は、すべての商用 AWS リージョンと AWS GovCloud (米国) リージョンでご利用いただけます。 Amazon Aurora は PostgreSQL と MySQL との完全な互換性を備え、世界規模で比類のない高いパフォーマンスと可用性を実現するように設計されています。組み込みのセキュリティ、継続的バックアップ、サーバーレスコンピューティング、最大 15 個のリードレプリカ、自動マルチリージョンレプリケーション、その他の AWS サービスとの統合が可能です。Amazon Aurora を使い始めるには、入門ページをご覧ください。
AWS Elastic Beanstalk console now integrates CloudWatch Logs in the Logs tab
AWS Elastic Beanstalk では、Elastic Beanstalk コンソールの環境ログタブに CloudWatch ログを直接統合できるようになりました。以前は、お客様は CloudWatch コンソールに移動して環境に関連するロググループとログストリームを探す必要がありました。今回のローンチにより、お客様は Elastic Beanstalk コンソールを離れることなく CloudWatch ログイベントを確認できるようになりました。 \n 「ログ」タブには、環境がログをストリーミングするロググループと、aws/elasticbeanstalk/ /* プレフィックスに一致するロググループが表示されます。お客様はロググループを選択してそのログストリームを表示できます。デフォルトでは最新のアクティブストリームが選択されます。ログストリームのドロップダウンでは、ストリームを切り替えたり、結果をフィルタリングしたりできます。詳細な分析を行うには、「CloudWatch で表示」ドロップダウンに CloudWatch コンソールのロググループ、ログストリーム、または CloudWatch Logs Insights への直接リンクが表示されます。
この機能は、Elastic Beanstalk を利用できるすべての AWS 商用リージョンと AWS GovCloud (米国) リージョンのすべての Elastic Beanstalk プラットフォームブランチで利用できます。サポートされているリージョンの全リストについては、「AWS リージョン」を参照してください。
Amazon CloudWatch で Elastic Beanstalk を使用する方法の詳細については、AWS Elastic Beanstalk 開発者ガイドを参照してください。詳細については、AWS Elastic Beanstalk 製品ページをご覧ください。
Amazon MWAA Serverless now supports Amazon EventBridge notifications
Apache Airflow (MWAA) 向け Amazon マネージドワークフロー (MWAA) サーバーレスが Amazon EventBridge のワークフローとタスク状態変更イベントをサポートするようになりました。これにより、データエンジニアリングチームとプラットフォームチームは、Apache Airflow ワークフローのイベント駆動型自動化を構築できます。\n 以前は、ワークフローの実行を監視するには、カスタムのポーリングロジックまたは手動による監視が必要でした。今回のローンチにより、MWAA Serverless は、開始済み、実行中、成功、失敗などの状態間でワークフローが遷移したときや、個々のタスクの状態がスケジュール済み、成功、失敗、再試行待ちなどの変化があったときにイベントを発行できるようになりました。この機能を使用すると、既存のワークフローをさらに自動化できます。たとえば、EventBridge通知を使用して本番ワークフローが失敗したときにアラートをトリガーしたり、上流のワークフローが成功したときに依存パイプラインを自動的に再開したり、コンプライアンスや監査のために状態遷移をAmazon S3に記録したりできます。
この機能は、Amazon MWAA サーバーレスが利用できるすべての AWS リージョンで利用できます。サポートされているリージョンの全リストについては、Amazon MWAA サーバーレスユーザーガイドの「リージョン」を参照してください。価格の詳細については、「Amazon EventBridge 料金表」を参照してください。詳細については、Amazon MWAA サーバーレスユーザーガイドの「Amazon MWAA サーバーレスのモニタリング」と、Amazon EventBridge イベントリファレンスの「Amazon MWAA サーバーレスイベント」を参照してください。
Amazon Managed Service for Prometheus now supports Native Histograms
Amazon Managed Service for Prometheus が Prometheus ネイティブヒストグラムの取り込み、保存、クエリをサポートするようになりました。これにより、お客様は従来のヒストグラムよりも精度が高くカーディナリティが低く高解像度のメトリクス分布をキャプチャできるようになりました。DevOpsエンジニア、サイト信頼性エンジニア、レイテンシー、リクエスト期間、その他のディストリビューションを監視するプラットフォームチームは、バケット境界を事前に定義したり、カーディナリティの高い時系列を管理したりしなくても、より正確なパーセンタイル計算を行えるようになりました。\n ネイティブヒストグラムでは、指数バケットを使用して自動的に解像度をデータに合わせるため、バケット境界ごとに 1 つの系列を使用するのではなく、ディストリビューション全体を 1 つの時系列に格納できます。これにより、アクティブな系列数が減ります。以前は22個の時系列を必要としていた20個のバケットを含む従来のヒストグラムでは、必要な時系列は1つだけになり、histogram_quantile () などの関数からより正確なテールレイテンシーの洞察が得られます。ネイティブヒストグラムを既存のクラシックヒストグラムと共に段階的に採用できるため、現在の監視を中断することなく、自分のペースでワークロードを移行できます。Amazon Managed Service for Prometheus では、実際の観測値を含むデータが入力されたバケットのみに基づいてネイティブヒストグラムが計測され、課金されます。そのため、スパースディストリビューションで空のバケットに対して料金を支払う必要はありません。
この機能は、プロメテウス向け Amazon マネージドサービスが提供されているすべての AWS リージョンで利用できます。開始するには、プロメテウス向け Amazon マネージドサービスのドキュメントを参照してください。ネイティブヒストグラムの料金については、プロメテウス向け Amazon マネージドサービスの料金ページをご覧ください。
Amazon Managed Service for Prometheus now supports out of order sample ingestion
Amazon Managed Service for Prometheus では、順不同のサンプルインジェストとワークスペースレベルのルールクエリオフセットがサポートされるようになりました。すべてのワークスペースのデフォルトの順序外時間枠は 1 分で、厳密な時系列から外れて到着したメトリックスサンプルもワークスペースで受け入れることができます。この時間枠は取り込みパターンに合わせて調整することも、0 に設定してこの機能を無効にして順序どおりのないサンプルを破棄することもできます。また、ルール評価クエリの実行前に遅延が発生するグローバルルールクエリオフセットを設定して、遅れて到着したサンプルをルールが実行される前に取り込むことができるようにすることもできます。\n これらの機能を組み合わせることで、分散型コレクター、バッチエクスポート、または変動するネットワークレイテンシーを使用するワークロードのデータ損失を減らし、アラート精度を向上させることができます。順不同のサンプルサポートにより、遅れて到着したデータポイントは破棄されるのではなく取り込まれ、メトリクスの完全性が維持されます。ルールクエリのオフセットは、予想される取り込み遅延を補います。これがないと、ルールは即座に評価され、まだ到着していないサンプルを見逃してしまい、すべてのメトリクスが到着した後に評価された同じ式とは異なる結果になってしまう可能性があります。CloudWatch が新たに販売した 2 つのメトリクス、アウトオブオーダリングレートとアウトオブオーダーサンプルエイジにより、取り込みパターンを可視化できるため、ワークロードに合わせて両方の設定を調整できます。
順序外サンプル取り込みとルールクエリオフセットは、プロメテウス向け Amazon マネージドサービスが一般的に利用できるすべての AWS リージョンで利用できます。まず、AWS コンソール、API、または CLI を使用して、ワークスペース設定でアウトオブオーダー時間枠とルーラークエリオフセットを設定します。詳細については、プロメテウス向け Amazon マネージドサービスのユーザードキュメントを参照してください。
AWS announces AWS Workload Credentials Provider
AWS は AWS ワークロード認証情報プロバイダーを発表しました。これは軽量なクライアントサイドプロバイダーで、AWS Certificate Manager (ACM) からエクスポートされた証明書のデプロイと AWS Secrets Manager からのシークレットのローカルキャッシュを AWS および AWS 以外のワークロードにわたって自動化します。\n 以前は、ACM からパブリック証明書またはプライベート証明書をエクスポートするお客様は、Amazon EventBridge を使用して更新を検出して更新された証明書をデプロイするカスタムオートメーションを構築する必要がありました。認証局ブラウザフォーラム (CA/B) の指示に従って公開証明書の有効期間が短くなるにつれて、このカスタム自動化を大規模に維持することが難しくなる可能性があります。AWS Workload Credentials Provider は、シークレットと証明書の両方をワークロードに配布および自動化するのに役立つ単一のプロバイダーを提供することで、この複雑さを解消します。証明書の ARN を使用して設定し、ファイルパスやサーバーのリロード動作などのオプションを指定します。その後、プロバイダーが証明書のエクスポートとデプロイを自動的に処理して、有効期限関連の障害を防ぎます。Windows と Linux 上で動作し、Apache と NGINX のウェブサーバーをサポートします。 シークレットキャッシュに関しては、プロバイダーは AWS Secrets Manager Agent との完全な下位互換性を維持しているため、同じ統合プロバイダーを通じて AWS と AWS 以外のワークロード全体でアプリケーションシークレットをローカルに安全にキャッシュできます。 AWS ワークロード認証情報プロバイダーはオープンソースで、GitHub で利用できます。すべての AWS リージョンで、エクスポート可能な ACM 証明書と Secrets Manager で使用できます。詳細については、AWS 証明書マネージャーのドキュメントまたは AWS シークレットマネージャーのドキュメントをご覧ください。
OpenAI GPT-5.4 and GPT-5.5 models now available in US East (N. Virginia) on Amazon Bedrock
本日、AWS は OpenAI の GPT-5.4 モデルと GPT-5.5 モデルの提供範囲を拡大したことを発表しました。これらのモデルは Amazon Bedrock で米国東部 (バージニア北部) リージョンで利用できるようになりました。GPT-5.4 と GPT-5.5 では、推論、コーディング、コンピューターの使用、ドキュメントワークフロー、長時間実行されるエージェントタスクを網羅するジェネレーティブ AI アプリケーションを構築できます。\n GPT-5.5 は OpenAI の最も有能なモデルで、高度なコーディング、リサーチ、分析、ソフトウェア運用、文書ワークフロー、長時間実行されるエージェントタスク向けに設計されています。自由形式の目標を理解し、ツールを使用し、より長いワークフローを推論し、曖昧さを乗り越え、複雑なタスクを少ないオーケストレーションで完了まで実行することができます。GPT-5.4は、コンテキストを解釈し、ツールと相互作用し、ソフトウェア環境を運用し、複数のステップにわたる出力を検証するプロダクションアプリケーションに、最先端の推論、コーディング、コンピューター使用、ロングコンテキストワークフロー、およびツールの使用をもたらします。どちらのモデルも、27万2000トークンのコンテキストウィンドウをサポートし、テキストと画像の入力を受け付け、サーバー側とクライアント側のツール呼び出し、プロジェクト、レスポンスストリーミングをサポートするResponses APIを通じて利用できます。 今回の発表により、GPT-5.4 と GPT-5.5 は他の AWS リージョンでも利用できるようになりました。開始するには、ドキュメントの GPT-5.5 と GPT-5.4 のモデルカードをご覧ください。
AWS Blogs
Amazon Web Services ブログ (日本語)
- 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編(#3/8)開催レポート
- 第一三共株式会社 × QSimulate: データ駆動型創薬 (D4) における QM-FEP 活用 — QSimulate × AWS で切り拓く親和性予測の高度化
- AWS Summit Japan 2026 ブース紹介 生産ラインの未来
- 生成AIで開発ツール操作を自動化 – Kiro × MCP Server × dSPACE ControlDesk
- Amazon DynamoDB グローバルテーブルのベストプラクティス – パート 1: 運用準備
- AWS DevOps Agent によるネットワークインシデント対応の自動化
- Kiro の Spec が速く、そしてスマートになりました
- Amazon DynamoDB グローバルテーブルのベストプラクティス – パート 3: AWS Fault Injection Service によるリージョナルレジリエンスの検証
- Amazon DynamoDB グローバルテーブルのベストプラクティス – Part 2: フェイルオーバー戦略
- Amazon Redshift Data Sharing を活用した位置情報ビッグデータ分析基盤の進化 ~KDDI Location Analyzer の新機能開発事例~
AWS Big Data Blog
AWS Compute Blog
- AWS Nitro 分離エンジン:AWS Nitro システム内のハイパーバイザーの正式な検証
- AWS ローカルゾーンと Outposts を使用して、RAG を活用した AI ソリューションをエッジで構築
- AWS コンピュートオプティマイザーの適切なサイズ設定で EC2 コストを最適化
AWS Database Blog
Desktop and Application Streaming
- ワークスポットと Amazon WorkSpaces コアマネージドインスタンスをセットアップする方法
- Amazon WorkSpaces Personal: Microsoft Entra ID と Intune による最新の管理アプローチ
AWS DevOps & Developer Productivity Blog
AWS for Industries
Artificial Intelligence
- オンデマンドパイプラインとバッチパイプラインでデータを動的に抽出
- Agent-Evalkit を使用して AI エージェントを体系的に評価する
- トレンドをすばやく見つけて、よりスマートに並べ替える:Amazon Quickのスパークラインとカスタムソートのロック解除
- Amazon Bedrock データオートメーションでブループリント抽出の精度を最適化
- フロンティアチームが AI ネイティブ開発をどのように改革しているか