みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 ところで、AWS Builders Online というイベントがまもなく開催されるのですが、参加されたことはありますでしょうか。最新の生成 AI サービスから実践的なデータ分析手法まで、ビジネスですぐに活用できる知識を得られるところや、実務で直面する課題に対する具体的な解決策を学べるようになっており、初学者の方にはおすすめのイベントとなっています。イベント登録は こちら から可能となっています。オンラインで参加可能ですので、熱い夏は自宅で AWS 学習に時間を費やしてみるのもよいかもしれませんね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月21日週の主要なアップデート   7/21(月) Amazon Braket が IQM の新しい 54 量子ビット量子プロセッサを追加 Amazon Braket で IQM の新しい 54 量子ビット量子プロセッサ「Emerald」が利用可能になりました。Emerald は超伝導技術を使った最新の量子コンピューティングデバイスで、従来より高い精度で量子アルゴリズムの研究・実験が可能です。Braket SDK や Qiskit などの人気フレームワークで量子プログラムを構築でき、量子機械学習や最適化問題の解決に活用できます。ストックホルムリージョンから利用でき、研究機関向けには AWS クレジットプログラムも提供されています。詳細は こちらの Blog 記事をご参照ください。 Amazon Connect が外部音声コネクタの日単位料金を発表 Amazon Connect の外部音声コネクタが 1 日 100 ドルの日次課金になりました。従来は、1コネクタあたり月額 3,100 ドルだったところが、細かい単位での課金が可能になり、コスト管理がしやすくなります。このコネクタには 2 種類あり、転送コネクタは既存の音声システムと Amazon Connect を連携させ、分析コネクタは他システムの音声データを Contact Lens で分析できます。既存のコールセンターシステムを活用しながら Amazon Connect の AI 機能を利用したい企業にとって便利な機能です。詳細は こちらのドキュメントをご参照ください。 Amazon SQS がマルチテナントワークロード向けのフェアキューを導入 Amazon SQS で fair queues (フェアキュー) 機能が提供開始されました。従来、マルチテナント環境で一つのテナントが大量メッセージを送信すると他のテナントの処理が遅延する問題がありましたが、この機能により各テナントの処理時間を公平に保てます。メッセージ送信時にメッセージグループ ID を指定するだけで利用でき、既存システムへの影響なく導入可能です。SaaS アプリや複数リソースのイベント処理に特に有効で、全商用リージョンで利用できます。詳細は こちらの Blog 記事をご参照ください。 7/22(火) Amazon MQ が RabbitMQ 向けに Graviton3 ベースの M7g インスタンスをサポート開始 Amazon MQ の RabbitMQ で新しい Graviton3 ベースの M7g インスタンスが利用可能になりました。従来の M5 インスタンスと比較して最大 50% のワークロード容量向上と最大 85% のスループット改善を実現します。M7g.medium から M7g.16xlarge まで幅広いサイズを選択でき、評価用途から本格的な本番環境まで対応可能です。また既存の M5 ブローカーからのインプレースアップグレードにも対応しており、ダウンタイムを最小限に抑えて性能向上を図れる点が魅力です。詳細は こちらのドキュメントをご参照ください。 AWS Audit Manager がコンプライアンスインサイト向上のためエビデンス収集を強化 AWS Audit Manager が 14 の標準フレームワークを更新し、エビデンス収集機能を強化しました。SOC 2 や PCI DSS v4.0 などの主要フレームワークでエビデンスの関連性が向上し、コンプライアンス検証がより効率的になります。多くの顧客で検出結果の数が最適化され、関連コストの削減も期待できます。6 月 6 日以降に作成したアセスメントは自動的に更新版が適用されますが、それ以前のものは新規作成が必要です。詳細は こちらのドキュメントをご参照ください。 Amazon Timestream for InfluxDB が 24xlarge メモリ最適化インスタンスをサポート開始 Amazon Timestream for InfluxDB で 24xlarge メモリ最適化インスタンスが利用可能になりました。96 vCPU、768 GiB のメモリ、最大 40 Gbps のネットワーク帯域幅を提供し、大規模な時系列データベースワークロードに対応できます。産業用テレメトリー、IoT 分析、金融取引プラットフォームなど、高速な応答時間が求められる用途に最適です。東京リージョンを含む複数のリージョンで利用でき、コンソール、CLI、SDK、CloudFormation から簡単にプロビジョニングできます。 7/23(水) Amazon RDS for PostgreSQL と Amazon Redshift のゼロ ETL 統合が一般提供開始 Amazon RDS for PostgreSQL と Amazon Redshift の zero-ETL 統合が一般提供開始されました。従来は複雑なデータパイプラインを構築する必要がありましたが、この機能により PostgreSQL のデータがほぼリアルタイムで Redshift に自動レプリケーションされ、すぐに分析できるようになります。複数の統合作成やデータフィルタリング、CloudFormation での自動化も可能で、データ分析の効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle と Amazon Redshift のゼロ ETL 統合 Amazon RDS for Oracle と Amazon Redshift の zero-ETL 統合機能が提供開始されました。従来は複雑な ETL パイプラインを構築する必要がありましたが、この機能により Oracle データベースに書き込まれたデータが数秒で Redshift に自動レプリケーションされます。これにより、ペタバイト規模のトランザクションデータをリアルタイムに近い形で分析や機械学習に活用できるようになります。特定のテーブルやデータベースを選択してレプリケーションでき、Oracle Database 19c で利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT SiteWise Query API が高度な SQL サポートと ODBC ドライバを追加 AWS IoT SiteWise Query API が大幅に強化され、高度な SQL 機能と ODBC ドライバーが追加されました。これまで複雑だった工業データの分析が簡単になり、文字列操作や集約関数、日時計算などの高度な SQL 操作が可能です。さらに ODBC ドライバーにより Tableau や Power BI、Excel との直接連携も実現し、カスタム開発なしでデータ可視化やレポート作成ができます。東京リージョンを含む 9 つのリージョンで利用可能で、工業データから迅速にビジネス洞察を得られるようになりました。詳細は こちらのドキュメントをご参照ください。 7/24(木) Amazon CloudWatch が IPv6 サポートを追加 Amazon CloudWatch が IPv6 サポートを開始しました。これまで IPv4 のみだったメトリクス取得やアラーム、ダッシュボード機能が IPv6 でも利用可能になります。IPv4 と IPv6 両方に対応するデュアルスタック環境で CloudWatch を運用でき、アドレス枯渇の心配がなく、IPv6 ネイティブなアプリケーションのモニタリングが簡単になります。詳細は こちらのドキュメントをご参照ください。 AWS Glue が Microsoft Dynamics 365 をデータソースとしてサポート開始 AWS Glue で Microsoft Dynamics 365 のネイティブコネクターが利用可能になりました。これまで複雑だった ERP や CRM システムからのデータ抽出が簡単になり、ETL ジョブの構築時間を大幅に短縮できます。企業の販売データや顧客情報を AWS のデータ分析基盤に効率的に統合でき、より包括的なビジネス分析が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon ElastiCache での Bloom フィルターサポートの発表 Amazon ElastiCache で Bloom filter が利用可能になりました。これまでキャッシュ内のアイテム存在確認には Set データ型を使用していましたが、Bloom filter を使うことで 98% 以上のメモリ効率化を実現できます。確率的データ構造により高速な存在チェックが可能で、大量データの重複判定やキャッシュ効率向上に効果的です。全リージョンで追加コストなしで利用できます。詳細は こちらのドキュメントをご参照ください。 7/25(金) AWS HealthOmics がワークフロー作成のためのサードパーティ Git リポジトリサポートを導入 AWS HealthOmics で Git リポジトリ連携機能が追加されました。GitHub、GitLab、Bitbucket からワークフロー定義を直接取得でき、従来必要だった手動ステージングが不要になります。バージョン管理と再現性が向上し、既存の開発プロセスを維持しながら効率的に活用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が メッセージテンプレート添付ファイル向けの AWS CloudFormation をサポート開始 Amazon Connect の Outbound Campaign で利用するメッセージテンプレートの添付ファイル (画像やドキュメント) が AWS CloudFormation で管理できるようになりました。これまで手動で作成・管理していた添付ファイルを、コードで自動化して複数環境 (本番・テスト・ステージング) に一貫してデプロイできます。メール配信キャンペーンでの画像添付などがより効率的になり、インフラ管理の負担軽減とヒューマンエラー削減が期待できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が予測編集 UI を開始 Amazon Connect で予測編集 UI が新登場し、コールセンターのプランナーが予測調整を簡単に行えるようになりました。従来は複雑だった予測値の変更が、新しい UI で直感的に操作可能になります。マーケティングキャンペーン期間中に火曜・水曜の 12 時から 14 時の予測を 15% 増加させるなど、具体的な日時・キュー・チャネルを指定した調整ができます。需要変動への迅速な対応と計画精度の向上を実現し、エージェントスケジューリング機能が利用可能な全リージョンで提供開始されました。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

双方向コミュニケーションは強固な関係構築の礎となります。リアクティブなカスタマーサポートもあらゆる種類の組織にとって重要ですが、プロアクティブな顧客へのアプローチによってカスタマーエクスペリエンスをさらに向上させることができます。しかし、組織は適切なメッセージを、適切な人に、適切なタイミングで送信する必要があります。 Amazon Connect のイノベーション により、組織は個々の顧客ニーズに合わせたターゲット型コミュニケーションを開始できます。 Amazon Connect Customer Profiles からのデータを活用することで、企業は今や顧客、オーディエンスをセグメント化し、 Amazon Connect Outbound Campaigns によりパーソナライズされたメッセージを作成して、事前に顧客とコミュニケーションを取り、信頼とロイヤルティを育み、大切な顧客との永続的な絆を築くことができます。 プロアクティブなコミュニケーションにおける従来の課題 今日、効果的なプロアクティブコミュニケーション戦略の実装を目指す企業は、数多くの課題に直面しています。組織は多くの場合、複数のシステムからのデータを組み合わせてターゲットとなる顧客セグメントを作成し、そのプロセスは IT や保守運用チームに依存しています。このプロセスは時間がかかるだけでなく、古いデータを生成する可能性があり、アウトバウンドコミュニケーションのルールやキャンペーンを頻繁に変更する必要を生じさせます。運用のスケーリングは困難になり、最新の顧客情報へのアクセスも限られているため、パーソナライゼーションの質が損なわれます。 Amazon Connect による動的でパーソナライズされた顧客エンゲージメント Amazon Connect を使えば、企業は、プロアクティブなパーソナライズされたコミュニケーションの提供、そして売上成長の促進やカスタマーサービスへの問い合わせを未然に防ぐことができます。組織は、 Amazon Connect Customer Profiles で、生成 AI を活用して、さまざまなデータソースから顧客データを簡単に集約、統合された顧客レコードを作成できます。70 種類以上のデータソースから顧客データをリアルタイムにプロファイルに組み合わせることもできます。 Amazon Connect Outbound Campaigns の機能と組み合わせ、組織は Amazon Connect Customer Profiles の属性をアウトバウンドキャンペーンのセグメントで使用でき、これらは動的に最新の状態に保たれます。 顧客セグメント、チャネル、スケジュールを定義すれば、Amazon Connect の管理コンソールから直接、チャネルをまたいだキャンペーンをすばやく作成および起動できます。これにはメッセージングのテンプレート管理が含まれます。セグメンテーションに使用されるのと同じ動的属性を使用して、 アウトバウンドキャンペーン のメッセージ自体をパーソナライズすることもでき、 Amazon Connect Customer Profiles は、組織全体の顧客ライフサイクルを支援する最新の顧客情報の拡張可能な情報源となります。 さらに、企業は継続的に顧客データと洞察を確認し、改善したいと考えているでしょう。 Amazon Connect Outbound Campaigns は、キャンペーンのパフォーマンスをリアルタイムで表示します。これには、キャンペーンの配信状況、応答率、または通話の結果（例：本人応答、留守番電話、話中・ビジー、目的完了）が含まれます。以前は、顧客はエンドツーエンドのパフォーマンスメトリクスを取得するために、データを組み合わせてカスタムダッシュボードを構築するための技術リソースが必要でした。現在は、これらのメトリクスを 1 か所で利用可能です。 様々なユースケースでの活用 これらの機能により、ビジネスユーザーは技術的な担当者に依存したり、複数のツール間でカスタム統合を構築・設定することなく、コミュニケーションを調整できるようになります。これらの機能はすべて Amazon Connect の Web コンソール内で利用でき、組織がターゲットを絞ったタイムリーなアウトバウンドコミュニケーションを提供するのに役立ちます。 サービスの予約確認、支払いの督促、またはカスタマージャーニーにおけるタッチポイントなどのユースケースで Amazon Connect は組織が一貫したコミュニケーションを維持し、価値ある関係を育成することを支援します。組織は今や、スケールできるパーソナライズされたオムニチャネルキャンペーンを簡単に作成できます。このようなコミュニケーションにより、特別オファーの案内やかご落ち・カート離脱のリマインドなど、マーケティング機会にも発展させることができます。 Amazon Connect Outbound Campaigns の料金は、アウトバウンドコミュニケーションの数と使用されるチャネルに基づいています。Customer Profiles と Outbound Campaigns を使用することで、企業は適切なタイミングで顧客にエンゲージし、プロアクティブでパーソナライズされたアウトリーチを通じて、より深く意味のある関係を育むことができます。 Amazon Connect でのプロアクティブコミュニケーションに関する技術ブログ で、開始方法について詳しく学びましょう。 Amazon Connect Outbound Campaigns と Customer Profiles を使用して、適切なタイミングで複数のチャネルを通じて適切な顧客と動的にエンゲージしましょう。詳細については、 お問い合わせ ください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先日は AWS Summit New York 2025 で 多くの AI エージェント関連サービスやプログラムが発表 されましたね。お客様から期待の声を多くいただいたのと同時に、私自身も非常にワクワクしました。 7/30（水）に 「 Amazon Q CLI でゲームを作ろうキャンペーンの報告と最新情報 update & Kiro のご紹介 」というイベントが予定されています。AI エージェントの最新情報が聞けるイベントとなってますのでご興味のある方はぜひご参加ください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、7 月 21 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。ニュースが中心の週となっています。 さまざまなニュース AWS Summit New York関連のニュース ブログ記事「AWS、AWS Summit New York 2025 にて AI エージェント構築に向けた新たなイノベーションを発表」を公開 AWS Summit New York 2025 にて AI エージェント関連の新しいサービスやプログラムがいくつか発表されました。本ブログでは、Amazon Bedrock AgentCore、AWS Marketplace の新カテゴリー、生成AIイノベーションセンターへの追加投資、Amazon Nova の新しいカスタマイズ機能など、Summit で発表された代表的な内容をまとめて紹介しています。 ブログ記事「Amazon Bedrock AgentCore のご紹介: AI エージェントをあらゆる規模で安全にデプロイおよび運用する (プレビュー)」を公開 Amazon Bedrock AgentCore（プレビュー）が発表されました。Amazon Bedrock AgentCore は、AI エージェントをあらゆる規模で安全にデプロイおよび運用するためのプラットフォームです。本ブログでは、AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、Code Interpreter の7つのコンポーネントの詳細と、Strands Agents を使用したカスタマーサポートアシスタントの実装例を解説しています。各機能の理解に向けては AgentCore サンプル GitHub リポジトリ  での体験がおすすめです！ ブログ記事「Amazon SageMaker AI での Amazon Nova のカスタマイズの発表」を公開 Amazon SageMaker AI で Amazon Nova のカスタマイズ機能が発表されました。Amazon Nova Micro、Nova Lite、Nova Pro を継続事前学習、教師ありファインチューニング、アライメントなどの手法を使ってカスタマイズできます。本ブログでは、各カスタマイズ手法の概要や、 Amazon SageMaker Studio 上で直接選好最適化を用いて Nova Micro モデルをカスタマイズする例について説明しています。 ブログ記事「TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に」を公開 TwelveLabs の動画理解モデル Marengo（動画埋め込みモデル）と Pegasus（動画言語モデル）が Amazon Bedrock で利用可能になりました。「試合の最初のタッチダウンを見せて」のような自然言語による動画検索や、タイトル、要約、章、ハイライトなどの説明テキスト生成が可能になります。本ブログでは、これらのモデルの機能とAmazon Bedrock での TwelveLabs モデルの開始方法ついて紹介しています。 ブログ記事「AWS AI League: 新しい究極の AI 対決で学習し、イノベーションを起こし、競い合う」を公開 AWS AI League という競い合いながら学ぶ、新しい生成 AI 学習プログラムが開始されました。組織がプライベートトーナメントを開催し、チームが協力して実際のビジネス課題を解決する AI ソリューションを構築します。本ブログでは、プログラムの構成や申し込み方法について説明しています。 ブログ記事「Amazon S3 Vectors と Amazon OpenSearch Service によるベクトル検索の最適化」を公開 本ブログでは、Amazon S3 Vectors と Amazon OpenSearch Service の統合機能（プレビュー）について解説しています。大規模なベクトル埋め込みを保存・検索する際のレイテンシー、コスト、精度のトレードオフという課題を解決するために、頻繁にクエリされないベクトルをS3 Vectorsに保持し、ハイブリッド検索や集計などの高度な検索機能にはOpenSearchを使用する最適化手法について説明しています。既存のベクトル検索システムの最適化を検討している方は是非ご覧ください。 その他のニュース ブログ記事「AWS Price List が自然言語でアップグレードされました：AWS Pricing MCP サーバーの紹介」を公開 AWS Price List が自然言語でアップグレードされ、AWS Pricing MCP サーバーがオープンソースツールとしてリリースされました。Model Context Protocol（MCP）を通じて、「us-west-2 で 3 つの m5.large インスタンスを実行するコストは？」のような自然言語による料金問い合わせが可能になりました。本ブログでは、240 を超える AWS サービスの複雑な料金情報を AI アシスタントとの会話で簡単に取得できる方法について説明しています。 ブログ記事「AWS Transform での Export for vCenter の使用」を公開 Export for vCenter という新しい AWS オープンソース Python プロジェクトが発表されました。AWS Transform for VMware で利用するために vCenter からインベントリデータをエクスポートするツールです。RVTools の代替手段として開発され、AWS Transform が必要とするデータのみを取得します。本ブログでは、セットアップ手順と実行手順ついて解説しています。 ブログ記事「AWS Serverless MCP Server の紹介：AI を活用してモダンアプリケーションを開発する」を公開 AWS Serverless MCP Server は、サーバーレス開発に特化したコンテキストガイダンスを提供し、開発者がアーキテクチャ、実装、デプロイに関する情報に基づいた決定を行えるよう支援するソリューションです。本ブログでは、Serverless MCP Server の概要と設定方法、サーバーレスアプリケーションの作成をテーマにした実際の動作イメージについて説明しています。 ブログ記事「JWT を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG 実装」を公開 本ブログでは、JWT と Fine-Grained Access Control（FGAC）を使用した Amazon Bedrock と Amazon OpenSearch Service による SaaS 向けマルチテナント RAG の実装方法について解説しています。厳密なテナントデータアクセス分離が必要なケースにおいては、ぜひ本文にあるアーキテクチャを参考にしてみてください。 ブログ記事「AWS Summit Japan 2025 で次世代のフードマネジメントに挑戦！ AI と IoT で実現する スマート廃棄物管理」を公開 本ブログでは、AWS Summit Japan 2025 の Builders Fair で展示された、AI と IoT を活用したスマート廃棄物管理システムについて報告しています。ゴミ箱に何がどれくらい廃棄されたのかを可視化する展示内容となっており、展示期間中の約 9 時間で 162件、149kgの廃棄物を処理し、認識精度88.4%を達成しました。Amazon Bedrock、AWS IoT Core、Amazon Timestream for LiveAnalytics などを使ったアーキテクチャが記載されています。 ブログ記事「AWS Cloud Quest に無料でプレイ可能な「生成 AI プラクティショナー」ロール追加 ＆ 全ロールが日本語化されました」を公開 AWS Cloud Quest に「生成 AI プラクティショナー」ロールが追加され、全ロールが日本語化されました。既存の「Cloud Practitioner」ロールに加えて合計20チャレンジ分の実際のAWSアカウントを使用した演習環境が無料で利用できるようになりました。ぜひ「 AWS Skill Builder 」に登録しお試しください。 ブログ記事「【開催報告】Neuron Community – Vol.2」を公開 本ブログでは、2025 年 7 月 15 日に開催された「Neuron Community – Vol.2」の様子をレポートしています。オープニングでは Discord上のNeuron Community の成長について、ライトニングトークでは国立情報学研究所様による「LLM-jp Chatbot Arena」での Amazon EC2 Trn1 インスタンス活用事例について発表された様子が紹介されています。 サービスアップデート Amazon EC2 P6-B200 インスタンスが米国東部 (バージニア北部) で利用可能になりました Amazon EC2 で新しい P6-B200 インスタンスが米国東部 (バージニア北部) リージョンで利用開始されました。NVIDIA Blackwell GPU を 8 基搭載し、従来の P5en インスタンスと比較して最大 2 倍の性能を実現します。AI モデルの学習や推論処理において、より高速で効率的な処理が可能になり、大規模な機械学習プロジェクトでの計算時間の短縮が期待できます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

7 月 21 日、ホーチミン市からシンガポールに戻る途中に記事を書いています。すばらしい一週間だったと思っていたところなので、少し振り返ってみたいと思います。7 月 21 日週、私は初めて Corne キーボードを試し、水準を確実に引き上げている講演者たちと一緒に AWS Summit Jakarta のリハーサルを終えてから、ベトナムに移動して AWS Community Day Vietnam にテクニカル基調講演の講演者として参加しました。このエネルギッシュな会合では、複数のテクニカルトラックとネットワーキングセッションを通じて、何百人ものクラウドプラクティショナーと AWS 愛好家が知識を共有しました。 私が行ったのは、「Reinvent perspective as modern developers」というタイトルの基調講演で、 サーバーレス や コンテナ の他、 Amazon Q Developer と Kiro を使用して知識習得時間を短縮し、生産性を高める方法についてお話ししました。数人の AWS コミュニティビルダーやコミュニティ開発者と話し合う機会もあり、Amazon Q Developer を実際に使用してアプリケーション構築の課題にどのように対処したのかを共有してくれました。クラウド開発ジャーニーにおける大幅な生産性向上と知識習得の円滑化を強調した人も幾人かいました。 シンガポールに戻るにあたり、私はおいしい cà phê sữa đá (アイスミルクコーヒー) の思い出だけでなく、この活気に満ちたクラウドイノベーターのコミュニティから得た新鮮な視点やインスピレーションも持ち返っています。 Kiro の紹介 先週のハイライトの 1 つは、何と言っても Kiro です。Kiro は、AI エージェントと連携するための簡素化された開発者エクスペリエンスを通じて、コンセプトから本番環境の実現を支援する AI IDE です。Kiro は、適切な計画と明瞭性を用いてプロトタイプを本番環境システムに移行させるために役立つ spec (スペック) や hook (フック) といった機能で「バイブコーディング」のさらに先を進みます。 ウェイティングリストに登録 して、提供開始時に通知を受け取りましょう。 7 月 14 日週の AWS リリース その他のニュースには、ニューヨークで開催された AWS Summit があり、ここでいくつかのサービスがリリースされました。こちらは、私が注目したいくつかのリリースです。 AWS Lambda のコンソールと IDE の統合機能やリモートデバッグ機能でサーバーレス開発を簡素化 – AWS Lambda で、ブラウザから Visual Studio Code への開発者ワークフローを合理化する、コンソールと IDE の統合機能とリモートデバッグ機能の提供が開始されました。これらの機能強化により、時間のかかるコンテキストの切り替えが不要になるとともに、開発者が好みの IDE 環境で Lambda 関数を直接デバッグできるようになります。 Amazon ECS の新しい組み込みブルー/グリーンデプロイで安全なソフトウェアリリースを迅速化 – Amazon ECS で、コンテナ化されたアプリケーションデプロイの安全性と一貫性を向上させる、組み込みブルー/グリーンデプロイの提供が開始されました。この機能により、カスタムデプロイツールを構築する必要がなくなると同時に、ロールバック機能やデプロイライフサイクルフックを使用することで、自信を持ってソフトウェアアップデートをリリースできます。 Amazon Bedrock AgentCore の紹介: AI エージェントをあらゆる規模でセキュアにデプロイして運用 – Amazon Bedrock AgentCore は包括的な一連のエンタープライズグレードサービスで、開発者が任意のフレームワークとモデルを使用して AI エージェントの大規模なデプロイをすばやく安全に行えるようにします。AgentCore Runtime、Memory、Observability、Identity、Gateway、Browser、および Code Interpreter の各サービスが含まれており、これらが連携してインフラストラクチャの複雑性を解消します。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットで AWS の使用を開始し、検証できます – AWS 無料利用枠で、新規のお客様に最大 200 USD の AWS クレジットを付与する強化特典が提供されるようになりました。サインアップ時に 100 USD を受け取り、EC2、RDS、Lambda、Bedrock、AWS Budgets を使ったアクティビティを完了すると、さらに 100 USD を獲得できるため、コストを発生させずに AWS サービスを簡単に検証できるようになります。 Amazon EventBridge の新しいログ記録でイベントドリブンのアプリケーションを監視してデバッグ – Amazon EventBridge で、強化されたログ記録機能の提供が開始されました。この機能は、成功、失敗、ステータスコードに関する詳細情報を伴う包括的なイベントライフサイクル追跡を実現します。この新しいオブザーバビリティ機能は、イベントジャーニーの全体を可視化することで、マイクロサービスとイベントドリブンアーキテクチャの監視における課題に対処します。 Amazon S3 Vectors の紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ – Amazon S3 Vectors は、耐久性を備えた専用ベクトルストレージソリューションで、ベクトルのアップロード、保存、クエリにかかるコストの総額を最大 90% 削減できます。Amazon S3 Vectors は、大規模なベクトルデータセットを保存し、AI アプリケーションに 1 秒未満のクエリパフォーマンスを提供するためのネイティブサポートを備えた初のクラウドオブジェクトストアです。 Amazon EKS が、クラスターあたり 10 万個のノードをサポートする超大規模な AI/ML ワークロードを実現 – Amazon EKS が、単一のクラスター内で最大 10 万個のワーカーノードをサポートするようになりました。このため、お客様は最大 160 万個の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU にスケールアップできます。この業界トップクラスのスケール機能により、お客様は Kubernetes 適合性と使い慣れた開発者エクスペリエンスを維持しながら、1 兆パラメータモデルをトレーニングし、AGI 開発を進展させることができます。 AWS Builder Center より もしまだご存知なければ、AWS は先日 AWS Builder Center と統合された community.aws をローンチしました。こちらは、私のおすすめ記事です。 How I Optimized My AWS Bill by Deleting My Account (Corey Quinn 著) – AWS コスト最適化戦略と、請求金額を削減するために検討することもあり得る強硬手段に関する、ユーモアとインサイトにあふれた見解です。 How to setup MCP with UV in Python the right way (Du’An Lightfoot 著) – 最適な開発ワークフローのために、Python で UV パッケージマネージャーを使用して Model Context Protocol (MCP) をセットアップする実践ガイドです。 Extending My Blog with Translations by Amazon Nova (Jimmy Dahlqvist 著) – ブログ記事に翻訳機能を追加する Amazon Nova の機能を利用して、世界中の読者にリーチする方法を学びましょう。 How I used Amazon Q CLI to fix Amazon Q CLI error “Amazon Q is having trouble responding right now” (Matias Kreder 著) – Amazon Q CLI を使用して Amazon Q 独自のエラーを解決する方法を実証する実践的なトラブルシューティングガイドで、AI 支援のデバッグの力を明らかにします。 近日開催される AWS イベント カレンダーを確認して、今後の AWS や AWS コミュニティのイベントにサインアップしましょう。 AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルならば、 All Builders Welcome Grant プログラム に申し込むこともできます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。台北 (7 月 29 日)、 メキシコシティ (8 月 6 日)、 ジャカルタ (6 月 26～27 日) など、最寄りの都市で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 シンガポール (8 月 2 日)、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 今後開催されるすべての AWS 主導の対面イベント と 開発者向けの仮想イベント をご覧いただけます。 7 月 21 日週のニュースは以上です。7 月 28 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ビルダー ID に参加: builder.aws.com で AWS Builder ジャーニーを始めましょう 原文は こちら です。

7 月 16 日、 ニューヨーク市で開催された AWS Summit で、エージェンティック AI 担当 AWS VP の Swami Sivasubramanian が、本番環境ですぐに使える AI エージェントをお客様が大規模に提供できるようにする方法について、基調講演を行いました。イベントでの主な発表を以下のとおりご紹介します。 Amazon Bedrock AgentCore のご紹介: あらゆる規模の AI エージェントを安全にデプロイして運用 (プレビュー) Amazon Bedrock AgentCore を使用すると、エンタープライズグレードのセキュリティを備えた AI エージェントの迅速なデプロイとスケーリングが可能になります。メモリ管理、ID 制御、ツール統合が提供されているため、オープンソースのフレームワークや基盤モデルを使用しながら、開発を効率化できます。 Amazon SageMaker AI での Amazon Nova カスタマイズの発表 AWS では、モデルトレーニングのすべての段階で SageMaker AI を使用して、Amazon Nova 基盤モデルを広範囲にカスタマイズできるようになりました。すぐに使える SageMaker レシピとして利用できるこれらの機能により、お客様はトレーニング前とトレーニング後の両方で Nova 理解モデルを適応させることができます。これには、業界全体のビジネス固有の要件により適切に対応するための微調整レシピや調整レシピも含まれます。 AWS 無料利用枠の更新: 新規のお客様は最大 200 USD のクレジットを使用した AWS の利用開始が可能に AWS は無料利用枠プログラムを強化し、新規ユーザー向けに最大 200 ドルのクレジットを用意しています。サインアップ時に 100 USD、Amazon EC2、Amazon Bedrock、AWS Budgets などのサービスでアクティビティを完了すると、さらに 100 ドルを獲得できます。 TwelveLabs の動画理解モデルが Amazon Bedrock で利用可能に TwelveLabs の動画理解モデルを Amazon Bedrock で利用できるようになりました。これにより、お客様は動画の検索、シーンの分類、コンテンツの要約、インサイトの抽出を、正確かつ確実に行うことができます。 Amazon S3 メタデータがすべての S3 オブジェクトのメタデータのサポートを開始 Amazon S3 Metadata では、ライブインベントリテーブルとジャーナルテーブルを通じて S3 バケット内のすべてのオブジェクトを包括的に可視化できるようになりました。これにより、変更から 1 時間以内の自動更新を使用して、既存のオブジェクトと新しいオブジェクトの両方を SQL ベースで分析できるようになりました。 Amazon S3 Vectors のご紹介: 大規模なネイティブベクトルサポートを備えた初のクラウドストレージ (プレビュー) Amazon S3 Vectors は、大規模なベクトルの保存とクエリをネイティブサポートする新しいクラウドオブジェクトストアです。従来のアプローチと比較して最大 90% のコスト削減を実現すると同時に、Amazon Bedrock ナレッジベース、SageMaker、AI アプリケーション用 OpenSearch とシームレスに統合できます。 Amazon SageMaker の新機能で、データからインサイトへのパスを合理化 Amazon SageMaker は、ダッシュボードの作成、ガバナンス、共有のための Amazon QuickSight 統合、ドキュメントとメディアファイルをカタログ化するための Amazon S3 非構造化データ統合、Lakehouse からの自動データオンボーディングという 3 つの新機能を導入しました。これらの機能は、構造化データと非構造化データの管理、視覚化、ガバナンスを単一のエクスペリエンスに統合することで、データサイロを排除します。 新しい Amazon EventBridge ログ記録で、イベントドリブンのアプリケーションをモニタリングおよびデバッグ Amazon EventBridge では、包括的なイベントライフサイクル追跡を提供する強化されたログ記録機能が提供されるようになりました。これにより、イベントが公開されたとき、ルールと照合されたとき、サブスクライバーに配信されたとき、または障害が発生したときを示す詳細なログを使用して、ユーザーがイベントドリブンのアプリケーションを監視およびトラブルシューティングできるようになります。 Amazon EKS がクラスターあたり 10 万ノードをサポートし、超大規模な AI/ML ワークロードを実現 Amazon EKS は現在、クラスターあたり 100,000 ノードまで拡張可能で、最大 160 万台の AWS Trainium アクセラレーターまたは 80 万個の NVIDIA GPU を使用して大規模な AI/ML ワークロードを実現しています。これにより、組織は Kubernetes との互換性と既存のツール統合を維持しながら、大規模な AI モデルのトレーニングと実行を効率的に行うことができます。 原文は こちら です。

本記事は米国時間 7 月 16 日に公開された「 AWS announces new innovations for building AI agents at AWS Summit New York 2025 」の日本語抄訳版です。 Amazon Bedrock AgentCore に加え、AWS Marketplace の新たなカテゴリーとAgentic AI開発の後押しに向けた1億米ドルの投資を発表 主なポイント： Amazon Bedrock AgentCore により、企業・組織は AgentCore の7つのコアサービスを活用し、安全な AI エージェントをエンタープライズ規模で導入・運用することが可能に AWS Marketplace の新カテゴリー追加により、企業・組織は有力プロバイダーによる AI エージェントやツールを簡単に見つけ、調達し、導入することが可能に 生成AIイノベーションセンター に 1 億米ドルを追加投資し、Agentic AI の開発・展開のさらなる加速を支援 Amazon Nova の新たなカスタマゼーション機能により、企業・組織のニーズにあった精度と柔軟性を実現 アマゾン ウェブ サービス（AWS）はこれまで、クラウドコンピューティングにおけるセキュリティ、信頼性、データプライバシーの基準を築いてきました。AWS は今回、AI エージェントの構築を支援する新たな機能とツールの発表により、同じ原則を Agentic AI にも適用します。お客様はこれにより、AWS の堅牢なテクノロジー基盤の上に AI エージェントを構築できるようになります。なかでも、Amazon Bedrock AgentCore は、お客様による高機能な AI エージェントのセキュアかつスケーラブルな導入・運用を支援するものです。 AWSで Agentic AI を統括するバイスプレジデントであるスワミ・シバスブラニアン（Swami Sivasubramanian） は AWS Summit New York の基調講演に登壇し、 AWS における Agentic AI 戦略 の要点を説明しました。AI エージェントは AI を活用して推論・計画・適応し、タスクを完了する自律的なソフトウェアシステムであり、あらゆる業界でイノベーションを加速させ、生産性を大きく向上させると述べました。 シバスブラニアンは次のように述べています。「これは複数の点で地殻変動のような大きな変化です。ソフトウェアの構築方法が根本から変わり、その展開・運用においても多くの新しい課題が浮上してきています。そして最も大きな影響として、ソフトウェアと世界との関わり方、そして私たちとソフトウェアの関係そのものが変わります」 Amazon Bedrock AgentCore で AI エージェントを大規模に展開・運用 AgentCore は高性能な AI エージェントを導入・運用するための、包括的なサービス群です。あらゆるAIフレームワークやモデルをご利用いただけます。 AI エージェントの導入を進めるなか、企業・組織は重要な課題に直面しています。それは、セキュリティ、信頼性、ガバナンスといったエンタープライズレベルの基準を満たしながら、デジタルの境界を越えて自律的に動作するシステムを構築することです。 AgentCore は、AI エージェントにおける概念実証（PoC）から本番運用に至るまでの重要なギャップを開発者が乗り越えるのを支援します。プロトタイプから、数百万ものエンドユーザーに対応できる拡張性の高いアプリケーションへと移行するための、多様な組み合わせが可能なソリューション群を提供します。Itaú Unibanco、Innovaccer、Boomi、Epsilon、Box といった AWS のお客様がすでに AgentCore を使った開発を始めています。 Amazon Bedrock AgentCore の主なサービス： AgentCore Runtime — エージェントには安全性を確保しつつ、変動するワークロードにも対応できる柔軟な実行環境が必要です。AgentCore Runtime は、低遅延でインタラクティブなエクスペリエンスと、業界最長となる最大8時間の複雑な非同期ワークロードの処理をサポートします。また、すべてのセッションを完全に分離可能な、唯一のフレームワーク非依存のサービスです。 AgentCore Memory — 人間が短期記憶と長期記憶の両方を活用するように、エージェントも効率的に動作するためには複雑なメモリ基盤が必要です。AgentCore Memory は、業界トップクラスの精度で短期記憶と長期記憶を提供し、開発者がコンテキストを理解するエージェントをより簡単に構築できるようにします。 AgentCore Identity — エージェントがユーザーのリクエストを実行するには、適切な認証を通じてツールやリソースへ安全にアクセスできる必要があります。AgentCore Identity は、Amazon Cognito、Microsoft Entra ID、Okta などユーザー認証とアクセスコントロールを一元管理を支援する、既存の アイデンティティ（ID） プロバイダーと連携し、シームレスかつ安全なエージェント認証を実現します。 AgentCore Gateway — AI エージェントが実世界のタスクを実行するには、多様なツールへのアクセスが欠かせません。AgentCore Gateway は、API、Lambda 関数、既存のサービスをエージェント対応のツールへ簡単に変換できる仕組みに加え、エージェントがツールを安全に発見・利用できる手段を提供します。 AgentCore Code Interpreter — AI エージェントが複雑な計算を実行、推論を検証し、データを処理し、ビジュアルを生成するためには、サンドボックス環境でコードを安全に記述・実行できる必要があります。AgentCore Code Interpreter を使えば、開発者は特定のインスタンスタイプやセッション設定を指定して、安全なコード実行環境を用意し、セキュリティ要件に対応することが可能です。 AgentCore Browser Tool — AgentCore Browser Tool は、モデルに依存しない高速かつ安全なクラウドベースのブラウザで、AI エージェントがフォーム入力やウェブサイトの操作といったタスクを大規模に実行できるようにします。 AgentCore Observability — 本番環境でのパフォーマンスを確保するには、エージェントのあらゆる動作を追跡・記録できることが重要です。AgentCore Observability は Amazon CloudWatch を基盤とし、主要なメトリクスに関するテレメトリーや組み込みダッシュボードを通じて、開発者にリアルタイムの可視性を提供します。また、既存のオブザーバビリティツールとも統合可能です。 企業のAIエージェント活用をよりシンプルにするAWS Marketplace 新カテゴリー シバスブラニアンは AWS Summit New Yorkで、 AWS Marketplace の新カテゴリー「AIエージェントとツール」の追加を発表しました。これにより、お客様は有力プロバイダーが提供する AI エージェントやツールを簡単に見つけ、調達し、導入・管理できるようになります。 AWS Marketplace の「AIエージェントとツール」カテゴリーを使えば、お客様は AI エージェントソリューションやツールをワンストップで検索・購入でき、AI 活用の取り組みを迅速に進めることができます。このカテゴリーを活用することで、すぐに統合できるツールを使って開発を加速できるだけでなく、エージェントの構築・運用・スケーリングを専門とする AWS プロフェッショナルサービスと連携しながら、AI 戦略を前進させることも可能です。 AWS 生成AIイノベーションセンターへの追加投資を発表 お客様による自律的な Agentic AI システムの開発を加速するため、AWS は 生成 AI イノベーションセンター に 2 回目となる 1 億米ドルの追加投資を行うことを 発表 しました。これは、過去 2 年間にわたって世界中の数千社に及ぶお客様を支援し、生産性の向上や顧客体験の変革を後押ししてきた実績を踏まえたものです。 例えば、 Warner Bros. Discovery Sports Europe は、Amazon Bedrock、Anthropic の Claude 3.5、その他の AWS サービスを活用し、自転車レースの実況担当者が素早く過去の記録などを調べることができる AI ソリューションを開発しました。また BMW は、2,300 万台以上に達するコネクテッドカーに対するネットワーク障害の診断方法を一新する AI ソリューションを AWS 上に構築しました。Syngenta や AstraZeneca といった企業も、Agentic AI によって業務に大きな変化をもたらしています。 AWS 生成AIイノベーションセンターには、AI サイエンティスト、ストラテジスト、エンジニアからなるグローバルチームが在籍しており、企業をはじめとするお客様やパートナーと直接連携しながら、AI 実装における最も複雑な課題の解決に取り組んでいます。 AWS Summit New York のその他の発表 Amazon Nova の新しいカスタマイズ機能：より高精度で柔軟なモデルの構築が可能に Amazon SageMaker AI 上で動作する Amazon Nova に 新たなカスタマイズ機能 が追加され、SageMaker HyperPod のサポートも加わりました。これにより、お客様は Nova を自社のニーズにさらに合わせて最適化できるようになります。また、 Nova Act SDK の 強化 を通じて、精度向上に加え、セキュリティやアクセス制御が拡張されました。これにより、開発者はウェブブラウザ上で確実に動作するエージェントを構築できるようになります。 Amazon S3 Vectors を発表 Amazon S3 Vectors は、AI ワークロードをサポートする初のクラウドオブジェクトストレージです。Amazon S3 Vectors により、お客様は従来の方法と比較し、ベクトルの保存とクエリのコストを最大 90% 削減できます。大規模なベクトルデータセットを保存・活用して AI を強化したり、S3 データのセマンティック検索において、コストパフォーマンスの高いソリューションを提供します。Amazon Bedrock Knowledge Bases や OpenSearch Service と連携し、検索拡張生成（RAG）やベクトル検索の運用を効率化・低コスト化します。 Kiro：プロトタイプからプロダクションまでを橋渡し Kiro は、AI エージェントを活用したソフトウェア開発に取り組む開発者向けの新しい IDE（統合開発環境）です。開発体験をシンプルにし、AI エージェントとのコラボレーションをより身近なものにします。Kiro を使えば、vibe coding だけでなく、Kiroスペックや Kiroフック といった機能を活用して、エージェントと一緒に詳細な設計を進めたり、テストの実行やドキュメント生成などのタスクを自動で実行するワークフローを起動したりできます。 Agentic な世界での構築を後押しする新たな MCP リソース Model Context Protocol（MCP） は、エージェントがデータソースやツール、メモリバンクなどに接続するための新たな標準仕様です。今回発表した ローカル AWS API MCP サーバー は、AWS の API 全体に関する知識を完全に備えており、開発者が AWS と連携しながら vibe coding を行えるようにします。これにより、あらゆるソフトウェアアシスタントが AWS に精通することがより簡単になります。さらに、2つ目のリソースとして提供される AWS Knowledge MCP サーバー は、AWS のドキュメントに関する包括的な知識を常に最新の状態で保持した MCP で、完全にマネージドかつ継続的に更新され、任意の MCP クライアントからリモートで利用可能です。 TwelveLabs の AI モデルが Amazon Bedrock で利用可能に TwelveLabsの AIモデル は、映像・音声・テキストを同時に処理することで、動画ライブラリを検索可能で活用しやすい資産へと変換します。お客様は自然言語のプロンプトを使って、目的のコンテンツを瞬時に見つけ、アクションをとることができるようになります。これらすべてが、AWS のセキュリティ、プライバシー、パフォーマンスのもとで提供されます。AWS は TwelveLabs のモデルを提供する初のクラウドプロバイダーです。 AWS と Meta がスタートアップ支援で連携 AWS と Meta は、Metaの基盤モデルである Llama を活用したAI アプリケーション構築を支援 するため、米国のスタートアップ 30 社を対象に、1 社あたり最大 20 万ドル分の AWS クレジットと、Meta および AWS の専門家による技術サポートを提供します。この 6 か月間のプログラムへの参加応募は、2025年8月8日までです。Llama モデルを使った最先端の AI アプリケーション開発を後押しすることで、AI イノベーションを加速させます。 Strands 1.0 により、AI エージェント同士の連携がより簡単に AWS は、オープンソース SDK Strands Agents のアップデートも発表しました。これは、複数の AI エージェントが連携して複雑な課題を解決するシステムを、これまでにないほど簡単に構築できる開発者向けツールです。従来は数か月かかっていた複雑な技術作業を、わずか数時間のプロセスに短縮できるため、企業はカスタマーサービス、データ分析、その他の高度なタスクを担う協調型 AI アシスタントのグループを構築しやすくなります。 ゲーミフィケーションで AI スキルを習得できる「AWS AI League」 AWS は、開発者が 生成AI を使って実世界の課題に挑戦しながら、組織内でのイノベーションに不可欠なスキルを習得できる「 AWS AI League 」を開始しました。このプログラムでは、開発者がファインチューニング、モデルのカスタマイズ、プロンプトエンジニアリングなどを実践的に学ぶため、最大 200 万ドル分の AWS クレジットを提供します。上位入賞者には、AWS re:Invent への全額負担の招待旅行や賞金が贈られます。 AWS、AI 時代のキャリアに備える若手人材育成に 300 万米ドルを投資 AWS は、6,600 以上の AWS Academy 加盟校の学生に対し、AWS Skill Builder の有料トレーニングコンテンツと AWS 認定試験の受験バウチャーを無償で提供し、AI 時代に求められるスキルの習得を支援します。また、Academy に属さない学生や新卒者も、将来有望なキャリア分野に関する調査レポートや、それにもとづくAWS Skill Builder 上の無料学習プランを活用してキャリア形成に活かすことができます。AWSは、初年度にグローバルで270万人の学生及び新卒者の参画を目標としています。

合併と買収 (M&A) は、事業を拡大し、製品ラインを多様化し、新しい市場を開拓する機会を組織にもたらします。ただし、旧来の IT システムの統合、厳しい規制への準拠、事業継続性の維持など、そこにはさまざまな課題が伴います。リソースの重複を排除し、プロセスを最適化して運用の一貫性を実現するのと同時に、コストを管理および最適化することは、合併を完了したり M&A 活動を行ったりした後にビジネス価値を最大化する上で、極めて重要な役割を果たします。 このブログ記事では、AWS Organizations を利用したM&A 後の AWS リソースとコストの最適化と管理に関するベストプラクティスと考慮事項について説明します。また、 Amazon S3 Storage Lens 、 AWS Compute Optimizer 、 AWS Cost Optimization Hub (コスト最適化ハブ) など、AWS Organizations が統合しているさまざまなコスト最適化サービスや分析サービスを紹介し、活用します。 前提条件 AWS Organizations 、 AWS Control Tower 、および AWS でのマルチアカウント設定 を理解していること その M&A に関連する買収元企業と買収先企業の両方について、AWS Organizations で設定されている organization (※訳注：一般的な意味での “組織” と区別するために本記事では “organization” と表記します) の構造を理解していること 合併元 organization からメイン organization へのアカウントの移行が完了していること ベストプラクティスと推奨事項 合併後の organization で適用可能なタグを評価し、リソースをグループ化してコストの一元管理を行う 合併後は、新たに合併されたビジネス内でタグを調整する戦略を立て、 Resource Groups を利用してプロジェクトや環境、コストセンターなどの特定の基準に基づいてAWS リソースの論理的なコレクションを作成する必要があります。それにより、アップデートの適用、アプリケーションのアップグレード、ネットワーク設定の調整などの一括アクションを実行でき、それと同時にリソース全体のコストを容易に追跡・管理することができます。また、コスト要因の特定、予算の設定、リソース使用の最適化も行えるため、最終的に AWS における潜在的なコスト削減につながる可能性もあります。 包括的な可視性を得るには、AWS Organizations を使用して一元化された”請求とコスト管理” のフレームワークを確立してください。AWS 上で実行されているアプリケーションがあり、リソースが EC2 インスタンス、RDS データベース、S3 バケットなどの複数のサービスに分散している場合を想定してみましょう。このアプリケーション用のリソースグループを作成し、すべてのリソースをグループ化することができます。これにより、グループ内のすべてのリソースの合計コストを確認できるようになり、 コストの集中箇所の特定 や、使用パターンの分析、実際の需要に基づいたリソースのサイズ適正化などを行うことが容易になります。また、利用できていないリソースや過剰な支出を削減することもできます。 例えば、リザーブドインスタンスやスポットインスタンスなどのコスト最適化戦略を グループ全体に適用して、コスト削減を最大化 することができます。AWS Resource Groups を使用して、リソースグループと呼ばれるキャパシティ予約の論理的なコレクションを作成できます。また、属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が異なるキャパシティ予約を 1 つのリソースグループに含めることもできます。キャパシティ予約のリソースグループを作成すると、個々のキャパシティ予約ではなく、キャパシティ予約のグループにインスタンスを割り当てることができます。キャパシティ予約のグループをターゲットとするインスタンスは、グループ内の任意のキャパシティ予約のうち属性 (インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン) が一致し、かつ他のインスタンスに割り当てられておらず利用可能なものとマッチングされます。 費用を正確に追跡するために、コストセンターを設けて、すべての AWS リソースに 一貫したコスト配分タグを実装 してください。例として、A 社と B 社が合併した後、「Project Alpha」と「Project Bravo」というワークロードが重複している各社のプロジェクトについて、コストの可視化を維持しながら AWS 環境を統合する必要がある場合を考えてみましょう。 コスト配分タグは以下のシナリオで役に立ちます: ”Project“, ”Environment“, ”CostCenter“, ”Application“, ”Department“ などの統一されたタグ構造を定義します。 リソースを移行し、統一された構造に従ってタグ付けをし直します。例えば、“Project Alpha” リソースには “Project=Alpha”, “Environment=Production”, “CostCenter=IT” のようにタグ付けし、“Project Bravo” リソースには “Project=Bravo”, “Environment=Live”, “Department=Engineering” のようにタグ付けします。 重複しているワークロードを識別し、両方のプロジェクト名でタグ付けします。例えば、共有データベースリソースには “Project=Alpha”, “Project=Bravo”, “Environment=Production”, “CostCenter=IT”, “Department=Engineering” のようにタグ付けします。 AWS Cost Explorer を使用して、さまざまなタグの組み合わせに基づいてコストレポートを生成します。これにより、共有コストを含め、各プロジェクト、環境、コストセンター、または部門に関連するコストを可視化できます。 共有リソースへの比例配分を含め、それぞれのプロジェクト、コストセンター、または部門に正確にコストを帰属させるコスト配分モデルまたはチャージバックモデルを実装します。 合併後の organization におけるリソースの重複を特定および削減する organization が合併する際、クラウド環境間で重複が発生し、無駄な支出につながることがよくあります。包括的なレビューを行うことで、リソースの余剰を明らかにし、最適な統合を実現することができます。 まず AWS Organizations で有効にした AWS Cost Optimization Hub (コスト最適化ハブ) を活用して、合併後の事業体全体の AWS コスト最適化推奨事項の特定、フィルタリング、集計から始めることをお勧めします。それにより、リソースのサイズ適正化、アイドル状態のリソースの削除、Savings Plans、およびリザーブドインスタンスに関する推奨事項が得られます。図 1 に示すように、Cost Optimization Hub を使用することで、合併後の organization 全体で推奨されるコスト最適化と統合された調査結果を 1 つのダッシュボードで確認することができます。そこで推定される節約額は、AWS アカウント、AWS リージョン、リソースタイプなどでフィルタリングして集計することができます。 自動化された推奨事項がニーズに合わず、コスト最適化分析を自分で行いたい場合は、AWS Organizations と統合された AWS Cost Explorer を利用することで organization 全体の推奨事項を可視化することができます。 図 1: Cost Optimization Hub (コスト最適化ハブ) で毎月の節約額を見積もる エンタープライズサポート のお客様の場合、 AWS Trusted Advisor からの最適化に関する更なる推奨事項も確認いただけます。Trusted Advisor は、図 2 に示すように、十分に活用されていないリソース、アイドル状態のロードバランサー、その他のコスト削減の可能性がある領域を特定するのに役立ちます。 organization 全体で AWS Trusted Advisor を有効 にし、 推奨事項を含むレポートを作成する ことをお勧めします。より規範的なガイダンスやベストプラクティスについては、ブログ記事「 AWS Trusted Advisor による運用上の優秀性の継続的な最適化 」をご覧ください。 図 2: AWS Trusted Advisor はコスト最適化のチェックの特定に有用 AWS Config は、AWS アカウント内のリソースの設定と関係性を評価、監査、確認することができます。このサービスは コスト最適化にも使用 できます。特定の Amazon Relational Database Service (Amazon RDS) インスタンスがアカウントにデプロイされた場合にアラートを受け取ることができるシナリオを考えてみましょう。必要以上に大きなインスタンスタイプを使用されている場合、特定のアカウントに予期せぬコストが発生する可能性があります。これに対処するには、AWS Config にカスタムルールを実装し、データベースインスタンスを監視してアラートを提供することでコストを最適化できます。 合併後のビジネスニーズに合わせてコンピューティングコストを最適化する AWS Compute Optimizer は、AWS Organizations を通じて管理されている複数のアカウントにわたって EC2 インスタンスを適切なサイズにするための推奨事項を提供することで、M&A 後のコストを最適化するのに役立ちます。ワークロードパターンを分析し、パフォーマンス要件を満たしながらコストを削減できるインスタンスタイプを提案します。Organizations でアカウントを統合し、Compute Optimizer の推奨事項を活用することで、十分に活用されていないインスタンスやサイズが大きすぎるインスタンスを特定して排除し、統合後の組織のコンピューティングリソース全体でコスト削減につなげることができます。 図 3: AWS Compute Optimizer – 動作の仕組み Compute Optimizer コンソールから Compute Optimizer を AWS Organizations と統合します。これにより、Compute Optimizer はサービスに必要なリソースの作成などの必要な設定を実行できるようになります。 AWS Compute Optimizer の使用を開始するには、Compute Optimizer コンソールを使用して メンバーアカウントを Compute Optimizer の委任管理者として指定 します。委任管理者アカウントを使用して、organization 内のすべてのアカウントのリソース最適化の機会を特定するように Compute Optimizer を設定します。詳細については、「 AWS Compute Optimizer の開始方法 」を参照してください。コンテナワークロードを扱う場合は、 organization 内の複数アカウント間での分割コスト配分データ (SCAD) を活用することができます。 ワークロードとインフラストラクチャが増えるにつれて、リザーブドインスタンスを利用してコストを削減したり、使用量に応じた階層型料金によるメリットを活用したりできる機会が増えます。適切なリザーブドインスタンス (RI) の構成を決定するには、使用パターンを分析することが重要です。両方の organization の既存の RI コミットメントを評価し、M&A 後の環境への適用可能性を評価します。使用パターンやインフラストラクチャの要件の変更に合わせて RI を必要に応じて変更または移管することで、RI の使用率を高め、コストを削減できます。 統合的なデータアーカイブとストレージの戦略を策定する M&A のトランザクションが終わったら、両 organization のストレージ使用状況を見直し、コスト削減の機会を見極めましょう。統合プロセス中または統合プロセス後のデータ保持とコンプライアンス要件を管理するためのデータアーカイブおよびストレージ戦略を策定します。 Amazon S3 Storage Lens は、オブジェクトストレージの使用状況やアクティビティの傾向を organization 全体で可視化し、コストを最適化してデータ保護のベストプラクティスを適用するための実行可能な推奨事項を提示します。S3 Storage Lens は、組織内の数百、数千ものアカウントにわたるオブジェクトストレージの使用状況とアクティビティを単一のビューで提供し、ドリルダウンして複数の集計レベルでインサイトを得ることができる初めてのクラウドストレージ分析ソリューションです。S3 Storage Lens を使用すると、そのバケット内のオブジェクトへのアクセスが頻繁ではない “コールド S3 バケット” を識別できます。図 4 に示すように、アカウント、リージョン、バケット、またはプレフィックスに基づいてフィルターを追加することで、詳細なインサイトを可視化できます。 Amazon S3 Glacier や Amazon S3 オブジェクトライフサイクルポリシー などの AWS ストレージサービスを活用することで、データアーカイブとライフサイクル管理を自動化し、時間の経過とともにストレージコストを削減することができます。 図 4: Amazon S3 Storage Lens では、organization 内のすべての S3 バケットにわたるオブジェクトストレージの使用状況とアクティビティを一元的に確認可能 バックアップポリシーとデータ保持の効率的かつ一元的なデータ管理を行うには、 AWS Backup の AWS Organizations との統合を有効化 してください 。これは、合併後の organization の複数の AWS アカウントとサービスにわたるバックアップとデータ保護を一元管理するための、費用対効果の高いソリューションを提供するものです。詳細については、「 AWS Backup のコストを最適化する 」を参照してください。 ネットワークインフラストラクチャの重複箇所を特定し解消する M&A では、しばしば異なる IT インフラストラクチャを統合する必要がある場合があり、それによって重複や非効率性が生じる可能性があります。これらのトランザクションには通常、ハイブリッドネットワークが含まれます。M&A の後に AWS でのデータ転送やネットワークのコストの最適化を怠ると、多額の不要な支出が発生する可能性があります。データ転送とネットワークの最適化の手法を活用することで、最終的には M&A による財務上のメリットと相乗効果を最大限に引き出すことができます。 M&A において、新規アカウントを既存の AWS Organizations 構造に統合する際には、IT インフラストラクチャの統合と、データ転送やネットワークなどの関連コストの最適化が重要となります。主なステップには、リージョン別のデータ転送パターンの特定および統合、データ転送料金を削減するための AWS PrivateLink や Resource Access Manager の活用、一元的な VPC 接続管理のための AWS Transit Gateway の利用などがあります。 AWS Data Exports と Amazon QuickSight による一元的なコストモニタリングにより、統合された請求データの可視化が可能になります。AWS Organizations 内で サービスコントロールポリシー (SCP) を実装することで、統合されたアカウント全体にコスト最適化プラクティスを強制的に適用できる一方、 AWS コスト配分タグ を使用することで、特定のビジネスユニットやプロジェクトにコストを分類し配分することが可能です。 統合フェーズでのネットワーク最適化の推奨事項の詳細については、 AWS ネットワーク最適化のブログ投稿 を参照してください。 サポートおよびライセンスにかかるコストを管理する 適切なサポート計画を立てることで、コストの削減、リスクの軽減、事業継続性の確保、合併後の事業体のより円滑な管理の促進が可能になります。そのために エンタープライズサポートプラン へアップグレードをお勧めします。このプランでは、AWS コスト最適化の専門家によるサポートを受けることができるようになります。そこでは AWS のアーキテクチャや使用パターンのレビューを通して、リソースの最適化やインスタンスのサイズ適正化、リザーブドインスタンスの活用、費用対効果の高いサービスやアーキテクチャの採用などについて、カスタマイズされた推奨事項が提供されます。 エンタープライズサポートの大きな利点は、organization 全体を対象としていることです。organization 全体でエンタープライズサポートプランを契約すると、追加または招待したすべてのアカウントに自動的に同じレベルのサポートが継承されます。これによりプロセスが合理化され、合併時に各アカウントに個別のサポートプランを付与する必要がなくなります。ただし、この機能は現在一部のリージョンのお客様のみが利用可能であり、お客様のエンタープライズ契約にはそのための必要な条項が含まれている必要があります。この機能を有効にする資格や、サポートプランに関する追加情報についてはテクニカルアカウントマネージャーにお問い合わせください。 AWS License Manager を使用することで、ソフトウェアライセンスの管理やライセンスコストの調整が可能になります。AWS Organizations と AWS License Manager を統合することで、organization 全体のライセンスを可視化できます。合併後の事業体全体のソフトウェアライセンスを一元的に可視化できるため、M&A の際のライセンスコストの最適化に役立ちます。図 5 は AWS License Manager がどのようにライセンスの追跡、プール化、再配布を可能にするかを示しており、これによりコンプライアンスを確保しながら重複購入を回避して、大幅なコスト削減につなげることができます。 図 5: AWS License Manager ダッシュボードは AWS およびオンプレミス環境全体にわたる Microsoft、SAP、Oracle、IBM などのベンダーからのソフトウェアライセンスの概要を提供 ソフトウェア調達を効率化し、重複するライセンスを排除し、合併後の事業体全体で統合された可視性を確保するために、organization 全体で AWS Private Marketplace を有効にすることをお勧めします。これにより、中央集権的なガバナンス、コスト管理、および効率的なソフトウェア配布が可能になり、M&A の際にスムーズな移行を可能としつつ、コスト削減を実現することができます。 M&A 成功後に継続的にコストを監視し最適化する M&A 後は、自組織の環境内のコストを継続的に監視することが極めて重要です。これは通常、当組織が最大限の最適化のためのスコープと機会を持ち、環境内での効率性を向上させる立場にあるためです。プロアクティブなコスト監視と最適化のプラクティスを確立し、進化するビジネスニーズとコスト要因に基づいてリソースの使用量を継続的にレビューして調整します。定期的にコスト最適化レビューを実施して、不要または十分に活用されていないリソースを特定して排除するように計画してください。これには、インスタンスのサイズ適正化、未使用リソースの削除、費用対効果の高い価格モデル (リザーブドインスタンス、スポットインスタンスなど) の活用などが含まれます。 合併後の organization の複数のアカウントで Amazon CloudWatch メトリクスをモニタリングすることで、CPU/メモリの使用量が低く、ダウンサイジングや終了が可能な、十分に活用されていないリソースを確認できます。使用パターンに基づいてリソースを起動および停止することで、アイドル状態のリソースのコストを削減できます。 AWS Budgets と AWS Cost Anomaly Detection をセットアップして、データ転送やネットワーキングに関連する潜在的なコスト急増や異常が発生したときにアラートや通知を受け取るようにしてください。AWS Lambda 関数を使用してアイドル状態のリソースを自動的に停止または終了する自動最適化を実装してください。また、需要に基づいてリソース容量を動的に調整する AWS Auto Scaling の使用も検討してください。 コスト管理プロセスと手順を文書化する M&A を通じて得たコスト管理のプロセス、手順、および得られた教訓を文書化して、組織の知識を把握し、統合後の組織への知識移転を促進してください。統合後のコストを効果的に管理できるように、コスト管理のベストプラクティス、ツール、プロセスについてステークホルダーにトレーニングとサポートを提供してください。これにより、コスト意識の文化が育まれ、M&A 移行期間中の効果的なコラボレーションが可能になります。 社内に知識共有プラットフォームがある場合は、そこにプロセスを文書化してください。また、エンタープライズサポートプランに加入している場合は、フルマネージド型の安全なプライベート空間である AWS re:Post Private を活用して、組織固有のクラウドコミュニティを構築し、独自の知識リソースへのアクセスを提供することもできます。 AWS re:Post Private は、信頼できる AWS 技術コンテンツを一元化し、プライベートな議論の場を提供します。これにより、チームが社内チーム間および AWS と連携する方法を改善して、技術的な障壁を取り除いたり、イノベーションを加速させたり、クラウドでのより効率的なスケーリングを実現したりできるようになります。 サービスを AWS Organizations と統合してボリュームディスカウントを利用する このブログ記事で説明されているサービスは、サービスのコンソールまたは API 操作 / CLI コマンドなどを使用して AWS Organizations 上で有効化することができます。これにより、必要なリソースの作成など、organization に必要なすべての初期化ステップを AWS サービスが実行できるようになります。 合併する organization のアカウントを合併後の organization に統合したら、organization 内のすべてのアカウントの使用量を合算することで、 ボリュームディスカウント 、リザーブドインスタンス割引、および Savings Plans を共有できます。請求の観点からは、AWS は organization 内のすべてのアカウントをあたかも 1 つのアカウントのように扱います。 Amazon Simple Storage Service (Amazon S3) などの一部のサービスには、特定の使用量に応じたボリューム料金階層があり、サービスの使用量が増えるほど料金が低くなります。一括請求により、AWS はすべてのアカウントの使用量を合算して適用するボリューム料金階層を判定し、可能な限り全体的な料金を低く抑えます。その後、AWS は各アカウントの使用量に基づいて全体のボリュームディスカウントの一部を各メンバーアカウントに割り当てます。 たとえば、Bob の一括請求には、Bob 自身のアカウントと Susan のアカウントの両方が含まれているとします。Bob のアカウントは管理アカウントなので、Bob は自分自身と Susan の両方の料金を支払います。Bob はその月に 8 TB のデータを転送し、Susan は 4 TB のデータを転送します。 この例では、AWS は最初の 10 TB のデータ転送に対して GB あたり $0.17、次の 40 TB に対して GB あたり $0.13 を請求します。これは、TB あたりに換算すると最初の 10 TB については $174.08 (= 0.17 × 1,024)、次の 40 TB については $133.12 (= 0.13 × 1,024) に相当します。なお、1 TB = 1,024 GB である点に注意してください。 Bob と Susan が使用した 12 TB については、Bob の管理アカウントに ($174.08 × 10 TB) + ($133.12 × 2 TB) = $1,740.80 + $266.24 = $2,007.04 が請求されます。 一括請求を階層化することのメリットがなければ、AWS は Bob と Susan の使用量に対してそれぞれ TB あたり $174.08 を請求することになり 、合計で $2,088.96 となっていたはずです。 3 つの AWS アカウントがあり、S3 ストレージとしてアカウント A は 10 TB、アカウント B は 15 TB、アカウント C は 20 TB を使用しているものとします。個別のアカウントの場合、それぞれのストレージ階層に基づいて個別に請求されます。これらのアカウントを AWS Organizations を使用している organization に統合すると、45 TB (10 TB + 15 TB + 20 TB) のストレージ使用量の合計が organization レベルで集計されます。この 45 TB の使用量は上位のストレージ階層に該当する可能性が高く、その場合個別アカウントの料金階層と比較して GB あたりの料金が低くなります。 AWS Organizations を通じてこのボリュームディスカウントを利用することで、特に organization 内の複数の AWS アカウントに大量のストレージ要件が分散している場合に、S3 ストレージ全体のコストを大幅に削減することができます。 まとめ このブログ記事で紹介したベストプラクティスを導入することで、組織はリソース利用を最適化し、コストを効果的に管理し、財務リスクを最小限に抑え、合併・買収 (M&A) の活動に関わるすべての関係者にとって統合を成功させることができます。ワーナーブラザーズ・ディスカバリーが AWS Organizations サービスやその他の統合サービスをどのように活用して買収を成功させたかを理解するには「 Improving Mergers and Acquisitions Using AWS Organizations with Warner Bros. Discovery 」をご覧ください。 AWS コストのレビュー、可視化、最適化に対して AWS の推奨事項と支援を最大限に活用するには、このブログ記事で取り上げているコスト最適化ハブ、S3 Storage Lens、Compute Optimizer などのサービスを AWS Organizations と統合してください。分散化された柔軟な管理を実現するために、AWS Organizations と統合されたサービスの委任管理者としてメンバーアカウントを指定することを検討してください。AWS Organizations と統合可能なサービスのリストを確認するには、 AWS Organizations で使用できる AWS サービス をご覧ください。 M&A を進めている中で organization の統合に関するベストプラクティスのガイダンスをお探しの場合は「 AWS Organizations のアカウント評価 」と、 アカウントの効果的な移行に関する 3 部構成のブログ投稿シリーズ を参照してください。さらに詳細な情報については「 Choosing an AWS cost management strategy 」と「 Starting your Cloud Financial Management journey: Cost savings 」をご覧ください。 著者について Nikhil Anand Nikhil Anandは、ロンドンを拠点とする AWS のシニアソリューションアーキテクトです。主にUKI (英国・アイルランド) 地域の中小規模 (SMB) および金融サービス機関 (FSI) のお客様を担当しており、セキュリティ、コンプライアンス、移行の分野でのバックグラウンドを持っています。また、お客様の移行プロセスにおける M&A トランザクションのアドバイザーとしても活動し、お客様の AWS クラウドでの構築とモダナイズを支援しています。仕事を離れると、スポーツに情熱を注ぎ、日々のトレーニングを欠かさず続けることを信条としています。 Nivedita Tripathi Nivedita Tripathi は AWS Organizations の GTM 担当シニアプロダクトマネージャーです。セキュリティとガバナンスのベストプラクティスを活用しながら、複数のアカウントにわたるクラウドインフラストラクチャの構築とスケーリングにおいてお客様を支援することに注力しています。テクノロジーへの深い情熱の一方で、 音楽を楽しみ、世界各地を旅し、家族と大切な時間を過ごすことを何よりの喜びとしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

By Kazuki Nagasawa, Cloud Support Engineer – AWS Support Engineering By Kensuke Fukumoto, Solutions Architect – AWS ISV/SaaS 近年、大規模言語モデル（LLM）の台頭により、様々な産業分野で AI の導入が加速しています。しかし、LLM の能力をさらに拡張し、最新の情報やドメイン固有の知識を効果的に活用するには、外部データソースとの統合が不可欠です。この課題に対する効果的なアプローチとして、Retrieval Augmented Generation（RAG）が注目を集めています。 RAG は、ユーザーの入力に基づいて既存の知識ベースや文書から関連情報を検索し、この情報を LLM の入力に組み込むことで、より正確で文脈に適した応答を生成する手法です。この技術は、製品開発における技術文書の活用から、カスタマーサポートでの FAQ 応答、さらには最新データに基づく意思決定支援システムまで、幅広いアプリケーションで実装されています。 RAG の実装は、Software as a Service（SaaS）プロバイダーとその利用者（テナント）の両方に大きな価値をもたらします。 SaaS プロバイダーは、単一のコードベースから複数のテナントにサービスを提供するためにマルチテナントアーキテクチャーを使用できます。テナントがサービスを利用するにつれて、適切なアクセス制御とデータ分離によって保護されながら、データが蓄積されていきます。このような環境で LLM を使用した AI 機能を実装する際、RAG により各テナントの固有データを使用してパーソナライズされた AI サービスを提供することが可能になります。 カスタマーサービスコールセンター SaaS を例に考えてみましょう。各テナントの過去の問い合わせ記録、FAQ、製品マニュアルは、テナント固有の知識ベースとして蓄積されます。RAG システムを実装することで、LLM はこれらのテナント固有のデータソースを参照して、各テナントのコンテキストに関連する適切な応答を生成できます。これにより、汎用的な AI アシスタントでは不可能な、テナント固有のビジネス知識を組み込んだ高精度なインタラクションが可能になります。RAG は、SaaS におけるパーソナライズされた AI 体験を提供する重要なコンポーネントとして、サービスの差別化と価値向上に貢献します。 しかし、RAG を通じてテナント固有のデータを使用する場合、セキュリティとプライバシーの観点で技術的な課題があります。主な懸念は、テナント間のデータ分離を維持し、意図しないデータ漏洩やクロステナントアクセスを防ぐセキュアなアーキテクチャの実装です。マルチテナント環境では、データセキュリティの実装が SaaS プロバイダーの信頼性と競争優位性に重大な影響を与えます。 Amazon Bedrock Knowledge Bases により、より簡単に RAG を実装できます。ベクトルデータベースとして OpenSearch を使用する場合、 Amazon OpenSearch Service または Amazon OpenSearch Serverless の 2 つの選択肢があります。マルチテナント環境を構築する際、各選択肢には異なる特徴と権限モデルがあります： Amazon OpenSearch Serverless： メタデータフィルタリング により、ベクトルデータベースからの検索結果をテナント別にフィルタリングできます（詳細は Multi-tenant RAG with Amazon Bedrock Knowledge Bases を参照） この権限モデルでは、データの作成や更新などの書き込み操作に対する権限を分離できません Amazon OpenSearch Service： Fine-grained access control （FGAC）が利用可能です ナレッジベースにアタッチされた単一の AWS Identity and Access Management （IAM）ロールを通じたアクセスとなるため、権限分離に FGAC を使用することが困難です この記事では、JSON Web Token（JWT）と FGAC の組み合わせ、およびテナントリソースルーティングを使用したテナント分離パターンを紹介します。前述の権限モデルの制限により FGAC の目標を達成できない場合は、この記事のソリューションを使用できます。このソリューションは、ベクトルデータベースとして OpenSearch Service、オーケストレーションレイヤーとして AWS Lambda を使用して実装されています。 次のセクションでは、OpenSearch Service における JWT と FGAC を使用したテナント分離の具体的な実装と、これによってセキュアなマルチテナント RAG 環境がどのように実現されるかを探ります。 OpenSearch Service におけるマルチテナントデータ分離での JWT の有効性 Amazon OpenSearch Service にマルチテナント SaaS のデータを格納する で紹介されているように、OpenSearch Service では、マルチテナントデータを管理する分離レベルとして、ドメインレベルの分離、インデックスレベルの分離、ドキュメントレベルの分離と複数の方法があります。 インデックスレベルとドキュメントレベルでのアクセス権限分離を実装するには、OpenSearch Security プラグインでサポートされている FGAC を使用できます。 OpenSearch Service では、IAM アイデンティティを OpenSearch ロールにマッピングすることで、きめ細かなアクセス制御を実現できます。これにより、各 IAM アイデンティティに対して OpenSearch での詳細な権限設定が可能になります。しかし、このアプローチには重大なスケーラビリティの課題があります。テナント数の増加に伴い、必要な IAM ユーザーやロールの数も増加し、AWS サービスクォータの制限に達する可能性があります。また、多数の IAM エンティティの管理は運用の複雑さを招きます。 動的に生成される IAM ポリシー でこの課題自体は克服できる可能性がありますが、動的に生成された各ポリシーは単一の IAM ロールにアタッチされます。単一の IAM ロールは単一の OpenSearch ロールにマッピングできますが、適切な分離のためにはテナントごとに IAM ロールと動的ポリシーが必要となり、多数のエンティティを管理する同様の運用上の複雑さが生じます。 この記事では代替アプローチを提供し、マルチテナント環境でのデータ分離とアクセス制御を実装するための自己完結型トークンである JWT の有効性に焦点を当てます。JWT を使用することで、以下の利点が得られます： 動的なテナント識別 – JWT ペイロードには、テナントを識別するための属性情報（テナントコンテキスト）を含めることができます。これにより、システムはリクエストごとにテナントを動的に識別し、このコンテキストを後続のリソースやサービスに渡すことができます。 OpenSearch における FGAC との統合 – FGAC は、JWT 内の属性情報を直接使用してロールマッピングを行うことができます。これにより、JWT 内のテナント ID などの情報に基づいて、特定のインデックスやドキュメントへのアクセス権限をマッピングできます。 JWT と FGAC を組み合わせることで、OpenSearch Service を使用したマルチテナント RAG 環境において、セキュアで柔軟かつスケーラブルなデータ分離とアクセス制御が実現されます。次のセクションでは、この概念を実際のシステムに適用するための具体的な実装詳細と技術的考慮事項を探ります。 ソリューション概要 RAG では、LLM の出力を拡張するために使用される関連文書などのデータは、埋め込み言語モデルによってベクトル化され、ベクトルデータベースにインデックスされます。自然言語でのユーザーの質問は、埋め込みモデルを使用してベクトルに変換され、ベクトルデータベースで検索されます。ベクトル検索によって取得されたデータは、出力を拡張するためのコンテキストとして LLM に渡されます。以下の図は、ソリューションアーキテクチャを示しています。 このソリューションでは、RAG におけるナレッジソースを格納するベクトルデータストアとして OpenSearch Service を使用します。フローは以下の通りです： 各テナントの RAG アプリケーションユーザーは、 Amazon Cognito ユーザープール のユーザーとして作成され、フロントエンドへのログイン時にテナント ID 情報でエンリッチされた JWT を受け取ります。各ユーザーのテナント情報は Amazon DynamoDB に格納されており、ユーザー認証時に トークン生成前 Lambda トリガー によって JWT に追加されます。 ユーザーがフロントエンドでチャットを開始すると、ユーザークエリは JWT とともに Amazon API Gateway を通じて Lambda 関数に渡されます。 ユーザークエリは、Amazon Bedrock で利用可能なテキスト埋め込みモデルと連携してベクトル化されます。 検索用のドメインとインデックス情報を DynamoDB から取得します。 OpenSearch Service でベクトル検索を実行し、インデックスからクエリに関連する情報を取得します。 取得された情報をコンテキストとしてプロンプトに追加し、Amazon Bedrock で利用可能な LLM に渡して応答を生成します。 このソリューションで注目すべき点は、OpenSearch Service でのテナントデータ分離と各テナントのデータへのルーティングに JWT を使用することです。OpenSearch Service で利用可能な FGAC を使用して各データセットへのアクセス権限を分離し、JWT に追加されたテナント ID 情報を使用してアプリケーションユーザーと分離された権限セットをマッピングします。このソリューションでは、お客様の要件に合わせて、データ分離の粒度に対して 3 つの異なるパターンを提供しています。また、JWT からのテナント ID 情報とデータの場所（ドメイン、インデックス）のマッピングを DynamoDB で定義することで、ルーティングも可能になります。 ユーザーがドキュメントを追加する際は、ファイルを Amazon Simple Storage Service （Amazon S3）にアップロードし、メタデータを DynamoDB 上の管理テーブルに書き込みます。OpenSearch Service にデータを格納する際は、ベクトル化のために Ingest pipelines でテキスト埋め込みモデル（Amazon Bedrock）が呼び出されます。ドキュメントの作成、更新、削除では、リクエストに JWT が付与されているため、テナントの識別が可能です。 このソリューションは、 AWS Cloud Development Kit （AWS CDK）を使用して実装されています。詳細については、 GitHub リポジトリ を参照してください。ソリューションのデプロイ手順は、リポジトリの README ファイルに含まれています。 前提条件 このソリューションを試すには、以下の前提条件が必要です： AWS アカウント AWS CDK の実行に必要な IAM アクセス権限 フロントエンド実行環境：node.js と npm のインストールが必要 AWS CDK が設定済みである必要があります。詳細については、 チュートリアル: 最初の AWS CDK アプリを作成する を参照してください Amazon Bedrock で使用するモデルへのアクセスが設定されている必要があります。このソリューションでは、Anthropic の Claude 3.5 Sonnet v2 と Amazon Titan Text Embedding V2 を使用します。詳細については、 Add or remove access to Amazon Bedrock foundation models を参照してください アーキテクチャ図に示されているリソースに加えて、AWS CDK デプロイにより以下のリソースと設定が AWS CloudFormation カスタムリソースとして作成されます： Amazon Cognito ユーザープール： tenant-a、tenant-b、tenant-c、tenant-d のユーザー DynamoDB テーブル： ユーザーとテナントのマッピング テナントと OpenSearch 接続先およびインデックスのマッピング OpenSearch Service ドメイン： JWT 認証設定 ベクトル埋め込み用 Ingest pipelines 各テナント用 FGAC ロールとロールマッピング k-NN インデックス Amazon Cognito によるユーザー認証と JWT 生成 このソリューションでは、RAG アプリケーションのユーザー認証に Amazon Cognito ユーザープールを使用します。Amazon Cognito ユーザープールは認証時に JWT を発行します。OpenSearch Service の FGAC では JWT 認証がサポートされているため、ユーザープールから発行されるパブリックキーを OpenSearch Service ドメインに登録することで、Amazon Cognito ユーザープールで認証されたユーザーからのアクセスを許可できます。また、FGAC によるテナントデータアクセス権限分離では、JWT ペイロードに追加できる属性を使用した認可が実行されます。これを実現するため、Amazon Cognito ユーザープールにトークン生成前 Lambda トリガーを設定し、DynamoDB に格納された各ユーザーのテナント ID 情報を取得してトークンに追加します。取得された JWT はフロントエンドで保持され、バックエンドへのリクエストに使用されます。DynamoDB には、ユーザー ID（sub）とテナント ID のマッピングが以下のように格納されています： { "pk": { "S": "membership#<Cognito user ID (sub)>" }, "sk": { "S": "tenant#tenant-a" } } Amazon Cognito でマルチテナント認証を実装するパターンは複数存在しますが、この実装では DynamoDB でのユーザー-テナントマッピングを持つ単一ユーザープールを使用しています。本番環境では追加の考慮事項が必要です。詳細については、 マルチテナントアプリケーションのベストプラクティス を参照してください。 JWT を使用したテナントデータへのリクエストルーティング テナントごとにリソースが分離されるマルチテナントアーキテクチャでは、テナントからのリクエストを適切なリソースにルーティングすることが不可欠です。テナントルーティング戦略の詳細については、 AWS における SaaS アプリケーションのテナントルーティング戦略 を参照してください。このソリューションでは、OpenSearch Service へのルーティングに、この記事で説明されているデータドリブンルーティングに類似したアプローチを使用します。 DynamoDB テーブルには、テナント ID、対象 OpenSearch Service ドメイン、インデックスのマッピング情報が以下のように格納されています： { "pk": { "S": "tenant#tenant-a" }, "sk": { "S": "os_config" }, "os_host": { "S": "<Amazon OpenSearch Service domain endpoint>" }, "os_index": { "S": "tenant-a-index" }, "rag_role": { "S": "tenant-a_role" } } フロントエンドから API Gateway を通じて Lambda 関数に送信される HTTP リクエストの Authorization ヘッダーから JWT を取得します。JWT を解析して取得されるテナント ID を使用してルーティング情報を取得し、ルーティング先を決定します。また、JWT は次のセクションで説明するように、OpenSearch へのリクエストの認証情報としても使用されます。 OpenSearch Service におけるマルチテナントデータ位置とアクセス権限の分離 OpenSearch Service におけるマルチテナントデータ分離戦略には、ドメインレベル、インデックスレベル、ドキュメントレベルの分離という 3 種類の分離パターンと、これらを組み合わせたハイブリッドモデルがあります。このソリューションでは、テナントデータへのアクセス権限制御に FGAC を使用し、テナントごとに専用のロールを作成します。 テナントユーザーと FGAC テナントロールのマッピングは、バックエンドロールを通じて実装されます。OpenSearch Service で利用可能な JWT 認証 では、JWT ペイロード内でバックエンドロールとリンクする属性を Roles key として指定できます。以下のスクリーンショットは、このドメイン設定を示しています。 JWT ペイロードには、以下のように tenant_id 属性が含まれています： "tenant_id": "tenant-a" この属性を OpenSearch JWT 認証の Roles key として設定し、以下のようにロールをマッピングすることで、テナントユーザーと FGAC ロールがリンクされます： { "tenant-a_role": { "backend_roles": [ "tenant-a" ] } } 以下のスクリーンショットは、OpenSearch Dashboards での FGAC におけるテナントロールマッピングの例を示しています。 このソリューションのサンプルでは、tenant-a、tenant-b、tenant-c、tenant-d の 4 つのテナントを提供し、3 つの分離方法すべてを試すことができます。以下の図は、このアーキテクチャを示しています。 各ロールには、対応するテナントデータのみにアクセスできる権限が割り当てられます。このセクションでは、JWT と FGAC を使用して 3 つの分離方法それぞれを実装する方法を紹介します： ドメインレベルの分離 – 各テナントに個別の OpenSearch Service ドメインを割り当てます。この分離パターンではドメインが各テナント専用であるため、ドメイン内でのデータ分離は必要ありません。そのため、FGAC ロールはインデックス全体へのアクセス権限を付与します。以下のコードは、インデックスへのアクセス権限を付与する FGAC ロール定義の index_permissions の一部です： "index_permissions": [ { "index_patterns": [ "*" ], インデックスレベルの分離 – 複数のテナントが OpenSearch Service ドメインを共有し、各テナントに個別のインデックスを割り当てます。各テナントは自分のインデックスのみにアクセスできる必要があるため、FGAC ロールの index_permissions は以下のように設定されます（tenant-b の例）： "index_permissions": [ { "index_patterns": [ "tenant-b-index*" ] ドキュメントレベルの分離 – 複数のテナントが OpenSearch Service ドメインとインデックスを共有し、インデックス内のテナントデータのアクセス権限分離に FGAC のドキュメントレベルセキュリティを使用します。各インデックスにはテナント ID 情報を格納するフィールドが含まれ、そのフィールドに対してドキュメントレベルセキュリティクエリが設定されます。以下のコードは、tenant-c と tenant-d がインデックスを共有する構成で、tenant-c が自分のデータのみにアクセスできる FGAC ロールの index_permissions の一部です： "index_permissions": [ { "index_patterns": [ "tenant-cd-shared-index*" ], "dls": """{"bool": {"must": {"match": {"tenant_id": "tenant-c"}}}}""", 以下のスクリーンショットは、FGAC ロールにおけるドキュメントレベル分離のためのインデックス権限の例を示しています。 考慮事項 この記事の実装では、DynamoDB テーブルと S3 バケットをテナント間で共有するモデルを使用しています。本番環境での使用では、 Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB と Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3 で紹介されているパーティショニングモデルを検討し、要件に基づいて最適なモデルを決定してください。 また、各リソースへのアクセス権限を制限する追加のレイヤーとして、 IAM ポリシーの動的生成 を使用できます。 クリーンアップ 予期しない料金を避けるため、リソースが不要になった場合は削除することをお勧めします。リソースは AWS CDK で作成されているため、cdk destroy コマンドを実行して削除します。この操作により、Amazon S3 にアップロードされたドキュメントも削除されます。 結論 この記事では、マルチテナント RAG において OpenSearch Service をベクトルデータストアとして使用し、JWT と FGAC を使用してデータ分離とルーティングを実現するソリューションを紹介しました。 このソリューションでは、JWT と FGAC の組み合わせを使用して厳密なテナントデータアクセス分離とルーティングを実装するため、OpenSearch Service の使用が必要です。執筆時点では、Amazon Bedrock Knowledge Bases は OpenSearch Service への JWT ベースのアクセスを使用できないため、RAG アプリケーションは独立して実装されています。 マルチテナント RAG の使用は SaaS 企業にとって重要であり、データ分離の厳密さ、管理の容易さ、コストなどの要件によって戦略は異なります。このソリューションでは複数の分離モデルを実装しているため、要件に基づいて選択できます。 マルチテナント RAG 実装に関するその他のソリューションや情報については、以下のリソースを参照してください： Multi-tenant RAG with Amazon Bedrock Knowledge Bases Build a multi-tenant generative AI environment for your enterprise on AWS Self-managed multi-tenant vector search with Amazon Aurora PostgreSQL Multi-tenant vector search with Amazon Aurora PostgreSQL and Amazon Bedrock Knowledge Bases 翻訳はソリューションアーキテクトの福本が担当しました。 著者について Kazuki Nagasawa は、Amazon Web Services のクラウドサポートエンジニアです。Amazon OpenSearch Service を専門とし、お客様の技術的な課題解決に注力しています。プライベートでは、様々な種類のウイスキーを探求したり、新しいラーメン店を発見したりすることを楽しんでいます。 Kensuke Fukumoto は、Amazon Web Services のシニアソリューションアーキテクトです。ISV や SaaS プロバイダーのアプリケーションモダナイゼーションと SaaS モデルへの移行支援に情熱を注いでいます。プライベートでは、バイクに乗ることやサウナに行くことを楽しんでいます。  

こんにちは、ソリューションアーキテクトの宇佐美です。 2025年7月15日に開催された「Neuron Community – Vol.2」の様子をレポートします。 このイベントは、「Neuron Community」の協力のもと開催しました。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニングセッション 常世 大史 （Amazon Web Services Japan G.K.） 資料： Discord 上の Neuron Community 内で公開 しています。 オープニングでは、AWS 内で Trainium と Inferentia を開発している部門、Annapurna Labs 所属の常世より、Neuron Community の立ち上げ経緯と初回イベント「 Neuron Community – Day One 」の振り返り、さらに2025年6月25日・26日に開催された AWS Summit Japan 2025 を Trainium、Inferentia、Neuron の視点から振り返りました。AWS Summit Japanでは、AWS が独自開発を行っている Trainium、Inferentia 等のチップおよび搭載モジュールの実物展示や、Amazon EC2 Trn2 UltraServers の実物大パネル展示を実施したことを紹介しました。 また、 Discord 上で立ち上がった Neuron Community についても改めて紹介しました。Neuron Community は2025年7月19日現在、56名が参加する規模へと成長しています。ユーザー同士が気軽に交流・議論できる場を目指して、コミュニティのさらなる発展を呼びかけました。 ライトニングトーク 清丸 寛一氏（国立情報学研究所）「日本語 LLM の対決の舞台「LLM-jp Chatbot Arena」を支える技術」 資料： Discord 上の Neuron Community 内で公開 していただいています。 国立情報学研究所の清丸氏からは、「日本語 LLM の対決の舞台「LLM-jp Chatbot Arena」を支える技術」と題して、大規模言語モデル (LLM : Large Language Model) を利用したサービス「 LLM-jp Chatbot Arena 」でどのように AWS Trainium を利用しているかについて紹介していただきました。LLM-jp Chatbot Arena は、2つの日本語 LLM の応答を同時に比較し、優れた方に投票できるプラットフォームです。投票の結果は、LLM の改善のために役立てることができます。 LLM-jp Chatbot Arena では、モデルに応じてインスタンスを使い分けており、一番大きなサイズである LLM-jp-3 172B モデル では、Amazon EC2 Trn1 インスタンス (trn1.32xlarge) を推論サーバーとして採用しているとのことです。Amazon EC2 インスタンスタイプは、運用コストを下げることを狙いとして選択されており、GPU ベースの p4d.24xlarge インスタンスと比較した場合、メモリサイズは約 80% になるものの、コストが 約 60% に抑えられる点を評価していただきました。 また、LLM-jp Chatbot Arena のアーキテクチャについても説明していただき、UI サーバーに Gradio 、リクエストルーターに LiteLLM 、 推論サーバーに vLLM を利用しているとのことでした。 Amazon EC2 Trn1 インスタンスを利用した感想は「 想像以上にふつうに動く 」とのことで、チャットボットとして十分な速度で、数ヶ月間止まることなく安定して動作したということです。一方、いくつかの注意点も共有していただき、「 公式の最新ドキュメント 」を参照することが重要というアドバイスをいただきました。 セッションの後の質疑応答も大いに盛り上がっていたのが印象的でした。 吉川 幸弘（Amazon Web Services Japan G.K.）「AWS Summit Japan 2025 デモ再演 ~Inferentia/Trainium で徳得を詰め！推論コスパシミュレーション~」 最後のセッションでは、SA の吉川から AWS Summit Japan 2025 の AWS Builders’ Fair Booth で展示していたデモを再演しました。デモの内容は vLLM に対して大量に推論リクエストを送信し、そのトークン対コストを可視化するというものです。 具体的には以下のようなアーキテクチャで、inf2.24xlarge の EC2 インスタンス 1 台に Llama 3 8B モデルをデプロイして 384 リクエストを同時に送り続け、レスポンスが完了したら次のリクエストを送り続けるインスタンス泣かせなデモアプリケーションです。 以下の写真は実際のデモの様子です。 写真内で投影されているブラウザ内の吹き出しは、それぞれがストリームレスポンスしている AWS Inferentia2 からのレスポンスです。この写真では 9 つの吹き出ししか見えていませんが、実際には 384 の吹き出しがあり、ブラウザのスクロールバーをスクロールすると同様の吹き出しが 384 個ズラっと並んでいます。ちなみに同時処理数を 384 としている背景は TP (tensor parallel size) を 8、 batch size を 128 に設定してモデルを動かす Amazon ECS タスク 3 つを内部に Neuron コアを 24 個持った inf2.48xlarge 1 台で動作させているため、128 batch size × 3 tasks で 384 同時処理にしています。batch size を 128 としていること自体もレイテンシーとスループットが個人的な主観で良さそうだと思ったパラメータがこの設定だっただけで、アクセラレータデバイスのメモリ上これが限界というわけではないというのも面白い部分です。 このデモでは、 Neuronx patterns Construct Library という Inferentia2 / Trainium1 で LLM を簡単に動かすための AWS CDK Construct Library (AWS の Infrastructure as Code Module) を使用しています。このライブラリは、LLM の サーバーを Infrastructure as Code として管理したい方のために、吉川が個人の OSS として開発・公開しているもので、Application Load Balancer と Amazon ECS on EC2 部分の構築に利用しています。 AWS Inferentia2 ハンズオン 「〜推論サーバーを立ち上げてみよう〜」 資料： Discord 上の Neuron Community 内で公開 しています。 イベント後半では、AWS Summit Japan 2025 のセッション「GPU 以外の選択肢！開発チームが徹底解説、効率的な AI 基盤の作り方」の内容を基に、AWS Inferentia2 の実践的なハンズオンを実施しました。参加者の皆様には、以下の2つの推論サーバー構築手順を体験していただきました： Amazon EC2 Inf2 インスタンス (inf2.xlarge) 上で vLLM を利用し、 Llama 3.2 マルチモーダルモデル をデプロイ Amazon SageMaker AI  上で Hugging Face TGI コンテナを利用し、 Qwen 2.5 モデル を簡単にデプロイ ライトニングトークでの活発な質疑応答の結果、ハンズオンの時間が予定より短くなりましたが、Amazon EC2 Inf2 インスタンス上で推論サーバーを立ち上げる手順は理解していただけたかと思います。 使用した日本語のハンズオンコンテンツは Neuron Community で公開 していますので、本イベントに参加できなかった方も、ぜひご自身のペースでお試しください。セルフペースでのハンズオン実施中に困ったことがあれば、コミュニティメンバーに気軽に質問できるのも、ユーザーコミュニティならではの強みですね。 さいごに 第2回目の Neuron Community も、ユーザーの皆さまからたいへん興味深い発表をしていただき、大いに盛り上がりました。質疑応答が盛り上がりすぎて時間が足りなくなったのは、次回への反省点です。 この機会に、Discord の AWS Neuron Community に参加してくれた方も、たくさんいらっしゃったようです。第3回目の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。 染谷 謙太郎 (Someya Kentaro) 通信のお客様を担当するソリューションアーキテクトです。 通信のお客様のクラウド活用を支援しています。 吉川 幸弘(Yoshikawa Yukihiro) デジタルコンテンツを扱うお客様を担当するソリューションアーキテクトです。 AWS CDK に関する知見を活かし、お客様が簡単に AWS リソースを管理できるように取り組んでいます。

この記事は Under the hood: Amazon EKS ultra scale clusters (記事公開日: 2025 年 7 月 16 日) を翻訳したものです。 本日、 Amazon Elastic Kubernetes Service (Amazon EKS) は最大 10 万台のノードをサポートするクラスターの提供を発表しました。 Amazon EC2 の新世代高速コンピューティングインスタンスタイプを活用することで、これは単一の Kubernetes クラスターで 160 万個の AWS Trainium チップまたは 80 万個の NVIDIA GPU を実現することを意味します。これにより、最先端のモデルトレーニング、ファインチューニング、エージェント推論などの超大規模人工知能 (AI) および機械学習 (ML) ワークロードが可能になります。現在 Amazon EKS を直接利用しているお客様だけでなく、EKS をコンピュートレイヤーとして活用する Amazon SageMaker HyperPod with EKS などの他の AI/ML サービスにもこれらの改善が拡張され、AWS の超大規模コンピューティング能力全体を向上させます。 お客様からは、トレーニングジョブのコンテナ化や Kubeflow などのオペレーター、Karpenter のようなプロジェクトを通じたリソースプロビジョニングとライフサイクルの合理化、プラグ可能なスケジューリング戦略のサポート、そして豊富なクラウドネイティブツールのエコシステムへのアクセスが、AI/ML 領域での成功に不可欠であることが明確に示されています。Kubernetes は、強力で拡張可能な API モデルと堅牢なコンテナオーケストレーション機能により、アクセラレーテッドワークロードの迅速なスケーリングと信頼性の高い実行を可能にする重要な要素として注目されています。複数の技術革新、アーキテクチャの改善、オープンソースでのコラボレーションを通じて、Amazon EKS は Kubernetes に完全に準拠しながら、超大規模向けの次世代クラスターコントロールプレーンとデータプレーンを構築しました。 AWS では、結合度が低く水平方向にスケーラブルな汎用アプリケーションを実行するお客様に対して、成長を維持するための戦略として セルベースのアーキテクチャ に従うことを推奨しています。しかし、最先端の AI/ML モデルの開発には、低遅延で高帯域幅の通信を備えた単一の統合システムとして連携する数千のアクセラレーターが必要です。これらを単一のクラスター内で実行することには、いくつかの重要な利点があります。まず、大規模な事前トレーニングからファインチューニング、バッチ推論まで、多様なジョブを実行するための共有されたキャパシティプールを通じて使用率を高めることでコンピューティングコストを削減します。これらのジョブを別々のクラスターに分割すると、キャパシティの断片化や再マッピングの遅延により使用率が低下する可能性があります。次に、巨大なジョブを複数のクラスターに分割すると、スケジューリング、検出、修復などの一元化された操作が複雑になります。代わりに単一のクラスターで実行することで、クラスター間の調整オーバーヘッドを排除し、全体的な信頼性とパフォーマンスを向上させることができます。第三に、ML フレームワークは、グローバルなクラスタービューで実行することを前提としているため、分割クラスターモードでは常にうまく機能するとは限りません。これらが時間の経過とともにマルチクラスターモデルに進化する一方で、私たちはお客様が今日イノベーションを起こせるようにすることが重要だと考えています。 技術的詳細 Kubernetes のコアクラスターアーキテクチャは ここ に示される通りです。Amazon EKS はその上に特定のインフラストラクチャとソフトウェア構成、クラスター管理プレーン、そしてお客様により進んだ AWS 統合を提供するコンポーネント・サービスを構築しています。Kubernetes データストア (etcd) と API サーバーはクラスターの中核を形成し、超大規模を実現する重要な要素です。これに続いて、クラスター全体の操作やノードのローカルな操作を実行する様々なコントローラーがあります。アドオンは、クラスター内で実行されるアプリケーションのサービスディスカバリー、テレメトリ、認証情報の提供などの拡張機能を提供します。アクセラレーテッドワークロードには、ノード管理とモニタリングのためのデバイスプラグインやデーモンなど、広範なアドオンが必要です。クラスター領域の外では、Amazon EKS 管理プレーンの様々なサービスが継続的にすべてのクラスターのセキュリティ確保、スケーリング、更新を行っています。この取り組みの一環として、私たちはこれらすべてのコンポーネントとサービスが 10 万台のノード規模でシームレスに動作するように設計し、継続的な統合テストを通じて継続的に検証しています。詳細を見ていきましょう。 次世代データストア etcd は強力な一貫性を持つ分散キーバリューデータベースで、Kubernetes API のストレージバックエンドを提供します。内部的には、 Raft コンセンサスアルゴリズムを使用して、すべてのクラスターメンバー間で一貫性のあるレプリケーションされた トランザクションログ を維持します。各メンバーはログのコピーを保持し、クラスターメンバーの過半数（またはクォーラム）がそのログに永続化した後にのみ、特定のトランザクションがローカルデータベースの状態に適用されます。etcd の管理とスケーリングは大きな負担であり、私たちはすでにこれをお客様から抽象化しています。私たちは etcd アーキテクチャに複数のイノベーションを導入し、Kubernetes に完全に準拠しながら、次世代のクラスターパフォーマンスをお客様に提供しています。私たちはオープンソースの etcd プロジェクトの成功に引き続き投資し、確かな etcd コアだけがこのような進歩への道を開くことができると信じています。 コンセンサスのオフロード: 根本的な変更を通じて、Amazon EKS は etcd のコンセンサスバックエンドを Raft ベースの実装から Journal にオフロードしました。Journal は AWS で 10 年以上にわたって構築してきた内部コンポーネントで、マルチ アベイラビリティゾーン (AZ) の耐久性と高可用性を備えた超高速の順序付きデータレプリケーションを提供します。コンセンサスを Journal にオフロードすることで、クォーラム要件に縛られることなく etcd レプリカを自由にスケールでき、ピアツーピア通信の必要性を排除しました。様々な回復力の向上に加えて、この新しいモデルは Journal の堅牢な I/O 最適化データプレーンを通じて、お客様に優れた予測可能な読み取りと書き込みの Kubernetes API パフォーマンスを提供します。 インメモリデータベース: etcd の耐久性は、基本的には基盤となるトランザクションログの耐久性によって決まります。なぜなら、ログによってデータベースが過去のスナップショットから復元できるようになるからです。Journal がログの耐久性を担当するため、私たちはもう一つの重要なアーキテクチャの進歩を可能にしました。etcd の マルチバージョン同時実行制御 (MVCC) レイヤーを永続化するバックエンドである BoltDB を、ネットワーク接続型の Amazon Elastic Block Store ボリュームから tmpfs を使用した完全なインメモリストレージに移行しました。これにより、より高い読み取りと書き込みのスループット、予測可能なレイテンシー、より高速なメンテナンス操作という形で桁違いのパフォーマンス向上が実現します。さらに、障害時の平均復旧時間 (MTTR) を低く保ちながら、サポートされる最大データベースサイズを 20 GB に倍増しました。 パーティション化されたキースペース: Kubernetes はネイティブに etcd クラスターをリソースタイプごとにパーティション化することをサポートしており、異なるタイプのキーの間でのシリアライズ可能なトランザクションを必要としません。etcd 自体は単純化のために現在キースペースのパーティション化をネイティブにサポートしていませんが、超大規模クラスターは、ホットなリソースタイプを別々の etcd クラスターに分割することで大きな恩恵を受けます。最適なパーティション化スキームにより、Amazon EKS は長年にわたって Kubernetes 向けに進化してきた etcd の豊富な API セマンティクスを引き続き使用しながら、書き込みスループットを最大 5 倍に向上させました。私たちの新しいアーキテクチャは動的な再パーティション化を可能にしますが、適切に割り当てられた静的なパーティションが 10 万台のノード規模をサポートするのに十分であることがわかりました。これらの改善は、超大規模向けの機能が有効化された新しい EKS クラスターでのみ利用可能です。 図 1. 再構築前後の Amazon EKS etcd サーバー 極限のスループットを持つ API サーバー Amazon EKS の Kubernetes API サーバーは現在、垂直方向と水平方向に自由にスケールでき、これは様々な利用のシグナルに応じて読み取りスループットと watch のファンアウトを増加させるために既に使用している戦略です。一方、書き込みスループットは主に etcd によって決定され、そこでの改善についてはすでに説明しました。以下では、Amazon EKS クラスターの Kubernetes v1.33 以降で提供される超大規模を可能にするための更なる強化について説明します。 API サーバーとウェブフックのチューニング: 大規模なトラフィックパターン、特にアクセラレーテッドワークロードでは、リソース効率とスケーラビリティのトレードオフを調整する方法で API サーバーと重要なウェブフックをチューニングすることが非常に適しています。リクエストタイムアウト、再試行戦略、並列処理、スロットリングルール、HTTP 接続の存続時間、ガベージコレクション、etcd クライアント設定など、様々な構成を慎重にチューニングすることで最適なパフォーマンスを達成しました。このようなチューニングはほとんどのワークロードには有益ではありませんが、数万ノードでのスループットとクラスターの信頼性向上には非常に効果的です。 キャッシュからの整合性のある読み取り: Kubernetes v1.31 では、 キャッシュからの強力な整合性のある読み取り が導入され、読み取りトラフィックの大部分を etcd から API サーバーにオフロードできるようになりました。以前は、ラベルやフィールドベースのフィルタリングを必要とする読み取り（例えば、Kubelet がノードに割り当てられた Pod を list する場合）では、API サーバーがまず etcd から全コレクションを list して、その後メモリ内でフィルタリングを実行してクライアントにレスポンスを送信していました。新しいメカニズムは etcd とのキャッシュの鮮度を追跡し、最新の場合は API サーバーのキャッシュから直接読み取りを提供します。サーバー側の CPU 使用率を 30% 削減し、list リクエストを 3 倍高速化することで、大幅な読み取りスループットの向上が明らかになりました。超大規模テストの一環として、ページ分割された読み取りを行うクライアントが v1.33 で不必要に etcd にフォールバックしていることを 発見 し、v1.33.3 でこれを修正して、大量のリクエストが同時に発生するシナリオでのクラスターの安定性を回復させました。 大規模コレクションの効率的な読み取り: 大規模クラスターには大量オブジェクトのコレクションが伴います。これらを効率的に list することは、reconciliation loop を開始する前に全コレクションをフェッチする必要がある Kubernetes コントローラーの前提条件です。例えば、Anthropic はジョブスケジューラーでこれを必要としていました。Kubernetes v1.33 で有効化された list レスポンスのストリーミング 機能は、コレクション全体を一度にバッファリングするのではなく、コレクション内のアイテムを段階的にエンコード・送信することで、メモリ効率を向上させ、それによって API サーバーの list リクエストの同時実行性 (約 8 倍) を改善しました。 カスタムリソースのバイナリエンコーディング: Kubernetes カスタムリソース (CR) は、トレーニングジョブ、パイプライン、推論サービスをモデル化するために Kubeflow などの ML フレームワークで広く使用されています。これらのリソースは、非効率な JSON エンコーディングのため、大規模にそれらを保存、処理、クライアントに送信する際にサーバー側で大きなオーバーヘッドが生じます。Kubernetes v1.32 でアルファ版の機能として導入された Concise Binary Object Representation (CBOR) エンコーディング は、より効率的な代替手段を提供します。バイナリエンコーディングを使用してペイロードサイズとシリアル化のオーバーヘッドを最大 25% 削減し、CR の処理を高速化・低コスト化します。これは、AI/ML のお客様が一般的に使用するノードデーモンなど、高スループットで高カーディナリティの CR クライアントにも利点があります。この機能は現在、アップストリームではデフォルトで有効になっていないことに注意してください。私たちはパフォーマンスをベンチマークして、ベータ版への昇格を支援しています。 超高速クラスターコントローラー クラスタースコープで動作するコントローラーは通常、集中的なクラスター操作（Pod のスケジューリングなど）を実行するためにリソースのグローバルビューを維持する必要があります。高可用性のために複製されていますが、多くの場合、競合を避けるために「リーダー」レプリカのみが実際の作業を行っています。クラスターが大きくなるほど、メモリに保持する状態が大きくなり、依存関係の TPS が増加し、大量の決定を下す必要があります。ほとんどのコントローラーは、複数のワーカースレッドとロックセーフなワークキューを通じて、受信した作業を並列に処理できます。十分なリソースがあれば、コントローラーが達成するスループットは多くの場合、ワーカーの並列性または依存関係のレート制限によって制限されます。これらを改善することで、多くの Kubernetes および EKS コントローラーのスループットを向上させました。しかし、超大規模を達成するには、これを超えてコントローラーのアーキテクチャを改善する必要がありました。 ロックの競合を最小化: Kubernetes コントローラーは Informer パターンを広く使用しています。これは、リソースのローカルなインメモリキャッシュを維持し、変更が発生したときに登録されたハンドラーに通知することで、Kubernetes リソースの変更を効率的に追跡して対応するメカニズムです。変更自体は、Kubernetes API サーバーとの長時間実行される watch の接続を通じて配信されます。コントローラーのワーカースレッドが大規模な list を実行すると、共有された Informer のキャッシュで高い読み取りと書き込みのロック競合が発生し、受信イベントの処理が遅延し、キューの滞留、高いメモリ使用量、最終的には輻輳崩壊などの様々な二次的な影響を引き起こすことを観察しました。私たちはこの問題についてアップストリームで 広範な調査 を行い、大規模な list リクエストを最適化するインデックスを追加することで、いくつかの主要なコントローラーを修正しました。さらに、 バッチ処理 により、変更率の高いシナリオでのイベント処理スループットを最大 10 倍向上させました。これらの改善をアップストリームに継続的に貢献しています。 スケジューリングの最適化: お客様は現在、独自のスケジューラーを導入し、デフォルトの Kubernetes スケジューラー (KS) の代わりに、または併用して使用できます。特定の AI/ML ワークロードは、ギャングスケジューリングとプリエンプションを効率的に実行するジョブスケジューラーの恩恵を受けます。しかし、KS は Kubernetes の DaemonSet、Deployment、Job、StatefulSet に一般的に使用される最も汎用的なスケジューラーであり続けています。ほとんどのコントローラーとは異なり、KS は正確性を満たすために Pod を直列に処理するため、そのスループットは本質的にレイテンシーに制約されています。大規模クラスターでは、評価するノードが多いため、このレイテンシーが悪化します。しかし、ワークロードに基づいてスケジューラープラグインを慎重に調整し、ノードのフィルタリングとスコアリングのパラメータを最適化することで、10 万台のノード規模でも一貫して 毎秒 500 Pod という高いスループットを達成しました。 Karpenter の強化 Karpenter は、Kubernetes のための柔軟で高性能なノードライフサイクル管理プロジェクトで、AWS が主導しています。Pod のスケジューリングニーズに基づいて適切なサイズのノードを自動的にプロビジョニングし、使用率の低いノードを統合することで、お客様がクラスターを効率的にスケールしてコストを最適化するのに役立ちます。お客様は多くの場合、汎用ワークロードとアクセラレーテッドワークロードを同じクラスターで実行し、Karpenter でコンピュートを統一的に管理したいと考えています。しかし、いくつかの制限により、超大規模 AI/ML ワークロードに理想的に適合しませんでした。私たちはこれらの問題を解決するために Karpenter を進化させました。 超大規模のための保証されたキャパシティ: ML トレーニングジョブは特定のパターンでバッチ処理されることがよくあります。Karpenter のリアクティブなプロビジョニングモデルはこれを予測せず、大規模なジョブが同時に到着したときにプロビジョニングの遅延を引き起こす可能性があります。この問題に対処するために、静的キャパシティのサポートを導入しました。静的ノードプールを使用することで、お客様はクラスター内の最小限のノードセットを一貫して作成および維持でき、それによって長期間実行される AI/ML ワークロードのためのキャパシティを保証できます。また、NodeClass API で EC2 Capacity Blocks for ML のサポートも追加しました。キャパシティブロックは、モデルトレーニング、ファインチューニング、実験の実行、推論需要の急増に備えるのに理想的です。Karpenter は、他のキャパシティタイプにフォールバックする前に、静的キャパシティをプロビジョニングする際にキャパシティブロックの使用を優先します。これらの変更はまもなくアップストリームに反映される予定です。 アクセラレーテッドコンピュートの自動修復: アクセラレーターの故障は稀ですが、発生すると AI/ML ワークロードに混乱をもたらす可能性があります。健全性の低下を検出するために EKS ノードモニタリングエージェント と Karpenter の ノード修復 機能を使用することで、お客様は必要に応じて異常なノードの自動交換を実行できます。同様に、お客様は Amazon EKS 最適化アクセラレーテッド AMI などのコンピュート構成の更新を推進するためにドリフト機能を活用できます。私たちは Karpenter の様々なコントローラーを並列化して、スケール時のパフォーマンスを向上させました。さらに、テスト中にメモリ割り当てや依存する API の非効率な呼び出しによるいくつかのボトルネックを発見しました。リソース使用量を最適化し、冗長な API 呼び出しを排除し、適切な操作をバッチ処理するために、これらのコードパスを最適化しました。これらの変更はすべて、超大規模でのノード修復とドリフトのレイテンシーの改善に役立ち、アップストリームで利用可能になっています。 クラスターネットワークのスケーリング Amazon EKS は Kubernetes Pod のネイティブ VPC ネットワーキングをサポートし、オーバーレイネットワークのオーバーヘッドを回避します。また、 カスタムサブネット 、 セキュリティグループ 、アクセラレーテッドワークロード向けの Elastic Fabric Adapter (EFA) サポートなどの進んだネットワーク統合も可能にします。お客様は、トラフィックを処理するロードバランサーとバックエンド Pod 間のネットワークホップを排除することで、アプリケーションの高いパフォーマンスを実現できます。以下の機能強化により、超大規模 AI/ML 機能がさらに向上しました。 IP 割り当てからウォームプレフィックスへの移行: クラスタースケールが大きくなるにつれて、 Network Address Usage (NAU) メトリクスを計画する必要があります。各 NAU ユニットは VPC のサイズを表す合計に貢献し、VPC は最大 256,000 NAU、または別の VPC とピアリングされている場合は 512,000 NAU をサポートできます。デフォルトでは、各 Pod は現在クラスター VPC から個別の IP アドレスを取得します。IP アドレスと IP プレフィックス はプレフィックスサイズに関係なく単一の NAU ユニットとしてカウントされるため、超大規模クラスターでアドレス管理に プレフィックスモード を使用するように Amazon VPC CNI を構成しました。さらに、プレフィックスの割り当ては、Amazon VPC CNI がノード起動後にノードからローカルにネットワークメタデータを検出する形で、Karpenter によってインスタンス起動パスで直接行われました。これらの改善により、10 万台のノード用の単一の VPC でネットワークを合理化しながら、ノードの起動速度を最大 3 倍に高速化することができました。 ネットワークパフォーマンスの最大化: 巨大なペタバイト規模のデータセットでトレーニングする場合、ネットワーク帯域幅がボトルネックになる可能性があります。超大規模 AI/ML ワークロードでは、 Amazon S3 から膨大なデータをクラスターにプルする必要がよくあります。データを待つ間にアクセラレーターがアイドル状態になるのを避けるために、ストレージレイヤーとノード間の高帯域幅データ転送が必要です。デフォルトでは、Amazon VPC CNI は Pod に割り当てられた Elastic Network Interface (ENI) に対して 1 つの ネットワークカード を選択します。このネットワークカードは、Pod のすべての送受信トラフィックを処理します。複数のネットワークカードをサポートする高速コンピューティングインスタンスタイプでは、追加のネットワークカードに Pod ENI を作成するプラグインサポートを有効にしました。これにより、Pod のネットワーク帯域幅容量（100 GB/s 以上）とパケットレート性能が向上し、それによってアクセラレーターの使用率も向上しました。 高速コンテナイメージプル 超大規模 AI/ML ワークロードでは、PyTorch トレーニング、TensorFlow ノートブック、SageMaker ディストリビューションなど、5 GB を超える大規模なコンテナイメージを使用する傾向があることを観察しました。コンテナイメージのダウンロードと展開の速度は、ワークロードの準備において重要な要素です。私たちは Seekable OCI (SOCI) 高速プル を導入し、ダウンロードと展開の並列処理を可能にしました。SOCI 高速プルは大きなレイヤーをチャンクでダウンロードし、このステップをより速く完了させます。次に、Trn2 ならびに P5e と P6 インスタンスタイプの両方でサポートされている高い Elastic Block Store (EBS) IOPS (260k) とスループット (10 GB/s) を活用して、展開時間を短縮しました。各レイヤーが完了するのを待ってから次のレイヤーを開始するのではなく、複数のレイヤーを同時に解凍して処理できる並列展開を導入しました。私たちのテストでは、デフォルトと比較して全体的なイメージのダウンロードと展開が最大 2 倍高速化されることが示されています。さらに、ワーカーノード VPC に Amazon S3 VPC エンドポイントを作成し、アベイラビリティゾーンあたり 100 GB/s の帯域幅を保証しました。これにより、コンテナイメージレイヤーのダウンロード中に十分なスループットが確保され、ノードの準備が大幅に高速化されました。 規模のテスト 私たちのテスト方法の重要な原則は、お客様と緊密に協力し、お客様のニーズから逆算して作業することです。これは、実際の超大規模 AI/ML ワークロードと、それらの成功を可能にする統合を模倣することを意味します。これには、大規模な分散事前トレーニングジョブから複数の同時ファインチューニングまたは蒸留ジョブ、高スループット推論の提供まで、幅広いワークロードをカバーする必要がありました。アクセラレーテッドインフラストラクチャを活用するには、クラスターがコンピュート・ネットワーク・ストレージ用の様々なデバイスプラグインを実行し、 Amazon ECR 、 Amazon FSx 、 Amazon S3 などの重要な AWS サービスを利用する必要もあります。さらに、AI/ML のお客様は一般的に、ヘルスモニタリング（ EKS ノードモニタリングエージェント ）、テレメトリ（ Amazon CloudWatch エージェント 、 NVIDIA DCGM サーバー ）、アプリケーション認証情報（ EKS Pod Identity エージェント ）、イメージキャッシュのためのノードエージェントをインストールします。広範なテストを通じて、これらすべてのコア機能が 10 万台のノードでシームレスにスケールし、信頼性高く動作することを検証しました。 ノードライフサイクル まず、Karpenter を使用して、ノードプールとインスタンスタイプの組み合わせで 10 万台の Amazon EC2 インスタンスを起動しました。これは 50 分で完了し、1 分あたり 2000 の準備完了ノードがクラスターに参加するレートでした。次に、新しい AMI にすべてのノードを更新する ドリフト を実行しました。これはお客様にとって一般的な Day-2 オペレーションです。Karpenter はノードの Disruption Budget を尊重しながら、約 4 時間でクラスター全体をドリフトさせることができました。最後に、Karpenter ですべてのノードを 70 分でスケールダウンしました。以下のグラフは、それぞれプロビジョニング、ドリフト、終了のタイムラインを示しています。 図 2. 10 万台のノードプロビジョニングのタイムライン 図 3. Karpenter によるドリフトのタイムライン 図 4. ノード終了のタイムライン ワークロードテスト 私たちのテストは 3 つのシナリオをカバーしました。すべての 10 万台のノードで実行される大規模な事前トレーニングジョブ、それぞれ 1 万台のノードを使用する 10 の並列ファインチューニングジョブ、そして 7 万台のノードでファインチューニングジョブを実行し、3 万台のノードで大規模推論を提供する混合モードのワークロードです。Amazon ECR からプルした vLLM モデルサーバーと Amazon FSx からロードされたモデルの重みを使用して、Meta Llama-3.2-1B-Instruct で推論を提供するために LeaderWorkerSet を使用しました。最大 10 万個の異種の AI Pod を実行するクラスターを観察してください。 図 5. 10 万台のノードで実行される AI/ML テストシナリオ クラスターがこれらのワークロードを処理する際、高い Kubernetes API の読み取りスループット (左) と書き込みスループット (右) が問題なく提供されます。 図 6. 高スループットの読み取りと書き込みリクエスト そして、p99 API レイテンシーは、get と write (左) の 1 秒と list (右) の 30 秒という Kubernetes SLO ターゲット 内に十分収まっています。 図 7. SLO ターゲット内の Kubernetes API リクエストレイテンシー クラスターには 10 万台のノードと 90 万個の Pod を含む 1000 万個以上の Kubernetes オブジェクト (左) と、パーティション全体で 32 GB に達する集約された etcd データベースサイズ (右) が含まれています。 図 8. 1000 万個以上のオブジェクトを持つ 32 GB の etcd データベース Kubernetes スケジューラーは一貫して毎秒最大 500 Pod のスループット (左) を提供し、クラスターコントローラーは短いワークキューの待ち行列 (右) を維持しながら処理に対応できました。 図 9. 毎秒 500 Pod のスケジューラースループットと短いコントローラーワークキューの待ち行列 クラスターの回復力 クラスターの回復力をテストするために、1000 ノードにわたって健全性の低下を誘発し、EKS ノードモニタリングエージェントがそれらを検出して異常としてマークし、Karpenter がそれらを健全な新しいノードに置き換えるノード自動修復を実行するまでの時間を測定しました。全体として、劣化した 1000 ノードすべてが 5 分以内に健全な新しいノードに置き換えられました (左)。また、150 万 QPS でクラスター DNS クエリを引き起こしました。 EKS CoreDNS オートスケーラー が Deployment のレプリカを 4000 にスケールすることで、p99 クエリレイテンシーは 1 秒未満に保たれました (右)。 図 10. 1000 ノード障害と 150 万 QPS DNS クエリに対するクラスターの回復力 まとめ Amazon EKS の 10 万台のノードクラスターのサポートは、超大規模 AI/ML インフラストラクチャにおける画期的な進歩を表しており、お客様は単一の統合システムで最大 160 万個の AWS Trainium チップまたは 80 万個の NVIDIA GPU をデプロイできるようになりました。etcd コンセンサスを AWS のマルチ AZ の Journal システムにオフロードするなどの一連のアーキテクチャ改善と様々な最適化により、Kubernetes に完全に準拠しながら桁違いのパフォーマンス向上を達成しました。これらのイノベーションは、Anthropic のようなお客様が最先端のモデルトレーニングと推論ワークロードを大規模で実行できるようにするだけでなく、Amazon SageMaker HyperPod などの Amazon のより広範な AI/ML サービス基盤も強化します。生成 AI が計算要件の限界を押し上げ続ける中、私たちは前例のない信頼性、パフォーマンス、規模で次世代のアクセラレーテッドワークロードをサポートする準備ができています。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本記事は、2025 年 7 月 21 日に公開された Optimizing vector search using Amazon S3 Vectors and Amazon OpenSearch Service を翻訳したものです。翻訳は Solutions Architect の 深見 が担当しました。 注: 2025 年 7 月 22 日現在、Amazon S3 Vectorsと Amazon OpenSearch Service の統合機能はプレビューリリースであり、今後変更される可能性があります。 ベクトル埋め込み と類似度検索機能の進歩に伴い、データの保存と検索方法が急速に進化しています。ベクトル検索は、生成 AI やエージェント AI などの最新のアプリケーションにとって不可欠なものとなっています。しかし、大規模なベクトルデータを管理することは大きな課題があります。組織は、数百万または数十億ものベクトル埋め込みを保存して検索する際、レイテンシー、コスト、精度のトレードオフに悩まされることが多くあります。従来のソリューションでは、大規模なインフラストラクチャの管理が必要になるか、データ量が増えるにつれて非常に高額なコストがかかります。 私たちは、 Amazon Simple Storage Service (Amazon S3) Vectors と Amazon OpenSearch Service の 2 つの統合機能のパブリックプレビューを公開しました。これにより、ベクトル埋め込みをより柔軟に格納および検索することができるようになります。 コスト最適化されたベクトルストレージ : OpenSearch Service マネージドクラスターは、マネージドサービスの S3 Vectors を使用してコスト最適化されたベクトル格納を行います。この統合により、レイテンシーの増加を許容してでもコストを抑えつつ、高度な OpenSearch の機能 (ハイブリッド検索、高度なフィルタリング、地理フィルタリングなど) を利用したい OpenSearch のワークロードをサポートします。 S3 Vectors からのワンクリックエクスポート : S3 ベクトルインデックスから OpenSearch Serverless コレクションへのワンクリックエクスポートにより、高パフォーマンスのベクトル検索が可能になります。S3 Vectors 上にベクトルストアを構築されたお客様は、より高速なクエリパフォーマンスを得るために OpenSearch を利用できるメリットがあります。 これらの統合を利用することで、頻繁にクエリされないベクトルを S3 Vectors に保持し、ハイブリッド検索や集計などの高度な検索機能を必要とするようなレイテンシの制約が最も高い操作には OpenSearch を使用することで、ベクトルワークロードを賢く分散させ、コスト、レイテンシー、精度を最適化できます。さらに、OpenSearch のパフォーマンスチューニング機能 (量子化、k 近傍 (knn) アルゴリズム、メソッド固有のパラメータ) は、コストや精度をほとんど妥協することなく、パフォーマンスを向上させるのに役立ちます。 この投稿では、ベクトル検索の実装に柔軟なオプションを提供しながら、このシームレスなインテグレーションについて説明します。コスト最適化されたベクトル格納のために、OpenSearch Service マネージドクラスターで新しい S3 Vectors エンジンタイプを使用する方法と、高パフォーマンスのシナリオで 10ms という低レイテンシーの持続的なクエリが必要な場合に、S3 Vectors から OpenSearch Serverless コレクションへのワンクリックエクスポートを使用する方法を学びます。この投稿の最後には、パフォーマンス、コスト、スケーラビリティの具体的な要件に基づいて、適切なインテグレーションパターンを選択して実装する方法がわかります。 サービスの概要 Amazon S3 Vectors は、およそ 1 秒以内のベクトル検索機能をネイティブでサポートする初めてのクラウドオブジェクトストアで、インフラストラクチャ管理は不要です。Amazon S3 の簡単さ、耐久性、可用性、コスト効率性に、ネイティブのベクトル検索機能を組み合わせたものです。ベクトル埋め込みを直接 S3 に保存して検索できます。Amazon OpenSearch Service は、ベクトルワークロードに対してマネージドクラスターと サーバーレスコレクションの 2 つの補完的なデプロイメントオプションを提供しています。どちらも Amazon OpenSearch の強力なベクトル検索と検索機能を活用しますが、それぞれが異なるシナリオに適しています。OpenSearch ユーザーにとって、S3 Vectors と Amazon OpenSearch Service の統合により、ベクトル検索アーキテクチャを最適化する前例のない柔軟性が得られます。リアルタイムアプリケーションに超高速のクエリパフォーマンスが必要な場合も、大規模なベクトルデータセットに低コストのストレージが必要な場合も、この統合により、特定のユースケースに最適なアプローチを選択できます。 ベクトル格納オプションの理解 OpenSearch Service は、さまざまなユースケースに最適化された、ベクトル埋め込みを格納および検索するための複数のオプションを提供しています。Lucene エンジン (OpenSearch のネイティブ検索ライブラリ) は、 Hierarchical Navigable Small World (HNSW) 手法を実装しており、効率的なフィルタリング機能と OpenSearch のコア機能との強力な統合を提供します。さらなる最適化オプションが必要なワークロードの場合、 Faiss エンジン (Facebook AI Similarity Search) は、 HNSW と IVF (Inverted File Index) の両方の手法 の実装に加えて、ベクトル圧縮の機能を提供します。HNSW はベクトル間の接続の階層的なグラフ構造を作成し、検索時の効率的なナビゲーションを可能にします。一方、IVF はベクトルをクラスター化し、クエリ時に関連するサブセットのみを検索します。S3 エンジンタイプの導入により、Amazon S3 の耐久性とスケーラビリティを活用しながら、およそ 1 秒以内のクエリパフォーマンスを維持できる、コスト効率の高いオプションが利用可能になりました。このように多様なオプションから、パフォーマンス、コスト、精度に関する特定の要件に基づいて最適なアプローチを選択できます。たとえば、アプリケーションが 50 ms 未満のクエリレスポンスと効率的なフィルタリングを必要とする場合、Faiss の HNSW 実装が最適な選択肢です。一方、ストレージコストを最適化しながら妥当なパフォーマンスを維持する必要がある場合は、新しい S3 エンジンタイプがより適切でしょう。 ソリューションの概要 この投稿では、2 つの主要な統合パターンについて説明します。 OpenSearch Service マネージドクラスターをマネージドサービスの S3 Vectors と使用して、ベクトルストレージのコストを最適化する OpenSearch Service ドメインを既に使用しており、およそ 1 秒以内のクエリパフォーマンスを維持しながらコストを最適化したいお客様向けに、新しい Amazon S3 エンジンタイプが魅力的なソリューションを提供します。OpenSearch Service は、Amazon S3 でのベクトル格納、データ取得、キャッシュ最適化を自動的に管理するため、運用オーバーヘッドがなくなります。 S3 ベクトルインデックスから OpenSearch Serverless コレクションへのワンクリックエクスポートにより、高性能なベクトル検索が可能に より高速なクエリパフォーマンスが必要なユースケースでは、S3 ベクトルインデックスからベクトルデータを OpenSearch Serverless コレクションに移行できます。この方法は、リアルタイムのレスポンスタイムが必要なアプリケーションに最適で、 Amazon OpenSearch Serverless の利点を得られます。これには、高度なクエリ機能とフィルタ、自動スケーリングと高可用性、管理の手間がかからないことが含まれます。エクスポートプロセスでは、スキーママッピング、ベクトルデータ転送、インデックス最適化、接続設定が自動的に処理されます。 次の図は、Amazon OpenSearch Service と S3 Vectors の間の 2 つの統合パターンを示しています。 前提条件 始める前に、次の項目について確認してください。 AWS アカウント Amazon S3 と Amazon OpenSearch Service へのアクセス権 OpenSearch Service ドメイン (１ 番目の統合パターンの場合) S3 ベクトルに格納されたベクトルデータ (2 番目の統合パターンの場合) 統合パターン 1 : S3 Vectors を使用した OpenSearch Service マネージドクラスター このパターンを実装するには: OpenSearch バージョン 2.19 で OR1 インスタンス を使用して OpenSearch Service ドメインを作成 します。 OpenSearch Service ドメインを作成する際、 Advanced features セクションで Enable S3 Vectors as an engine option を選択します。 OpenSearch Dashboards にサインイン し、 Dev tools を開きます。次に、knn インデックスを作成し、 engine として s3vector を指定します。 PUT my-first-s3vector-index { "settings": { "index": { "knn": true } }, "mappings": { "properties": { "my_vector1": { "type": "knn_vector", "dimension": 2, "space_type": "l2", "method": { "engine": "s3vector" } }, "price": { "type": "float" } } } } ベクトルを Bulk API を使ってインデクシングします: POST _bulk { "index": { "_index": "my-first-s3vector-index", "_id": "1" } } { "my_vector1": [2.5, 3.5], "price": 7.1 } { "index": { "_index": "my-first-s3vector-index", "_id": "3" } } { "my_vector1": [3.5, 4.5], "price": 12.9 } { "index": { "_index": "my-first-s3vector-index", "_id": "4" } } { "my_vector1": [5.5, 6.5], "price": 1.2 } { "index": { "_index": "my-first-s3vector-index", "_id": "5" } } { "my_vector1": [4.5, 5.5], "price": 3.7 } { "index": { "_index": "my-first-s3vector-index", "_id": "6" } } { "my_vector1": [1.5, 2.5], "price": 12.2 } 通常どおり knn クエリを実行します: GET my-first-s3vector-index/_search { "size": 2, "query": { "knn": { "my_vector1": { "vector": [2.5, 3.5], "k": 2 } } } } 次のアニメーションは、上記の手順 2 から 4 を示しています。 統合パターン 2 : S3 ベクトルインデックスを OpenSearch Serverless にエクスポート このパターンを実装するには: Amazon S3 の AWS マネジメントコンソールに移動し、S3 Vector Bucket を選択します。 エクスポートしたいベクトルインデックスを選択します。 Advanced search export の下にある Export to OpenSearch を選択してください。 または、次のようにすることもできます。 OpenSearch Service コンソールに移動します。 ナビゲーションペインから Integrations を選択します。 ここに Import S3 vectors to OpenSearch vector engine – preview という新しい統合テンプレートが表示されます。 Import S3 vector index を選択してください。 次に、 Export S3 vector index to OpenSearch vector engine テンプレートが事前に選択され、S3 ベクトルインデックスの Amazon リソースネーム (ARN) が事前に入力された Amazon OpenSearch Service 統合コンソールに移動します。 必要な権限 を持つ既存のロールを選択するか、新しいサービスロールを作成してください。 下にスクロールして Export を選択し、新しい OpenSearch Serverless コレクションを作成し、S3 ベクトルインデックスからデータを OpenSearch knn インデックスにコピーする手順を開始します。 OpenSearch Service コンソールの インポート履歴 ページに移動します。ここで、S3 ベクトルインデックスを OpenSearch サーバーレス knn インデックスに移行するために作成された新しいジョブが表示されます。ステータスが In Progress から Complete に変わったら、 新しい OpenSearch サーバーレスコレクションに接続 し、 新しい OpenSearch knn インデックスをクエリ できます。 次のアニメーションは、新しい OpenSearch サーバーレスコレクションに接続し、Dev ツールを使用して新しい OpenSearch knn インデックスをクエリする方法を示しています。 クリーンアップ 継続的な課金を避けるには: パターン 1 の場合: S3 Vectors を使用する OpenSearch インデックスを削除 します。 不要になった場合は、 OpenSearch Service マネージドクラスターを削除 します。 パターン 2 の場合: OpenSearch Service コンソールの Import history セクションからインポートタスクを削除します。このタスクを削除すると、インポートタスクによって自動的に作成された OpenSearch ベクトルコレクションと OpenSearch 取り込みパイプラインの両方が削除されます。 結論 Amazon S3 Vectors と Amazon OpenSearch Service の革新的な統合は、ベクトル検索技術の変革的な到達点を示し、企業に前例のない柔軟性とコスト効率を提供します。この強力な組み合わせは、それぞれのサービスの長所を兼ね備えています。Amazon S3 の高い耐久性とコスト効率が、OpenSearch の高度な AI 検索機能とシームレスに融合しています。企業は今や、ベクトル検索ソリューションを数十億ものベクトルまでスケールアップできるようになり、レイテンシー、コスト、精度を制御できるようになりました。OpenSearch Service を使って 10ms という極めて高速なクエリ性能を優先するか、S3 Vectors を使ってコスト最適化された秒未満の優れた性能を実現するか、OpenSearch で高度な検索機能を実装するかに応じて、この統合はお客様のニーズに合った完璧なソリューションを提供します。OpenSearch マネージドクラスターで S3 Vectors エンジンを試し、S3 ベクトルインデックスから OpenSearch Serverless への 1 クリックエクスポートをテストすることで、今すぐ始めることをお勧めします。 詳細については、以下をご覧ください。 Amazon S3 Vectors のドキュメント Amazon OpenSearch Service のドキュメント OpenSearch Service と Amazon S3 Vectors の統合 Amazon OpenSearch Service ベクトルデータベースのブログ 著者について Sohaib Katariwala は、シカゴに拠点を置く Amazon OpenSearch Service を専門とする AWS のシニアスペシャリストソリューションアーキテクトです。彼の関心は、データとアナリティクス全般にあります。特に、顧客が AI を活用してデータ戦略を立て、現代の課題を解決することを支援することに情熱を注いでいます。 Mark Twomey は、ストレージとデータ管理に特化した AWS のシニアソリューションアーキテクトです。適切なタイミングで適切な場所に適切なコストでデータを配置できるよう、お客様と協力することを楽しんでいます。アイルランド在住の Mark は、田舎を散歩したり、映画を観たり、本を読むことが好きです。 Sorabh Hamirwasia は、OpenSearch プロジェクトで働く AWS のシニアソフトウェアエンジニアです。主な関心事は、コスト最適化された高性能な分散システムの構築です。 Pallavi Priyadarshini は、Amazon OpenSearch Service の Senior Engineering Manager で、検索、セキュリティ、リリース、ダッシュボードの高性能でスケーラブルなテクノロジーの開発を主導しています。 Bobby Mohammed は、AWS の Principal Product Manager で、検索、GenAI、Agentic AI の製品イニシアチブを主導しています。以前は、SageMaker プラットフォームでのデータ、分析、ML 機能、Intel での深層学習トレーニングと推論製品など、機械学習のフルライフサイクルにわたる製品に携わっていました。

7 月 17 日、 AWS Lambda の 2 つの重要な機能強化、すなわち、コンソールと IDE の統合、およびリモートデバッグを発表します。これにより、デベロッパーは、ローカル開発環境でサーバーレスアプリケーションを構築したり、デバッグしたりするのがこれまで以上に容易になります。これらの新機能は、2024 年後半にリリースされた 強化されたコンソール内編集エクスペリエンス や 改善されたローカル統合開発環境 (IDE) エクスペリエンス など、Lambda 開発エクスペリエンスに対する最近の改善に基づいています。 サーバーレスアプリケーションを構築する際、デベロッパーは通常、ワークフローを合理化するために、ローカル開発環境のセットアップとクラウドデバッグ機能という 2 つの領域に重点的に取り組みます。デベロッパーはコンソールから IDE に関数を持ち込むことができますが、このプロセスをより効率的にする方法を模索しています。さらに、関数はクラウド内のさまざまな AWS サービスとインタラクションするため、デベロッパーは、開発サイクルで早めに問題を特定して解決するための、強化されたデバッグ機能を求めています。この機能を使用することで、ローカルエミュレーションへの依拠を減らし、開発ワークフローを最適化するのに役立ちます。 コンソールと IDE の統合 1 つ目の課題に対処するため、コンソールと IDE の統合を導入します。これにより、 AWS マネジメントコンソール から Visual Studio Code (VS Code) へのワークフローが効率化されます。この新機能は、 [Visual Studio Code で開く] ボタンを Lambda コンソールに追加します。これにより、デベロッパーは、ブラウザで関数を表示した後、迅速に IDE で編集できるようになるため、ローカル開発環境のための時間のかかるセットアッププロセスが不要になります。 コンソールと IDE の統合により、セットアッププロセスが自動的に処理され、VS Code のインストールと AWS Toolkit for VS Code の確認が行われます。すべてを既に設定済みのデベロッパーの場合、このボタンを選択するとすぐに VS Code で関数コードが開くため、編集を続行して、数秒で変更を Lambda にデプロイできます。VS Code がインストールされていない場合、デベロッパーはダウンロードページにリダイレクトされ、AWS Toolkit がない場合はインストールを促すメッセージが表示されます。 コンソールと IDE の統合を使用するには、新しい関数を作成した後に表示される [開始方法] のポップアップ、または既存の Lambda 関数の [コード] タブのいずれかで、 [VS Code で開く] ボタンを見つけます。このボタンを選択すると、VS Code が自動的に開きます (必要に応じて AWS Toolkit がインストールされます)。コンソール環境とは異なり、統合ターミナルを備えた完全な開発環境にアクセスできるようになりました。これは、パッケージの管理 (npm install、pip install)、テストの実行、リンターやフォーマッターなどの開発ツールの使用が必要なデベロッパーにとって大きな改善です。コードを編集したり、新しいファイル/フォルダを追加したりできます。変更を加えると、自動デプロイプロンプトがトリガーされます。デプロイを選択すると、AWS Toolkit は自動的に関数を AWS アカウントにデプロイします。 リモートデバッグ デベロッパーが IDE に関数を用意すると、リモートデバッグを使用して、AWS アカウントにデプロイされた Lambda 関数を VS Code から直接デバッグできます。リモートデバッグの主な利点は、他の AWS サービスと統合しながら、デベロッパーがクラウドで実行されている関数をデバッグできるようにするということです。これにより、開発の迅速化と信頼性の向上を実現できます。 リモートデバッグを使用すると、デベロッパーは、 Amazon Virtual Private Cloud (VPC) リソースと AWS Identity and Access Management (AWS IAM) ロールへの完全なアクセスを使用して関数をデバッグできるため、ローカル開発とクラウド実行の間のギャップが解消されます。例えば、VPC 内の Amazon Relational Database Service (Amazon RDS) データベースとインタラクションする Lambda 関数をデバッグする場合、デベロッパーは、本番と一致しない可能性のあるローカル環境のセットアップに時間を費やすのではなく、クラウドで実行されている関数の 実行環境 を数秒以内にデバッグできるようになりました。 リモートデバッグの使用を開始するのは簡単です。デベロッパーは VS Code で Lambda 関数を選択し、数秒でデバッグを有効にすることができます。AWS Toolkit for VS Code は、関数コードを自動的にダウンロードし、安全なデバッグ接続を確立して、ブレークポイント設定を有効にします。デバッグが完了すると、AWS Toolkit for VS Code はデバッグ設定を自動的にクリーンアップし、本番トラフィックへの影響を防ぎます。 試してみましょう リモートデバッグを試してみるために、Python で記述された基本的な「hello world」サンプル関数を使用して開始することにしました。この関数は、以前に AWS Lambda 用に AWS マネジメントコンソール を使用して作成したものです。AWS Toolkit for VS Code を使用すると、 [エクスプローラー] ペインで関数に移動できます。関数の上にマウスを移動して右クリック (Windows の場合は Ctrl キーを押しながらクリック) すると、コードがローカルマシンにダウンロードされ、IDE で編集できるようになります。ファイルを保存すると、最新の変更を Lambda にデプロイするかどうかをたずねられます。 ここから再生アイコンを選択すると、関数の [リモート呼び出し設定] ページが開きます。このダイアログに [リモートデバッグ] オプションが表示されるので、関数ハンドラーコードのローカルコピーをポイントするように設定します。 [リモート呼び出し] を選択する前に、左側の、コードを一時停止して検査する任意の場所でブレークポイントを設定できます。 コードは呼び出されるとクラウドで実行され、VS Code でステータスをリアルタイムでモニタリングできます。次のスクリーンショットでは、print ステートメントにブレークポイントが設定されているのがわかります。関数はコードのこの位置で実行を一時停止し、ローカル変数の値などを検査してから、次のブレークポイントに進んだり、コードを 1 行ずつステップインしたりできます。 ここでは、コードをステップインすることを選択しました。コードを 1 行ずつ実行していくと、IDE の左側にコンテキストとローカル変数およびグローバル変数が表示されます。さらに、IDE の下部にある [出力] タブでログを追跡できます。ステップスルーする中で、関数の実行によるログメッセージや出力メッセージがリアルタイムで表示されます。 強化された開発ワークフロー これらの新機能は連携して動作し、より効率的な開発エクスペリエンスを実現します。デベロッパーはコンソールから開発を開始し、コンソールと IDE の統合を使用して VS Code に迅速に移行して、リモートデバッグを使用してクラウドで実行されている関数をデバッグできます。このワークフローにより、複数のツールや環境を切り替える必要がなくなります。これは、デベロッパーが問題をより迅速に特定して修正するのに役立ちます。 今すぐご利用いただけます これらの新機能は、AWS Toolkit for VS Code (v3.69.0 以降) がインストールされた AWS マネジメントコンソールと VS Code を通じて利用を開始できます。コンソールと IDE の統合は、AWS GovCloud (米国) リージョンを除く、Lambda が利用可能なすべての商用 AWS リージョン でご利用いただけます。詳細については、 Lambda および AWS Toolkit for VS Code のドキュメントをご覧ください。リモートデバッグ機能の詳細 (利用可能な AWS リージョンなど) については、 AWS Toolkit for VS Code および Lambda のドキュメントにアクセスしてください。 コンソールと IDE の統合およびリモートデバッグは追加コストなしでご利用いただけます。リモートデバッグでお支払いいただくのは、デバッグセッションにおける標準の Lambda 実行コストのみです。リモートデバッグは、リリース時点では Python、Node.js、Java ランタイムをサポートし、将来的には他のランタイムにもサポートを拡大する予定です。 これらの機能強化は、サーバーレス開発エクスペリエンスの簡素化に向けた大きな前進であり、デベロッパーはこれまで以上に効率的に Lambda 関数を構築およびデバッグできるようになります。 原文は こちら です。

2018 年以来、 AWS DeepRacer は世界中で 560,000 人超のビルダーを魅了し、デベロッパーが競争的なエクスペリエンスを通じて学び、成長できることを実証してきました。本日、当社は AWS Artificial Intelligence (AI) League により拡張して、 生成 AI 時代に乗り出します。 これは他に類を見ない競争的なエクスペリエンスです。スキルレベルにかかわらず、生成 AI を深く探求し、仲間と競い合い、魅力的かつ競争的なエクスペリエンスを通じて実際のビジネス課題を解決するソリューションを構築するチャンスです。 AWS AI League では、お客様の組織がプライベートトーナメントを開催します。このトーナメントでは、チームが協力して、実用的な AI スキルを用いて実際のビジネスユースケースを解決するために競い合います。参加者は効果的なプロンプトを作成し、モデルをファインチューニングしながら、ビジネスに関連する強力な生成 AI ソリューションを構築します。競争を通じて、参加者のソリューションは、精度とレイテンシーに基づいてパフォーマンスを追跡するリアルタイムのリーダーボード上で、リファレンス標準に照らして評価されます。 AWS AI League エクスペリエンスは、AWS のエキスパートが主導する 2 時間のハンズオンワークショップから始まります。その後、自分のペースで実験し、最後はゲームショー形式のグランドフィナーレで、参加者がビジネス課題を解決する、生成 AI を用いて生み出した成果を披露します。組織は半日以内に独自の AWS AI League をセットアップできます。スケーラブルな設計により、効率的なタイムラインを維持しながら、500～5,000 人の従業員をサポートできます。 最大 200 万 USD 相当の AWS クレジット と、 AWS re:Invent 2025 での 25,000 USD の賞金総額によって支えられるこのプログラムは、実際のビジネス課題を解決するユニークな機会を提供します。 AWS AI League は、組織における生成 AI 機能の開発方法を変革します AWS AI League は、ハンズオンのスキル開発、ドメインの専門知識、ゲーミフィケーションを組み合わせることで、組織における生成 AI 機能の開発方法を変革します。このアプローチは、あらゆるスキルレベルのユーザーのために、AI 学習をアクセシブルかつ魅力的なものにします。チームは、実際の組織のニーズを反映した業界固有の課題を通じて連携します。各課題では、実際のビジネス要件を反映したリファレンスデータセットと評価基準が提供されます。 カスタマイズ可能な業界固有の課題 – 特定のビジネスコンテキストに合わせて競争をカスタマイズできます。ヘルスケアチームは患者の退院サマリーの作成に取り組み、金融サービスは不正検出に注力し、メディア企業はコンテンツ作成ソリューションを開発します。 統合 AWS AI スタックエクスペリエンス – 参加者は、 Amazon SageMaker AI 、 Amazon Bedrock 、 Amazon Nova などの AWS の AI および ML ツールを実際に体験できます。これらのツールは、 Amazon SageMaker Unified Studio からアクセスできます。チームは、組織の AWS アカウント内の、コスト管理された安全な環境で作業します。 リアルタイムのパフォーマンス追跡 – リーダーボードは、競争を通じて、提出されたものを既存のベンチマークとリファレンス標準に照らして評価し、正確性と速度に関する即時のフィードバックを提供するため、チームはソリューションをイテレーションして改善できます。最終ラウンドでは、このスコアリングにはエキスパートによる評価が含まれます。ドメインのエキスパートとライブオーディエンスがリアルタイムで投票に参加し、実際のビジネス課題を最も効果的に解決する AI ソリューションを決定します。 AWS AI League は、2 つの基礎的な競争トラックを提供します: Prompt Sage – The Ultimate Prompt Battle – 画期的なソリューションを実現する完璧な AI プロンプトの作成を競います。金融詐欺の検出からヘルスケアワークフローの合理化まで、ゼロショット学習と思考の連鎖推論を用いてリーダーボードの上位を目指す参加者にとって、あらゆる単語が重要です。 Tune Whiz – The Model Mastery Showdown – 汎用 AI モデルを業界固有の強力なモデルへと磨き上げ、その能力を高めます。参加者は、ドメインの専門知識と専門的な質問を武器に、ビジネス言語を流暢に話すモデルをファインチューニングします。圧倒的なパフォーマンス、驚異的な効率性、コスト最適化の完璧なバランスを実現した参加者が勝利を手にします。 生成 AI は進化を続けており、AWS AI League ではこれらのトラックに加えて、定期的に新しいチャレンジやフォーマットを導入していく予定です。 今すぐご利用いただけます 始める準備はできていますか? 組織は、 AWS AI League ページ を通じて申し込むことで、プライベートコンテストを開催できます。個人デベロッパーは、 AWS Summits や AWS re:Invent で開催されるパブリックコンテストに参加できます。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。この件に関して、技術的なガイダンスと専門知識を活用して惜しみなくご支援いただいた Natasya Idries 氏に感謝申し上げます。このご支援のおかげで、この概要を包括的にまとめることができました。 –  Eli 原文は こちら です。

コンテナは開発チームがアプリケーションをパッケージ化およびデプロイする方法に革命をもたらしましたが、これらのチームは、デプロイリスクを軽減するためにリリースを注意深くモニタリングしたり、カスタムツールを構築したりする必要があり、これがリリース速度の低下につながっています。大規模な開発では、開発チームはビジネスのためのイノベーションではなく、差別化につながらないデプロイツールの構築とメンテナンスに貴重なサイクルを費やしています。 7 月 17 日より、 Amazon Elastic Container Service (Amazon ECS) に組み込まれているブルー/グリーンデプロイ機能を使用して、アプリケーションのデプロイをより安全かつ一貫性のあるものにすることができます。この新機能により、カスタムデプロイツールを構築する必要がなくなり、ロールバック機能を使用してソフトウェアアップデートをより頻繁にリリースすることについての自信がつきます。 Amazon ECS コンソールで組み込みのブルー/グリーンデプロイ機能を有効にする方法を次に示します。 既存の「ブルー」環境でライブトラフィックを引き続き処理しながら、新しい「グリーン」アプリケーション環境を作成します。グリーン環境を徹底的にモニタリングおよびテストした後、ライブトラフィックをブルーからグリーンにルーティングします。この機能により、Amazon ECS は、コンテナ化されたアプリケーションのデプロイをより安全で信頼性の高いものにする組み込み機能を提供するようになりました。 アプリケーショントラフィックをブルー環境からグリーン環境にシフトすることで、ブルー/グリーンデプロイがどのように機能するかを説明する図を以下に示します。詳細については、 Amazon ECS ブルー/グリーンサービスデプロイのワークフロー のページをご覧ください。 Amazon ECS は、本番トラフィックをルーティングする前に合成トラフィックを使用して新しいバージョンを検証するためのイベントフックを提供しながら、このワークフロー全体をオーケストレートします。エンドユーザーに公開する前に本番環境で新しいソフトウェアバージョンを検証し、問題が発生した場合にはほぼ瞬時にロールバックできます。この機能は Amazon ECS に直接組み込まれているため、カスタムツールを構築することなく、設定を更新するだけでこれらの安全対策を追加できます。 開始方法 ECS サービスのブルー/グリーンデプロイを設定して使用する方法を示すデモをご紹介します。その前に、 AWS Identity and Access Management (IAM) ロールの設定など、いくつかのセットアップステップを完了する必要があります。IAM ロールは、「 Required resources for Amazon ECS blue/green deployments 」ドキュメントページに記載されています。 このデモでは、リスクを最小限に抑えるために、ブルー/グリーン戦略を使用してアプリケーションの新しいバージョンをデプロイします。まず、ブルー/グリーンデプロイを使用するように ECS サービスを設定する必要があります。これは、ECS コンソールや AWS コマンドラインインターフェイス (AWS CLI) を通じて、または Infrastructure as Code を使用して行うことができます。 Amazon ECS コンソールを使用して、新しいサービスを作成し、通常どおりに設定します: [デプロイオプション] セクションで、 [デプロイコントローラータイプ] として [ECS] を選択し、 [デプロイ戦略] として [ブルー/グリーン] を選択します。 [ベイク時間] とは、本番トラフィックがグリーンにシフトした後、ブルーへの即時ロールバックが可能になるまでの時間です。ベイク時間が経過すると、ブルータスクは削除されます。 また、デプロイライフサイクルフックも導入されます。これらは、デプロイワークフローを拡張するために使用できるイベントドリブンのメカニズムです。デプロイライフサイクルフックとして使用する AWS Lambda 関数を選択できます。Lambda 関数は必要なビジネスロジックを実行できますが、フックステータスを返す必要があります。 Amazon ECS は、ブルー/グリーンデプロイ中に次のライフサイクルフックをサポートします。各ステージの詳細については、 デプロイライフサイクルステージ のページをご覧ください。 スケールアップ前 スケールアップ後 本番トラフィックシフト テストトラフィックシフト 本番トラフィックシフト後 テストトラフィックシフト後 私のアプリケーションでは、テストトラフィックシフトが完了し、グリーンサービスがすべてのテストトラフィックを処理するようになったときにテストしたいと考えています。エンドユーザートラフィックはないため、このステージでロールバックしてもユーザーに影響はありません。そのため、まずは自分の Lambda 関数を使用してテストできるので、 [テストトラフィックシフト後] が私のユースケースに適しています。 少しコンテキストを変えて、デプロイの続行を許可する前にそのデプロイを検証するために使用する Lambda 関数に注目してみましょう。デプロイライフサイクルフックとしての Lambda 関数では、合成テスト、別の API の呼び出し、メトリクスのクエリなど、あらゆるビジネスロジックを実行できます。 Lambda 関数内では、 hookStatus を返す必要があります。 hookStatus が SUCCESSFUL の場合、プロセスは次のステップに進みます。ステータスが FAILED の場合、ブルーデプロイにロールバックします。 IN_PROGRESS の場合、Amazon ECS は 30 秒後に Lambda 関数を再試行します。 次の例では、アプリケーションのテストスイートの一部としてファイルアップロードを実行する Lambda 関数を使用して検証をセットアップしました。 import json import urllib3 import logging import base64 import os # ログ記録を設定します logger = logging.getLogger() logger.setLevel(logging.DEBUG) # HTTP クライアントを初期化します http = urllib3.PoolManager() def lambda_handler(event, context): """ Validation hook that tests the green environment with file upload """ logger.info(f"Event: {json.dumps(event)}") logger.info(f"Context: {context}") try: # 実際のシナリオでは、テストエンドポイント URL を作成します test_endpoint = os.getenv("APP_URL") # アップロード用のテストファイルを作成します test_file_content = "This is a test file for deployment validation" test_file_data = test_file_content.encode('utf-8') # ファイルアップロード用のマルチパートフォームデータを準備します fields = { 'file': ('test.txt', test_file_data, 'text/plain'), 'description': 'Deployment validation test file' } # ファイルアップロードを含む POST リクエストを /process エンドポイントに送信します response = http.request( 'POST', test_endpoint, fields=fields, timeout=30 ) logger.info(f"POST /process response status: {response.status}") # レスポンスに OK ステータスコード (200～299 の範囲) が含まれているかどうかを確認します if 200 <= response.status < 300: logger.info("File upload test passed - received OK status code") return { "hookStatus": "SUCCEEDED" } else: logger.error(f"File upload test failed - status code: {response.status}") return { "hookStatus": "FAILED" } except Exception as error: logger.error(f"File upload test failed: {str(error)}") return { "hookStatus": "FAILED" } デプロイがフックに関連付けられたライフサイクルステージに達すると、Amazon ECS は、デプロイコンテキストを使用して Lambda 関数を自動的に呼び出します。この検証関数は、グリーンリビジョンに対して包括的なテスト (アプリケーションの正常性のチェック、統合テストの実行、パフォーマンスメトリクスの検証など) を実行できます。その後、関数は、デプロイを続行するか、中止するかを ECS に知らせます。 また、私はブルー/グリーンデプロイ戦略を選択したため、ロードバランサーおよび/または Amazon ECS Service Connect を設定する必要があります。 [ロードバランシング] セクションで、 [Application Load Balancer] を選択します。 [リスナー] セクションで、ポート 80 の既存のリスナーを使用し、2 つの [ターゲットグループ] を選択します。 この設定に問題がなければ、サービスを作成し、ECS が新しいサービスをプロビジョニングするのを待ちます。 ブルー/グリーンデプロイのテスト 次に、ブルー/グリーンデプロイをテストします。このテストでは、テストトラフィックシフトが完了した後、Amazon ECS は Lambda 関数をトリガーします。この場合、私の Lambda 関数はアプリケーションへのファイルアップロードを実行するため FAILED を返しますが、私のアプリケーションにはこの機能がありません。 サービスを更新し、ブルー/グリーンデプロイ機能が失敗を検出した場合にはロールバックしてくれるので安心して [新しいデプロイの強制] にチェックを入れます。タスク定義は変更していませんが、引き続き新しいデプロイをトリガーする必要があるため、このオプションを選択します。 このステージでは、ブルー環境とグリーン環境の両方が実行中であり、グリーンリビジョンがすべてのテストトラフィックを処理しています。一方、Lambda 関数の Amazon CloudWatch Logs に基づいて、デプロイライフサイクルフックが想定どおりに機能し、次のペイロードが出力されていることも確認できます: [INFO] 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Event: { "executionDetails": { "testTrafficWeights": {}, "productionTrafficWeights": {}, "serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice", "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854" }, "executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5", "lifecycleStage": "POST_TEST_TRAFFIC_SHIFT", "resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt" } 想定どおり、私の AWS Lambda 関数はテストの実行に失敗したため、 hookStatus として FAILED を返します。 [ERROR] 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File upload test failed: HTTPConnectionPool(host='xyz.us-west-2.elb.amazonaws.com', port=80): Max retries exceeded with url: / (Caused by ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f8036273a80>, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (connect timeout=30)')) 検証が正常に完了しなかったため、Amazon ECS は、以前の機能するデプロイバージョンであるブルーバージョンへのロールバックを試みます。 [イベント] セクションの ECS イベントを通じてこのプロセスをモニタリングでき、デプロイの進行状況を詳細に確認できます。 Amazon ECS は、デプロイを以前の機能するバージョンに正常にロールバックします。ブルーリビジョンは実行中のままとなり、本番トラフィックを受信できる準備が整っているため、ロールバックはほぼ瞬時に行われます。このプロセス中は、本番トラフィックが新しいアプリケーションバージョンにシフトすることはないため、エンドユーザーへの影響はありません。ECS がテストトラフィックを元の安定したバージョンにロールバックするだけです。これにより、従来のローリングデプロイに伴う一般的なデプロイのダウンタイムが排除されます。 また、ロールバックのステータスは [前回のデプロイ] セクションで確認できます。 テスト全体を通じて、ブルー/グリーンデプロイ戦略が一貫した予測可能な動作を提供することがわかりました。さらに、デプロイライフサイクルフックにより、デプロイの動作をより柔軟に制御できます。各サービスリビジョンは、タスク定義、ロードバランサーの設定、Service Connect の設定など、イミュータブルな設定を維持します。これは、ロールバックによって、以前実行されていたのとまったく同じ環境が復元されることを意味します。 知っておくべき追加情報 いくつかの留意点を次に示します: 料金 – ブルー/グリーンデプロイ機能は、追加料金なしで Amazon ECS に含まれます。お支払いいただくのは、デプロイプロセス中に使用されたコンピューティングリソースについての料金のみです。 利用可能なリージョン – この機能は、すべての商用 AWS リージョンでご利用いただけます。 Amazon ECS コンソール で Amazon ECS サービスの設定を更新して、ブルー/グリーンデプロイの使用を開始しましょう。 よいデプロイを! – Donnie 原文は こちら です。

はじめに 2025 年 6 月 26 日に AWS Summit Japan 2025 の AWS Builders’ Fair にて、カメラと重量センサーを活用した新しいスマート廃棄物管理ソリューションを展示しました。これは、過去に AWS Blog で紹介されたソリューションを基に、日本の食品を取り扱う企業が直面する課題に合わせて改良を加えたものです。 特に外食企業やスーパーマーケットでは、「何が」「どこで」「どれくらい」廃棄されているかの把握が重要な課題となっています。従来の手作業による管理では多大な労力が必要でしたが、本ソリューションでは生成 AI 技術の活用により、事前の学習データを用意することなく廃棄物の自動認識が可能になりました。 これにより、企業はデータに基づいて仕入れ量を最適化し食品廃棄を削減できます。そして、事業コストの抑制と同時にフードロス削減という社会課題の解決への貢献にもつながります。まさに、経験や勘に頼った従来の管理手法から、IoT と AI 技術を活用したデータドリブンな管理へ変化する挑戦といえます。 本ブログでは、Summit 展示での展示内容や検出精度、コストについて詳しく紹介します。さらに、お客様から寄せられた貴重なフィードバックを基に、本ソリューションの実用化に向けた展望について考察していきます。 図1 : 当日の展示の様子 事前準備 本ソリューションでは、IoT デバイスゲートウェイとして Raspberry Pi を使用し、廃棄物の重量を測定する重量センサーと、ゴミを落としたときに廃棄物の静止写真を撮る WEB カメラを使用します。展示ソリューションには以下の機器が使われました。 Raspberry Pi： Raspberry Pi 3 Model b+ 重量センサー： Gravity – HX711搭載I2C重量センサキット 1Kg WEB カメラ： Kensington W2050 Pro 1080p HX711 重量センサーを ドキュメント に沿って組み立てた後、Raspberry Pi と I2C 接続します。また、WEB カメラは USB 経由で Raspberry Pi に接続します。Raspberry Pi には最新バージョンの Raspberry Pi OS をインストールします。さらに、このソリューションでは、Raspberry Pi 上で AWS IoT Greengrass を構成し、 AWS IoT Core へ接続します。 デモで体験できることとアーキテクチャ このデモでは、AI と IoT などの技術を活用することで、ゴミ箱に何がどれくらい廃棄されたのかを可視化できるようになります。これまで把握しづらかったフードロスの実態を、目で見て理解できる第一歩を体験していただけます。 図2 : ゴミ箱に廃棄されたものを判定し、ダッシュボードに表示される様子 このデモは、以下に示す AWS サービスとセンサー類によって構築されています。 図3 : スマートゴミ箱デモのアーキテクチャ 1. IoT デバイスによる自動検知とデータ送信 重量変化をトリガーとした自動撮影システム デバイス上では、カスタムアプリケーションが重量の変化（±10g）を常時監視しています。廃棄物がゴミ箱に投入されると、重量センサーが変化を検知し、自動的にカメラがトリガーされる仕組みです。この自動化により、従来の手動撮影では困難だった「廃棄の瞬間を逃さない記録」が可能になります。重量をトリガーにすることで、写真を撮影する手間なくクラウド上にデータを送れることが大きな利点です。 セキュアなクラウド連携 重量データは MQTT チャネルを介して AWS IoT Core に送信され、同時に撮影された廃棄物の画像は AWS IoT Greengrass Stream manager を使用して Amazon S3 バケットにアップロードされます。 AWS IoT ロールエイリアス により、AWS IoT Core 以外のサービス（S3など）にも安全にアクセスできます。この仕組みでは、IAM アクセスキーやシークレットキーをデバイスに個別に埋め込む必要がなく、デバイス証明書による統一的な認証管理が可能です。また、デバイス上で動作するコンポーネントは、AWS IoT Greengrass のクラウド経由でのデプロイ機能により、リモートでの管理・更新が可能です。デバイスのスクリプトやソフトウェアをクラウドから一元的にアップデート・管理できるため、運用コストの削減と迅速な機能改善が実現されます。 2. 生成 AI を用いてごみの種別を判定 AWS IoT Core 経由で送られてきたスマートゴミ箱の中の画像は、Amazon S3 に格納されます。 AWS Lambda は撮影された画像を取得し、 Amazon Bedrock を用いてゴミ箱の中に入っているものを判定します。 図4 : Amazon Bedrock を利用して捨てられたゴミを判定するイメージ Anthropic の Claude Sonnet 3.7 を搭載した Amazon Bedrock は、最新のものとひとつ前の撮影画像から、画像の差分を認識し、新しく捨てられたごみの名称と、ごみの種別を出力します。 従来の画像判定モデルでは、新しい種類の画像を認識するためには追加の学習データを用いた再トレーニングが必要とされていました。しかしながら、大規模言語モデル （LLM） は、膨大な量のデータを事前学習しており、そのような追加学習の必要性が大幅に軽減されています。そのため、今回のデモで用いたモデルについても追加学習をすることなく実施しました。 画像のパス、ごみの名称とセンサーデータなどのテレメトリデータは、 Amazon Timestream for LiveAnalytics に格納されます。なお、Amazon Timestream for LiveAnalytics は 2025 年5 月時点で新規受付を終了しているため、Amazon Timestream for InfluxDB や Amazon DynamoDB 等の利用をご検討ください。 3. ダッシュボード上にリアルタイムで可視化 図5 : ダッシュボード Amazon Timestream に蓄積されたレコードは、 Amazon Managed Grafana 上のダッシュボードで可視化されます。データに更新されると、最新の画像とレコードがダッシュボード上に即座に反映されます。廃棄物管理ダッシュボードでは、リアルタイムで取得された画像やレコードを表示するダッシュボードの他に、過去のレコードを集計・分析して表示する機能も実装しています。これにより、長期的なトレンド分析や、他店舗の廃棄物量との比較が容易になります。 結果 AWS Summit Japan 2025 でのスマート廃棄物管理の展示では、約 9 時間の連続稼働で 162 件、149 kg の廃棄物を処理し、認識精度 88.4% を達成しました。AI と IoT 技術の組み合わせにより、従来見えなかった食品廃棄の実態をリアルタイムで可視化することで実用化への可能性を検証できました。 試行回数と検出精度 ＊精度は検出方法や対象物により大きく異なります。本文ではモデル自体の精度ではなく、検出手法の精度についての結果と考察を目的としていることにご留意ください。 展示期間中の約 9 時間で 162 件の廃棄イベントを検知しました。このうち、手や関係のない物が写り込んだ 12 件を除いた 150 件（92.0%）を評価の対象としました。 画像認識における精度評価は以下のように行いました： 全て正しく判定できた場合：100% 部分的に正しく判定できた場合：判定できた割合 まったく判定できなかった場合：0% 150件の分析結果から、以下のことが分かりました： 1. 1つずつゴミを捨てたケース（138 件、全体の 92.0%） 全て正しく判定した割合は 86.2% でした。部分的に正しく判定したケースも含めると 89.9% となりました 「ペットボトル」「バナナ」「りんご」などの個別の食品は特に高い精度で判定できました 2. 複数のゴミを同時に捨てたケース（12件、全体の 8.0%） 部分的に正しく判定したケースも含めた精度は 70.8% で、全て正しく判定した割合は 33.3% でした 全てのゴミを正確に判定することは難しく、一部のゴミを見逃すことがありました この結果から、1 つずつゴミを捨てた場合は高い精度で判定できることが分かりました。一方で、複数のゴミを同時に捨てた場合は精度が約 19% 低下することも判明しました。 コスト 展示での費用実績を分析すると、初期コストとしてハードウェアデバイスの費用が ￥ 23,318、162 件の廃棄処理に対してクラウド利用料が $ 19.2 発生しました。それぞれの内訳は下記の表で示します。 本ソリューションを複数店舗、複数ゴミ箱に展開する際には、設置するゴミ箱の数に応じて初期費用が、処理する廃棄物の件数に応じてクラウド利用料が増加します。 展示日1日間のクラウド利用料（サービス別） サービス コスト Amazon Timestream $16.80 Amazon Bedrock $2.20 その他サービス $0.20 合計 $19.20 初期コスト 品目 金額 Raspberry Pi ¥12,980 重量センサー ¥5,358 WEB カメラ ¥4,980 合計 ¥23,318 お客様からの声 本展示では、多くの来場者から貴重なフィードバックをいただきました。業界を超えた幅広い分野からの反響があり、食品廃棄問題の重要性と本ソリューションの可能性を再確認することができました。 外食産業からの声 外食チェーン企業の方々からは、「現在は廃棄するゴミを重量計にのせて手書きで記録しており、自治体ごとに分類が異なるため管理が大変」というご意見をいただきました。特に粗利を最大化するために在庫の最適化を極力進めたいというニーズがあり、本ソリューションの価値を感じていただけました。 また、実用化に向けた具体的な改善提案として、「手が塞がっていることが多いので音声で上書きできる機能」や「自治体ごとに異なる分類表を読み込ませ、LLM が検出した廃棄物をどのゴミ箱に捨てるべきか正しくガイドする機能」へのニーズが挙げられました。 ホテル業界からは、「ビュッフェではある程度の食品廃棄は許容されるが、過剰な廃棄は問題になっている」という課題が共有されました。 他業界への応用可能性 展示では外食産業だけでなく、様々な業界からの関心が寄せられました。 工場現場では「部品などの画像分析」や「廃棄物管理の自動化」への応用可能性が指摘されました。ある製造業の来場者からは「ゴミの手動分別をした後にリサイクルや廃品回収で買い取ってもらっているが、ルールが複雑なので自動化していきたい」という具体的なニーズをお聞きしました。 建設業界でも「木材・建材の廃棄量は問題になっている」とのコメントがあり、本ソリューションの応用範囲の広さを実感しました。 コンサルティング企業の方からは、「産業用廃棄物の分類は法律でも決まっていて分類が大変。特に外国人労働者にとってはハードルが高い」という課題をお聞きしました。「正しいゴミ箱を教えてくれるのか、入れたら自動で分類してくれるのか、知識がなくても分類できるようになるのをアシストしてくれると嬉しい」という具体的なニーズが示されました。 改善提案 実用化に向けた改善提案としては、以下のような声が寄せられました。 一度に複数のゴミを捨てた時の判定精度向上：「一気にゴミを捨てた時に判定できないのは不便」 コスト削減：「デバイス代が高くつくのはコスト面から厳しい。例えば一店舗に複数のゴミ箱を置いて、一台のカメラで判別することはできないか？」 家庭用への応用：「自治体ごとのルールを読んでくれて、家のゴミ分別を自動でやってくれるようにしてほしい」「ゴミ箱に入れてほしくないもの（例えば燃えるゴミ入れに電池が入る等）が廃棄されるとアラートが飛んでほしい」 これらのフィードバックは、本ソリューションの実用化に向けた貴重な示唆となりました。特に、自治体ごとに異なる廃棄物分類ルールへの対応や、複数物体の同時判定精度の向上は、今後の開発における重要な課題として認識しています。今後は、これらのフィードバックを活かし、より実用的で幅広い業界に適用可能なソリューションへと発展させていきたいと考えています。 まとめ AWS Summit Japan 2025 で AI と IoT 技術を組み合わせたスマート廃棄物管理ソリューションを展示しました。 約9時間の連続稼働で 162 件の廃棄物を処理し、88.4% の認識精度を達成しました。特に注目すべきは、事前の学習データなしで生成 AI（Amazon Bedrock）により多様な廃棄物を自動認識できた点です。また、サーバレスアーキテクチャにより、インフラ管理が不要で処理量に応じた従量課金を実現できました。 展示では外食産業を中心に、製造業、建設業、ホテル業界など幅広い分野から関心が寄せられ、「自治体ごとの分類ルール対応」「音声修正機能」「複数ゴミ箱の一元管理」など具体的な改善提案をいただきました。多くの方に関心を持っていただけたことを嬉しく思います。 本ソリューションは従来の「経験と勘」に頼った廃棄物管理から「データドリブン」な管理への転換を可能にし、企業の収益性向上と環境負荷軽減を同時に実現する可能性を示しました。今後は複数物体同時判定の精度向上、コスト最適化、業界特化機能の開発、スケーラビリティの向上に取り組み、持続可能な社会の実現に貢献していきます。 このブログは、ソリューションアーキテクトTei、大久保、本田、古山、寺山 が執筆しました。

7 月 16 日、 Amazon SageMaker AI の Amazon Nova 向けのカスタマイズ機能 スイートを発表しました。お客様は、事前トレーニング、教師ありファインチューニング、アライメントなど、モデルトレーニングライフサイクル全体にわたって、Nova Micro、Nova Lite、Nova Pro をカスタマイズできるようになりました。これらの手法は、すぐに使用できる Amazon SageMaker レシピとして提供され、 Amazon Bedrock にシームレスにデプロイされ、オンデマンド推論とプロビジョンドスループット推論の両方をサポートします。 Amazon Nova 基盤モデル は、さまざまな業界における多様な生成 AI ユースケースをサポートします。お客様は、デプロイをスケールする中で、独自の知識、ワークフロー、ブランド要件を反映したモデルが必要になります。プロンプト最適化と 検索拡張生成 (RAG) は、汎用基盤モデルをアプリケーションに統合するのに適していますが、ビジネスクリティカルなワークフローでは、特定の精度、コスト、レイテンシー要件を満たすためにモデルのカスタマイズが必要です。 適切なカスタマイズ手法の選択 Amazon Nova モデルは、1) 教師ありファインチューニング、2) アライメント、3) 継続的な事前トレーニング、4) 知識蒸留など、幅広いカスタマイズ手法をサポートしています。最適な選択は、目標、ユースケースの複雑さ、データとコンピューティングリソースの可用性によって異なります。また、複数の手法を組み合わせることで、パフォーマンス、コスト、柔軟性の最適な組み合わせで、目的の結果を達成することもできます。 教師ありファインチューニング (SFT) は、対象のタスクとドメインに固有の入出力ペアのトレーニングデータセットを使用して、モデルパラメータをカスタマイズします。データ量とコストに関する考慮事項に基づいて、次の 2 つの実装アプローチから選択します: パラメータ効率の高いファインチューニング (PEFT) – LoRA (Low-Rank Adaptation) などの軽量アダプターレイヤーを通じて、モデルパラメータのサブセットのみを更新します。フルファインチューニングと比較して、より迅速なトレーニングと、より低いコンピューティングコストを提供します。PEFT 対応の Nova モデルは Amazon Bedrock にインポートされ、オンデマンド推論を使用して呼び出されます。 フルファインチューニング (FFT) – モデルのすべてのパラメータを更新し、大規模なトレーニングデータセット (数万件のレコード) がある場合に最適です。FFT を通じてカスタマイズされた Nova モデルも Amazon Bedrock にインポートし、プロビジョンドスループットを使用した推論のために呼び出すことができます。 アライメント は、企業ブランドやカスタマーエクスペリエンスの要件など、製品固有のニーズや振る舞いに関する望ましい選好にモデル出力を導きます。これらの選好は、実証例やポリシーなど、複数の方法でエンコードできます。Nova モデルは、2 つの選好アライメント手法をサポートしています: 直接選好最適化 (DPO) – 好ましい/好ましくない応答ペアを使用して、モデル出力をチューニングする簡単な方法を提供します。DPO は、比較ベースの選好から学習し、トーンやスタイルなどの主観的な要件に合わせて出力を最適化します。DPO は、パラメータ効率の高いバージョンとフルモデル更新バージョンの両方を提供します。パラメータ効率の高いバージョンは、オンデマンド推論をサポートします。 近似ポリシー最適化 (PPO) – 強化学習を用いて、有用性、安全性、エンゲージメントなどの望ましい報酬を最適化することで、モデルの振る舞いを強化します。報酬モデルは出力にスコアを付けることで最適化をガイドし、モデルが以前に学習した能力を維持しながら効果的な振る舞いを学習するのをサポートします。 継続的事前トレーニング (CPT) は、社内文書、トランスクリプト、ビジネス固有のコンテンツなど、大量のラベルなし所有データを用いた自己教師あり学習を通じて、基本的なモデルの知識を拡張します。CPT に続いて、SFT と、DPO または PPO を通じたアライメントを実施することで、アプリケーションに合わせて Nova モデルを包括的にカスタマイズできます。 知識蒸留 は、大規模な「教師」モデルから、小規模でより高速かつコスト効率の高い「生徒」モデルへと知識を伝えます。蒸留は、お客様が十分な参照入出力サンプルを有しておらず、より強力なモデルを活用してトレーニングデータを拡張できるシナリオで役立ちます。このプロセスにより、特定のユースケース向けの教師レベルの精度と、生徒レベルの費用対効果と速度を備えた、カスタマイズされたモデルが作成されます。 さまざまなモダリティとデプロイオプションで使用できるカスタマイズ手法をまとめた表を次に示します。各手法は、実装要件に応じて、特定のトレーニングおよび推論機能を提供します。 レシピ モダリティ トレーニング 推論 Amazon Bedrock Amazon SageMaker Amazon Bedrock オンデマンド Amazon Bedrock プロビジョンドスループット 教師ありファインチューニング テキスト、画像、動画 パラメータ効率の高いファインチューニング (PEFT) フルファインチューニング 直接選好最適化 (DPO) テキスト、画像、動画 パラメータ効率の高い DPO フルモデル DPO 近似ポリシー最適化 (PPO) テキストのみ 継続的な事前トレーニング  テキストのみ 蒸留 テキストのみ Cosine AI、Massachusetts Institute of Technology (MIT) Computer Science and Artificial Intelligence Laboratory (CSAIL)、Volkswagen、Amazon Customer Service、Amazon Catalog Systems Service などのアーリーアクセスのお客様は、既に Amazon Nova のカスタマイズ機能を成功裏に使用しています。 Nova モデルのカスタマイズの実際の仕組み 以下では、既存の選好データセットに対して直接選好最適化を用いて Nova Micro モデルをカスタマイズする例について説明します。これを実行するために、 Amazon SageMaker Studio を使用できます。 Amazon SageMaker AI コンソール で SageMaker Studio を起動し、 [JumpStart] を選択します。これは、基盤モデル、組み込みアルゴリズム、事前構築済みの ML ソリューションを備えた機械学習 (ML) ハブであり、数回クリックするだけでデプロイできます。 その後、 [Nova Micro] を選択し、 [トレーニング] を選択します。Nova Micro は、Nova モデルファミリーの中で最も低い推論あたりのコストで最も低レイテンシーで応答を提供するテキストのみのモデルです。 次に、 [ファインチューニング] レシピを選択して、ラベル付きデータでモデルをトレーニングし、特定のタスクのパフォーマンスを強化して、望ましい振る舞いになるよう調整できます。 [直接選好最適化] を選択すると、好みに合わせてモデル出力を簡単にチューニングできます。 [サンプルノートブックを開く] を選択すると、レシピを実行する環境オプションが 2 つあります。すなわち、SageMaker トレーニングジョブまたは SageMaker Hyperpod のいずれかです: クラスターを作成し、JupyterLab スペースを選択してサンプルノートブックでモデルをトレーニングする必要がない場合は、 [SageMaker トレーニングジョブ でレシピを実行] を選択します。 あるいは、反復的なトレーニングプロセスのために最適化された永続的なクラスター環境が必要な場合は、 [SageMaker HyperPod でレシピを実行] を選択します。このような Nova モデルのトレーニングに必要な、特殊な分離された環境を提供するために、少なくとも 1 つの制限付きインスタンスグループ (RIG) を持つ HyperPod EKS クラスターを選択できます。その後、JupyterLabSpace を選択し、 [サンプルノートブックを開く] を選択します。 このノートブックは、SageMaker Nova モデルとレシピを使用して SageMaker HyperPod ジョブを作成し、推論のためにデプロイするためのエンドツーエンドのチュートリアルを提供します。SageMaker HyperPod レシピを使用することで、最適化されたトレーニングジョブのために、複雑な設定を合理化し、データセットをシームレスに統合できます。 SageMaker Studio では、SageMaker HyperPod ジョブが正常に作成されたことを確認し、その後の進捗状況をモニタリングできます。 ジョブが完了したら、ベンチマークレシピを使用して、カスタマイズされたモデルがエージェントタスクでより優れたパフォーマンスを発揮するかどうかを評価できます。 包括的なドキュメントと追加の実装例については、 GitHub で SageMaker HyperPod レシピリポジトリにアクセスしてください。 当社は、お客様からのフィードバックと新たな ML トレンドに基づいてレシピを引き続き拡張し、AI モデルのカスタマイズを成功させるために必要なツールをお客様に提供していきます。 利用可能なリージョンと開始方法 Amazon SageMaker AI での Amazon Nova のレシピは、米国東部 (バージニア北部) でご利用いただけます。この機能の詳細については、 Amazon Nova のカスタマイズのウェブページ と「 Amazon Nova ユーザーガイド 」にアクセスしてください。使用を開始するには、 Amazon SageMaker AI コンソール をご利用ください。 – Betty 原文は こちら です。

この記事は「 Introducing AWS Serverless MCP Server: AI-powered development for modern applications 」をソリューションアーキテクトの松本が翻訳したものです。 最新のアプリケーション開発では、ソフトウェアの構築とデプロイをより迅速かつ効率的に行う方法が求められています。過去 10 年間で、サーバーレスコンピューティングはソフトウェア開発における変革的なアプローチとして台頭し、開発者が基盤となるインフラストラクチャを管理することなくアプリケーションの構築に集中できるようになりました。開発者が AWS でのサーバーレス  を使用してアプリケーションを構築する際、適切なサービスの選択、ベストプラクティスの理解、実装パターンについてのガイダンスを求め、このパラダイムを最大限に活用しようとします。 本日、AWS はオープンソースの AWS Serverless Model Context Protocol (MCP) Server を発表しました。これは AI 支援とサーバーレス専門知識を組み合わせ、開発者が最新のアプリケーションを構築する方法を強化するツールです。Serverless MCP Server は、サーバーレス開発に特化したコンテキストガイダンスを提供し、開発者がアーキテクチャ、実装、デプロイに関する情報に基づいた決定を行えるよう支援します。 この記事では、 Serverless MCP Server が AI コーディングアシスタントと連携してサーバーレス開発を効率化する方法について説明します。このソリューションを使用してサーバーレス開発ワークフローを加速し、堅牢で高性能なアプリケーションをより効率的に構築する方法を学びましょう。 概要   サーバーレスコンピューティングにより、開発チームは運用効率を向上させながら市場投入までの時間を大幅に短縮できます。開発者はビジネス価値の創出に集中でき、AWS サービスが自動的にスケーリング、可用性、インフラストラクチャのメンテナンスを処理します。 AWS Lambda は、イベントに応じてコードを実行するシームレスなコンピュートサービスを提供し、1 日数リクエストから 1 秒あたり数千リクエストまで瞬時にスケールします。200 以上の AWS サービスとの統合により、Lambda は開発者が Amazon API Gateway 、 Amazon S3 、 Amazon DynamoDB などからのトリガーを使用して高度なアプリケーションを構築できるようにします。データ処理パイプライン、リアルタイムストリーム処理、Web アプリケーションのいずれを構築する場合でも、Lambda は一般的なプログラミング言語と開発フレームワークをサポートし、開発チームがサーバーレスパラダイムを採用しながら既存のスキルを活用できるよう支援します。 MCP Server MCP は、AI エージェントが外部ツールやデータソースと対話するためのオープンプロトコルです。AI アシスタントが外部システムによって提供される様々な機能を発見、理解、使用する方法を定義します。このプロトコルにより、AI モデルは標準化されたインターフェースを通じてリアルタイム情報にアクセスし、特定のタスクを実行することで、自身のトレーニングデータを超えた機能を拡張できます。 MCP サーバーは、 Amazon Q Developer 、 Cline 、 Cursor などの AI アシスタントが MCP クライアントを介して使用できるツール、リソース、コンテキスト情報を提供することで、このプロトコルを実装します。これらは知識の架け橋として機能し、AI アシスタントにクラウドアーキテクチャと実装に関する情報に基づいた決定を行うために必要な追加コンテキストを提供します。これは特に、開発者が複数のサービス、イベントパターン、統合ポイントを操作してスケーラブルで高性能なアプリケーションを構築するサーバーレスアプリケーションにとって価値があります。 AWS は現在、 AWS Lambda Tool MCP Server を提供しており、これにより AI モデルはコード変更なしに既存の Lambda 関数と MCP ツールとして直接対話できます。この MCP サーバーは MCP クライアントと Lambda 関数の間の橋渡しとして機能し、AI アシスタントが Lambda 関数にアクセスして呼び出すことを可能にします。 Serverless MCP Server 本日発表されたオープンソースの AWS Serverless MCP は、サーバーレスパターン、ベストプラクティス、AWS サービスに関する包括的な知識を AI コーディングアシスタントに提供することで、サーバーレス開発体験を強化します。この MCP サーバーはインテリジェントなコンパニオンとして機能し、初期設計からデプロイまでのアプリケーション開発ライフサイクル全体を通じて開発者をガイドし、各段階でコンテキストに応じた支援を提供します。 新しい Serverless MCP サーバーは、サーバーレス開発の多くの領域をカバーするツールを提供します。初期計画とセットアップフェーズでは、MCP サーバーは開発者が AWS Serverless Application Model (AWS SAM) テンプレートを使用して新しいプロジェクトを初期化し、適切な Lambda ランタイムを選択し、プロジェクトの依存関係をセットアップするのを支援します。これにより、開発者は適切な構成と構造を持つ新しいサーバーレスアプリケーションを迅速に立ち上げることができます。 開発が進むにつれて、MCP サーバーはサーバーレスアプリケーションの構築とデプロイを支援します。ローカルテスト、デプロイアーティファクトの構築、デプロイの管理のためのツールを提供します。Web アプリケーションについては、MCP サーバーはバックエンド、フロントエンド、またはフルスタックアプリケーションのデプロイとカスタムドメインのセットアップに特化したサポートを提供します。 MCP サーバーはまた、包括的な可観測性ツールを通じて運用の優秀性を強調し、開発者がアプリケーションのパフォーマンスを効果的に監視し、問題をトラブルシューティングするのを支援します。開発プロセス全体を通じて、サーバーは Infrastracture as a Code (IaC) の決定、Lambda 固有のベストプラクティス、 Lambda Event Source Mappings (ESM) のイベントスキーマに関するコンテキストガイダンスを提供します。 Serverless MCP Server の実際の動作 Serverless MCP Server の機能を実証するために、サーバーレスアプリケーションの作成、デプロイ、トラブルシューティングのシナリオを通じて説明します。 前提条件とインストール 開始するには、 GitHub または Python Package Index (PyPi) から AWS Serverless MCP Server をダウンロードし、インストール手順に従います。この MCP サーバーは、Q Developer、Cursor、Cline などの任意の AI コーディングアシスタントで使用できます。この記事のウォークスルー例では Cline を使用しています。 MCP クライアント構成に次のコードを追加します。Serverless MCP Server はデフォルトで  default AWS プロファイルを使用します。別のプロファイルを使用する場合は AWS_PROFILE に値を指定します。同様に、 AWS リージョン とログレベルの値も必要に応じて調整してください。 { "mcpServers": { "awslabs.aws-serverless-mcp": { "command": "uvx", "args": [ "awslabs.aws-serverless-mcp-server@latest" ], "env": { "AWS_PROFILE": " your-aws-profile ", "AWS_REGION": "us-east-1", "FASTMCP_LOG_LEVEL": "ERROR" } } } } Code Serverless MCP Server には、安全で制御された開発を確保するための組み込みガードレールが含まれています。デフォルトでは、MCP サーバーは読み取り専用モードで動作し、変更を加えないアクションのみを許可します。この安全第一のアプローチにより、アプリケーションやインフラストラクチャに意図しない変更を防ぎながら、サーバーレス機能とアーキテクチャパターンを探索できます。また、サーバーはデフォルトで Amazon CloudWatch Logs へのアクセスを制限し、機密性の高い運用データが AI アシスタントに公開されないよう保護します。 開発ニーズが進化するにつれて、これらのセキュリティデフォルトを選択的に上書きできます。 --allow-write フラグはデプロイや更新などのタスクのための変更操作を有効にし、 --allow-sensitive-data-access はデバッグとトラブルシューティングのために CloudWatch Logs へのアクセスを提供します。これらの権限は必要な場合にのみ、適切な開発コンテキストで有効にすることを検討してください。 サーバーレスアプリケーションの作成とデプロイ To-Do リスト Web アプリケーションを構築したいとします。AI アシスタントに次のようにプロンプトを出します。 新しいワークスペースで To-Do リスト Web アプリケーションを構築したいと思います。To-Do の追加、一覧表示、削除を行いたいです。AWS Lambda はこれに適した選択肢でしょうか？ エージェントは get_lambda_guidance_tool を使用して、ユースケースと推測されるイベントソース（この場合は API Gateway）に基づいたカスタマイズされたガイダンスを受け取ります。次に、アプリケーションを AWS にデプロイする方法についてより詳しく理解したいと思います。 後でアプリケーションを AWS にデプロイしたいと思います。どのインフラストラクチャ・アズ・コードツールが最適でしょうか？ AWS SAM や AWS Cloud Development Kit (AWS CDK) など、関数を AWS にデプロイするいくつかの方法があります。モデルは推奨を行う前に詳細情報を取得することを選択します。Serverless MCP Server から get_iac_guidance_tool を選択します。 Serverless MCP Server は、 AWS Serverless Application Model Command Line Interface (AWS SAM CLI) との対話や、バックエンド、フロントエンド、またはフルスタックアプリケーションなどのアプリケーションベースのブループリントのデプロイにも役立ちます。 デプロイの前に、関数が正しく動作することを確認するためにローカルでテストします。 デプロイする前に Lambda 関数をローカルでテストしたいと思います。SAM プロジェクトから「TodoFunction」を GET リクエストで呼び出すことはできますか？ アプリケーションが動作することを確認したので、バックエンドロジックを AWS にデプロイしたいと思います。そこで、エージェントにアプリを展開するよう促します。エージェントは deploy_webapp ツールを選択し、バックエンド deploymentType を含むアプリをデプロイするための引数をツールに提供します。このツールは AWS Lambda Web Adapter フレームワークを使用しており、追加の Web アダプターなしで Express や Next.js などの標準的な Web フレームワークで書かれたアプリケーションを簡単にデプロイできます。 エージェントはデプロイのステータスを確認して、正常に完了することを確認することもできます。 これでアプリケーションは AWS にデプロイされ、トラフィックを処理する準備ができました。 サーバーレスアプリケーションのトラブルシューティング Serverless MCP Server は、Lambda 関数のテストとトラブルシューティングもサポートしています。問題の特定と修正において AI アシスタントに貴重なコンテキストを提供します。例えば、エージェントを使用してアプリケーションに問題がないか確認できます。 To-Do アプリのログとメトリクスを確認して、問題がないか調べてください モデルはログとメトリクスを分析し、メモリ割り当ての調整などの推奨事項を提供できます。 Serverless MCP Server ツールは、アシスタントが問題を特定し推奨事項を生成するために必要な追加コンテキストを提供します。 この例での分析と推奨事項は次のとおりです： ログ分析 To-Do アプリの 3 つの Lambda 関数すべてのログをチェックし、特にエラーを探しました： • ListTodosFunction ：エラーは検出されませんでした • AddTodoFunction ：エラーは検出されませんでした • DeleteTodoFunction ：エラーは検出されませんでした すべての関数は正常に動作しており、成功した実行があり、エラーログはありません。 パフォーマンスメトリクス Lambda 関数のパフォーマンス • メモリ使用量は割り当てられた 512 MB のうち 100～106 MB（約 20% の使用率）で妥当です • ウォームスタートの実行時間は速く、85～195 ms の範囲です • スロットリングやメモリ不足のエラーは検出されませんでした • ログに関数エラーや例外はありません API Gateway メトリクス • 総リクエスト数：11 件のリクエストが記録されました • 平均レイテンシー：797 ms • P95 レイテンシー：3364 ms（高い） • 4XX エラー：0（クライアントエラーなし） • 5XX エラー：1（サーバーエラーが 1 件検出されました） 特定された問題 ログ分析ではエラーは見つかりませんでしたが、メトリクスは 1 つの潜在的な問題を示しています： API Gateway での 1 件の 5XX エラー ：API Gateway ログに 1 件のサーバーサイドエラーが記録されています。Lambda 関数のログに対応するエラーがないため、これは以下に関連している可能性があります： • タイムアウト（API Gateway の応答に時間がかかりすぎている） • API Gateway と Lambda 間の統合の問題 • 一時的なネットワークの問題 比較的高い P95 レイテンシー ：95 パーセンタイルのレイテンシーが 3364 ms と平均と比較してかなり高いです。これは一部のリクエストの完了に大幅に時間がかかっていることを示唆しています。 推奨事項 5XX エラー率が再発するかどうかを監視します。 エラーパスのエッジにより詳細なログ記録を実装することを検討します。 高い P95 レイテンシーの原因を調査します。コールドスタート、ペイロードサイズ、またはネットワークレイテンシーが原因として考えられます。 より詳細な履歴的なレイテンシーとエラーメトリクスのために API Gateway と Lambda のパフォーマンスダッシュボードを有効にすることを検討します。 トラフィックが増加しても性能が健全であることを確認するために、メモリと実行時間のメトリクスの監視を継続します。 Serverless MCP Server がサポートする機能 Serverless MCP Server はいくつかの MCP ツールを提供しており、これらは 4 つのカテゴリに分類できます。 サーバーレスアプリケーションのライフサイクル sam_init_tool ：選択したランタイムと依存関係を持つ新しい AWS SAM プロジェクトを初期化します。 sam_build_tool ：AWS SAM CLI を使用してサーバーレスアプリケーションをビルドし、デプロイアーティファクトを準備します。 sam_deploy_tool ：サーバーレスアプリケーションを AWS にデプロイし、アーティファクトのアップロードとスタックの作成を管理します。 sam_local_invoke_tool ：カスタムイベントと環境でテストするために Lambda 関数をローカルで呼び出します。 Web アプリケーションのデプロイと管理 deploy_webapp_tool ：Lambda Web Adapter を使用して、バックエンド、フロントエンド、またはフルスタック Web アプリケーションを Lambda にデプロイします。 update_frontend_tool ：フロントエンドアセットを更新し、オプションで Amazon CloudFront キャッシュを無効化します。 configure_domain_tool ：証明書と DNS セットアップを含むカスタムドメインを構成します。 可観測性 sam_logs_tool ：ログを取得し、フィルタリングと時間範囲の選択をサポートします。 get_metrics_tool ：指定されたメトリクスを取得します。 ガイダンス、IaC テンプレート、デプロイヘルプ get_iac_guidance_tool ：IaC ツールの選択に関するガイダンスを提供します。 get_lambda_guidance_tool ：特定のランタイムとユースケースに Lambda を使用する場合のアドバイスを提供します。 get_lambda_event_schemas_tool ：Lambda 統合のイベントスキーマを返します。 get_serverless_templates_tool ：さまざまなサーバーレスアプリケーションタイプの AWS SAM テンプレート例を提供します。 deployment_help_tool ：デプロイに関するヘルプとステータス情報を提供します。 deploy_serverless_app_help_tool ：Lambda へのサーバーレスアプリケーションのデプロイに関する指示を提供します。 ツールとリソースの完全なリストについては、Serverless MCP Server の ドキュメント をご覧ください。 ベストプラクティスと考慮事項 AWS Serverless MCP Server でサーバーレスアプリケーションを構築する際は、まず AI 支援のガイダンスを使用してアーキテクチャの決定を行うことから始めましょう。開発全体を通じて、サービスの選択、イベントパターン、インフラストラクチャ設計に関する情報に基づいた決定を行うためにガイダンスツールを使用します。AWS にデプロイする前に、Serverless MCP Server のローカルテスト機能を使用してアプリケーションの動作を検証します。このアプローチは、アプリケーションが AWS のベストプラクティスに沿っていることを確認するのに役立ちます。 本番環境で実行されているアプリケーションを確実に運用するには、堅牢な監視と可観測性が不可欠です。デプロイの監視とログ記録およびメトリクスのセットアップには、Serverless MCP Server ツールを使用します。これにより、アプリケーションのパフォーマンスを追跡し、潜在的な問題を迅速に特定するのに役立ちます。 結論 オープンソースの AWS Serverless MCP Server は、開発ライフサイクル全体を通じて AI 支援のガイダンスを提供することで、サーバーレスアプリケーション開発を効率化します。AI 支援とサーバーレス専門知識を組み合わせることで、開発者はより効率的にアプリケーションを構築およびデプロイできるようになります。Serverless MCP Server のツールセットは、初期化から可観測性まで、完全な開発プロセスをサポートし、開発者が AWS のベストプラクティスを実装するのを支援します。 組織がサーバーレスコンピューティングを採用し続けるにつれて、開発を効率化し、提供を加速するツールはますます価値が高まります。AWS は、サーバーレスアプリケーションを構築する開発者向けの MCP サーバーのコレクションを拡大し、顧客のフィードバックと新たなサーバーレス開発パターンに基づいて既存のツールを改良し続けます。 開始するには、 GitHub リポジトリ にアクセスし、 ドキュメント を探索してください。GitHub リポジトリを通じて経験や提案を共有し、MCP サーバーの機能を改善し、AI 支援のサーバーレス開発の未来を形作るのに役立ててください。 サーバーレス学習リソースの詳細については、 Serverless Land をご覧ください。

この記事は「 Enhance productivity with Amazon Bedrock Agents and Powertools for AWS Lambda 」をソリューションアーキテクトの松本が翻訳したものです。 公共部門は、生産性とサービス提供を向上させるための革新的なソリューションを必要とする独自の課題に直面しています。大規模言語モデル (LLM) はさまざまなアプリケーションで大きな可能性を示していますが、その真価は、最新データ、時間、天気、速報イベントなどのリアルタイム情報にアクセスできるときに発揮されます。この能力は、効果的な公共部門の計画と意思決定に不可欠です。しかし、LLM だけでは、特に動的でタイムセンシティブな業務を管理する公共機関にとって、タイムリーで関連性の高いインサイトを提供するには不十分かもしれません。 学習内容 この記事では、以下について説明します。 公共部門機関が直面する主な課題と、リアルタイムデータアクセスが重要である理由 Amazon Bedrock Agents と Powertools for AWS Lambda がこれらの課題にどのように対応するか 公共部門における実用的なアプリケーションを示す実際のユースケース 技術的な実装の詳細とベストプラクティス 主な課題とリアルタイムデータの必要性 公共部門の業務に LLM を実装する際、公共機関は人工知能 (AI) を効果的に活用する能力を制限するいくつかの重要な課題に直面します。リアルタイムデータへのアクセスが限られていると、LLM が最新かつ実用的なインサイトを提供できなくなり、既存システムとの統合の難しさや厳格なコンプライアンス要件がさらに実装を複雑にします。 リアルタイムデータアクセスは、タイムリーな情報が重要な状況での違いを生む優先対応において特に重要です。また、決定が最新の情報に基づいていることを確保するポリシーコンプライアンスや、公共機関がリソースを最も必要とされる場所に効率的に振り向けるのに役立つリソース配分にも同様に重要です。 Amazon Bedrock Agents と Powertools for AWS Lambda の紹介 これらの課題に対処するために、シームレスに連携する 2 つの強力なツールを活用できます。 Amazon Bedrock Agents は、組み込みのビジネスロジックを持つ AWS Lambda 関数を呼び出すための機能呼び出しを利用します。これにより、外部 API へのアクセスとさまざまなデータソースとの統合が可能になり、API を介した公共機関間のコミュニケーションとデータ共有が促進されます。 サーバーレスのベストプラクティスを実装する開発者ツールキットである Powertools for AWS Lambda (Python) と組み合わせることで、公共機関は高いセキュリティとコンプライアンス基準を維持しながら、開発速度を大幅に向上させることができます。 公共部門における実際のアプリケーション Amazon Bedrock Agents と Powertools for AWS Lambda が、実用的な例を通じて公共機関の業務をどのように改善するかを見てみましょう。 天気予報プロンプト ユースケースの説明 : 州の農業部門は、効果的な害虫駆除と環境への影響を最小限に抑えるために、天気予報に基づいて農薬散布スケジュールを計画する必要があります。 ユーザー : シアトル (ワシントン州) の今後 72 時間の予想降水量はどれくらいですか？ エージェント : シアトル (ワシントン州) の今後 72 時間の予想降水量は 0.5 インチです。 コンプライアンス文書取得プロンプト ユースケースの説明: 公共機関の IT 部門は、公共機関が使用するクラウドサービスが連邦セキュリティ基準を満たしていることを確認するために、最新の FedRAMP コンプライアンス文書を必要としています。 ユーザー: AWS に最近の FedRAMP コンプライアンス文書はありますか？ エージェント: AWS からの最近の FedRAMP コンプライアンス文書をいくつか紹介します… 労働力計画プロンプト ユースケースの説明: 州の雇用機関は、求職者の就職を支援し、地域の熟練労働力を確保するために、IT スペシャリスト向けの最新の求人情報を提供する必要があります。 ユーザー: ワシントン DC から 100 マイル以内の「IT スペシャリスト」の求人を一覧表示してください。 エージェント: ワシントン DC から 100 マイル以内の「IT スペシャリスト」の求人をいくつか紹介します… 主要なアプリケーション分野 データと分析業務 公共機関はリアルタイムデータ分析を活用して、実績に基づく政策決定とリソース配分の最適化を推進できます。この基盤により、より応答性が高く効率的な行政サービスが可能になり、運用コストも削減されます。 以下を通じて政策決定とリソース配分を強化します。 将来の計画のためのリアルタイムの国勢調査と人口統計分析 政策評価のための経済指標モニタリング 自動化された財務報告とデータ取得 既存のデータ管理システムとの統合 運用とコンプライアンス管理 統合されたモニタリングとレポート機能を備えた複雑な運用ワークフローの合理化により、規制コンプライアンスを維持しながら効率性を高め、運用リスクを軽減します。 以下の自動化を通じて運用効率を向上させます。 リアルタイムの航空状況更新とモニタリング AWS Artifact を介した AWS コンプライアンス文書管理 日付/時間の計算と検証プロセス 規制コンプライアンスの追跡とレポート 環境とインフラストラクチャ管理 包括的なモニタリングとデータ駆動型のインサイトを通じて、環境とインフラストラクチャの管理を改善します。このアプローチにより、公共機関は変化を予測し、迅速に対応し、重要なインフラストラクチャをより効果的に維持できるようになります。 以下を含む重要な環境データをモニタリングおよび分析します。 地震活動と地震追跡 正確な位置情報サービスとマッピング 天気予報と悪天候警報 インフラストラクチャの状態とメンテナンススケジューリング 労働力と公衆衛生 リアルタイムデータ分析とトレンドモニタリングを通じて、公衆衛生と労働力の決定を向上させます。このデータ駆動型アプローチにより、正確なヘルスケア計画と戦略的リソース展開が可能になります。 以下によりリソース管理を最適化します。 リアルタイムの労働力可用性追跡 求人市場トレンド分析 公衆衛生データモニタリング 人口健康指標 ソリューションアーキテクチャ コンポーネント Amazon Bedrock LLM : 応答生成に使用される大規模言語モデル。 Amazon Bedrock Agent : ユーザーがソリューションと対話するためのオーケストレーションとタスク分析のインターフェース。 AWS Lambda と Powertools for AWS Lambda (Python) : データ取得と処理のロジックを含む Lambda 関数。 Amazon Bedrock Agent アクショングループ : エージェントが実行するアクションを管理します。 エージェントビジネスロジック : エージェントがユーザークエリを処理するために従う特定のロジックとルール。 Amazon Bedrock Knowledge Base : ポリシー文書、コンプライアンス文書、ビジネス文書を含むリポジトリ。 OpenAPI スキーマ : エージェントが呼び出せる API 操作を定義します。 公共機関 API エンドポイント : 公共機関固有のデータとサービスへのアクセスを提供します。 Amazon Bedrock Guardrails: セキュリティとコンプライアンスポリシーを適用するメカニズム。 基本的な相互作用   ユーザープロンプト: AWS Lambda クライアントが Amazon Bedrock Agent にプロンプトを送信します。   エージェント処理: エージェントは高度な推論を使用してタスクを論理的な順序に分解します。リクエストを満たすために必要な API と対話し、進行するか追加情報を収集するかを決定します。   ガードレール評価: 入力プロンプトが設定されたガードレールに対してコンプライアンスをチェックされます。入力が評価に失敗した場合、ブロックメッセージが返され、プロセスは終了します。   データ取得と実行: 入力がガードレール評価に合格した場合、エージェントは関連する Lambda 関数を呼び出し、タスクを完了するために必要に応じて Knowledge Base にクエリを実行します。   応答生成: タスクの完了後、エージェントは応答を作成します。この応答はコンプライアンスのためにガードレールに対してチェックされます。応答が評価に失敗した場合、ブロックメッセージで上書きされるか、機密情報がマスクされます。   ユーザー応答: コンプライアンスに準拠した応答が AWS Lambda クライアントに返されます。 図 1. この記事で説明するソリューションのアーキテクチャ図。主要なコンポーネントは Amazon Bedrock、AWS Lambda、および Powertools for AWS Lambda です。 このアーキテクチャをさらに詳しく調べるために、これらのコンポーネントが実用的な実装でどのように連携するかを示す Lambda 関数の例を見てみましょう。 技術的な実装 以下は、Powertools for AWS Lambda を使用して天気データを取得する Lambda 関数の実装例です。 # Powertools for AWS のロギングとトレースを初期化 logger = Logger ( ) tracer = Tracer ( service = "WeatherForecastAgent" ) # BedrockAgentResolver は Lambda と Bedrock Agent の統合を処理 app = BedrockAgentResolver ( ) # Bedrock Agent の天気予報呼び出し用のエンドポイントを定義 @app . get ( "/forecast" , description = "Retrieve current weather forecast at a station." ) @tracer . capture_method def get_weather ( station_id : str = Query ( . . . , description = "The id of the weather observation station." ) ) - > dict : # API 呼び出しをログに記録 logger . info ( f"Retrieving weather data for station: { station_id } " ) # 気象観測所の最新の観測データを取得 base_url = "https://<your-api-endpoint>" url = f" { base_url } / { station_id } /observations/latest" response = requests . get ( url , timeout = 30 ) response . raise_for_status ( ) # API レスポンスを解析 data = response . json ( ) # 天気情報を抽出 temperature = data [ 'properties' ] [ 'temperature' ] [ 'value' ] description = data [ 'properties' ] [ 'textDescription' ] # 取得したデータをログに記録 logger . info ( f"Weather for station { station_id } : Temp: { temperature } , Desc: { description } " ) # X-Ray アノテーションをトレースフィルタリング用に追加 tracer . put_annotation ( key = "station_id" , value = f" { station_id } " ) return { "statusCode" : 200 , "body" : data } # ロギングとトレースを使用したメイン Lambda ハンドラー @logger . inject_lambda_context ( log_event = True ) @tracer . capture_lambda_handler def lambda_handler ( event : dict , context : LambdaContext ) - > dict : return app . resolve ( event , context ) if __name__ == "__main__" : # Bedrock Agent 設定用の OpenAPI スキーマを出力 print ( app . get_openapi_json_schema ( ) ) Python この例では: Powertools for AWS Lambda の Logger と Tracer により、関数の実行の包括的な可観測性がロギングとトレースを通じて可能になります。 BedrockAgentResolver は Amazon Bedrock Agent と Lambda 関数間のルーティングを処理し、合理化された API 統合を提供します。 構造化ロギングと AWS X-Ray アノテーションが実装され、API 呼び出しを追跡し、詳細なトレース分析を可能にします。 Powertools は OpenAPI スキーマを生成する機能を提供し、開発者は Bedrock Agent のセットアップ中に API インターフェースを定義するために使用できます。 次の図は、Amazon Bedrock Agent とのサンプル対話を示しており、エージェントがユーザープロンプトを処理し、リアルタイムデータを取得する方法を示しています。エージェントが外部 API と統合し、タイムリーな応答を生成する能力は、公共部門の生産性とサービス提供を向上させる上で重要です。 図 2. Amazon Bedrock Agent の呼び出し例。 包括的な可観測性を確保するため、サンプル Lambda 関数は Amazon CloudWatch をロギングに使用しています。CloudWatch は関数の実行に関する詳細なログイベントを取得し、開発者が問題を診断しパフォーマンスを監視するのに役立ちます。 図 3. Amazon CloudWatch ログイベントの例。 可観測性をさらに強化するために、Lambda 関数は分散トレース用に AWS X-Ray と統合されています。X-Ray は関数の実行の視覚的なマップを提供し、開発者がシステム全体でリクエストの流れを追跡し、ボトルネックを特定し、パフォーマンスを最適化することを可能にします。 図 4. AWS X-Ray トレースマップの例。 この例は、Amazon Bedrock Agents と統合された Powertools for AWS Lambda のいくつかの付加価値機能を強調しています。組み込みの可観測性、自動スキーマ生成、標準化されたエラー処理の組み合わせにより、開発サイクルが加速し、本番環境レベルの信頼性が維持されます。これらの機能により、開発チームは AI 対応アプリケーションを自信を持って迅速にプロトタイプ作成し、デプロイすることができます。 結論 Amazon Bedrock Agents と Powertools for AWS Lambda を活用することで、公共機関は生成 AI と LLM の可能性を最大限に引き出し、イノベーションを推進し、市民へのサービス提供を改善することができます。これらのツールは、リアルタイムデータへのアクセスを可能にすることで LLM の機能を強化し、開発者の速度を大幅に向上させます。これにより、公共機関はインフラストラクチャの複雑さに対処するのではなく、市民に価値を提供することに集中できます。結果として、より機敏で応答性が高く、効果的な公共部門が実現し、構成員のニーズをより良く満たすことができます。 次のステップ このブログの技術的なソリューションを確認するには、この投稿の GitHub リポジトリ をご覧ください。さらなる読み物とリソースについては、以下のリンクをご覧ください。 リソース Powertools for AWS Lambda (Python) Amazon Bedrock Agents Amazon Bedrock のマルチエージェントコラボレーション機能の紹介 (プレビュー)

7 月 15 日より、 Amazon EventBridge の拡張ログ記録機能を使用して、包括的なログでイベントドリブンのアプリケーションをモニタリングおよびデバッグできます。これらの新しい機能強化は、イベントフローのモニタリングとトラブルシューティングの方法を改善するのに役立ちます。 Amazon EventBridge コンソール でこの新しい機能を見つける方法は次のとおりです: 新しいオブザーバビリティ機能は、包括的なイベントライフサイクル追跡を提供することで、マイクロサービスとイベントドリブンのアーキテクチャのモニタリングの課題に対処します。EventBridge は、ルールに一致したイベントが発行されたり、サブスクライバーに配信されたり、失敗して再試行されたりするたびに、詳細なログエントリを生成するようになりました。 成功、失敗、ステータスコードに関する詳細情報により、イベントの進行状況全体を可視化できるため、問題の特定と診断が容易になります。以前は何時間もかかっていた試行錯誤によるデバッグが、詳細なイベントライフサイクル追跡と組み込みのクエリツールにより、数分で完了するようになりました。 Amazon EventBridge の拡張オブザーバビリティの使用 Amazon EventBridge のログ記録機能をご紹介するデモをご覧ください。 既存のイベントバス、または新しいカスタムイベントバスを作成する際に、ログ記録を有効にすることができます。まず、EventBridge コンソールに移動し、左側のナビゲーションペインで [イベントバス] を選択します。 [カスタムイベントバス] で、 [イベントバスを作成] を選択します。 この新しい機能は、 [ログ] セクションに表示されます。 [ログの保存先] を設定するには、 Amazon CloudWatch Logs 、 Amazon Data Firehose ストリーム、 Amazon Simple Storage Service (Amazon S3) の 3 つのオプションがあります。ログをデータレイクにストリーミングする場合は、Amazon Kinesis Data Firehose ストリームを選択します。 イベントバスにカスタマーマネージドキー (CMK) が指定されている 場合、ログは転送中に TLS で、および保管中に暗号化されます。CloudWatch Logs はカスタマーマネージドキーをサポートし、Data Firehose はダウンストリームの宛先のためにサーバー側の暗号化を提供します。 このデモでは、 [CloudWatch ログ] と [S3 ログ] を選択します。 また、 [ログレベル] を [エラー]、[情報]、[トレース] から選択することもできます。ペイロードを確認する必要があるため、 [トレース] を選択し、 [実行データを含める] を選択します。ペイロードデータのログ記録には機密情報が含まれる場合があり、この設定は選択したすべてのログの保存先に適用されるため、注意が必要です。その後、 [CloudWatch ロググループ] と [S3 ログ] のそれぞれに 1 つずつ、合計で 2 つの保存先を設定します。そして、 [作成] を選択します。 ログ記録が有効になったら、テストイベントの発行を開始して、ログ記録の動作を観察できます。 最初のシナリオでは、 AWS Lambda 関数を構築し、この Lambda 関数をターゲットとして設定しました。 [イベントを送信] を選択して、イベントバスに移動し、サンプルイベントを送信します。 使用するペイロードを次に示します: { "Source": "ecommerce.orders", "DetailType": "Order Placed", "Detail": { "orderId": "12345", "customerId": "cust-789", "amount": 99.99, "items": [ { "productId": "prod-456", "quantity": 2, "price": 49.99 } ] } } サンプルイベントを送信すると、S3 バケットでログが使用可能になっていることがわかります。 また、Amazon CloudWatch ログにログエントリが表示されているのがわかります。ログには、 EVENT_RECEIPT から SUCCESS までのイベントライフサイクルが表示されます。イベントのライフサイクル全体の詳細については、TBD:DOC_PAGE をご覧ください。 それでは、これらのログを評価してみましょう。簡潔にするために、いくつかのログのみを含めることとし、読みやすくするために編集しています。イベントをトリガーした際のログを次に示します: { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1751608776896, "event_bus_name": "demo-logging", // REDACTED FOR BREVITY // "message_type": "EVENT_RECEIPT", "log_level": "TRACE", "details": { "caller_account_id": "123", "source_time_ms": 1751608775000, "source": "ecommerce.orders", "detail_type": "Order Placed", "resources": [], "event_detail": "REDACTED FOR BREVITY" } } イベントが正常に呼び出された際のログを次に示します: { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1751608777091, "event_bus_name": "demo-logging", // REDACTED FOR BREVITY // "message_type": "INVOCATION_SUCCESS", "log_level": "INFO", "details": { // REDACTED FOR BREVITY // "total_attempts": 1, "final_invocation_status": "SUCCESS", "ingestion_to_start_latency_ms": 105, "ingestion_to_complete_latency_ms": 183, "ingestion_to_success_latency_ms": 183, "target_duration_ms": 53, "target_response_body": "<REDACTED FOR BREVITY>", "http_status_code": 202 } } 追加のログエントリには、トラブルシューティングを容易にするリッチなメタデータが含まれています。例えば、イベントが成功した場合、イベントの開始から完了までのレイテンシータイミング、ターゲットが処理を完了するまでの期間、HTTP ステータスコードを確認できます。 完全なイベントライフサイクル追跡による失敗のデバッグ EventBridge のログ記録の利点は、問題が発生したときに明らかになります。失敗のシナリオをテストするために、Lambda 関数の許可を意図的に誤って設定し、適切な許可のない別の Lambda 関数をポイントするようにルールを変更します。 許可が不足しているため、試行は永続的な失敗で終わりました。ログには、 FIRST 試行が NO_PERMISSIONS ステータスで終わったことが示されています。 { "message_type": "INVOCATION_ATTEMPT_PERMANENT_FAILURE", "log_level": "ERROR", "details": { "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed", "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123", "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail", "attempt_type": "FIRST", "attempt_count": 1, "invocation_status": "NO_PERMISSIONS", "target_duration_ms": 25, "target_response_body": "{\"requestId\":\"a4bdfdc9-4806-4f3e-9961-31559cb2db62\",\"errorCode\":\"AccessDeniedException\",\"errorType\":\"Client\",\"errorMessage\":\"User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action\",\"statusCode\":403}", "http_status_code": 403 } } 最後のログエントリには、タイミングメトリクスと正確なエラーメッセージとともに、完全な失敗の概要が示されています。 { "message_type": "INVOCATION_FAILURE", "log_level": "ERROR", "details": { "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed", "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123", "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail", "total_attempts": 1, "final_invocation_status": "NO_PERMISSIONS", "ingestion_to_start_latency_ms": 62, "ingestion_to_complete_latency_ms": 114, "target_duration_ms": 25, "http_status_code": 403 }, "error": { "http_status_code": 403, "error_message": "User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action", "aws_service": "AWSLambda", "request_id": "a4bdfdc9-4806-4f3e-9961-31559cb2db62" } } ログは、ボトルネックを特定するのに役立つ詳細なパフォーマンスメトリクスを提供します。 ingestion_to_start_latency_ms: 62 はイベントの取り込みから呼び出しを開始するまでの時間を示し、 ingestion_to_complete_latency_ms: 114 は取り込みから完了までの合計時間を表します。さらに、 target_duration_ms: 25 は、ターゲットサービスの応答にかかった時間を示しており、EventBridge の処理時間とターゲットサービスのパフォーマンスを区別するのに役立ちます。 エラーメッセージには、失敗したアクション ( lambda:InvokeFunction アクション )、失敗した理由 ( ID ベースのポリシーでアクションが許可されていない )、関係するロール ( Amazon_EventBridge_Invoke_Lambda_1428392416 )、影響を受けた特定のリソース (Lambda 関数の Amazon リソースネーム (ARN) で示されます) が明確に記載されています。 EventBridge のログ記録機能を使用した API の宛先のデバッグ EventBridge のログ記録機能が特に役立つと思われるユースケースの 1 つは、API の宛先に関する問題のデバッグです。 EventBridge API の宛先 は、イベントバスルールまたはパイプのターゲットとして呼び出すことができる HTTPS エンドポイントです。HTTPS エンドポイントは、HTTPS 呼び出しを使用して、イベントバスから、外部システム、Software as a Service (SaaS) アプリケーション、またはサードパーティー API にイベントをルーティングするのに役立ちます。これらは接続を使用して認証と認証情報を処理します。これにより、イベントドリブンのアーキテクチャを HTTPS ベースのサービスと簡単に統合できます。 API の宛先は、外部の HTTPS エンドポイントにイベントを送信するためによく使用されますが、外部エンドポイントからのエラーのデバッグの失敗は課題となる場合があります。これらの問題は通常、エンドポイントの認証要件の変更や、変更された認証情報に起因します。 このデバッグ機能のデモを行うため、意図的に、接続リソースで誤った認証情報を使用して API の宛先を設定しました。 この誤って設定されたエンドポイントにイベントを送信すると、拡張ログ記録でこの失敗の根本原因が示されます。 { "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging", "message_timestamp_ms": 1750344097251, "event_bus_name": "demo-logging", //REDACTED FOR BREVITY//, "message_type": "INVOCATION_FAILURE", "log_level": "ERROR", "details": { //REDACTED FOR BREVITY//, "total_attempts": 1, "final_invocation_status": "SDK_CLIENT_ERROR", "ingestion_to_start_latency_ms": 135, "ingestion_to_complete_latency_ms": 549, "target_duration_ms": 327, "target_response_body": "", "http_status_code": 400 }, "error": { "http_status_code": 400, "error_message": "Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination." } } ログによって失敗の概要がすぐにわかります。target_arn はこれが API の宛先に関係していることを示し、 final_invocation_status は SDK_CLIENT_ERROR を示していて、 http_status_code は 400 です。これは、クライアント側の問題を示しています。最も重要なのは、 error_message が次のように明示的に示しているということです: ApiDestination エンドポイントを呼び出すことができません: 接続のために含まれた認証情報が API の宛先について認可されていないため、リクエストは失敗しました。 この完全なログシーケンスは、デバッグに関する役立つインサイトを提供してくれます。なぜなら、イベントの受信から、取り込み、ルールのマッチング、呼び出しの試行まで、EventBridge を通じてイベントがどのように移動したのかを正確に把握できるからです。この詳細度により、推測作業が排除され、問題の根本原因を直接特定できます。 知っておくべき追加情報 いくつかの留意点を次に示します: アーキテクチャサポート – ログ記録は、カスタムイベントバス、パートナーイベントソース、HTTPS エンドポイントの API の宛先など、すべての EventBridge 機能で機能します。 パフォーマンスへの影響 – ログ記録は非同期で実行されるため、イベント処理のレイテンシーやスループットに測定可能な影響はありません。 料金 – ログの保存と配信には、Amazon S3、Amazon CloudWatch Logs、または Amazon Data Firehose の標準料金がかかります。EventBridge のログ記録自体には追加料金はかかりません。詳細については、 Amazon EventBridge の料金ページ にアクセスしてください。 可用性 – Amazon EventBridge のログ記録機能は、EventBridge がサポートされているすべての AWS リージョンでご利用いただけます。 ドキュメント – 詳細については、 Amazon EventBridge のモニタリングとデバッグに関するドキュメント をご覧ください。 Amazon EventBridge のログ記録機能の使用を開始するには、 EventBridge コンソール にアクセスし、イベントバスでのログ記録を有効にしてください。 構築がうまくいきますように! –  Donnie 原文は こちら です。

本稿は、2025 年 7 月 14 日に AWS Migration & Modernization Blog で公開された “ Using Export for vCenter with AWS Transform ” を翻訳したものです。 Export for vCenter は、AWS Transform for VMware で利用するために vCenter からインベントリデータをエクスポートする、新しい AWS オープンソース Python プロジェクトです。Export for vCenter は、AWS Transform for VMware および AWS Transform Assessments が必要とするデータのみを取得します。データは RVTools 形式と一致する列を持つ CSV 形式でエクスポートされます。 Export for vCenter は、以下のようなお客様からのフィードバックにお応えするために用意されました： vCenter インベントリを取得するために Windows 実行ファイルをインストールしたくない Python はアプリケーションセキュリティによって承認されているが、RVTools については承認を待つ必要がある vCenter Server に対してどの API 呼び出しが実行されているかを把握したい vCenter インベントリを取得するために Windows クライアントを使用したくない どの仮想マシンの情報がエクスポートされるかを簡単に制御したい 必要最小限の情報のみを確実にエクスポートしたい どのような理由であれ、AWS Transform 用に vCenter からインベントリデータをエクスポートするために、Export for vCenter を利用できます。 使用開始 このプロジェクトは現在、 Export for vCenter GitHub リポジトリで利用できます。セットアップ手順と実行手順が  README に記載されています。プロジェクトを実行できるようになるまで数分しかかかりません。 図 1 に示すように、正規表現に基づいて仮想マシンをスキップすることができます。 図 1 – 仮想マシン スキップリストファイル vm-skip-list.txt 以下は実行中のスクリプトの例です。 図 2 – vCenter 用エクスポートの実行 スクリプトは ‘vcexport.zip’ という名前のファイルを出力します。zip 内のファイル名は RVTools で CSV エクスポートした場合と一致します。CSV の総数とその中の列は、RVTools エクスポートのサブセットです。AWS Transform で必要とするデータのみがエクスポートされます。 図 3 – Export for vCenter によってエクスポートされた CSV ファイル AWS Transform for VMware がエクスポートしたデータを RVTools Export として検出した例です。 図 4 – AWS Transformへのインポートが成功 クリーンアップ 環境変数を削除するため、ターミナルセッションを終了します 任意 – エクスポートファイルである vcexport.zip を削除します 任意 – 今後新しいエクスポートを実行する予定がない場合は、プロジェクトフォルダ全体を削除します 結論 Export for vCenter は、vCenter からのデータエクスポートを行うための代替ツールを提供する AWS のオープンソースプロジェクトです。このブログでは、スクリプトの機能を簡単に紹介しました。AWS Transform for VMware および AWS Transform Assessments において、RVTools の代替として使用できます。主な利点は以下の通りです： AWS Transform が必要とするデータフィールドのみがエクスポートされます 正規表現を使用して仮想マシンをフィルタリングできます ソースコードを実行ファイル形式にコンパイルする必要がありません Windows クライアントは必要ありません 実際にお試しいただくには、 Export for vCenter GitHub リポジトリをご確認ください。 Patrick Kremer インフラストラクチャのマイグレーションとモダナイゼーションに特化したシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、20 年間の VMware での経験を活かして、お客様の AWS ソリューションへの移行を支援しています。AWS Solutions Architect Professional の認定を取得しており、教育とブログ執筆に情熱を注いでいます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。