この記事は Enhance Ecommerce Visualization with Avataar’s Creator Platform on AWS (記事公開日: 2024 年 7 月 29 日) を翻訳したものです。 ボストン・コンサルティング・グループ の調査によると、2027 年までに e コマースは世界の小売売上の 41% を占めると予測されています。オンライン販売は、物理的な接触なしで品質保証が必要となるため、オフライン販売とは大きく異なります。Wyzowl の 2024 年ビデオマーケティング統計 によると、82% の購買者がブランドのビデオを見た直後に購入しており、87% がビデオの品質がブランドへの信頼に影響すると述べています。人間の脳は視覚的に魅力的な情報に報酬を与えるため、可視化が顧客の信頼を得る鍵となります。 AWS パートナーである Avataar は、この知見に基づき、AI を使用して写実的な製品コンテンツを生成することでブランドを支援し、オンラインショッピング体験を再定義しています。Avataar は Amazon Bedrock と Amazon Elastic Compute Cloud (EC2) を活用した Creator Platform を提供しています。この Creator Platform は、その可視化機能によりショッピング体験を向上させ、顧客の想像力と注意を捉えます。結果として、これは顧客エンゲージメントを高め、その後のアクションを促進します。インドの自動車製造会社である Bajaj は、Avataar のインタラクティブな仮想製品ショールームを実装することでこれらの利点を経験しました。同社はオンラインでの試乗予約の成約率が 9% に達し、平均エンゲージメント時間が 3 倍に増加したことを確認しています。 Avataar のプラットフォームで e コマース体験を再構築 Avataar の技術の中核にあるのは、生成 AI とコンピュータービジョンアルゴリズムの組み合わせです。これらのアルゴリズムは、従来の製品写真や 3D レンダリングソフトウェアソリューションの制約に縛られない、実生活に即した製品可視化体験を生成するように設計されています。Avataar は、シルエット写真や製品の特定の側面を詳細に表現するクローズアップショットを含む、魅力的な製品画像を生成するためにデータセットを訓練しました。 このプラットフォームは、テキストプロンプトからライフスタイル画像も生成できます。 Avataar の Creator workspace に 3D モデルを追加し、この製品が実際の環境でどのように見えるかをテキストプロンプトで説明するだけです。あとは、AI ソリューションが驚くべき結果を生み出してくれます。以下の画像で見られるように、左の画像は理想的な環境を従来の写真撮影で表現したものです。これはコストと時間がかかるアプローチで、市場投入までの時間が長くなります。 Avataar の Creator platform を使用すると、ブランドは製品のデジタルツインを使用し、AI にテキストプロンプトを提供することで理想的な背景を作成できます。AI 背景生成機能により、ブランドはコスト効率良く、ターゲット層に合わせた様々な設定を検証できます。 従来の画像 vs. Avataar の生成画像 さらに、このプラットフォームは 3D カタログ用の空間動画を生成するためのユーザーフレンドリーなフレームワークを提供しています。Avataar はテンプレート化されたアプローチを通じて小売業者にスケーラビリティを提供します。カテゴリーごとにひとつのテンプレートを作成し、動画内の 3D モデルを簡単に置き換えることで、カタログ全体の動画を生成できます。 さらに驚くべきことは何でしょうか？これらすべてが、Avataar の生成 AI 技術を活用したコンテンツ制作システムによって実現され、同時にコンテンツ制作費を最大 40% 削減することが可能ということです。 Avataar は、小売業者が様々な販売プラットフォームに対応できるよう、必要とされるフォーマットとアスペクト比で出力を統合する機能も提供しています。このシームレスな統合により、チームの手作業の労力が削減され、市場投入までの時間が短縮されます。 AWS は Avataar の e コマース向けビジュアル探索をどのように支えているか Avataar の技術は、没入型でリアルなビジュアルショッピング体験を創造するために、3D コンピュータービジョン、生成 AI 、ニューラルレンダリングの最先端の研究を適用しています。AWS は、Avataar の高負荷な処理要求に対応できる強力なクラウドコンピューティング基盤を提供しています。AI アルゴリズムの実行をサポートするために必要なスケーラビリティ、信頼性、パフォーマンスを AWS が提供することで、Avataar の AI システムと人間が協力し、大規模に空間コンテンツを提供できます。さらに、AWS のグローバルインフラストラクチャは、最小限の遅延で最適なコンテンツ配信をサポートし、世界中の顧客のユーザー体験を向上させています。 AWS ParallelCluster 、 Amazon CloudFront 、 Elastic Load Balancing などの AWS サービスを使用することで、Avataar は効率的に運用するだけでなく、e コマース環境の需要の変化に応じてシームレスにスケールアップできます。Avataar を使用することで、小売業者は顧客を魅了し、コンバージョンを促進する 3D 対応の製品ストーリーを作成できます。例えば Samsung は、Avataar と協力してバナーページに 没入型コンテンツを採用 し、プレミアム製品のソーシャルコンバージョンとエンゲージメントを 10 倍に増加させました。 ステップ バイ ステップ：Avataar の Creator platform を使用した可視化 Avataar のセルフサービス型 Creator platform は、ユーザーが簡単かつ効率的に非常にリアルな製品ビジュアルを作成できるようにします。以下のステップに従って始めましょう： ステップ 1 ：Creator へのアクセス。 Avataar Creator platform には3つの方法でアクセスできます： 1) 公開リンクを使用して メールアドレスでログイン する。 2) AWS Marketplace — 製品ストーリーテリングのための生成 AI にアクセスする。 3) Avataar または Avataar を使用している同僚から受け取った招待メールのリンクを使用する。 ステップ 2 ：プロジェクトの作成と設定。 プラットフォームにログインしたら、「プロジェクト」タブからプロジェクト名とカテゴリーを指定して、新しいプロジェクトを開始できます。3D オブジェクトファイルをアップロードし、オブジェクトに関連する詳細情報を追加します。キャンバス上でオブジェクトをプレビューし、送信してアップロードを完了します。 ステップ 3 ：レンダリング品質の向上とアニメーションの設定。 Avataar の Creator platform 独自の機能として、強化されたレンダラーがあります。トグルを有効にするだけで、非常に写実的な設定でオブジェクトを可視化できます。必要に応じて、さらに詳細を追加するために照明設定とノイズレベルを調整できます。動画の場合、画像、クリップ、テキストをインポートし、これらをそれぞれアニメーション化する柔軟性があります。 ステップ 4 ： AI 背景生成機能の使用。 オブジェクトのカメラアングルを設定し、AI 背景生成機能を使用します。希望するライフスタイル背景をテキストで入力し、生成された複数の背景オプションから選択して、トレイに追加します。 ステップ 5 ：レンダリングされた画像と動画のエクスポート。 画像や動画をエクスポートするには、「エクスポート」をクリックし、出力タイプを選択します。画像の場合、同じカテゴリーの製品に対して再度アングルを手動で選択する手間を省くために、テンプレートを保存することもできます。 ステップ 6 ：コンテンツの作成。 Avataar のクリエイターにログインし、魅力的な画像や動画の作成を始めましょう。このコンテンツを使用して、e コマースリスティングのエンゲージメントとコンバージョンの向上を促進しましょう。 e コマースの多次元的な未来 AWS を活用した Avataar の Creator platform を通じて、ブランドは大規模に写実的な画像を提供し、市場投入までの時間を短縮し、商品リストを向上させることができます。小売業界が進化するにつれ、顧客の信頼とロイヤリティを獲得し、維持するために、製品の可視化がより重要になっています。Avataar の空間体験により、小売業者やブランドは従来のストーリーテリングの物理的限界を超え、e コマースビジネスの未来に備えることができます。 関連記事へのリンク Scaling product visualization and storytelling in retail with Avataar’s GenAI Spatial storytelling across industries: Applications in retail and beyond The inner circle Q&A: Jane Rawnsley, Senior Vice President, Creative, Avataar AWE panel: Rendering believable 3D assets for ecommerce Avataar’s Creator platform documentation Avataar in AWS Marketplace 著者について Pratishtha Gupta Pratishtha は、Avataar でカスタマーサクセスを先導し、米国と中東全域の重要な企業および中堅市場のアカウントを管理しています。10 年以上にわたる卓越したキャリアの中で、彼女はデータ駆動型のアプローチを用いて、クライアントとの強固なパートナーシップを育成し、自身の製品に大きな成長をもたらしています。 Akanksha Tripathi Akanksha は、小売業者やブランド向けの AI を活用したコンテンツ制作プラットフォームである Avataar で、GTM（Go-to-Market）パートナーシップを率いています。彼女の役割では、強固なパートナーシップエコシステムを育成・管理し、AWS などの戦略的パートナーとのビジネス成長と共同イノベーション イニシアチブ を推進しています。 Santanu Chattopadhyay Santanu Chattopadhyay は、小売・消費財業界ソリューションを担当する AWS APJ（アジア太平洋地域）パートナーテクノロジーリーダーです。彼は、最先端の AWS サービスを使用して小売・消費財業界のソリューションを構築および強化するために、APJ 全域のパートナーと協力しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。 原文 はこちら。

本記事は、2024/03/28 に公開された Sync users and groups from Okta with Amazon QuickSight を翻訳したものです。 注：2023年8月現在、Amazon QuickSight は AWS IAM Identity Center 対応アプリケーションとなっています。この機能により、QuickSight をサブスクライブしている管理者は、IAM Identity Center を使用して、ユーザーがOkta やその他の外部 ID プロバイダでログインできるようになります。詳細については、QuickSight ドキュメントの「 Simplify business intelligence identity management with Amazon QuickSight and IAM Identity Center (AWS blog post)」および「 Configure your Amazon QuickSight account with IAM Identity Center 」を参照してください。この新しいインテグレーションを使用することをお勧めします。このブログ投稿は、既存のアカウント構成の参考として提供されています。 Amazon QuickSight は、クラウドベースでサーバーレスかつ組み込み可能なビジネスインテリジェンス（BI）サービスです。QuickSight は完全に管理されたサービスとして、インタラクティブなダッシュボードを作成、公開することができ、あらゆるデバイスからアクセスしたり、アプリケーション、ポータルおよびウェブサイトに埋め込むことができます。 QuickSight は、Standard Edition と Enterprise Edition の両方で、Security Assertion Markup Language 2.0 (SAML 2.0) による ID フェデレーションをサポートしています。フェデレーションを使用すると、企業の ID プロバイダー（IdP）を使用してユーザーを管理し、ログイン時にそのユーザーを QuickSight に渡すことができます。IdP には、Microsoft Active Directory Federation Services、Ping One Federation Server、Okta などがあります。 本稿執筆時点では、QuickSight はエンタープライズグレードの認証メカニズムとして、フェデレーテッド・シングル・サインオン（SSO）と Active Directory（AD）のインテグレーションをサポートしています。後者では、役割の割り当てとコンテンツの認可のために、ネイティブの AD グループをシームレスに同期することができます。しかし、SAML を使用して連携 SSO を行う場合、適切なロールでユーザを自動的にプロビジョニングすることもできます。現在、このインテグレーションは、IdP と QuickSight 間のグループとユーザーまたはグループのメンバーシップを自動的に同期させてはいますが、その同期を遅延させています。これは、自動的にプロビジョニングされたユーザーに対して、アセットへの適切なアクセスを許可し、権限を付与するために重要です。 主な課題は以下の 3 つです。 サードパーティ IdP からのユーザーとグループの自動同期 ユーザーのグループへの自動割り当て ユーザーとグループが IdP から削除された場合の QuickSight からのデプロビジョニング この投稿では、スケーラブルな方法でこれらの課題を克服するための手順とコードサンプルを提供します。Okta を使用したソリューションを示しますが、他の IdP を使用することもできます。これは実績のあるソリューションで、QuickSight の複数のお客様で使用され、実装されています。 ソリューション概要 このソリューションでは、QuickSight と以下の AWS サービスを使用して、ユーザー、グループ、およびそれらのメンバーシップを IdP から自動的に同期します。この場合、IdP は唯一の信頼できるソースとして機能します。 AWS Lambda はサーバーレス、イベント駆動型のコンピュートサービスで、サーバーのプロビジョニングや管理を行うことなく、事実上あらゆるタイプのアプリケーションやバックエンド・サービスのコードを実行できます。200 以上の AWS サービスや SaaS（Software as a Service）アプリケーションから Lambda をトリガーすることができ、使用した分だけ料金を支払うようになっています。 AWS Step Functions は、開発者が AWS サービスを使用して分散アプリケーションを構築し、プロセスを自動化し、マイクロサービスをオーケストレーションし、データと機械学習（ML）パイプラインを作成するのを支援するビジュアルワークフローサービスです。 Amazon EventBridge は、イベントを使用してアプリケーション・コンポーネントを接続するサーバーレス・サービスで、スケーラブルなイベント駆動型アプリケーションを簡単に構築できる。イベントにマッチするルールを作成し、1 つまたは複数のターゲット関数またはストリームにルーティングできます。 AWS Identity and Access Management （IAM）は、ユーザーの AWS リソースへのアクセスを安全に制御するのに役立ちます。IAM を使用して、誰が AWS リソースを使用できるか（認証）、どのリソースを使用できるか、どのように使用できるか（認可）を制御できます。詳細については、 IAM ユーザーガイド を参照してください。 次の図は、サードパーティの IdP からユーザーとグループの同期を実行するワークフローを示しています。 このソリューションは、オンデマンド・モードでもスケジュール・モードでも実装できます。どちらの場合でも、このソリューションが最初に行うのは、一連の Lambda 関数の実行をオーケストレーションする Step Functions ワークフロー（ Okta-QuickSight-Sync ）のトリガーです。 QuickSight-Okta-Group-Sync – QuickSight 間でグループを同期します。 QuickSight-Okta-User-Sync – ユーザーとそのグループ・メンバーシップを作成します。 QuickSight-Okta-User-Deprovisioning – QuickSight ユーザーを削除し、行き場のなくなったアセットを QuickSight の専用管理ユーザーに転送します。 以下のセクションでは、AWS CloudFormation を使用してソリューションリソースを構成する手順を説明します。まず、CloudFormation スタックに必要なパラメータを取得する必要があります。 OKTAAPIToken OKTADomain OKTAQuickSighAPPId QuickSightAdminUserName QuickSightAdminIAMRole QuickSightAuthorIAMRole QuickSightReaderIAMRole 前提条件 以下の前提条件が必要です。 QuickSight アカウントのサブスクリプション QuickSight へのフェデレーションが有効な Okta サブスクリプション AWS アカウントの管理者権限 （訳者注）本ソリューションを手順に従って試す場合、QuickSight アカウント作成および CloudFormation の実行は バージニア北部（us-east-1）リージョン で行ってください。 IdP から OKTAAPIToken を取得し、Lambda から API コールを行う まず、CloudFormation スタックのパラメーターとして使う API トークンを作成します。 以下のステップを完了します。 管理者アカウントでOktaドメインにログインします。 ナビゲーションペインの Security で API を選択します。 Tokens タブで、Create token を選択します。 トークン名（例：Okta API token for QuickSight user and group Sync）を入力し、 Create token を選択します。 Okta がトークン値を生成します。 トークン値をコピーし、後のステップで使用するために保存します。 OK, got it を選択し、モーダルウィンドウを閉じます。 Okta は以下のように Token Value を生成します。 トークンの詳細は API ページに記載されています。詳細には、トークンの作成日、有効期限、最終使用日のタイムスタンプが含まれます。 API トークンの有効期限は Okta のアカウント構成によって異なります。トークンの有効期限切れにより Lambda コードが失敗した場合は、新しいトークンを生成し、Lambda 設定で更新してください。 IdP の OKTADomain を取得する Oktaドメイン名を検索する には、次の手順を実行します。 管理者アカウントで Okta 組織にサインインします。 ダッシュボードの右上にあるグローバルヘッダで Okta ドメインを探します。 ドメイン URL 全体をコピーし、後のステップで使用するためにこれを保存します。 Okta に設定されている QuickSight アプリケーションの OKTAQuickSighAPPId を取得する アプリケーションIDを取得するには、以下の手順に従ってください。 管理者アカウントで Okta 組織にサインインします。 ナビゲーションペインの Applications で Applications を選択します。 QuickSight アプリケーションを選択します。 ブラウザの URL に表示されているアプリケーション ID をコピーし、後の手順で使用するために保存します。 QuickSightAdminUserName を取得し、アセットを管理ユーザーに転送する admin または author ロールを持つユーザをデプロビジョニングする際、アセットの所有権を移行するために、この admin ユーザを使用します。以下の手順を実行してください。 管理者権限で QuickSight アカウントにサインインします。 ユーザ・プロファイル・アイコンを選択し、 QuickSightを管理 を選択します。 ユーザーを管理 にある管理者ユーザー名（この記事では OktaSSOUser を使用）をコピーし、後のステップで使用するために、これをメモします。 QuickSight IAM ロールを作成する Amazon QuickSightへのアクセスをOktaでフェデレートする （ 日本語訳 ）ブログポストの手順に従って、IAMロールを設定します。 管理者 : QuickSightOktaAdminRole 作成者 : QuickSightOktaAuthorRole リーダー : QuickSightOktaReaderRole （訳者注ここから） 各ロールには以下のようなポリシーを設定してください。ポリシーの内容は適宜変更してもかまいません。 管理者 （ポリシー名は、必ず QuickSightOktaCreateAdminPolicy とし、 QuickSightOktaAdminRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateAdmin", "Resource": "*" } ] } 作成者 （ポリシー名は、必ず QuickSightOktaCreateAuthorPolicy とし、 QuickSightOktaAuthorRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateUser", "Resource": "*" } ] } リーダー （ポリシー名は、必ず QuickSightOktaCreateReaderPolicy とし、 QuickSightOktaReaderRole にアタッチしてください。） { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "quicksight:CreateReader", "Resource": "*" } ] } （訳者注ここまで） このソリューションでは、ユーザー登録のための AWS Lambda コードは上記の IAM ロールを使用します。IAM ロールの命名は正確に保つようにしてください。デプロイしたら、IAM ロールをカスタムロールで更新してください。 これで CloudFormation テンプレートに必要なパラメータが揃いました。 AWS CloudFormation でリソースを作成する Launch Stack を選択してリソースをプロビジョニングします （訳者注）CloudFormation を実行するリージョンは バージニア北部 (us-east-1) に設定してください。 スタックの作成 のページで、 次へ を選択します。 前のステップで取得したパラメータを入力し、 次へ 選択します。 入力項目を確認し、 送信 を選択します。 CloudFormation が正常にデプロイされると、すべてのリソースがそれぞれのアカウントにデプロイされます。 EventBridgeルールを有効にする デプロイされたリソースの一部として、EventBridge ルールが作成されます。スクリプトの偶発的な実行を避けるため、デフォルトでは無効になっています。このルールは、毎日 12:00 UTC にトリガされるように設定されています。 次の手順を実行して、ルールを有効にします。 EventBridge コンソールで、ナビゲーション ペインの バス の下にある ルール を選択します。 ルールリストで、CloudFormation テンプレートで作成したルール（ OktaQSSyncEventsRule ）を選択します。 UTC 12:00　からの既存のルール設定を編集して独自のスケジュールを設定するには、 イベントパターン セクションで 編集 を選択します。 ルールを有効にするには、 有効化 を選択します。 ルールを有効にすると、Step Functions ワークフローの実行がトリガーされ、Okta から QuickSight へのユーザーとグループの自動同期が開始されます。 留意点 Okta ドメイン、Okta アプリケーション ID、API キー、および Okta の QuickSight アプリケーションに割り当てられた QuickSight 専用の管理者、ユーザー、グループは、QuickSight で同期される唯一のグループです。Okta のすべてのユーザーとグループが同期されるわけではありません。 QuickSight からユーザーをデプロビジョニングまたは削除する場合、行き場のなくなったアセットの所有権は、QuickSight-Okta-User-Deprovisioning Lambda 関数の環境変数で設定された専用管理ユーザーに移行されます。 クリーンアップ クリーンアップするには、CloudFormation スタックを削除して、作成したすべてのリソースをデプロビジョニングします。これにより、3 つの Lambda 関数と関連するロールとポリシー、Step Functions ワークフローと関連するロール、EventBridge ルールと関連するロールが削除されます。 まとめ この投稿では、Okta と QuickSight 間のユーザーとグループの自動同期を設定する手順を説明しました。このソリューションにより、QuickSight からグループとそのメンバーシップを手動で管理する必要がなくなり、Okta からユーザが削除された際にQuickSight からユーザをデプロビジョニングする必要がなくなります。 ご質問やご意見がございましたら、コメントをお寄せください。 その他のディスカッションや質問への回答については、 QuickSight Community をご覧ください。

AWS Deadline Cloud は、Amazon Web Services (AWS) から提供されるフルマネージドサービスで、スケーラブルなフルマネージドのビジュアルコンピューティングファームを数分で起動できます。Blender、Houdini、Maya、Nuke などのデジタルコンテンツ制作 (DCC) アプリケーションのレンダリングジョブは、Deadline Cloud Service-Managed Fleets (SMF) を使用することで、迅速かつターンキーで実行できます。これらのアプリケーションは、SMF 環境のワーカー用に conda パッケージ としてサービスに含まれています。しかし、異なるバージョンの DCC を実行したり、サードパーティ製のプラグインを使用したり、パイプラインコードをカスタマイズしている場合はどうすればよいでしょうか。 このブログ記事では、独自の conda パッケージを作成し、 Amazon S3 バケットに conda チャネルをホストして、そのパッケージを Deadline Cloud のレンダーワーカーが利用できるようにする方法を説明します。アプリケーション全体をバンドルして依存関係なく実行可能なパッケージを作成したり、 conda-forge コミュニティによって維持・ホストされている数千のパッケージを元に作成することができます。カスタム conda パッケージとチャネルを利用できるので、Deadline Cloud のパイプラインを拡張し、事実上あらゆるクリエイティブ ツールをサポートすることができます。 このブログ記事の手順に従って、公式のアップストリームバイナリビルドから Blender 4.1 conda パッケージをビルドするために Deadline Cloud キューを使用し、新しいカスタム conda チャネルを使って Blender 4.1 を見つけるようにプロダクションキューを構成し、ファームで Blender のデモシーンをレンダリングします。 パッケージビルドのアーキテクチャ 図 1: 本記事で作成するパッケージビルドキューと通常 Deadline Cloud レンダリングジョブが実行されるプロダクションキューの関係を示しています。 このブログ記事で展開されるアーキテクチャは、conda パッケージビルドジョブ専用の新しいパッケージビルドキューをファームに追加します。 このアーキテクチャの主な特徴は次のとおりです: プロダクションキューは、S3 バケットの /Conda プレフィックスに対する読み取り権を持つため、カスタムの conda パッケージを使用することはできますが、変更することはできません。 パッケージビルドキューは、S3 バケットの /Conda プレフィックスに対する読み取り/書き込み権を持つため、新しくビルドされたパッケージをアップロードし、conda チャネルのインデックスを再作成することができます。 パッケージビルドキューは、S3 バケット内に別のジョブアタッチメントプレフィックスを持つため、そのデータはプロダクションデータから分離されています。 パッケージビルドジョブは、プロダクションキュー用に既に作成したフリートを使用するため、管理が必要な個別のインフラストラクチャコンポーネントの数を減らすことができます。 前提条件 このチュートリアルでは、以下が条件を満たしている必要があります。 AWS アカウント を持っていること Git がインストールされていること AWS Deadline Cloud 用に Deadline Cloud CLI がインストールされていること Deadline Cloud が AWS アカウントにセットアップされており、少なくとも 1 つのキューとフリートがあること 詳細については、 Deadline Cloud の開始方法 のドキュメントを参照してください。 カスタム conda パッケージ用のキューの権限設定 conda パッケージをローカルでビルドすることはできますが、このブログ記事では AWS Deadline Cloud でパッケージをビルドします。これにより、完成したパッケージを conda チャネルとして使用する Amazon S3 バケットに簡単に配信でき、自身のコンピューティングリソースでのビルドに必要な依存関係を減らすことができ、コンピュータをビルドプロセスで拘束することなく複数のパッケージをビルドできます。 AWS Deadline Cloud のカスタム conda チャネルには、Amazon S3 バケットが必要です。新しいバケットを作成するか、既存のキューの 1 つから S3 バケットを再利用できます。Deadline Cloud の目的のキューのキュー詳細ページのジョブアタッチメントファイルタブで、キューの S3 バケット情報を確認できます。 図2: “default-queue-s3-bucket” という名前のジョブアタッチメントバケットを持つ “Production Queue” のキュー詳細ページの例。   ジョブアタッチメントファイルタブには、現在設定されているバケットが表示されます。また、ジョブアタッチメントバケットの上にある “Awsdeadlinecloudqueuerole” というキューサービスロールにも注目してください。バケット名とキューのロール名は異なります。 プロダクションキューを設定するには、キューの詳細ページにあるバケット名とキューサービスロールの両方が必要です。ゴールは、プロダクションキューに S3 バケットの新しい /Conda プレフィックスへの読み取り権を与え、パッケージビルドキューには読み取り/書き込み権を与えることです。ロールのアクセス権を編集するには、このページのキューサービスロールをクリックします。これにより、そのロールの AWS Identity and Access Management (IAM) ページに直接移動します。 キューサービスロールを表示するときは、 [+] を選択してポリシー名が AWSDeadlineCloudQueuePolicy で始まるポリシーを展開し、[編集] を選択してください。 デフォルトでは、このキューロールは、 最小権限の原則 に従い、AWS アカウント内の 特定のリソースへのアクセスのみ に制限されているため、権限は限られた数しか表示されません。ビジュアルエディタまたは JSON エディタを使用して、次の例のような新しいセクションを追加できます。オレンジ色で強調されているバケット名とアカウント番号は、ご自身のものに置き換えてください。ポリシーへの新しい追加は、バケットと新しい /Conda プレフィックスの両方に対して、 s3:GetObject と s3:ListBucket の権限を許可する必要があります。 { "Effect": "Allow", "Sid": "CustomCondaChannelReadOnly", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3::: default-queue-s3-bucket ", "arn:aws:s3::: default-queue-s3-bucket /Conda/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": " 111122223333 " } } }, パッケージビルドキューの作成 次に、conda チャネル用の特定の conda パッケージをビルドするジョブを送信する、新しいパッケージビルドキューを作成します。Deadline Cloud コンソールのファームページから、キューの作成を選択します。 S3 バケットは、プロダクションキューと同じバケットを使用するか、新しいバケットを作成します。通常の Deadline Cloud のジョブアタッチメントファイルとは別に保管するため、 /DeadlineCloudPackageBuild などの新しいプレフィックスを作成することをお勧めします。フリートの関連付けについては、既存のフリートを使用することもできますし、現在のフリートが適さない場合は、完全に新しいフリートを作成することもできます。 キューサービスロールについては、新しいキューサービスロールを作成して使用することをお勧めします。このロールを設定すると、指定した S3 バケットとプレフィックスに対する読み取り/書き込み権が自動的に付与されます。 パッケージビルドキューの権限設定 先程プロダクションキューのロールを変更したのと同様に、パッケージビルドキューのロールを変更して、 /Conda プレフィックスへの読み取り/書き込み権を与える必要があります。 パッケージビルドキューの詳細ページから、キューサービスロールをクリックし、 [+] をクリックしてから [編集] をクリックします。この一連の権限は読み取り/書き込みする必要があるため、ポリシーの追加には、デフォルトのキュー宛先で使用される 4 つの権限 ( s3:GetObject 、 s3:PutObject 、 s3:ListBucket 、 s3:GetBucketLocation ) に加えて、 s3:DeleteObject によるオブジェクトの削除機能が含まれています。これらの権限は、パッケージビルドジョブが新しいパッケージをアップロードしてチャネルをインデックスを再作成するために必要です。オレンジ色で強調表示されているバケット名とアカウント番号は、ご自身のものに置き換えてください。 { "Effect": "Allow", "Sid": "CustomCondaChannelReadWrite", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3::: default-queue-s3-bucket ", "arn:aws:s3::: default-queue-s3-bucket /Conda/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": " 111122223333 " } } }, Blender 4.1 パッケージのビルド 以下の手順では、bash 互換のシェルから git を 使用して、 Deadline Cloud Samples GitHub から Open Job Description (OpenJD) パッケージのビルドジョブと、 conda レシピを取得します。Windows の git インストールには、 git BASH と呼ばれる bash のバージョンが含まれており、これを使用できます。また、 Deadline Cloud CLI をインストールし、 Deadline Cloud monitor にログインするか、別の AWS 認証方式を使用する必要があります。最後のステップは、Deadline Cloud CLI を使用してそれらの OpenJD ジョブバンドルをキューに送信することです。 bash 互換のシェルで deadline config gui を実行し、構成 GUI を開いて、デフォルトのファームとキューを作成したパッケージビルドキューに設定してください。 git clone で Deadline Cloud サンプル GitHub リポジトリをクローンし、 conda_recipes ディレクトリ に切り替えると、 submit-package-job というスクリプトが見つかります。このスクリプトを初めて実行すると、次の例のように Blender をダウンロードする手順が表示されます。手順に従ってダウンロードが完了したら、ジョブを再度実行してサブミッションを作成してください。 $> deadline config gui $> git clone https://github.com/aws-deadline/deadline-cloud-samples.git $> cd deadline-cloud-samples/conda_recipes $> ./submit-package-job --recipe blender-4.1/ No S3 channel provided, using job attachments bucket default ERROR: File blender-4.1/blender-4.1.1-linux-x64.tar.xz not found. To submit the blender-4.1 package build, you need the archive blender-4.1.1-linux-x64.tar.xz To acquire this archive, follow these instructions... $> ./submit-package-job --recipe blender-4.1/ No S3 channel provided, using job attachments bucket default Building package into conda channel s3://default-queue-s3-bucket/Conda/Default + deadline bundle submit build_linux_package -p RecipeName=blender-4.1 -p OverrideSourceArchive=blender-4.1/blender-4.1.1-linux-x64.tar.xz -p RecipeDir=blender-4 .1/blender-4.1 -p 'S3CondaChannel=s3://default-queue-s3-bucket/Conda/Default' -p CondaChannels= Submitting to Queue: Package Build Queue ... Job creation completed successfully Deadline Cloud monitor を使用して、ジョブの実行中の進行状況とステータスを確認します。デフォルトの 2 vCPU、8 GiB RAM のインスタンスサイズ仕様では、パッケージのビルド、S3 バケットへのアップロード、チャネルの再インデックスに 22 分かかりました。デフォルトのフリート設定は conda パッケージのビルドとレンダリングには比較的小さいため、設定を増やすことをお勧めします。 図3. パッケージビルドジョブがハイライトされた Deadline Cloud monitor Deadline Cloud monitor の左下には、ジョブの 2 つのステップ (パッケージのビルドとインデックスの再作成) が表示されています。右下には、各ステップの個々のタスクが表示されています。この例では、各ステップに 1 つのだけタスクがあります。 パッケージビルドのステップのタスクを右クリックし、[ログを表示] を選択します。右側に、セッション操作のリストが表示され、ワーカーホストでタスクがどのようにスケジュールされるかを示すます。セッション操作は次のとおりです。 アタッチメントファイルの同期 : この操作は、ジョブのアタッチメントファイルシステムの設定に応じて、入力ジョブのアタッチメントファイルデータをコピーするか、仮想ファイルシステムをマウントします。 Conda の起動 : この操作は、Deadline Cloud コンソールのオンボーディングフローがデフォルトで追加する OpenJD キュー環境 のものです。ジョブは conda パッケージを指定しないため、すぐに終了し、conda 仮想環境は作成されません。 CondaBuild 環境の起動 : この操作は、conda パッケージのビルドと conda チャネルのインデックスの再作成に必要なソフトウェアを含む、カスタマイズされた conda 仮想環境を作成します。 conda-forge チャネルからインストールします。 タスクの実行 : この操作は、Blender パッケージのビルドを実行し、作成されたパッケージを S3 にアップロードします。 図 4. Deadline Cloud monitor のログビューアー ログは構造化された形式で Amazon Cloudwatch 内に保存されています。ジョブが完了した後、「すべてのタスクのログを表示」をチェックすると、ジョブが実行された環境のセットアップとティアダウンに関する追加のログを表示できます。 パッケージビルドジョブがどのように実装されているのか気になる方は、 ソースコード をご確認ください。たとえば、チャネルのインデックスを再作成するステップには、一度に 1 つのパッケージビルドジョブのみがインデックスの再作成を実行できるようにする相互排他があります。これは OpenJD 環境として実装されており、 Amazon S3 の強い整合性 を使用して、追加のインフラストラクチャを必要とせずに正しい実装されています。 プロダクションキュー環境にconda チャネルを追加 S3 conda チャネルと Blender 4.1 パッケージを使用するには、Deadline Cloud に送信するジョブの CondaChannels パラメータに s3:///Conda/Default チャネル場所を追加する必要があります。構築済みの Deadline Cloud サブミッターには、カスタム conda チャネルと conda パッケージを指定できるフィールドが用意されています。 プロダクションキューの conda キュー環境を少し変更するだけで、すべてのジョブを変更する必要がなくなります。Deadline Cloud コンソールを開き、プロダクションキューのキュー環境タブに移動します。リストの「Conda」キュー環境のチェックボックスを有効にし、[編集] を選択します。Costomer-Managed Fleet の場合は、Deadline Cloud samples GitHub にある conda キュー環境サンプル のいずれかを使用して conda パッケージの使用を有効にできます。 CondaChannels パラメータを指定するセクションに、デフォルト値を以下のように設定する行があります: default: "deadline-cloud" この行を編集して、新しく作成した S3 conda チャネルで始めます: default: "s3:///Conda/Default deadline-cloud" Service-Managed Fleets では、デフォルトで conda の strict channel priority が有効になっているため、S3 チャネルに  blender をビルドすると、conda は deadline-cloud チャネルを全く考慮しなくなります。つまり、以前は deadline-cloud チャネルを使用して成功していた blender=3.6 を含むジョブが、Blender 4.1 をビルドした後は失敗するようになります。 Blender 4.1 ジョブをプロダクションキューに送信 パッケージがビルドされ、キューがそのチャネルを使用するように設定されたので、いよいよパッケージを使用してレンダリングします。まず、CLI コマンドの  deadline config gui を再度実行し、プロダクションキューを選択して、プロダクションキューに切り替えてください。 まだ Blender のシーンを持っていない場合は、 Blender のデモファイル ページに移動し、ダウンロードするファイルを選択します。私たちは、 Blender Splash Artwork セクション にある  Nicole Morena 氏が作成し、CC-BY-SA ライセンスの下でリリースされた Blender 3.5 – Cozy Kitchen シーンファイルを選択しました。ダウンロードすると  blender-3.5-splash.blend というファイルが含まれており、クイックスタートのオンボーディングフリートでも簡単にレンダリングできます。他のシーンをレンダリングする場合は、Deadline Cloud コンソールからフリート設定値を増やす必要があるかもしれません。 Deadline Cloud samples GitHub リポジトリには、次のコマンドを使用して Blender シーンをレンダリングできるサンプルジョブが含まれています。 $> deadline bundle submit blender_render \ -p CondaPackages=blender=4.1 \ -p BlenderSceneFile=/path/to/downloaded/blender-3.5-splash.blend \ -p Frames=1 Submitting to Queue: Production Queue ... Job creation completed successfully Deadline Cloud monitor で、送信したジョブのタスクを選択し、ログを表示するオプションを選択します。ログビューの右側で、「Launch Conda」と呼ばれるセッションアクションを選択します。キューの環境で設定された 2 つの conda チャネルで Blender 4.1 を検索し、S3 チャネルでパッケージを見つかったことがわかります。 ジョブが完了したら、 出力をダウンロード して結果を確認できます。 クリーンアップ キューからフリートの関連付けを解除したあと、キューを削除してください。 /Conda プレフィックスを削除するには、AWS コンソールで S3 バケットに移動し、バケットを開き、 /Conda プレフィックスを選択し、「削除」を選択して、指示に従ってください。 OS の通常の削除手順を実行して、ダウンロードしたファイルや git クローンしたファイルを削除してください。 IAM ポリシーに追加した権限を削除するには、前述の手順に従って各ポリシーに移動し、追加したセクションを削除してください。 まとめ このブログ記事では、キューロールのアクセス権を変更する方法、新しいバージョンのソフトウェア用にカスタム conda パッケージをビルドする方法、プロダクションレンダーキュー用の conda チャネルとして機能する S3 バケットを追加する方法を説明しました。Open Job Description と AWS Deadline Cloud は、さまざまな計算ジョブ、およびレンダリングジョブを処理できるように設計されており、組み込みの SMF サポートと私たちが提供するビルド済みのサブミッターをはるかに超えてパイプラインを拡張できます。提供されている例を参考に、小さなプラグインや Nuke gizmoなどの簡単なものから始めて、今日からあなたの Deadline Cloud ファームの機能をカスタマイズしてみてください。 著者について Mark Wiebe Mark Wiebe is a Principal Engineer at AWS Thinkbox, focused on solutions for creative content. Sean Wallitsch Sean is a Senior Solutions Architect, Visual Computing at AWS. 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳はソリューションアーキテクトの濵野が担当しました。原文は こちら です。

「AWS には興味があるが、何から学習したらいいかわからない」「新卒エンジニアとして、クラウドに関する知見を伸ばしたい」「フルスタックエンジニアを目指して AWS も身につけたい」というお悩みはありませんか？これらのお悩みの一助となるのが、今回紹介させていただくイベント AWS JumpStart 2025 です。 2022 年から始まり毎年開催されている AWS JumpStart ですが、本イベントの内容や 2025 年の開催方針について、このブログでは紹介させていただきます。 AWS JumpStart とは AWS JumpStart は、新卒を含む AWS 初学者のエンジニアを対象とした、クラウドネイティブなテックリード人材を育成するための第一歩となる実践的な研修プログラムです。事前学習用動画と 2 日間の集中的なオンラインワークショップを通して、皆様の AWS に対する理解度を一気に引き上げることを目的としています。 AWS について話を聞いたことはあるが使ったことはない EC2 等の単体サービスは触ったことあるが、システム全体の設計経験はない クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい といった方々には短期間で一気にレベルアップできる内容となっているので、AWS を学びはじめるのにもってこいのプログラムとなっています。 AWS JumpStart 2025 のご案内 今年 2024 年にも開催した JumpStart ですが、1,000 人を超えるエンジニアの皆さまにご参加いただき大変好評でした。翌年の開催要望も多くいただいており、2025 年も全 4 回、各回 2 日間での開催を決定しました！ AWS JumpStart 2025（全てオンラインでの開催です） 開催日時（各回 2 日間：9 – 18 時） 2025 年 3 月 13 日（木）~ 3 月 14 日（金） 2025 年 5 月 27日（火）~ 5 月 28 日（水） 2025 年 8 月 27日（水）~ 8 月 28 日（木） 2025 年 10 月 23日（木）~ 10 月 24 日（金） 参加費 無料 参加登録ページ Coming Soon 2024 年の JumpStartは、新卒 1 年目向けとそれ以外の初学者向けで開催回を分けておりましたが、2025 年は同一イベントとして開催させていただきます。ついていけるか心配という新卒の方もいるかもしれませんが、グループワークはできるだけ近い属性の方と組んでいただけるように計画しております。両参加者にとって今まで以上にスキルアップを実感いただけるような枠組みを目指していきます！ 参加登録方法については、2025 年 1 – 2 月を目処にお知らせいたします。 こちらのブログ内にてアップデートさせていただきますので今しばらくお待ちください。AWS JumpStart 2025 も多くの方々のご参加を心よりお待ちしております！ 事前学習コンテンツ 一方で、AWS を学習するのは初めてで、イベントでついていけるか不安という方もいるかと思います。AWS JumpStart ではイベント開始前に無料の事前学習コンテンツを配布しており、参加者のレベル感の統一を図っております。 本イベントに申し込まれた方に別途ご連絡いたしますが、「早めに内容を確認したい」といった熱心なご意見をしばしばいただくため、以下に事前コンテンツの一例を掲載いたします。 Cloud for Beginners モジュール 0&1（ 動画 ） クラウドの前提となる、Web サービスの基礎や IT 基礎について解説している 40 分ほどの動画です。 AWS Technical Essentials（ URL ） クラウドを初めて学ぶ技術者に向けた、AWS の基本的な概念を包括的に学習できる 4 時間ほどのコンテンツです。 別途 AWS Builder ID アカウントを作成する必要があります。 2024 年開催の様子 AWS JumpStart 2024 も全 2 日、オンラインにて開催しました。受動的な講義コンテンツだけではなく、能動的に皆さんに手を動かしていただけるようなイベントを目指しました。 1 日目 1 日目は、講義形式の座学と実際に手を動かすハンズオンを交互に実施し、知識定着を図りました。座学では事前学習コンテンツの振り返りに加えて、実際に AWS でシステムを構築する際にアーキテクチャで気にするポイントについて解説しました。ハンズオンでは実際に仮想サーバーを起動していただく基礎的な内容からスタートし、最終的に簡単な Web アプリを動かすまでを目指しました。 2 日目における最終成果物 2 日目は、1 日目に学習した内容を踏まえて、実際に AWS アーキテクチャを設計いただきました。とある事業を立ち上げる会社の新入社員として、どのようなアーキテクチャを実装するべきか要件と照らし合わせながら検討しました。ワークは初め個人で検討したのち、5 名前後のチームで議論しました。 2024 年は最終的に以下のようなアーキテクチャ図が作成されました。このイベントを通して、AWS のアーキテクチャ図を読み書きできるようになるのが 1 つの目標です。 参加者からの感想 参加者の皆様からは大変ありがたいことにさまざまなポジティブな感想をいただきました。 自分たちの疑問に思うであろう点をあらかじめ説明してくれ、内容が耳にスッと入ってきた。このプログラムを通じて資格の取得に励んでいきたい。 2日間を通して、AWSのサービスについて少しですが理解することが出来ました。そして、自分の理解の足りなさが分かったので、それぞれのサービスの特徴や他のサービスとの関連などについて勉強をしたいと思いました。 事前学習を含めるとかなり多い時間のオンラインセミナーだったが終始楽しく、眠くなることもなく参加できてよかった。ありがとうございました。 今回で 4 年目の開催となりますが、新卒研修として取り組んでくださっている会社も増えてきております。新卒 1 年目のエンジニア、そして AWS 初学者のエンジニアの方にぜひ受講いただきたい内容を目指しております。 まとめ AWS JumpStart では、事前学習からハンズオン、チームでの検討と発表までのワークショップを通して、AWS の理解とアーキテクチャ設計力を向上できるプログラムを 2 日間のワークショップ形式で用意しています。 運営メンバー一同、より良い内容での JumpStart 2025 をお届けするべく準備を進めておりますので、是非とも参加ご検討ください。

こんにちは。ソリューションアーキテクトの徳永です。2024 年 11 月 15 日に「生成 AI が切り拓く、 今後のエンジニアリング環境」というというテーマで、セミナーをオンラインにて開催いたしました。本ブログでは、イベント内容を簡単にご紹介しつつ、アセット資料を紹介致します。このセミナーでは、生成 AI を活用して実際にエンジニアリング環境の改善を進めている3 社様の先進的な取り組みをご紹介させて頂きました。 リポジトリをまるごと AI でレビューする LongContext モデルを利用したレビューシステムの紹介 合同会社 EXNOA 技術統括本部 技術推進部 高嶋 俊作 様 技術統括本部 情報管理室 小野寺 崇 様 【 資料 】 【 動画 】 EXNOA 様には、 LongContext モデルを活用してソースコードを含むプロジェクトの改善提案を自動生成する取り組みについてご紹介頂きました。ソースコードを ZIP ファイルとして固めてアップロードすると、LLM が選択したレビュー観点に従って、どのファイルに、どのような問題があり、どのように改善すればよいのかをマークダウン形式でフィードバックしてくれます。また、改善のためのコードまで提案されていました。有効な改善提案まで AI が判定して出力するという形になっており、実践的な内容となっていました。例では、 JSON のデコードに関するエラー処理が不足しているなど、見落としやすい箇所に関しての指摘がなされていました。実際にすでに現場でのレビューに利用されており、レビューの初期コストの削減とレビューの精度向上に寄与しています。 LLM は Claude 3.5 Sonnet をメインとし、Gemini 1.5 Pro をサブとして採用されたとのことです。 AWS を採用した理由としては、すでに AWS を利用していたためノウハウがあったことが大きいとのことです。 コードレビューはひとつのプロンプトで行うのではなく、多段構成でレビューを実施していました。最初にレビューファイルのパスを展開し、レビュー対象に対して、レビュー観点ごとに調整したプロンプトを投げる形でレビューをする形です。プロンプトは英語で構成することで精度を高めている点や、 API による呼び出しに対して Exponential Backoff によるリトライ処理を行っている点など、 LLM を扱う上での工夫がみられました。 ペアーズにおける Amazon Bedrock を活用した障害対応支援生成 AI ツールの導入事例 株式会社エウレカ MLOps Engineer 成川 聖 様 【 資料 】 【 動画 】 エウレカ様での障害対応プロセスで LLM を使ったチャットボットを構築した事例をご紹介いただきました。 エウレカ様では、障害対応における属人性の高さや業務の複雑性など様々な課題を軽減するために障害対応報告の自動生成機能を開発されました。エウレカ様では、これまでも ChatOps による障害対応の円滑化を図られてきましたが、さらにコマンド操作だけで障害の内容を要約し、報告書やポストモーテムとしてまとめられるように拡張されています。 この機能は Amazon Bedrock と Claude 3.5 Sonnet を使って実現されており、Amazon Elastic Kubernetes Service (EKS) との統合や、Knowledge Bases for Amazon Bedrock などによる Managed RAG 機能が利用できることが採用理由として挙げられていました。 また、障害対応時に専用の Slack チャンネルを作成してコミュニケーションを集約させており、チャンネル作成時に自動的に Pairs Navi という Chat Bot が参加します。エウレカ様では Knowledge Bases for Amazon Bedrock を活用し 1,500 ページ以上のドキュメントから RAG を構築しており、対応メンバーは Pairs Navi を介して障害対応プロセスをキャッチアップすることができます。 実際に導入してみると、障害対応そのものよりもオンボーディングで利用される割合のほうが高いこと、緊急性の高い業務の中でわざわざ Chat Bot をメンションすることに敷居があることなどが分かったため、より自律的に振る舞う Agent 型への改良を進められているそうです。 生成 AI ソリューションとサイバーエージェントの変化 サイバーエージェント様 System Security 推進 Group (SSG) 開発チーム マネージャ 小笠原 清志 様 【 資料 】 【 動画 】 サイバーエージェント様では AI を活用し様々な生産性の改善に取り組まれており、今回はセキュリティにおける生成 AI 活用事例を紹介していただきました。まず紹介していただいたのが、サイバーエージェントのすべての社員が利用できる、セキュリティ相談ができるチャットツールです。プライバシーやセキュリティを意識した設計となっており、 AI により、いままでよりも気軽にセキュリティの相談ができるようになりました。過去に起票された社内のセキュリティチケットを参照しているため、社内の事情に精通した回答を返すことが可能になっております。ただの RAG アプリケーションではなく、専門性の高いエージェントを複数用意しており、個人情報の相談ができるエージェントなど、ユースケースに沿った形で使えるようになっています。課題解決までのリードタイムが短縮され、社内でも活用が進んでいます。 この取り組みは、サイバーエージェント様の Developers Blog – 生成AIでセキュリティの課題をどこまで改善できるか考える でも紹介されています。あわせてご参照ください。 また、生成 AI を使える人から、生成 AI アプリを作れる人へとステップアップをしてもらうという目的で、 Dify の環境を構築している事例を紹介していただきました。この事例に関しては builders.flash にて詳しく紹介されております。エンジニア不要な業務改善を狙っているとのことでした。 クロージング | 生成 AI が切り拓く、今後のエンジニアリング環境 アマゾンウェブサービス ジャパン 合同会社 ソリューションアーキテクト 徳永 貴大 【 資料 】 【 動画 】 最後に、クロージングとしてソリューションアーキテクトの徳永から Amazon Q Developer と Failure Analysis Assistant の紹介をさせていただきました。Amazon Q Developer ではソフトウェア開発ライフサイクル全般を統合支援するサービスです。コードの推薦や、セキュリティの問題のある箇所をスキャンして、改善提案を受けることができます。 Failure Analysis Assistant は障害対応時のログ解析を LLM にさせて一次対応をさせるためのサンプル実装です。 Slack 上でアラートを受信したのちに、 Slack 上に表示されるフォームに必要な情報をいれることで、自動的にログを収集し、 Bedrock の API を通じて LLM による解析処理を行った後に、障害の原因の分析結果を Slack 上で受け取ることができます。AWS Blog Failure Analysis Assistant – AIOps で障害分析を効率化してみよう – と aws-samples のリポジトリから詳しい情報をご覧いただけますのでご活用ください。 おわりに 本ブログでは 2024 年 11 月 15 日に開催された「 生成 AI が切り拓く、 今後のエンジニアリング環境 」の内容をご紹介させていただきました。本セミナーに参加いただいた皆さま、誠にありがとうございました。引き続き皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログはソリューションアーキテクト徳永が担当しました。 (Updated : 2024/12/04 日本時間) 12/4 の AWS re:Invent 2024 の Matt Garman の基調講演で、徳永のセッションでご紹介した Amazon Q Developer に関連する下記のアップデートが出ました。ぜひそれぞれの解説ブログもご参照ください。 New Amazon Q Developer agent capabilities include generating documentation, code reviews, and unit tests Investigate and remediate operational issues with Amazon Q Developer (in preview) Announcing Amazon Q Developer transformation capabilities for .NET, mainframe, and VMware workloads (preview) Introducing GitLab Duo with Amazon Q

本日、AWS は Invoice Configuration を発表しました。これにより、お客様固有のビジネスニーズに合わせて請求書をカスタマイズできます。Invoice Configuration を使用すると、同じ AWS Organization に属する子会社、コストセンター、法人、部署などの各事業体に属するメンバーアカウントについて、別々の AWS 請求書を受け取ることができます。 Invoice Configuration により、事業体レベルで AWS の料金を分割したり、別の “請求書の受取人” (Invoice Receiver) を指定したり、各事業体に属するメンバーアカウントごとに個別の請求書を受け取ったりすることができます。これにより、AWS 請求書をより迅速に処理できるようになるだけでなく、各事業体の資金を個別に追跡できるようにしたり、事業体全体で実施される独自の FinOps プロセスにあわせて AWS 請求書をカスタマイズしたりできるようになります。 AWS のディスカウントを最大化しつつ、費用と時間のかかる請求書の分割を軽減する 一括請求 が有効になっている AWS Organization をお持ちの場合、お客様は単一の AWS Organization 内の全メンバーアカウントの使用量に対する AWS 請求書を受け取ります。複数の事業体を持つお客様からは、AWS 請求書を管理するためには、事業体ごとに別々の AWS Organization を作成してそれぞれの使用量に対して個別の請求書を受け取るようにするか、請求書の料金を手動で分割して指定された事業体に割り当てるようにする必要がある、という話をよく伺うことがありました。別々の AWS Organization を作成するとボリュームディスカウントを受けられなくなりますが、(1 つの Organization に複数の事業体を収容すると) 料金の手動分割には時間がかかり AWS 請求書の処理のオーバーヘッドも増加します。Invoice Configuration を使用し、各事業体に属するメンバーアカウントのグループを管理して事業体ごとに個別の AWS 請求書を受け取るようにすることにより、AWS 請求書の処理を簡素化することができます。 ここでは、ある企業が AWS アカウントを様々な事業体にマッピングするという独自の要件を抱えているシナリオについて順を追って説明します。最初に Invoice Configuration UI を使って、事業体に属するメンバーアカウントを請求ユニット (Invoice Unit) に割り当てます。最後に、同じ操作をプログラムで行う方法についても説明します。 AWS Invoice Configuration のカスタマイズ 各事業体に属するメンバーアカウントの請求ユニットを 3 つのステップで作成することで、Invoice Configuration のカスタマイズを開始できます。まず、請求ユニットを作成して名前を付けます。次に、請求書の受取人となるアカウントである “請求書の受取人 (Invoice Receiver)” を割り当てます。どのメンバーアカウントをその請求ユニットに含めるかを選択できます。最後に、請求ユニットを作成したら、オプションで発注書 (Purchase Order) を 1 つ以上の請求ユニットに関連付けることができます。発注書を請求ユニットに関連付けることで、各事業体の資金を個別に追跡できるようになります。Invoice Configuration は、 ここ に記載されている SDK もサポートしています。また、 AWS CloudFormation を使ってリソースをデプロイし請求ユニットをプロビジョニングすることもできます。 シナリオ このシナリオでは、事業体の構造は AWS アカウント (A, B, C) で表される 3 つのコストセンターで構成されており、AWS Organization には管理アカウント (M) があります。その他に、アカウント (C) と同じコストセンター内にアカウント (D) とアカウント (E) の 2 つのアカウントがあります。組織の要件は、コストセンター (C) に対する請求書を別途受け取ることです。その請求書はアカウント (C), (D), (E) の使用量と共にアカウント (C) 宛に送付される必要があります。Invoice Configuration が登場するまでは、管理アカウント (M) がこの Organization 内のすべてのアカウントについての一括請求書を受け取っていました。しかし、請求ユニットを使うと、管理アカウント (M) は各コストセンターに対応する個別の請求書を受け取ることができます。各請求書には、その請求ユニットに含まれるアカウントに対する請求のみが含まれます。 図 1. AWS Organization 内の多層ビジネス構造の図 はじめに Invoice Configuration は、管理アカウントレベルで使用できる機能です。はじめに、すべてのアカウントに正しい税金設定が行われていることを確認してください。これを確認するには、“請求とコスト管理” コンソールにログインして “税金設定 (Tax Settings)“ を選択します。ここで、アカウントに正しい事業法人名、住所、納税登録情報が設定されていることを確認する必要があります。この例では、すべてのアカウントの税金設定が同じである想定としています。 注: AWS が納税情報を収集しない管轄区域については、支払い設定で正しい請求先住所と請求連絡先が設定されていることを確認してください。AWS は、お客様の所在地に基づいて AWS 請求書の税金を計算します。税金の計算方法の詳細については https://aws.amazon.com/tax-help/location/ をご覧ください。 ステップ 1：請求ユニットの作成 左側のナビゲーションバーで “請求書設定 (Invoice Configuration)” を選択します。コストセンター (C) およびコストセンター (C) 内アカウントの請求書を個別に受け取るには、 こちら の手順を参照してください。このシナリオでは、アカウント (C) を “請求書の受取人 (Invoice Receiver)” として指定します。アカウント (C) を “請求書の受取人” として選択すると、アカウント (C) は請求ユニットに関する請求書を受け取ります。請求書を分割する必要があるもののその配信先を管理アカウント (M) のままにしたい場合は、オプションで管理アカウントを “請求書の受取人” として選択することができます。アカウント (C), (D), (E) をこの請求ユニットのメンバーとします。 アカウント (A) とアカウント (B) が別々の請求書を受け取る必要がある場合には、オプションでそれらに対応する請求ユニットを設定することができます。アカウント (A) もしくはアカウント (B) に対する請求ユニットを設定しない場合、それらのアカウントに対する使用量は従来と同じ動作 (つまり、両方とも (SOR ごとに) 単一の請求書に統合され管理アカウント (M) に発行される) に従うことになります。 注: 管理アカウント (M) に使用量がない場合、AWS がこの請求書を受け取るアカウントを選択します。 図 2. コストセンター C の請求ユニットが設定された、更新済みのビジネス構造 ステップ 2：請求ユニットの更新 組織の変更があり、アカウント (B) がアカウント (D) および (E) と共にコストセンター (C) にマッピングされたものとします。 図 3. “コストセンター C とアカウント B“ の請求ユニットが設定された、更新済みのビジネス構造 AWS 請求書へのこの変更の反映は、前のステップで作成した請求ユニットを更新してアカウント (B) をその請求ユニットに追加するだけで行えます。請求ユニットの更新については こちら のドキュメントを参照してください。 注: 請求ユニットの変更は月内のいつでも行うことができます。例えば、月額請求書では、アカウント (B) がコストセンター (C) の請求ユニットへその月の 15 日に追加された場合、そのアカウントに対応する月全体の使用量が請求ユニットのアニバーサリー請求書に含まれる形となります。 ステップ 3：発注書 (PO) と請求ユニットの関連付け Invoice Configuration が登場するまでは、発注書を管理アカウントに関連付けることしかできませんでした。Invoice Configuration を使うと、PO を各請求ユニットに関連付けることができます。組織で事業体ごとに個別の資金調達プロセスがあり、その資金調達にかかるコストを追跡したいのであれば、請求ユニットを作成してその事業体の個別の請求書を受け取り、その請求ユニットに対して PO を割り当てるだけでそれを行うことができます。詳細な手順については 発注書のドキュメント を参照してください。 ステップ 4：請求書の取得 請求ユニットに対応する請求書には、請求コンソールの “請求書 (Bills)” ページからアクセスできます。請求書は管理アカウントおよび “請求書の受取人” アカウントのメールアドレスにも電子メールで送信されます。 請求ユニットのプログラムによる管理 事業体全体で数十もしくは数百のアカウントを作成・管理されていることもあるかもしれません。このユースケースでは、Invoice Configuration API を使い、プログラムで事業体を請求ユニットにマッピングしたり、請求ユニット内のアカウントの追加や更新を管理したりできます。Invoice Configuration API は AWS CLI、AWS SDK、AWS CloudFormation をサポートしています。開始するには、 API リファレンス をご覧ください。新しいアカウントを作成するときに、既に作成済みの請求ユニットにそれらのアカウントをプログラムから追加したり、事業体用の新しい請求ユニットをプログラムから作成したりできます。 まとめ Invoice Configuration は、各事業体に属するメンバーアカウントの AWS 請求書をカスタマイズしたり、事業体に対応する AWS 請求書ごとに個別の受取人や発注書を追加したりすることのできる機能です。この機能により、ボリュームディスカウントを最大化しながら、個別の AWS 請求書を受け取ることができます。Invoice Configuration を AWS 請求とコスト管理コンソール、もしくはプログラムから使用し、請求ユニットを作成・管理したり、事業体ごとに個別の請求書を受け取ったりすることができます。 TAGS: invoices Vinni Satija Sagar Vinni Satija は AWS AppConfig のプロダクトマネージャーで、ワシントン D.C. を拠点としています。彼女はお客様に対して “working backward” なアプローチをとることに情熱を注いでいます。彼女はテクノロジーを使ってお客様のニーズに応えるソリューションを作ることを楽しんでいます。 Micah Bowonthamachakr Micah は AWS Invoicing のソフトウェア開発エンジニアで、顧客体験を直接革新するための新機能の設計や実用的なソリューションの構築に注力しています。Micah は熱心なボディビルダーであり、神学や哲学の本を読むことを楽しみ、次の釣りやキャンプ旅行にいつもワクワクしています。 Nitin Nair Nitin は AWS Billing のソフトウェア開発マネージャーです。彼は顧客体験を活用してお客様がビジネス目標を達成できるよう支援する製品の構築に熱心に取り組んでいます。余暇には料理科学の探求や音楽制作を楽しんでいます。 Vijay Nattanmai Viswanathan Vijay は AWS Invoicing のソフトウェア開発エンジニアで、世界中の何百万もの AWS のお客様のための直感的な請求ソリューションの作成に注力しています。Vijay は平日はクラウドで過ごし、週末には岩壁を登ったり、街で一番おいしいものを探したり、かわいい子猫の面倒を見たり、お気に入りのビデオゲームで戦ったりしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

急速に変化する消費財業界では、ブランドは顧客の関心を正確に捉え、維持する必要があります。AWS と Amazon Ads を使用することで、ブランドはカスタマーエクスペリエンスをカスタマイズし、オーディエンスを的確にターゲットし、サードパーティパートナーと安全にコラボレーションできます。このブログでは、これらのツールがどのように具体的な成果をもたらすかを紹介します。 利益を生むカスタマイズされた顧客体験を提供 今の顧客は、関連性が高くて、カスタマイズされた体験を提供する信頼できるブランドを求めています。さらに、パーソナライズされた体験も求めています。AWS と Amazon Ads は、企業がリアルタイムでデータ主導のインサイトを統合し、大規模なパーソナライズを可能にします。 ブランドは、ファーストパーティおよびサードパーティーのデータを使用して、行動、好み、購入履歴に基づいてオーディエンスをセグメンテーションできます。これらのインサイトにより、パーソナライズされた製品レコメンデーションやエクスペリエンスを提供し、顧客エンゲージメントを高めて、コンバージョンを促進できます。 パーソナライゼーションは単なる流行語ではありません。コンバージョン率の向上と顧客との長期的な関係につながります。ブランドはカスタマイズされた体験に投資することで、顧客とより強固なつながりを築き、ブランドロイヤルティとライフタイムバリューを生み出します。 ターゲットオーディエンスへの直接アプローチ 広告のパフォーマンスを最大化するためには、ハイパーターゲティングが重要です。広告主は Amazon Ads を使用して、オーディエンスを簡単にハイパーセグメント化し、正確に広告を配信できます。このセグメンテーションは、ブランドが特定の消費者行動、地域、または人口統計学的プロファイルをターゲットにするのに役立ちます。 たとえば、スキンケアブランドでは、最近美容製品を閲覧したユーザーや、同様のカテゴリで購入したユーザーに広告を表示できます。このアプローチにより、すべての広告がターゲットオーディエンスに関連したものになり、クリックスルー率とキャンペーン全体の成功率が向上します。 顧客は理解されていると感じたときに積極的に反応するため、パーソナライズされたメッセージはよい結果につながります。 高度な顧客プロファイリングで先を行く 顧客プロファイルは、基本的な人口統計を超えて進化しています。Amazon Kinesis、Amazon Simple Storage Service (Amazon S3)、AWS Glue、Amazon SageMaker などのサービスで Amazon Ads のデータを使用することにより、ブランドはトランザクションデータ、行動データ、サイコグラフィックデータに基づいて機械学習を使用して包括的な顧客プロファイルを構築できます。 購入傾向などの特定の顧客行動を予測することで、ブランドはより関連性の高い広告やコンテンツを配信し、エンゲージメントとコンバージョンを増やすことができます。高度なプロファイリングにより、広告主は予算をより効率的に配分し、適切なメッセージを適切な人に適切なタイミングで確実に届けることができます。ブランドは、各オーディエンスの固有のニーズと共鳴する関連性の高いキャンペーンを作成することで、競争力を維持できます。 Amazon Marketing Cloud と AWS Clean Rooms で安全にコラボレーション 顧客データをエンリッチするにはサードパーティとのコラボレーションが不可欠ですが、プライバシー保護の問題も伴います。Amazon Marketing Cloud (AMC) と AWS Clean Rooms は、プライバシーを侵害しない安全なデータ共有環境を提供します。 AWS Clean Rooms はプライバシーポリシーに準拠したコラボレーションを可能にし、データが安全に処理され、匿名化されることに役立ちます。この匿名化は、ブランドが顧客プロファイルを強化するためにデータプロバイダーと頻繁に提携する消費財広告において特に重要です。AMC は、厳格なデータプライバシー基準を維持しながら高度な分析を可能にします。これにより、広告主は顧客の信頼を維持しながらパートナーシップの価値を最大化できます。 プラットフォーム間の広告キャンペーンを簡単に調整 複数のチャネルで連携されたキャンペーンを実施することは困難です。AWS は、業務を合理化し、一貫したメッセージを提供することで、ブランドの取り組みを最大化できるように支援します。Amazon Ads はクロスプラットフォームのキャンペーン管理ツールを提供し、AWS はマーケティングツールを統合してシームレスなデータ共有を促進します。 キャンペーンの調整は、グローバルブランドにとって特に重要です。AWS と Amazon Ads は、メッセージングが地域間で一貫性を保ち、世界中で統一されたブランド体験を提供できるようにしています。 Amazon Bedrock で生成 AI の可能性を解き放つ 生成 AI は広告制作を変革しつつあり、Amazon Bedrock はその最前線に立っています。広告主は生成 AI を使用して、個々の消費者の共感を呼ぶ動的でパーソナライズされた広告を作成できます。AI を活用した広告をさまざまなセグメントに合わせてカスタマイズできるため、時間を節約しながら大規模に関連性を確保できます。また、Amazon Bedrock の多様な大規模言語モデルを使用することで、ブランドはリアルタイムの顧客インタラクションに適応する高品質で魅力的な広告を制作し、コンバージョン率を向上させることができます。 広告の新たな高みを目指す準備はできていますか？ 広告環境が進化するにつれて、消費財ブランドは競争力を維持するために高度なテクノロジーを採用する必要があります。AWS と Amazon Ads は、パーソナライズされた、ハイパーターゲティングを絞ったキャンペーンの実施を可能とし、実際の成果を上げるための強力なツールを提供しています。 次の方法でブランドの新しい可能性を解き放ちます。 2024 年 12 月 4 日午前 11 時 30 分から午後 12 時 30 分 (太平洋標準時) に開催される re:Invent で開催される AWS チョークトーク RCG 302: Boost consumer goods advertising performance with AWS and Amazon への参加 re:Invent の AWS ブースの訪問 NRF 2025: Retail’s Big Show (1 月 12 日から 14 日)の AWS ブース #5438 でのデモの視聴 著者について Wilson Thankachan Wilson Thankachan 氏 は、サプライチェーンのバックグラウンドを持つ AWS のグローバル CPG パートナーソリューションアーキテクトです。彼は 消費財の顧客のニーズに応えるために、AWS のパートナーと協力して、提供するサービスを技術的に検証し、ガイダンスを提供しています。 Prashant Yadav Prashant Yadav 氏は、アマゾンウェブサービス (AWS) の AdTech、MarTech、生成 AIを専門とするシニア PSA です。認定ソリューションアーキテクト、生成 AI プラクティショナー、MBA 卒業生として、Prashant氏 は、技術的な専門知識とビジネス感覚を独自に融合させた職務を遂行しています。彼は、スケーラブルで回復力があり、費用対効果の高いソリューションの構築に長けており、ビジネスの成功を促進する影響力の大きい結果を一貫して提供しています。 このブログの翻訳はソリューションアーキテクトのシャルノ ミカエルが担当しました。原文は「 Boost Engagement with AWS and Amazon Ads 」です。

図1. AWS は IT 運用を変革できる新しい機能をリリース re:Invent 2024 で Nandini Ramani (VP Search Observability & Cloud Ops) により、AWS がクラウド運用 (Cloud Operations) の未来をどのように作っていくのかをお見せしました。このブログ記事の 3 つのセクションでは、クラウドオペレーションをより俊敏で効率的、そして安全なものに変革するための主要な AWS のクラウド運用関連の発表を取り上げています。これらの機能により、1/ クラウドガバナンスの変革、2/ インフラストラクチャ、アプリケーション、ネットワーク、データベース、コンテナの観測の変革、3/ 観測したものの分析の変革が可能になります。 1. クラウドガバナンスの変革 クラウド運用を変革するには、適切なツールとガバナンスフレームワークを選択して始める必要があります。これらのツールにより、一貫した可視性を確保し、望ましくない非準拠アクションを防ぐことができます。さらに、簡単かつスケーラブルに統制を適用できるため、設定の逸脱を防止し、セキュリティとコンプライアンスを改善できます。 Node management experience in AWS Systems Manager AWS Systems Manager のノード管理体験が新しくなり、ノード管理の簡素化によって運用を効率化できるようになりました。EC2 インスタンス、ハイブリッド、マルチクラウド環境で実行されているサーバーなど、あらゆる場所で実行されているノードを簡単に管理できます。包括的で集中管理されたビューから、大規模なノード管理が可能になり、管理されていないノードを特定、診断、修復することもできます。また、Systems Manager は Amazon Q Developer と統合されたため、AWS コンソールのどこからでもノードの状況を確認し、制御できるようになりました。 図 2. AWS Systems Manager での新しいノード管理体験 Resource control policies AWS Organizations のリソースコントロールポリシー (RCP) は、AWS 環境全体でデータ境界を中央集権的に構築することができる予防的コントロールです。RCP を使用すると、AWS リソースへの外部からのアクセスを大規模かつ中央集権的に制限できます。例えば、RCP を使用すると、「組織外のプリンシパルが組織内の Amazon S3 バケットにアクセスできない」という要件を実現できます。これは、個々のバケットポリシーで付与された権限に関係なく適用されます。RCP は、既に存在する組織ポリシーの実現の手段の 1 つであるサービスコントロールポリシー (SCP) を補完します。SCP では、組織内の IAM ロールとユーザーが持つ権限の範囲を中央集権的に制御できますが、RCP では、組織内の AWS リソースが持つ権限の範囲を中央集権的に制御できます。AWS Control Tower を使用して、 RCP ベースの構成可能なマネージドコントロール をデプロイできます。 Declarative Policies 宣言的ポリシー (Declarative Policy) は、AWS Organizations の新しい予防的コントロールです。このポリシーで、組織内の AWS サービスのベースライン構成などをお客様が簡単かつ継続的に実施できるようになります。宣言的ポリシーは、ポリシーに準拠していない操作を防ぐように設計されています。例えば、お客様は宣言的ポリシーを使用して、特定のプロバイダーが提供する AMI を使用したインスタンスの起動のみを許可するように EC2 を設定することや、組織全体で VPC でのパブリックアクセスをブロックすることが可能となります。宣言的ポリシーで定義された設定は、サービスが新しい API や機能を追加したり、お客様が組織に新しいプリンシパルやアカウントを追加した場合でも維持されます。現在、宣言的ポリシーは EC2、EBS、VPC の設定をサポートしています。また、 AWS Control Tower での宣言的ポリシーを使用して実装されたマネージドコントロールを発表しました 。 Enhanced event selectors on AWS CloudTrail Lake アクティビティログや AWS Config の設定項目をキャプチャ、イミュータブルに保存、アクセス、分析するのに役立つマネージドデータレイクである AWS CloudTrail Lake のイベントフィルタリングを強化しました。強化されたイベントフィルタリングは、既存のフィルタリング機能を拡張し、CloudTrail イベントがイベントデータストアに取り込まれるかどうかをより細かく制御できるようになりました。この強化により、セキュリティ、コンプライアンス、運用における調査の効率と精度が向上し、コストを削減できます。 Centralized resource context and quick actions in AWS Resource Explorer AWS Resource Explorer で、AWS サービスからのリソースの分析とプロパティを集約する新しいコンソール体験をリリースしました。これにより、キーワードベースの検索で AWS リソースを簡単に検索し、関連するリソースプロパティを表示し、リソースを確実に管理するためのアクションを実行できる単一のコンソール体験が提供されます。AWS Cost Explorer によるリソースレベルのコスト、AWS Security Hub の検出結果、AWS Config のコンプライアンスと設定履歴、AWS CloudTrail によるイベント履歴、および接続されたリソースを可視化する関係グラフを確認できるようになりました。 2. 観測の変革 スケーラブルかつ効率的な運用のためには、オブザーバビリティ (可観測性) がビジネス上の重要課題です。迅速に意思決定を行い、問題の根本原因を特定し、より効率的に運用するためには、可視性が必要です。AWSは、アプリケーション、インフラストラクチャ、ネットワーク、データベース、コンテナを観測するための新機能を発表しました。主な内容は以下のとおりです。 Amazon CloudWatch adds context to observability data in service console, accelerating analysis Amazon CloudWatch は、オブザーバビリティデータにコンテキストを追加し、ITオペレーター、アプリケーション開発者、サイト信頼性エンジニア (SRE) が関連するテレメトリ間を簡単に移動し、リソース間の関係を視覚化し、分析を加速することができるようになりました。この新機能は、さまざまなメトリクスとログからほぼリアルタイムの洞察を獲得し、問題の根本原因をより早く特定し、運用効率を向上させます。この機能により、Amazon CloudWatch は自動的にオブザーバビリティデータと関連する AWS リソース (Amazon EC2 インスタンスや AWS Lambda 関数など) の関係を視覚化します。 図3. Amazon CloudWatch は、サービスコンソールでオブザーバビリティデータにコンテキストを追加 Amazon CloudWatch adds network performance monitoring for AWS workloads using flow monitors Amazon CloudWatch Network Monitoring では、フローモニターを使用して、AWS ワークロードのネットワークパフォーマンスを監視できるようになりました。この新機能により、Amazon EC2 や Amazon EKS などのコンピュートインスタンスと、Amazon S3、Amazon RDS、Amazon DynamoDB などの AWS サービス間のワークロードのネットワークパフォーマンスをリアルタイムに可視化できるため、ワークロードのネットワーク障害を迅速に検出して特定できます。CloudWatch Network Monitoring は、フローモニターによって、AWSワークロードのTCPベースのパケットロスやレイテンシ、ネットワーク正常性といったメトリクスを提供し、問題の根本原因を迅速に特定できるようにサポートします。 Amazon CloudWatch Database Insights for Amazon Aurora Amazon Aurora PostgreSQL および Amazon Aurora MySQL をサポートする Amazon CloudWatch Database Insights を発表しました。Database Insights は、DevOps エンジニア、アプリケーション開発者、データベース管理者 (DBA) がデータベーストラブルシューティングを迅速に行い、データベース群の全体的な健全性を把握できるように設計されたデータベースオブザーバビリティソリューションです。Database Insights は、アプリケーション、データベース、およびそれらが実行されているオペレーティングシステムからログとメトリクスを統合し、コンソールに統一されたビューを提供します。 Amazon CloudWatch Container Insights launches enhanced observability for Amazon ECS Amazon CloudWatch Container Insights は、Amazon EC2 および Amazon Fargate で実行される Amazon Elastic Container Service (ECS) のオブザーバビリティを強化し、クラスターレベルからコンテナレベルまで詳細なメトリクスを追加設定なしで提供することで、問題の特定とトラブルシューティングを迅速化します。強化されたオブザーバビリティにより、お客様は様々なコンテナレイヤーを視覚的に掘り下げて確認し、個々のコンテナにおけるメモリリークなどの問題を直接特定できるため、平均修復時間を短縮できます。 Amazon CloudWatch launches observability solutions for AWS services and workloads on AWS オブザーバビリティソリューションは、AWS でのインフラストラクチャとアプリケーションの監視を迅速に開始するのに役立ちます。オブザーバビリティソリューションを使用すると、Java 仮想マシン (JVM)、Apache Kafka、Apache Tomcat、または NGINX などの一般的なワークロードと AWS サービスに焦点を当てたオブザーバビリティガイダンスを提供するソリューションのカタログから選択できます。ソリューションには、Amazon CloudWatch エージェントのインストールと設定、事前定義されたカスタムダッシュボードの展開、メトリックアラームの設定などの監視タスクが含まれています。 AWS Fault Injection Service now generates experiments reports AWS Fault Injection Service (AWS FIS) は、実験レポートを生成するようになり、これによってレジリエンステストのエビデンスを作成する時間と労力を削減します。レポートでは、実験アクションの要約と、お客様が作成した Amazon CloudWatch ダッシュボードからのアプリケーション応答がキャプチャされます。AWS FIS を使用すると、障害復旧とフェイルオーバーテストの訓練時に現実にあるような障害状況を作り出す障害挿入の実験を行えます。 3. 分析の変革 生の運用データから性能の問題や根本原因を特定するのは時間がかかることがあります。すべての生データを保存するためのスケーラビリティ、データをインデックス化して分析するためのクエリエンジン、さまざまなシステム間でデータをコピーする必要がないことが必要です。以下をお読みいただき、AWS が Amazon CloudWatch と Amazon OpenSearch Search の新機能、ゼロ ETL 統合によって、検索と分析体験をどのように改善しているかをご覧いただくことで、オブザーバビリティと分析を強化するためにベストな AWS ソリューションが選択できるようになります。 Amazon CloudWatch Application Signals with complete visibility into application transaction spans CloudWatch Application Signals における強化された検索と分析の体験をリリースしました。この機能により、開発者とオンコールエンジニアは、アプリケーショントランザクションスパン (application transaction span = ユーザーとさまざまなアプリケーションコンポーネント間の詳細な相互作用を記録した、分散トレースの構成要素) に対する完全な可視性を獲得できます。開発者は、インタラクティブなビジュアルエディタと Logs Insights クエリの強化を通じて、アプリケーションのパフォーマンスやエンドユーザーへの影響に関するあらゆる質問に答えることができます。CloudWatch Logs は、データマスキング、サブスクリプションフィルタを介した転送、メトリック抽出など、トランザクションスパンに対する高度な機能を提供します。 Amazon OpenSearch Service zero-ETL integration with Amazon CloudWatch 私たちは Amazon CloudWatch と Amazon OpenSearch Service の最高の体験を提供するため、両サービスの統合された新しい分析体験とゼロ ETL 統合を発表しました。CloudWatch のお客様は、OpenSearch の Piped Processing Language (PPL) および OpenSearch SQL を活用できるようになりました。さらに、CloudWatch のお客様は、Amazon Virtual Private Cloud (VPC)、AWS CloudTrail、AWS Web Application Firewall (WAF) などの Vended Log 用の事前構成済みダッシュボードを使用して、トラブルシューティングを加速できるようになりました。OpenSearch のお客様は、データを複製する必要なく、CloudWatch Logs を分析できるようになりました。 Amazon OpenSearch Service zero-ETL integration with Amazon Security Lake Amazon OpenSearch Service が、Amazon Security Lake とのゼロ ETL 統合を提供するようになり、OpenSearch を介して直接セキュリティデータをクエリ分析できるようになりました。この統合により、従来は分析コストが高額になりがちだった大量のデータソースを効率的に調査できるようになり、セキュリティ調査を合理化し、セキュリティ環境の包括的な可視性を得ることができます。データを選択的に取り込むことができ、複雑なデータパイプラインを管理する必要がなくなったため、効果的なセキュリティオペレーションに集中しながら、分析コストを削減できる可能性があります。 Next-gen Amazon OpenSearch Service UI for enhanced data exploration and collaboration Amazon OpenSearch Service はモダンな運用分析エクスペリエンスを提供開始しました。これによってマネージドドメインとサーバーレスコレクションにまたがるデータの洞察を一つのエンドポイントから得ることができます。新しい OpenSearch 分析エクスペリエンスは、Observability、Security Analytics、Essentials、 検索の各ユースケース向けの機能を提供することで、ユーザーが運用データから洞察を得られるようにします。また、このリリースにはチームが専用のスペースを作成でき、コラボレーションと生産性の向上が図られています。ユーザーは、基盤となるマネージドクラスターやコレクションのバージョンに関係なく、最新の UI の機能強化を利用できます。 図4. Amazon OpenSearch Service は、モダンな運用分析体験を提供開始 AWS CloudTrail Lake announces two AI-powered capabilities AWS CloudTrail Lake における 2 つの AI による機能強化を発表しました。これらの新機能はログ分析を簡素化し、AWS の環境全体でより深い洞察と迅速な調査を可能にします。1/ CloudTrail Lake の AI による自然言語クエリ生成機能がリリースされました。これにより、複雑な SQL クエリを記述することなく、AWS でのアクティビティについて平易な英語で質問できるようになりました。2/ AI によるクエリ結果要約機能 (プレビュー) は、クエリが自然言語クエリ生成機能で生成されたものか手動で記述したSQLであるかに関わらず、自然言語で要約を提供します。例えば、アクセスが拒否されたリクエストが最も多いユーザーを見つけるクエリを実行した後、「要約」をクリックすると、調査結果から要点の概要を取得できます。 AWS CloudTrail Lake launches enhanced analytics and cross-account data access AWS は AWS CloudTrail Lake に 2 つの重要な機能強化を発表しました。1. 包括的なダッシュボード機能で、新しい「ハイライト」ダッシュボードが AI による分析機能 (プレビュー中) を含む AWS アクティビティログの概要を一目で把握できるようになりました。2. イベントデータストアのクロスアカウント共有機能で、リソースベースのポリシー (RBP) を使用して選択した IAM アイデンティティに対し、イベントデータストアを安全に共有できるようになりました。 まとめ 図5. AWS は機能とサービスを接続し、より統合された体験を提供 re:Invent 2024 で、AWS は運用をより安全で俊敏、効率的、そしてインテリジェントなものにするための強力な新機能を発表しました。Systems Manager での強化されたノード管理、宣言的ポリシーおよびリソースコントロールポリシーによる新しい予防統制機能などでガバナンス機能を改善することができます。オブザーバビリティの課題に対処するため、AWS は CloudWatch の新機能を発表しました。テレメトリにコンテキストを追加する、ネットワークフローを監視する、Amazon Aurora のデータベースの分析を行う、ECS のオブザーバビリティを強化するといったことが可能になります。CloudWatch のアプリケーショントランザクションスパン、新しいゼロ ETL 統合、OpenSearch Service の改善により、運用データとセキュリティデータの分析方法を変革できます。最後に、AWS は機能とサービスを接続することで、コンテキストの構築、データのコピー、ポリシーの管理、ETL パイプラインの保守などの必要がなくなり、より統合された一体型の体験ができるようになりました。これにより、お客様がアプリケーションを開発し、提供することに集中できます。 このブログの翻訳はソリューションアーキテクトの 堀 貴裕 が担当しました。原文は こちら です。 著者について: Rashmi Sahni Rashmi Sahni は、AWS クラウド運用プロダクトマーケティングチームのシニアプロダクトマーケティングマネージャーで、クラウドガバナンスおよびコンプライアンスサービスを担当しています。彼女はクラウドガバナンスのベストプラクティスをお客様に理解していただき、イノベーションを加速することに情熱を注いでいます。ニューヨークのコロンビア大学で博士号を取得しています。仕事の合間には、料理、自転車、娘への話を楽しんでいます。 Tiffany Chen Tiffany Chen は AWS の CSC チームのソリューションアーキテクトで、ヘルスケアおよびライフサイエンス業界を担当しています。彼女は AWS のお客様のデプロイメントワークロードをサポートし、現在は大企業のお客様と協力して、適切に設計され、コスト最適化されたソリューションを構築しています。余暇時間には、旅行、ガーデニング、ベーキング、バスケットボール観戦を楽しんでいます。 Winnie Chen Winnie Chen は AWS のソリューションアーキテクトで、金融サービス業界を中心に、中小企業のお客様をサポートしています。お客様の AWS 移行と AWS 上でのインフラ構築を支援しています。余暇時間には旅行や、ハイキング、サイクリング、ロッククライミングなどのアウトドア活動を楽しんでいます。

この記事は、 Track, allocate, and manage your generative AI cost and usage with Amazon Bedrock | Amazon Web Services を翻訳したものです。 企業が 生成 AI を積極的に導入するにつれて、付随するコストの管理という課題に直面しています。プロジェクトや複数の事業部門にわたって生成 AI アプリケーションの需要が急増する中、コストの正確な配分と追跡はより複雑になっています。組織は、顧客やユーザーセグメント全体でコストの透明性を維持しながら、ビジネスへの影響度と重要性に基づいて生成 AI への支出に優先順位をつける必要があります。この可視性は、生成 AI サービスの正確な価格設定、費用の部門間精算の実装、使用量ベースの課金モデルの確立に不可欠です。 コストを管理するためのスケーラブルなアプローチがないと、組織は予算外の使用とコストの超過のリスクにさらされます。手動での支出監視と定期的な使用制限の調整は非効率で、人的ミスが発生しやすく、潜在的な過剰支出につながる可能性があります。プロビジョニングされたモデル、カスタムモデル、エージェントとエージェントエイリアス、モデル評価、プロンプト、プロンプトフロー、ナレッジベース、バッチ推論ジョブ、カスタムモデルジョブ、モデルコピージョブなど、 さまざまな Amazon Bedrock リソースでタグ付けがサポートされている にもかかわらず、これまではオンデマンドの基盤モデルへのタグ付け機能がありませんでした。この制限により、生成 AI の取り組みのコスト管理がより複雑になっていました。 これらの課題に対処するため、 Amazon Bedrock では、組織がオンデマンドモデルに タグ を付け、付随コストを監視できる機能が公開されました。組織は、すべての Amazon Bedrock モデルに AWS コスト配分タグ を付けることで、コストセンター、事業部門、アプリケーションなどの組織の分類に使用状況を関連付けることができるようになりました。生成 AI の支出を適切に管理するため、組織は AWS Budgets などのサービスを使用して、タグベースの予算とアラームを設定し、使用状況を監視し、異常や事前に定義したしきい値に関するアラートを受け取ることができます。この自動化されたスケーラブルなアプローチにより、非効率な手動プロセスを排除し、過剰支出のリスクを軽減し、重要なアプリケーションを優先的に扱うことができます。生成 AI 関連の支出に対する可視性とコントロールを強化することで、組織は生成 AI への投資を最大限に活用し、イノベーションを促進することができます。 Amazon Bedrock アプリケーション推論プロファイルの紹介 Amazon Bedrock では最近、 クロスリージョン推論 が導入され、AWS リージョン間で推論リクエストを自動的にルーティングできるようになりました。この機能は、Amazon Bedrock によって事前定義されているクロスリージョン推論プロファイルを使用し、さまざまなリージョンから異なるモデル ARN (Amazon Resource Name) を設定し、単一のモデル識別子 (モデル ID と ARN の両方) の下に統合します。この機能によってモデルの使用における柔軟性は向上しましたが、ワークロードやテナント間でのコストの追跡、管理、制御のためのカスタムタグを付与することはサポートされていません。 この課題を解決するため、Amazon Bedrock は新機能として アプリケーション推論プロファイル を導入しました。これにより、組織はカスタムのコスト配分タグを適用して、Amazon Bedrock のオンデマンドモデルのコストと使用状況を追跡、管理、制御できるようになります。この機能により、組織は Bedrock の基盤モデルに対してカスタム推論プロファイルを作成し、テナント固有のメタデータを追加できるため、さまざまな AI アプリケーション全体でリソースの割り当てとコストの可視化を効率化できます。 アプリケーション推論プロファイルの作成 アプリケーション推論プロファイルを使用すると、ユーザーは推論リクエストとリソース管理のためのカスタマイズされた設定を定義できます。これらのプロファイルは、次の 2 つの方法で作成できます： 単一モデル ARN 設定 : オンデマンドのベースモデル ARN を 1 つ使用して直接アプリケーション推論プロファイルを作成し、選択したモデルで迅速なセットアップを可能にします。 システム定義の推論プロファイルからのコピー : 既存のシステム定義の推論プロファイルをコピーしてアプリケーション推論プロファイルを作成します。これにより、拡張性と耐障害性を向上させるためのリージョン間推論機能などの設定が継承されます。 アプリケーション推論プロファイルの ARN は以下の形式になります。推論プロファイル ID は、プロファイル作成時に Amazon Bedrock によって生成される一意の 12 桁の英数字文字列です。 arn:aws:bedrock: <region> : <account_id> :application-inference-profile/ <inference_profile_id> クロスリージョン推論プロファイルとアプリケーションの推論プロファイルの比較 クロスリージョン推論プロファイルとアプリケーション推論プロファイルの主な違いは、 type 属性と ARN 名前空間内のリソース仕様にあります。 クロスリージョン推論プロファイル : これらは SYSTEM_DEFINED の type 属性を持ち、 inference-profile リソースタイプを使用します。クロスリージョンおよびマルチモデル機能をサポートするように設計されていますが、AWS によって一元管理されています。 { … "inferenceProfileArn": "arn:aws:bedrock:us-east-1: <Account ID> :inference-profile/us-1.anthropic.claude-3-sonnet-20240229-v1:0", "inferenceProfileId": "us-1.anthropic.claude-3-sonnet-20240229-v1:0", "inferenceProfileName": "US-1 Anthropic Claude 3 Sonnet", "status": "ACTIVE", "type": "SYSTEM_DEFINED", … } アプリケーション推論プロファイル : これらのプロファイルは type 属性が APPLICATION で、 application-inference-profile リソースタイプを使用します。ユーザー定義のプロファイルで、モデル構成に対する詳細な制御と柔軟性を提供し、AWS Identity and Access Management (IAM) を使用した属性ベースのアクセス制御 (ABAC) によってポリシーをカスタマイズできます。これにより、より正確な IAM ポリシーの作成が可能になり、Amazon Bedrock へのアクセスをより安全かつ効率的に管理できます。 { … "inferenceProfileArn": "arn:aws:bedrock:us-east-1: <Account ID> :application-inference-profile/ <Auto generated ID> ", "inferenceProfileId": <Auto generated ID> , "inferenceProfileName": <User defined name> , "status": "ACTIVE", "type": "APPLICATION" … } これらの違いは、 Amazon API Gateway や他の API クライアントと統合する際に重要であり、正確なモデルの呼び出し、リソースの割り当て、ワークロードの優先順位付けを適切に行うために役立ちます。組織はプロファイルの type に基づいてカスタマイズされたポリシーを適用でき、分散 AI ワークロードの制御とセキュリティを強化できます。両方のモデルを次の図に示します。 コスト管理のためのアプリケーションの推論設定の確立 架空のシナリオとして、保険会社が生成 AI を通じて顧客体験を向上させる取り組みを始めたとイメージしてください。この会社は、保険金請求処理の自動化、個人向けの保険商品の推奨、さまざまな地域の顧客に対するリスク評価の改善といった機会を特定しました。しかし、このビジョンを実現するためには、組織は生成 AI ワークロードを効果的に管理するための堅牢なフレームワークを採用する必要があります。 保険会社が、各事業部門に合わせたアプリケーション推論プロファイルを作成することから始まります。AWS コスト配分タグを割り当てることで、組織は Bedrock の支出パターンを効果的に監視・追跡できます。例えば、保険金請求処理チームは、 dept: claims 、 team: automation 、 app: claims_chatbot などのタグを持つアプリケーション推論プロファイルを作成しました。このタグ付け構造により、コストを分類し、予算に対する使用状況を評価することができます。 ユーザーは Bedrock API または boto3 SDK を使用してアプリケーション推論プロファイルを管理および使用できます。 CreateInferenceProfile : 新しい推論プロファイルを開始し、プロファイルのパラメータを設定できるようにします。 GetInferenceProfile : 特定の推論プロファイルの詳細を取得し、その設定と現在のステータスを確認できます。 ListInferenceProfiles : ユーザーのアカウント内で利用可能なすべての推論プロファイルを一覧表示し、作成されたプロファイルの概要を提供します。 TagResource : ユーザーがアプリケーション推論プロファイルを含む特定の Bedrock リソースにタグを付けることができ、リソースの整理やコスト追跡を容易にします。 ListTagsForResource : 特定の Bedrock リソースに関連付けられたタグを取得し、リソースがどのように分類されているかを理解するのに役立ちます。 UntagResource : リソースから指定されたタグを削除し、リソースの分類管理ができます。 Invoke models with application inference profiles : Converse API : 会話型のやり取りのために、指定された推論設定を使用してモデルを呼び出します。 ConverseStream API : Converse API と同様ですが、リアルタイムのやり取りのためにストリーミングレスポンスをサポートします。 InvokeModel API : 一般的なユースケースのために、指定された推論設定でモデルを呼び出します。 InvokeModelWithResponseStream API : モデルを呼び出してレスポンスをストリーミングします。大規模なデータ出力や長時間実行される処理の処理に有用です。 アプリケーション推論プロファイル API は、AWS Management Console からアクセスできないことにご注意ください。 アプリケーション推論プロファイルを使用した Converse API によるモデルの呼び出し 以下の例では、アプリケーション推論プロファイルを作成し、そのプロファイルを使用して Converse API を呼び出し、会話を行う方法を示します。 def create_inference_profile(profile_name, model_arn, tags): """Create Inference Profile using base model ARN""" response = bedrock.create_inference_profile( inferenceProfileName=profile_name, description="test", modelSource={'copyFrom': model_arn}, tags=tags ) print("CreateInferenceProfile Response:", response['ResponseMetadata']['HTTPStatusCode']), print(f"{response}\n") return response # Create Inference Profile print("Testing CreateInferenceProfile...") tags = [{'key': 'dept', 'value': 'claims'}] base_model_arn = "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0" claims_dept_claude_3_sonnet_profile = create_inference_profile("claims_dept_claude_3_sonnet_profile", base_model_arn, tags) # Extracting the ARN and retrieving Application Inference Profile ID claims_dept_claude_3_sonnet_profile_arn = claims_dept_claude_3_sonnet_profile['inferenceProfileArn'] def converse(model_id, messages): """Use the Converse API to engage in a conversation with the specified model""" response = bedrock_runtime.converse( modelId=model_id, messages=messages, inferenceConfig={ 'maxTokens': 300, # Specify max tokens if needed } ) status_code = response.get('ResponseMetadata', {}).get('HTTPStatusCode') print("Converse Response:", status_code) parsed_response = parse_converse_response(response) print(parsed_response) return response # Example of Converse API with Application Inference Profile print("\nTesting Converse...") prompt = "\n\nHuman: Tell me about Amazon Bedrock.\n\nAssistant:" messages = [{"role": "user", "content": [{"text": prompt}]}] response = converse(claims_dept_claude_3_sonnet_profile_arn, messages) アプリケーション推論プロファイルを使用したタグ付け、リソース管理、コスト管理 アプリケーション推論プロファイル内のタグ付けにより、組織は特定の生成 AI 関連の取り組みにコストを割り当てることができ、正確な費用の追跡が可能になります。アプリケーション推論プロファイルでは、作成時にコスト配分タグを適用でき、さまざまな AWS リソースへのメタデータの関連付けを可能にする既存の TagResource および UnTagResource API を通じて、追加のタグ付けをサポートしています。 project_id 、 cost_center 、 model_version 、 environment などのカスタムタグは、リソースの分類に役立ち、費用の可視性を向上させ、チームが予算に対する支出と利用状況を把握できるようにします。 アプリケーション推論プロファイルとコスト配分タグによるコストと使用状況の可視化 AWS Budgets 、 AWS Cost Anomaly Detection 、 AWS Cost Explorer 、 AWS Cost and Usage Reports (CUR)、 Amazon CloudWatch などのツールでコスト配分タグを活用することで、組織は支出傾向を把握し、予算内に収めるために早期にコストの急増を検出して対処することができます。 AWS Budgets を使用すると、組織はタグベースのしきい値を設定し、支出が予算の上限に近づくとアラートを受け取ることができ、AI リソースのコストを管理し、予期せぬ急増に迅速に対応するためのプロアクティブなアプローチを提供します。例えば、営業部門のサポートチームのチャットボットアプリケーションに、 dept: sales 、 team: support 、 app: chat_app というタグをアプリケーションの推論プロファイルに適用することで、それぞれの予算を設定できます。また、AWS コスト異常検出 はタグ付けされたリソースの異常な支出パターンを監視し、異常なコストを自動的に特定して検知することで、コスト配分タグの運用を容易にします。 以下の AWS Budgets コンソールのスクリーンショットは、予算のしきい値を超過した状態を示しています。 より詳細な分析のために、AWS Cost Explorer と CUR を使用することで、組織はタグ付けされたリソースを日次、週次、月次で分析し、リソースの割り当てとコスト最適化に関する十分な情報に基づいた意思決定を行うことができます。タグのキー/バリューや ARN などのメタデータ属性に基づいてコストと使用状況を可視化することで、組織は支出状況の詳細な内訳を把握することができます。 以下の AWS Cost Explorer コンソールのスクリーンショットは、タグのキーと値でフィルタリングされたコストと使用量のグラフを示しています。 次の AWS Cost Explorer コンソールのスクリーンショットは、Bedrock アプリケーションの推論プロファイル ARN でフィルタリングされたコストと使用量のグラフを示しています。 組織は Amazon CloudWatch を使用して Bedrock アプリケーションのランタイムメトリクスを監視し、パフォーマンスとコスト管理に関する追加のインサイトを得ることもできます。メトリクスはアプリケーションの推論プロファイルごとにグラフ化でき、チームはタグ付けされたリソースのしきい値に基づいてアラームを設定できます。これらのアラームによってトリガーされる通知と自動応答により、コストとリソース使用量をリアルタイムで管理し、予算超過を防ぎ、生成 AI ワークロードのコストを適切に管理することができます。 次の Amazon CloudWatch コンソールのスクリーンショットは、Bedrock アプリケーション推論プロファイル ARN でフィルタリングされた Bedrock ランタイムメトリクスをハイライトしています。 以下の Amazon CloudWatch コンソールのスクリーンショットは、Bedrock アプリケーションの推論プロファイル ARN でフィルタリングされた呼び出し上限のアラームを示しています。 タグ付け、予算設定、異常検出、詳細なコスト分析を組み合わせることで、組織は AI への投資を効果的に管理できます。これらの AWS ツールを活用することで、チームは支出パターンを明確に把握でき、重要なアプリケーションを予算内に収めながら、より適切な意思決定を行い、生成 AI イニシアチブの価値を最大化することができます。 タグに基づくモデル呼び出しのためのアプリケーション推測プロファイル ARN の取得 組織は、Amazon Bedrock API を呼び出す際、モデル推論の呼び出しを含め、生成 AI ゲートウェイや大規模言語モデルのプロキシを使用することがよくあります。アプリケーション推論プロファイルの導入により、組織はオンデマンドの基盤モデルのモデル推論を実行するために、推論プロファイル ARN を取得する必要があります。 適切な推論プロファイル ARN を取得するには、主に 2 つのアプローチがあります。 静的な設定アプローチ： この方法では、 AWS Systems Manager Parameter Store または AWS Secrets Manager に、テナント/ワークロードキーと対応するアプリケーション推論プロファイル ARN をマッピングする静的な設定ファイルを保持します。このアプローチは実装が簡単ですが、重大な制限があります。推論プロファイルの数が数十から数百、あるいは数千に拡大するにつれて、この設定ファイルの管理と更新が非常に困難になります。この方法は静的な性質上、変更が発生するたびに手動での更新が必要となり、特に組織がタグに基づいて正しい推論プロファイルを動的に取得する必要がある大規模なデプロイメントでは、不整合や保守作業の増加につながる可能性があります。 Resource Groups API を使用した動的な取得： 2 番目のよりロバストなアプローチは、AWS Resource Groups の GetResources API を活用して、リソースとタグフィルターに基づいてアプリケーション推論プロファイル ARN を動的に取得します。この方法では、テナント ID、プロジェクト ID、部門 ID、ワークロード ID、モデル ID、リージョンなど、さまざまなタグキーを使用して柔軟なクエリが可能です。このアプローチの主な利点は、スケーラビリティと動的な性質にあり、現在のタグ設定に基づいてアプリケーション推論プロファイル ARN をリアルタイムで取得できることです。 ただし、考慮すべき点がいくつかあります。 GetResources API にはスロットリング制限があるため、キャッシュメカニズムの実装が必要です。組織は、パフォーマンスを最適化し API コールを削減するために、API の出力に基づいて TTL (Time-To-Live) を設定したキャッシュを維持する必要があります。さらに、TTL に基づいてキャッシュが更新される際に、常に最新の推論プロファイル ARN を読み取れるよう、スレッドセーフの実装が重要です。 次の図に示すように、この動的なアプローチでは、クライアントが特定のリソースタイプとタグフィルターを使用して Resource Groups サービスにリクエストを送信します。サービスは対応するアプリケーション推定プロファイル ARN を返し、これは一定期間キャッシュされます。その後、クライアントはこの ARN を使用して、 InvokeModel または Converse API を通じて Bedrock モデルを呼び出すことができます。 この動的な取得方法を採用することで、組織はアプリケーション推論プロファイルを管理するためのより柔軟でスケーラブルなシステムを構築できます。これにより、要件の変更やプロファイル数の増加に対してより簡単に対応できるようになります。 前述の図のアーキテクチャは、タグに基づいて推論プロファイルの ARN を動的に取得する 2 つの方法を示しています。それぞれのアプローチの長所と短所を説明します： TTL 付きキャッシュを維持する Bedrock クライアント: この方法では、クライアントがリソースタイプとタグフィルターに基づいて AWS ResourceGroups サービスの GetResources API を直接クエリします。クライアントは、取得したキーを TTL 付きのクライアント管理キャッシュに保存します。クライアントは、スレッドセーフな方法で GetResources API を呼び出してキャッシュを更新する責任を持ちます。 Lambda ベースの方法: このアプローチでは、呼び出し元のクライアントと ResourceGroups API の間の仲介役として AWS Lambda を使用します。この方法では、インメモリキャッシュを備えた Lambda Extensions コア を使用し、 ResourceGroups への API 呼び出し回数を削減する可能性があります。また、設定管理やキャッシュデータの永続的な保存に使用できる Parameter Store とも連携します。 両方のメソッドは、 ResourceGroup API のクエリに同様のフィルタリング条件 (リソースタイプフィルターとタグフィルター) を使用し、テナント、モデル、リージョンなどの属性に基づいて推論プロファイルの ARN を正確に取得できます。これらのメソッドの選択は、想定されるリクエスト量、目標とするレイテンシー、コストの考慮事項、追加の処理やセキュリティ対策の必要性などの要因によって決まります。Lambda ベースのアプローチはより柔軟で最適化の可能性が高い一方、直接 API を使用する方法は実装とメンテナンスがより簡単です。 Amazon Bedrock のリソースタグ付け機能の概要 Amazon Bedrock のタグ付け機能は大きく進化し、マルチアカウントの AWS Control Tower 環境全体でリソース管理を行うための包括的なフレームワークを提供するようになりました。この進化により、組織は開発、ステージング、本番環境全体でリソースを管理できるようになり、AI/ML ワークロードのコストの追跡、管理、配分が容易になります。 Amazon Bedrock のリソースタグ付けシステムは、その中核において複数の運用コンポーネントにまたがっています。 組織は、バッチ推論ジョブ、エージェント、カスタムモデルジョブ、ナレッジベース、プロンプト、プロンプトフローに効果的にタグを付けることができます。この基本的なタグ付けの仕組みにより、運用リソースの詳細な制御が可能になり、さまざまなワークロードコンポーネントを正確に追跡・管理できます。Amazon Bedrock のモデル管理の側面では、カスタムモデルとベースモデルの両方を包含する新たな機能層が導入され、プロビジョンドモデルとオンデマンドモデルを区別し、それぞれに固有のタグ付け要件と機能を持たせています。 アプリケーション推論プロファイルの導入により、組織は Bedrock のベースとなる基盤モデルをオンデマンドで管理およびモニタリングできるようになりました。チームはシステム定義の推論プロファイルから派生したアプリケーション推論プロファイルを作成できるため、アプリケーションレベルでより正確なリソーストラッキングとコスト配分を設定できます。この機能は、複数の AI アプリケーションを異なる環境で実行している組織にとって特に価値があります。リソースの使用状況とコストを詳細なレベルで明確に可視化できるからです。 次の図は、マルチアカウント構造を視覚化し、これらのタグ付け機能が異なる AWS アカウント間でどのように実装できるかを示しています。 まとめ この投稿では、Amazon Bedrock の最新機能であるアプリケーション推論プロファイルを紹介しました。その動作方法を探り、重要な考慮事項について説明しました。この機能のコードサンプルは、この GitHub リポジトリ で入手できます。この新機能により、組織はオンデマンドのモデル推論ワークロードと支出を、業務全体にわたってタグ付け、割り当て、追跡できるようになります。組織は、テナント、ワークロード、コストセンター、事業部門、チーム、アプリケーションなど、特定の組織分類に従って、すべての Amazon Bedrock モデルにタグを付け、使用状況を監視できます。この機能は、Amazon Bedrock が提供されているすべての AWS リージョンで一般提供されています。 翻訳はソリューションアーキテクトの福本が担当しました。 著者について Kyle T. Blocksom は、南カリフォルニアを拠点とする AWS のシニアソリューションアーキテクトです。 Kyle の情熱は、人々を結びつけ、テクノロジーを活用してお客様に喜ばれるソリューションを提供することです。 仕事以外では、サーフィン、食事、愛犬とじゃれあう、甥や姪を甘やかすことを楽しんでいます。 Dhawal Patel は AWS のプリンシパル機械学習アーキテクトです。 大企業から中規模のスタートアップまで、分散コンピューティングや人工知能に関連する問題に取り組んできました。 自然言語処理やコンピュータビジョンなどのディープラーニング分野に注力しており、SageMaker での高性能なモデル推論の実現をお客様を支援しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今週の 12 月 2 日 – 6 日 はついに AWS re:Invent 2024 ですね。このブログを執筆している12 月 2 日時点ですでに多くの update が発表され、いよいよ始まる雰囲気を感じています。ライブで見る方もそうでない方も 1 年に一度のお祭りを楽しみましょう。 12 月 6 日 (金) の 12:00-13:00 に毎年恒例の「 新サービス・新機能の全てを1時間でサクッとお伝えするWebinar 」を開催しますので、ぜひご参加ください。 それでは、11 月 25 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon DynamoDB と Amazon Q Developer による迅速な開発」を公開 この記事では、Amazon Q Developer を使用することで DynamoDB にまつわる開発速度がどのように向上するかを紹介しています。Amazon Q Developer で、DynamoDB のテーブル作成を行う CloudFormation テンプレートの生成と、CRUD オペレーションを実行するコードを生成する様子が書かれています。 ブログ記事「【開催報告】動画&資料公開 | AWS AI Day 〜AWS のテクノロジーで加速する生成 AI のプロダクション活用〜」を公開 2024 年 10 月 31 日に AWS AI Day が開催されました。こちらのブログはイベントの様子をまとめた記事です。生成 AI の実用化に向けた AWS の技術動向、お客様による活用事例の取り組みなどが紹介されました。当日のセッション動画と資料が公開されていますので、ぜひご覧ください。 ブログ記事「Amazon Titan Text Embeddings V2、Amazon OpenSearch Serverless、および Amazon Bedrock Knowledge Bases における バイナリ埋め込みを使用した費用対効果の高い RAG アプリケーションの構築」を公開 先週、 Amazon Bedrock Knowledge Bases と Amazon OpenSearch Serverless における Amazon Titan Text Embeddings V2 用のバイナリ埋め込みの提供開始 を発表しました。こちらのブログでは、バイナリベクトルを利用するメリットとサービスの設定方法を紹介しています。 サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション Amazon Q Appsでプライベート共有機能を開始 Amazon Q Apps とは、組織独自の生成 AI アプリケーションを自然言語で構築することが可能なサービスです。今回、Amazon Q Apps にてプライベート共有機能が追加されました。この新機能により、アプリ作成者はアプリへのアクセスを特定の Amazon Q Business ユーザーに制限できるようになり、組織内での使用をより細かく制御できるようになりました。 Amazon Q Apps がデータ収集機能を開始（プレビュー版） Amazon Q Apps が、データ収集機能のパブリックプレビューを開始しました。組織データを収集するためのフォームベースのアプリを作成できるようになり、チームサーベイ、新入社員のオンボード進捗追跡、プロジェクトの振り返りなどに活用できます。収集したデータに対して生成 AI で実用的なインサイトを得ることができるようになっています。 Amazon Q Developer Pro にて、ユーザーアクティビティに関する新しいダッシュボードが利用可能に Amazon Q Developer Pro 向けに提供されているユーザーアクティビティを管理するダッシュボードが新しくなり、より詳細な情報が見れるようになりました。これまで閲覧できていた 生成コード行数等の情報に加えて、チャットのメッセージ数や最終アクティビティ日などが見れるようになっています。 Amazon Q Developer が Oracle から PostgreSQL への埋め込み SQL の変換をサポート開始 Amazon Q Developer は、アプリケーション内の Oracle SQL を PostgreSQL に変換する機能をサポート開始しました。これまで DB の移行には SQL を手動で変換する必要がありましたが、Amazon Q Developer が DMS Schema Conversion からメタデータを取得し、互換性のあるバージョンに自動で変換します。 Amazon Q Developer が自然言語によるコスト分析機能を提供開始 Amazon Q Developer にコスト分析機能が追加されました。ユーザーは「前四半期で最もコストがかかったサービスは何ですか？」といった AWS コストに関する質問を自然言語で行うことができます。各回答には、Cost Explorer でデータを可視化するためのリンクが含まれており、透明性の確保も可能になっています。現在は英語のみのサポートとなっています。 Amazon Q Developer がコンソールのコンテキストに基づいてよりパーソナライズされたチャット回答を提供可能に Amazon Q Developer は、ユーザーが現在閲覧している AWS サービスと、操作しているリージョンに基づいて、問い合わせを動的に理解し応答することが可能になりました。このアップデートにより、見ているページの情報をユーザーが入力することなく質問ができるようになるため、より迅速に欲しい情報を得ることができます。 Amazon Q Developer の Eclipse IDE 向けプラグインがパブリックプレビューで利用可能に Amazon Q Developer の Eclipse IDE 向けプラグインがパブリックプレビューで利用可能になりました。この機能により、Eclipse の開発者は、IDE 内で Amazon Q Developer とプロジェクトについてチャットを行い、インラインのコード提案機能を使用してより迅速にコーディングを行うことができます。 Amazon Q Developer が Java アップグレード変換 CLI をパブリックプレビューでローンチ Amazon Q Developer にて Java アップグレード変換 CLI のパブリックプレビューを開始しました。これまで、IDE を通じて Java 8・Java 11 から Java 17 への変換が可能でしたが、CLI では上記に加えて、カスタム変換機能をサポートします。カスタム変換機能で、コードベースや内部ライブラリに特化した独自の変換を定義できるようになりました。 Amazon Q Java transformation がステップバイステップのアップグレードとライブラリアップグレードをサポート開始 Amazon Q Developer Java アップグレード変換機能が、ステップバイステップのアップグレードとJava 17 アプリケーション向けのライブラリアップグレードをサポート開始しました。ステップバイステップのアップグレードでは、コード変更の各差分を開発者が確認しながらテストができるようになっています。また既に Java 17 を使用しているアプリケーションのライブラリを最新にアップグレードできるようになり、メンテナンスにかかる時間と労力を節約できるようになりました。 Amazon Q Businessにて、ドキュメント内の画像からインサイトを抽出する機能をサポート 企業システム内のデータに基づいて、質問への回答や要約が可能な Amazon Q Business にて、ドキュメント内に埋め込まれた画像情報からインサイトを抽出し質問に答える機能を提供開始しました。この新機能により、PDF、Microsoft PowerPoint、Google Docs などのテキスト情報だけでなく、埋め込まれた図表・チャートなどの情報も照合できるようになりました。 Amazon Connect Contact Lens にて、生成 AI を使用してコンタクトを自動分類可能に Amazon Connect Contact Lens は、生成 AI を使用してコンタクト (顧客とコンタクトセンターの間で行われる1回のやり取り) を自動的に分類する機能を提供するようになりました。Contact Lens は、コンタクトに自動的にラベルを付け、会話のポイントがわかるようにします。また、これらのラベルに対して検索が可能です。この機能は英語に対応しており、米国東部（バージニア北部）および米国西部（オレゴン）の2つのAWSリージョンで利用可能です。 Amazon Connectにて、Amazon Q in Connect 向けの AI ガードレールを発表 コンタクトセンター向けの生成 AI アシスタントである Amazon Q in Connect にて、AI ガードレールを設定できるようになりました。コンタクトセンター管理者は、Amazon Q in Connect 向けに企業固有のガードレールを設定し、有害・不適切な応答のフィルタリング、機密性の高い個人情報の編集などの制限を行うことができます。 Amazon Connectにて、顧客セグメント向けAIアシスタントとトリガーベースのキャンペーンを発表 Amazon Connect は、AIアシスタントを使用することで、自然言語クエリを使用して顧客セグメントを作成し顧客データの傾向に基づいた推奨事項を受け取ることができるようになりました。例えば、前四半期にサポートケースが増加した顧客や、先月購入が減少した顧客などのセグメントを容易に特定できます。また顧客イベントに基づくトリガーベースのキャンペーンを数回のクリックで実施できるようになりました。ショッピングカートの放棄や特定のヘルプページへの頻繁な訪問などの行動をトリガーに、即座にコミュニケーションを行うことができます。 Amazon Connectにて、会話型 AI ボット作成の簡素化を発表 Amazon Connect で、会話型 AI ボットの作成、編集、継続的な改善が、数回のクリックでできるようになりました。Amazon Connect のドラッグアンドドロップ式ワークフローデザイナーを使用することで、コードを書くことなくパーソナライズされた体験を簡単に提供できるようになります。 Amazon Connect Contact Lensにて、生成 AI を活用したエージェントの自動パフォーマンス評価機能を提供開始 Amazon Connect Contact Lensは、生成 AI を使用してエージェントのパフォーマンス評価の入力を自動的に行う機能を提供開始しました。管理者は自然言語で評価基準を指定することが可能です。顧客とのやり取りの一部または全てを生成 AI を使用して自動評価し、エージェントの指導のために会話の特定のポイントを参照しながら、自動評価の背景と根拠も提供します。東京リージョン含む 8 つのAWSリージョンで利用可能です。 Amazon Q in Connect にて生成 AI 搭載のセルフサービスを開始 コンタクトセンター向けの生成 AI アシスタントである Amazon Q in Connect にて、自動音声応答（IVR）やデジタルチャネルを通じたエンドカスタマーのセルフサービス対応をサポートするようになりました。Amazon Q in Connectは、エンドカスタマーと直接会話し、意図を理解して正確な回答を提供します。この機能により、顧客満足度とファーストコンタクト解決率を向上させることができるようになります。 PartyRockにて、アプリ検索機能の改善と、無料日次利用枠を発表 これまで 50 万以上のアプリが作成されている PartyRock にて、アプリ検索機能が改善されより簡単に見つけたいアプリが探せるようになりました。ホームページの検索バーを使用して、公開されているすべての PartyRock アプリを探索できるようになっています。また、現在の無料トライアルに代わり、2025 年からは無料日次利用枠を通じて PartyRock アプリにアクセスし実験できるようになります。 サービスアップデート – アプリケーション開発のためのツール Agents for Amazon Bedrock の新機能 InlineAgents を発表 Agents for Amazon Bedrock に InlineAgents という新機能が追加されました。開発者は事前に Agents のリソースを作成することなく、基盤モデル、アクショングループ、ナレッジベースをその場で指定して呼び出すことができるようになりました。この機能により、様々なエージェント機能を試したり、エージェントが利用できるツールを動的に更新したりすることが可能になりました。 Amazon Bedrock Agents がカスタムオーケストレーションをサポート Amazon Bedrock Agents は、エージェントのマルチステップタスクの処理方法や複雑なワークフローの実行方法を制御できるカスタムオーケストレーションに対応しました。この機能により、エージェントのオーケストレーションロジックを開発者が定義できるようになり、特定のユースケースに合わせてエージェントの動作をカスタマイズできるようになりました。 Amazon Bedrock Knowledge Bases がカスタムコネクターとストリーミングデータの取り込みに対応 Amazon Bedrock Knowledge Bases が、カスタムコネクターとストリーミングデータの取り込みに対応し、開発者は直接 API コールを通じてナレッジベースにデータを追加、更新、削除できるようになりました。この新機能により、ユーザーは、S3 等の中間ストレージを使用せずに直接データの取り込みができるため、これまで発生していた中間ストレージの運用コストを削減できます。この機能は、Amazon Bedrock Knowledge Bases がサポートされているすべてのリージョンで利用可能です。カスタムコネクター機能の使用に追加コストはかかりません。 Amazon Bedrockにて、RAG アプリケーションの精度向上のため Rerank API をサポート開始 Amazon Bedrockは、リランカーモデルである Amazon Rerank 1.0と Cohere Rerank 3.5 モデルの提供を開始しました。リランカーモデルとは、RAG においてユーザークエリへの関連性が高い文書順に並び替えることによって、RAG の精度向上に貢献するためのモデルです。Amazon Bedrock Knowledge Base を利用する場合は、Retrieve および RetrieveAndGenerate API にてリランカーの有効化が可能です。これらのモデルは、東京リージョン含む 4 リージョンで利用可能です。 Amazon Bedrock Model Evaluation にて LLM-as-a-judge 機能を追加（プレビュー版） Amazon Bedrock Model Evaluationでは、ユースケースに最適な基盤モデルを評価、比較、選択することができます。今回、Model Evaluation に新しい評価機能である LLM-as-judge がプレビュー版として追加されました。LLM-as-judge では、LLM の出力を人間ではなく評価用 LLM が評価することができます。「正確性」「有用性」などの評価基準をユーザーが設定するとその項目に沿って LLM が評価を行うことができます。これにより人間による評価の何分の一かのコストで人間に近い評価品質を得ることができるようになります。 Amazon Bedrock Knowledge Bases が RAG 評価機能をサポート開始（プレビュー） Amazon Bedrock Knowledge Bases にて RAG アプリケーションを評価する機能の提供をプレビューで開始しました。この機能では、情報検索のみ、または検索と回答生成の両方を評価することができます。評価は LLM-as-a-Judge テクノロジーによって実行され、開発者は評価モデルを選択することができます。検索評価では、コンテキストの関連性やカバレッジなどの指標、検索と回答生成の評価では、正確性、忠実性（ハルシネーション検出）などの品質指標や、有害性、回答拒否などの責任ある AI 指標から選択ができます。ローンチ時点では英語のコンテンツ向けに最適化されていますが、他の言語でも機能します。また東京リージョンでもサポートされています。詳しくは こちらのブログ を参照ください。 Amazon Bedrock Knowledge Bases にて、検索精度向上のための自動生成クエリフィルターを提供開始 Amazon Bedrock Knowledge Bases にて、RAG アプリケーションの検索精度向上のための自動生成クエリフィルター機能を提供開始しました。この機能により、複雑なフィルター式を手動で記述することなく、ドキュメントのメタデータに基づいてフィルタリングされた検索結果を受け取ることができます。例えば、「ワシントンで請求を申請する方法」というクエリに対して、「ワシントン」という州が自動的にフィルターとして適用され、関連するドキュメントのみを取得することが可能です。複雑なフィルター式を手動で構築する必要なく検索精度を向上させることが可能になります。東京リージョンでもサポートされています。 Amazon Bedrock Knowledge Bases がストリーミングレスポンスに対応 Amazon Bedrock Knowledge Bases にて、ストリーミングレスポンスを実現するための RetrieveAndGenerateStream API のサポートを開始しました。この新しいストリーミング API により、完全なレスポンスを待つことなく、LLM が生成する応答をリアルタイムで受け取ることができるようになります。現在すべての既存の Amazon Bedrock Knowledge Base リージョンでサポートされています。 サービスアップデート – 生成AI開発のためのインフラストラクチャー Amazon SageMaker で、マルチアダプターモデル推論をローンチ Amazon SageMaker で、1 つのエンドポイントに複数のファインチューニングされた LoRA（Low-Rank Adaptation）モデルアダプターを配置し、リクエストに基づいてアダプターを動的に読み込むマルチアダプターモデル推論を提供開始しました。 この機能により、共通のベースモデル上に構築された複数の LoRA アダプターを効率的にホストでき、高いスループットとコスト削減を実現しやすくなりました。デプロイ方法は こちらのブログ を参照ください。 Amazon SageMakerにて、AI推論のコスト削減を支援する「Scale Down to Zero」を提供開始 Amazon SageMakerにて、非アクティブ時にエンドポイントをゼロインスタンスまでスケールダウンする Scale Down to Zero 機能を提供開始しました。この機能により、AI モデルを使用した推論の実行コストを削減でき、特に変動の大きいトラフィックパターンを持つアプリケーションに有益です。 Amazon EC2 キャパシティブロックにて、即時開始と延長をサポート開始 Amazon EC2 の機械学習向けキャパシティブロックにて、即時開始と延長という新しいオプションをサポート開始しました。開発者は、GPU および機械学習チップインスタンスのキャパシティブロックを数分で開始することができます。また、機械学習ジョブが予想以上に長引いた場合にキャパシティブロックを延長することができるようになりました。さらに、より長期間のプロジェクト向けには、最大 6 ヶ月間のキャパシティブロックを予約することも可能になっています。 サービスアップデート – その他関連アップデート AWS Marketplace にて、AI による製品サマリーと比較機能を提供開始 AWS Marketplace にて、生成 AI により製品情報と顧客レビューを要約する機能と、類似の SaaS 製品を推奨する機能を提供開始しました。これにより、ソフトウェア購入の意思決定をより迅速に行うことができるようになります。 AWS DMS スキーマ変換にて 生成 AI の利用が可能に AWS Database Migration Service (AWS DMS) にて、生成 AI を活用したスキーマ変換が利用可能になりました。この機能によって、Microsoft SQL Server などの商用エンジンから Amazon Aurora PostgreSQL 互換エディションおよび Amazon RDS for PostgreSQL へのデータベーススキーマ変換が可能です。特に、ストアドプロシージャ、関数、トリガーなど、通常は手動での変換が必要な複雑なコードオブジェクトの変換に役立ちます。 来週の週刊生成 AI with AWS は、特別号として re:Invent で発表されたビッグなアップデートをピックアップして紹介する予定です。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

こんにちは、Amazon Connect ソリューションアーキテクトの清水です。2024年 10月のアップデートまとめ はご覧いただけたでしょうか。いよいよ re:Invent 2024 が開催されますが、直前の11月にも大きなアップデートがありました。今回は Amazon Connect ならではの特徴である AWS エコシステムを活かし新たなチャネルとして電子メールがサポートされました。これによりお客様からのお問い合わせを電話やチャットと同じフローで対応することが可能になりました。また、今月は Amazon Connect をご利用いただいたお客様に寄稿いただいたブログを改めてご紹介いたします。 それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートとブログについて 2024年11月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートとブログについて 注目#1 Amazon Connect Email is now generally available (Amazon Connect Email が一般提供開始) Amazon Connect の新しいチャネルとして電子メールを追加しました。AWS のマネージドメールサービスである Amazon SES と連携しつつ、ほとんどの設定は Amazon Connect の画面から行うことが可能です。Web ページに掲載している問い合わせ先や、問い合わせフォームからの送信先を Amazon Connect のメールアドレスに設定し、電話やチャット同様にコールフローを設定することで最適なエージェントへルーティングが可能です。このとき、メールの件名やアドレスから適切なキューへ自動的に振り分けることもできます。エージェントは従来のソフトフォンを利用してメールの作成や返信を行うことが可能なため、ウインドウを切り替えることなくオペレーションが可能です。管理者は電話とメールの優先度を調整したり対応チームを分けるなど柔軟な設計が可能になり、メールの対応時間も含めた KPI レポートが作成できます。設定方法は こちら 、料金は こちら をご覧下さい。 注目#2 お客様事例ブログ | Amazon Connect で 58% のコストダウン / ANA X が実践する生成 AI でのお客様の声 (VoC) 分析 ANA X 様では、2022年にオンプレミス型 PBX から Amazon Connect への移行を行い、コンタクトセンターの柔軟性・スケーラビリティ向上と内製化に取り組まれました。このブログでは、移行後の定量的な効果、プロジェクトの移行プロセスとエピソード、移行プロジェクト成功のポイントについて詳細な情報を公開いただきました。さらに、コンタクトセンター運用開始後のお客様の声 (VoC) 分析について目的と課題を整理した上で、生成 AI で分析する効果や内製化のために実践した LLM 学習方法をご紹介いただきました。クラウドコンタクトセンターの具体的な導入効果を知りたい方や、VoC 分析にどこから手を付けて良いか悩まれている方にお役に立つ内容となっています。 2. 2024年11月のアップデート一覧 Amazon Connect now allows agents to self-assign tasks (Amazon Connect でエージェントがタスクを自分に割り当て可能に) – 11/25/2024 Amazon Connect では、エージェントがエージェントワークスペースまたはコンタクトコントロールパネル (CCP) からタスクを作成して自分に割り当てることができるようになりました。たとえば、エージェントは任意の時間にタスクをスケジュールして自分にアサインすることで、顧客に最新情報を伝えるフォローアップアクションをスケジュールできます。 関連リンク 管理者ガイド Amazon Connect Contact Lens launches calibrations for agent performance evaluations (Amazon Connect Contact Lens がエージェントパフォーマンス評価のキャリブレーションを開始) – 11/25/2024 マネージャーがエージェントのパフォーマンスを評価する方法の一貫性と正確性を高めるため、キャリブレーションを実行できるようになりました。キャリブレーションでは、複数のマネージャーが同じ評価フォームを使って同じコンタクトを評価できます。異なるマネージャーが記入した評価の違いを確認することで、評価のベストプラクティスについて意見を交換し、評価フォームを改善することができます。また、マネージャーの回答と承認された評価と比較することで、パフォーマンス評価における精度を測定し、改善させることができます。 関連リンク 管理者ガイド Amazon Connect Contact Lens generative AI-powered post contact summarization is now available in 5 new regions (Amazon Connect Contact Lensの生成AIを活用した会話後要約機能が5つのリージョンで利用可能に) – 11/22/2024 Amazon Connect Contact Lens の生成 AI を活用した会話後要約機能が、ヨーロッパ（ロンドン）、カナダ（セントラル）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アジアパシフィック（シンガポール）の AWS リージョンで利用可能になりました。この機能は、長時間の顧客との会話を簡潔でわかりやすい文章に要約します（例：「顧客は直前のフライトキャンセルに対する払い戻しを受け取っておらず、エージェントは業務手順に従った払い戻しを提案しなかった」）。これにより、エージェントは顧客とのコールが完了してから数秒以内に要約にアクセスでき、コール後の作業を迅速に完了することができます。 関連リンク 管理者ガイド 会話後要約でサポートしている言語 Amazon Connect now provides granular disconnect reasons for chats (Amazon Connect がチャットの詳細な切断理由を提供開始) – 11/22/2024 Amazon Connect のコンタクトレコードに、チャットの詳細な切断理由が含まれるようになり、これに基づいてカスタマーエクスペリエンスを改善しパーソナライズすることが可能になりました。例えば、エージェントがネットワークの問題で切断した場合、次に最適なエージェントにチャットをルーティングすることができます。また顧客が無応答のために切断した場合、プロアクティブに SMS を送信してチャットの再開を図ることができます。 関連リンク 管理者ガイド (DisconnectReason) Amazon Connect Email is now generally available (Amazon Connect Email が一般提供開始) – 11/22/2024 Amazon Connect Email は、カスタマーサービスの電子メールの優先順位付け、割り当て、解決の自動化を容易にする組み込み機能を提供し、顧客満足度とエージェントの生産性を向上させます。Amazon Connect Email を使用すると、顧客が送信した電子メールやウェブサイトやモバイルアプリのウェブフォームを通じて送信された電子メールを受信し、応答することができます。自動応答の設定、電子メールの優先順位付け、ケースの作成または更新、エージェントの支援が必要な場合に最適なエージェントへの電子メールのルーティングが可能です。さらにこれらの機能は Amazon Connect のアウトバウンドキャンペーンとシームレスに連携し、プロアクティブでパーソナライズされた電子メールコミュニケーションを実現します。 関連リンク 管理者ガイド ブログ記事 Amazon Connect Contact Lens がカスタムダッシュボードをサポート – 11/20/2024 Amazon Connect Contact Lens が、カスタムダッシュボードの作成、および既存のダッシュボードへのウィジェットの追加や削除をサポートしました。これらのダッシュボードを使用することで、カスタム定義の期間（例：週ごと）、サマリーチャート、時系列チャートなどを用いて、リアルタイムおよび過去の集計されたパフォーマンス、傾向、インサイトを表示し比較することができます。今回、これらのダッシュボードをさらにカスタマイズし、ウィジェットを変更して特定のビジネスニーズに最適なビューを作成できるようになりました。例えば、セルフサービス、キュー、エージェントのパフォーマンスをモニタリングしたい場合、これら3種類のウィジェットをダッシュボードに追加して、コンタクトセンターのパフォーマンスを一元的に把握することができます。 関連リンク 管理者ガイド Amazon Connect の予測、キャパシティプランニング、スケジューリングで 9 つの追加言語のサポートを開始 – 11/20/2024 Amazon Connect の予測、キャパシティプランニング、スケジューリングにおいて、9 つの追加言語をサポートしました。新たにサポートされる言語には以下が含まれます：カナダフランス語、中国語（簡体字および繁体字）、フランス語、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語（ブラジル）、およびスペイン語。 関連リンク 管理者ガイド Amazon Connect が、パーソナライズされたプロアクティブな新たなエンゲージメント機能を提供 – 11/18/2024 Amazon Connect が顧客のニーズに積極的に対応し、より良い顧客成果を実現するための新機能を提供しました。顧客体験の中で適切なタイミングに、適切なチャネルから、リアルタイムのサービス更新、プロモーションオファー、製品使用のヒント、予約リマインダーなどの積極的なアウトバウンドコミュニケーションを開始できます。Amazon Connect Customer Profiles を使用して、販売管理システムの注文、モバイルアプリの位置データ、予約システムの予約データ、ウェブサイトからのインタラクションなど、リアルタイムの顧客行動に基づいて動的に更新されるターゲットセグメントを定義できます。 関連リンク 管理者ガイド (customer segment) 管理者ガイド (outbound campaigns) ブログ記事1 (英語) ブログ記事2 (英語) Amazon Connect がチャットやタスクを使用する際のコールバックのサポートを開始 – 11/01 Amazon Connect では、音声通話に加えてチャットやタスクからコールバックをリクエストできるようになりました。たとえば営業時間外に顧客がコンタクトセンターに問い合わせた場合、チャットメッセージを送信するか、ウェブフォームからの問い合わせをタスクに連携することで、音声でのコールバックをリクエストできます。コールバックによって顧客は待ち続けることなく、営業時間が開始されたらエージェントから電話を受けることができます。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 Amazon Connect で 58% のコストダウン (日本語記事/ 英語版はこちら ) ANA X はこれまでのノウハウとその選択肢を生かし、オンプレミス型の PBX を中心としたコールセンターシステムから、クラウドベースの Amazon Connect にマイグレーションを成功させました。本記事では、その経緯と成功体験を共有し、読者が自らの力でシステム移行と運営を実現できる可能性について触れます。 ANA X が実践する生成 AI でのお客様の声 (VoC) 分析 (日本語記事/ 英語版はこちら ) ANA X では問い合わせ対応が長時間化する原因分析、顧客ニーズの詳細分析において課題を持っていました。そこで生成 AI 技術に注目し、従来の分析手法では見逃されがちだった微細なトレンドやパターンを正確に把握し、分析する手法を発見しました。生成 AI がコンタクトセンターでの VoC 分析にどのように貢献するか、特に最新の LLM (大規模言語モデル) 技術を用いた手法の利点と従来手法との比較した際の優位性についてを紹介します。 インゲージ社、Amazon Connect によりクラウド電話機能を実現。AI サービスとの統合も行い利便性を向上 (日本語記事) 「 Re:lation 」は、顧客対応の問題を解決するための問い合わせ対応・メール共有システムです。複数のコミュニケーションチャネルを一画面に集約し、チーム間で共有・管理できる機能を提供しています。また、 Amazon Connect を活用した クラウド電話機能 やAIサービスとの統合により、電話での会話の文字起こしなど多様な機能を実現しています。この記事では、AWS の利用状況や Amazon Connect を活用するようになった経緯などを、「 Re:lation 」提供企業である株式会社インゲージに詳しく伺いました。 Implementation of DevSecOps Ecosystem for Amazon Connect at NatWest (英語記事) 多くの組織がカスタマーサービス向上を目指す中、クラウドベースのコンタクトセンターソリューションが注目されています。NatWest Group にとって、Amazon Connect を活用したカスタマーエクスペリエンス向上は、長期的なロイヤルティと競争優位性を高める重要な取り組みでした。しかし大規模導入にはDevSecOps エコシステムの実装と管理に課題があります。NatWest は、Amazon Connect 導入に加えコンタクトセンター変革の長期的成功と回復力を保証する堅牢なエコシステム構築に着手しました。このガイドは、NatWest の経験から得た洞察とベストプラクティスを提供します。 Best practices for handling email messages within a flow (英語記事) カスタマーサービスにおいてメールは重要なコミュニケーション手段です。しかし問い合わせ量の増加により効率的な管理が課題となっています。自動化されたメール処理ソリューションを導入することでこれらの課題に対処し、顧客体験とエージェントの生産性を向上させることができます。この記事では、Amazon Connect と AI を使用してインテリジェントなメールルーティング、顧客インサイト、パーソナライズ、自動化機能を実現する方法を見ていきます。 Transform customer data into personalized customer experiences with Amazon Connect Customer Profiles and Outbound Campaigns (英語記事) コンタクトセンターチームは顧客に問題が発生する前にとコミュニケーションを取ることで、顧客ロイヤルティの向上と収益増加を目指しています。しかし効果的な事前対応にはパーソナライズされ一貫性のあるコミュニケーションが必要です。顧客データは多くの場合、ビジネスサイロ、アプリケーション、チャネル間で分断されており効果的な事前対応を難しくしています。この記事では、計算属性を使用して Amazon Connect Customer Profiles データを実用的なデータポイントに変換する方法を解説します。これらのデータポイントは、注文履歴データに基づいたインバウンドの音声応答や、リアルタイムでターゲット化された顧客セグメントを使用した Outbound Campaign など、体験をパーソナライズするために使用することができます。 Announcing: Proactive communications with outbound campaigns and Customer Profiles in Amazon Connect (英語記事) 双方向のコミュニケーションは強固な関係の基礎です。あらゆるタイプの組織にとって事後対応型のカスタマーサポートは不可欠ですが、積極的な働きかけは顧客満足度を新たな高みへと引き上げることができます。しかし、組織は適切なメッセージを適切な人に適切なタイミングで送信する必要があります。Amazon Connect で発表された最新のイノベーションにより、組織は個々の顧客のニーズに合わせたターゲットコミュニケーションを開始することができます。この記事では、Amazon Connect Customer Profiles を効果的に利用して、個々の顧客の注文履歴などの生の顧客データを実用的なデータポイントに変換する方法を紹介します。 今月のお知らせはここまでです。12月はいよいよ re:Invent 2024 を開催します。皆様のコンタクトセンター改革をご支援する新しい発表を楽しみにしてください。このブログへのフィードバックもお待ちしています！ シニア Amazon Connect ソリューションアーキテクト 清水 幸典

効率的で効果的な顧客サービスを提供することは組織にとって不可欠であり、メールは依然として重要なコミュニケーションチャネルです。メールは顧客が助けを求めたり、問題を解決したりするための柔軟で使い慣れた媒体です。チャットやソーシャルメディアなどの新しいコミュニケーション手段が台頭していますが、メールは非同期な性質をもつため、顧客は自分自身のペースでやり取りを行えると同時に、組織は詳細なやり取りの履歴を得ることが可能です。しかし、顧客からの問い合わせの量が増えるにつれて、メールサポートの効率的な管理が課題になる可能性があります。顧客からのメールを処理するプロセスが合理化されなければ、組織は緊急の問い合わせの優先順位付けや、一人一人に合わせた対応、機密情報の識別に苦労することになります。 メールの解析と分析を自動化することで、これらの課題に対処し、顧客体験とエージェントの生産性の両方を改善できます。自動化されたメール処理のソリューションを導入することで、組織は顧客からの問い合わせを効率的に管理して対応でき高度なパーソナライゼーションおよびデータプライバシー規制の遵守とタイムリーな問題解決を両立できるようになります。組織はメールの内容に基づいて、重要な問題のエスカレーション、自動返信の送信、回答不要なお礼のメールのルーティングを避けるなど、適切な措置を講じることが可能になります。また、メール分析では、意図、感情、キーワード、個人情報を検出することも可能です。 Amazon Connect は、 Amazon Connect Agent Workspace からメール問い合わせを簡単に処理できる機能を発表しました。このブログ記事では、人工知能 ( AI ) を使用したインテリジェントなメールルーティング、有意義な顧客洞察、パーソナライズ、メール処理の自動化を Amazon Connect でどのように実現するか紹介します。 概要 Amazon Connect Email は他の Amazon Connect チャネルと同様の フロー を使用使用して、ルーティング、キューイング、および統合機能を提供します。Amazon Connect には、受信メールを処理するための StartEmailContact API が用意されています。この API はリクエストオブジェクトのフィールドにメールの基本情報を含むことができ、これらのフィールドを使用してメール情報を入力することで Amazon Connect 内でメールによる問い合わせを開始できます。ただし、メールの問い合わせ情報に保存されるのは、差出人、宛先、CC、件名などの メールの問い合わせ属性だけです。メール本文の内容と添付ファイルは Amazon Simple Storage Service (S3) に保存されます。 メールの問い合わせ情報を入力する方法の詳細については、 Set up email in Amazon Connect を参照してください。 メールメッセージの処理 AWS Lambda を使ったフローで Amazon S3 からメールメッセージを取得し、 AI 、機械学習 (ML) 、 Amazon Bedrock のような大規模言語モデル (LLM) によって内容を分析できます。 顧客が Amazon Connect インスタンスに設定されたメールアドレスにメールを送信すると、そのメールは最初に Amazon Simple Email Service (SES) によって処理されます。その後、Amazon SES サービスが StartEmailContact API を呼び出します。この API はリクエストパラメータの検証と、「To」または「CC」フィールドの 1 つ以上のメールアドレスが有効で、Amazon Connect インスタンス内に存在するかの確認を行います。確認に成功すると、問い合わせ ID が生成され、API レスポンスとして返却されます。その後、Amazon Connect インスタンスのメールアドレスに関連付けられたフローを開始する前に、非同期ワークフローによりメールメッセージが処理されます。 Amazon Connect ではメールのメタデータ ( From 、 To 、 CC 、件名 ) にフロー属性としてアクセスしワークフロー内のルーティングを決定できます。ただし、メールメッセージの内容は reference データとして S3 に保存されます。 メールメッセージへのアクセス、分析、利用方法に関する推奨設計は次のとおりです。 メールメッセージを処理するフローを作成し、フロー内の Lambda 関数を呼び出します。 フローをメールアドレスに関連付ける方法については、 Set up email in Amazon Connect を参照してください。 Lambda 関数を使用して S3 のメールメッセージにアクセスします。 ListContactReferences — メールメッセージの場所と添付ファイルの場所のリストを取得します。 GetAttachedFile — S3 からメールメッセージ ( AssociatedResourceArn ) をダウンロードして、選択した自動化ソリューションに送信します。 選択した AI ソリューション ( Amazon Bedrock など ) にメールメッセージを送信します。 メールメッセージ内の意図、感情、キーワード、個人情報を検出するよう自動化ソリューションに促します。 Lambda 関数からの応答をフローに返却します。 意図 ( 例：「パスワードリセット」、「Windows アップデート」、「Wi-Fi が機能しない」 ) 感情 ( 例： 嬉しい、怒っている、悲しい、ニュートラル ) キーワード ( 顧客の名前、住所、電話番号など ) 個人情報検出 ( 例： True / False ) 返却された値に基づいてフロー内で処理を実行します。 「メッセージを送信」ブロックを使用して、顧客からのFAQやよくある質問に自動的に回答します。 顧客の感情に基づいて、キュー内のメールコンタクトをエスカレーションします。 顧客から共有され情報に基づいてプロフィールを入力する。 メール内で個人情報が検出されたことをスーパーバイザーに通知する。 リファレンス実装は GitHub で公開されています。リファレンス実装では Amazon Bedrock で利用可能な Anthropic Claude Haiku モデルを利用しています。このリファレンス実装では必要なアウトプットをキー/バリュー形式で生成し、 Amazon Connect フロー内の後続のステップで利用します。 まとめ メール管理に AI による自動化を採用することで、組織はカスタマーサポートの対応方法を変革できます。これにより、メールの量が増えても、サービスの質を犠牲にすることなく業務を拡大できます。このソリューションを実装することで、 Amazon Connect のお客様は、高度なパーソナライゼーションと応答性を維持しながら、顧客からの問い合わせを効率的に処理することができます。 本ブログはソリューションアーキテクトの奈良 一希が翻訳しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 いよいよ今週は AWS re:Invent です。 様々なセッションが予定されています。オンラインで視聴できるものもあるので、皆さんぜひチェックしてください。 週刊AWSも次回はre:Invent 特別号を予定しています！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年11月25日週の主要なアップデート 11/25(月) Request future dated Amazon EC2 Capacity Reservations Amazon EC2 キャパシティ予約が将来日付のリクエストをサポートしました。これにより将来の利用予定に対して特定アベイラビリティゾーンのキャパシティを予約し安心して利用することが可能になります。この機能はすべてのAWS 商用リージョン、AWS 中国リージョン、および AWS GovCloud (米国) リージョンで追加費用なしで利用できます。詳細については ドキュメント をご確認ください。 Amazon EC2 Capacity Blocks now supports instant start times and extension Amazon EC2 Capacity Blocks for MLに３つの機能が追加され、より柔軟なGPUやMLチップの確保が可能になりました。今回の機能追加により、Capacity Blocksを即座に開始し数分でGPUやMLチップをプロビジョニングできるようになった他、Capacity Blocksの拡張することで想定以上の消費に備えることも可能になりました。そしてもう一つはCapacity Blocksの有効期間を延長し最大６ヶ月間プロビジョニングすることが可能になります。Amazon EC2 Capacity Blocksは米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京とメルボルン) の P5e、P5、P4d、Trn1 インスタンスで利用できます。詳細については ドキュメント をご確認ください。 Amazon S3 adds new functionality for conditional writes Amazon S3で、更新前にオブジェクトが変更されていないかどうかを評価する条件付き書き込みを実行がサポートされました。これにより同じオブジェクトに対する同時書き込みを調整し、書き込み競合による誤った上書きを防ぐことができます。この機能はHTTP if-match条件ヘッダーを介してオブジェクトのEtagに対して一致評価を行うことで実現します。この機能はすべてのAWS リージョンで追加料金なしで、AWS SDK、APIまたはCLIを介して利用可能です。詳細については ドキュメント をご確認ください。このリリースと同時に バケットポリシーで条件付き書き込みを義務付ける機能 もリリースされていますので、そちらもチェックしてみてください。 AWS Cloud WAN simplifies on-premises connectivity via AWS Direct Connect AWS Cloud WANがAWS Direct Connectとの直接接続をサポートしました。これまではDirect Connectでオンプレミスネットワークと接続するにはAWS Transit Gatewayが必要でした。今回の統合により接続がより簡単になります。今回の統合によるCloud WAN Direct Connect アタッチメントでは、BGPを使用したAWSとオンプレミスネットワーク間の自動ルート伝達のサポートが追加されています。この機能は当初は 11の商用リージョン で利用可能です。東京と大阪は現時点では未対応な点ご注意ください。また、Direct Connect アタッチメントの料金は他のCloud WAN アタッチメントと同じです。詳細については ドキュメント の他、こちらの ブログ もご確認ください。 Amazon Q Developer now transforms embedded SQL from Oracle to PostgreSQL Amazon Q Developer in the IDEでAWS Database Migration Service (DMS)のスキーマ変換のメタデータを利用したOracle SQLからPostgreSQLへの変換に対応しました。従来はDMSとDMSのスキーマ変換を利用して移行する場合はアプリケーションのSQLを変更先のRDBMSに合わせて手作業で変更する必要がありました。このアップデートによりSQLの変換および検証を効率的に行うことができます。この機能は Visual Studio Code と IntelliJ IDE で利用可能です。 11/26(火) AWS PrivateLink now supports cross-region connectivity AWS PrivateLinkがネイティブなクロスリージョン接続をサポートしました。これまでInterface VPC Endpointは同じリージョンのVPCへの接続のみをサポートしていました。今回のサポートによりクロスリージョンピアリングを設定することなくInterface Endpointを介して他のAWSリージョンでホストされているサービスに接続できるようになります。この機能は東京を含む7つのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon EBS announces Time-based Copy for EBS Snapshots Amazon EBSがTime-based Copy スナップショットを発表しました。この機能は個々のコピーリクエストに対して15分から48時間の範囲で希望時間を指定することで、指定した期間内にEBSスナップショットがリージョン内およびリージョン間で確実にコピーされるものです。これによりリージョン間コピーの時間予測が容易になり、RPO要件の確認が確実になります。また、EventBridgeとCloudWatchの新しいメトリクスSnapshotCopyBytesTransferredを使ってコピーオペレーションのモニタリングも可能になりました。この機能は、AWS コンソール、AWS CLI、AWS SDKを介してすべてのAWS 商用リージョンとAWS GovCloud (米国) リージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon Aurora now supports Graviton4-based R8g database instances AWS Graviton4ベースのR8gインスタンスがAmazon Aurora PosgreSQL互換およびMySQL互換で一般提供されました。Graviton4はGraviton3に比べてワークロードに応じて最大40%のパフォーマンス向上、最大29%のコストパフォーマンス向上が見込めます。このインスタンスはバージニア北部、オハイオ、オレゴンおよびフランクフルトの4つリージョンで利用可能です。インスタンスタイプの方法は ドキュメント をご確認ください。このAuroraアップデートと同時に Amazon RDS for PostgreSQL, MySQL, MariaDBでもR8gとM8gのサポート が発表されています。 Amazon Redshift multi-data warehouse writes through data sharing is now generally available Amazon Redshiftのデータ共有によるマルチデータウェアハウスからの書き込みが一般提供(GA)されました。この機能は複数のRedshift データウェアハウスからRedshiftデータベースに書き込むことができるもので、書き込まれたデータはコミットされるとすぐにすべてのRedshift データウェアハウスで使用できるようになります。これによりワークロードを複数のRedshiftに分割することで、個々の目的に合わせた最適なサイズのウェアハウスを使いながら、データを共有して利用することが可能になります。この機能はAmazon Redshift データ共有がサポートされているすべてのAWSリージョンにおいて、RA3インスタンスタイプを使うプロビジョニングされたクラスターとRedshift Serverlessのワークグループで利用できます。詳細は ドキュメント をご確認ください。 Amazon EC2 C7g instances are now available in additional regions Amazon EC2 C7g インスタンスが大阪とパリの2つのリージョンで新たに利用可能になりました。C7gはAWS Graviton3 プロセッサを搭載しており、Graviton2 ベースのインスタンスよりも最大で25%パフォーマンスが向上します。EC2 C7gの詳細は Webサイト をご確認ください。 AWS Network Firewall expands the list of supported protocols and keywords in firewall rules AWS Network FirewallがHTTP2, QUIC, PostgreSQLなどのプロトコル検出を新たにサポートしました。AWS Network Firewallは Amazon VPC に必要なネットワーク保護を簡単にデプロイできるマネージド型ファイアウォールサービスです。今回の対応によりセキュリティ制御をより柔軟に適用することが可能となります。 11/27(水) Amazon Bedrock Agents now supports custom orchestration Amazon Bedrock Agentsがカスタムオーケストレーションをサポートしました。この機能では計画と解決、思考の木、標準運用手順（SOP）など、カスタマイズされたオーケストレーション戦略をエージェント向けに実装できます。AWS Lambda を使用してオーケストレーションロジックを定義できるため、特定のユースケースに合わせてエージェントの動作を柔軟に調整可能です。この機能はAmazon Bedrock Agentsがサポートされているすべての AWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 AWS Amplify introduces passwordless authentication with Amazon Cognito AWS AmplifyがAmazon Cognitoの新しいパスワードレス認証機能をサポートしました。JavaScript、Swift、Android 用の Amplify クライアントライブラリを使用してSMSワンタイムパスワード、EメールワンタイムパスワードおよびWebAuthn パスキーを使用してアプリケーションへの安全なサインインを実装できます。この機能により、複雑なパスワードを覚える手間が省けるため、顧客体験が向上する他、利用ユーザーと提供企業の両方のアカウント管理が簡素化されます。この機能はAmazon CognitoがサポートされているすべてのAWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon FSx for Lustre now supports Elastic Fabric Adapter and NVIDIA GPUDirect Storage Amazon FSx for LustreがElastic Fabric Adapter (EFA) と NVIDIA GPUDirect Storage (GDS) をサポートしました。Amazon FSx for Lustreは機械学習 (ML) やハイパフォーマンスコンピューティング (HPC)などの高速な処理が求められる際に広く活用いただけるストレージです。今回、EFAをサポートしたことでAWS Scalable Reliable Datagram (SRD) プロトコルを使用してネットワークスループットの使用率を高め、データ転送中にオペレーティングシステムをバイパスすることで、ワークロードのパフォーマンスを向上することが可能になります。GDSはEFAを基盤として実現されており、ファイルシステムとGPUメモリ間で直接データ転送を実現することで最大12倍のスループット向上が可能です。EFAとGDSはPersistent-2 ファイルシステムが利用可能なすべての商用AWSリージョンで利用可能です。詳細についてはブログ” Amazon FSx for Lustre increases throughput to GPU instances by up to 12x “をご確認ください。 Amazon Q Java transformation launches Step-by-Step and Library Upgrades Amazon Q DeveloperにはJavaのアップグレード変換を行うCode Transformationの機能があります。今回この機能が段階的なアップグレードとライブラリのアップグレードに対応しました。一括変換ではなく、少量ずつコード変更を確認できるようになることで、手動でのエラー修正や確認、テストが容易になります。また、すでにJava 17で稼働しているアプリケーションを最新の信頼性の高いライブラリにアップグレードできるため、変換後のアプリケーションに関しても保守にかかる時間と労力を節約できます。これらの昨日はVisual Studio CodeとIntelliJ IDEで利用可能です。詳細は こちら をご確認ください。 Amazon Q Developer for the Eclipse IDE is now in public preview コーディングやテストなどのソフトウェア開発を支援するAmazon Q DeveloperのEclipse IDE用プラグインがパブリックプレビューに入りました。これまではVSCode, IntelliJなどで使うことができましたが、Eclipse IDEでも利用できることでより多くの方にご活用いただけます。このプラグインはAmazon Q Developerがサポートされているすべての AWS リージョンでご利用いただけます。詳細は Blog をご確認ください。 Introducing Amazon Q Apps with private sharing Amazon Q Businessの生成AI搭載アプリを作成する機能であるAmazon Q Appsで、作成したアプリのアクセス制御ができるようになりました。従来はすべてのユーザーに公開しかできませんでしたが、今回のアップデートにより選択したユーザーに限定して共有できることで部署やチーム、個人などアプリケーションの目的に応じて制限が可能です。Amazon Q Appsでのプライベート共有についての詳細は ドキュメント をご確認ください。 11/28(木) アップデートはありませんでした 11/29(金) アップデートはありませんでした 今日は最後に一つ紹介させてください。 最近、開発の場面で生成AIを利用したいという相談をいただくことが増えてきたように感じます。皆さんの周りではいかがでしょうか？同僚のソリューションアーキテクトの淡路(X @gee0awa )が開発につかえる Bedrock のユースケースのサンプルとして Bedrock Engineer というアプリを開発しています。あくまでも個人でのサンプルとして扱っていただければと思いますが、今後正式に公開予定もあるのでもしよかったらチェックしてください。 SA淡路からのコメント Amazon Bedrock を開発にも使用できるユースケースとして、Bedrock Engineer を開発しました。このアプリケーションは自律的な開発エージェントやウェブサイト生成の機能を搭載しています。開発エージェントは、１ファイルだけではなくプロジェクト構造を読み理解した上で一連のコードの生成や仕様書の生成を自動化します。ウェブサイト生成では、React、Vue、Svelte コードを生成してリアルタイムにプレビューするほか、RAG の仕組みを応用することで、デザインシステムに従ったコード生成を実現します。ソフトウェア開発においても生成AIの活用の幅が広がってきたように感じます。ぜひチェックしてみてください。 US時間の日曜日(日本時間の12/2 月曜日 未明)にも多くのアップデートが出ていますが、こちらは次週号で扱う予定です。 それでは、また来週、週刊AWS re:Invent特別号でお会いしましょう！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本記事を読んでいる方の多くは、病院の待ち時間に悩んだことがあるのではないでしょうか。その一方で、全国の外来患者数は 2025 年にピークを迎えると見込まれており、214 の医療圏では 2020 年ですでにピークアウトしていると見込まれています (「 資料ー第７回第８次医療計画等に関する検討会 」より)。待ち時間が減るのは患者にとって良いかもしれませんが、病院にとっては直接的な収入減となります。働き方改革等による人件費増、物価・エネルギー価格高騰といったコスト増がさらに追い打ちとなり、病院の経営に深刻な影響を与えています。実際、2024 年の一般社団法人国立大学病院長会議の記者会見では 42 国立大学病院のうち 32 病院が赤字と報告されており、この中には東京大学医学部附属病院のような首都圏の病院も含まれます ( 国立大学病院長会議 記者会見資料 )。つまり、あなたが定年後しばしば病院のお世話になる時、地元の病院が頼れるかは予断を許さない状況ということです。 2024/11/21 から 24 にかけて開催された 医療情報学連合大会 では、待ったなしの病院の業務・経営改革について各病院の医療情報研究者や実務担当者より多くの発表がありました。AWS もブースの出展やスポンサーセミナーなどを開催させていただきました。本記事では当日講演頂いた恵寿総合病院様、東京大学医学部付属病院様の生成 AI 活用の取り組みを中心にご紹介します。 恵寿総合病院様 : 入退院サマリの作成に生成 AI を活用し迅速な情報連携を実現 能登半島に位置する恵寿総合病院様は、地域医療を支える重要な医療機関です。属する能登北部、中部の医療圏は合計 15 万人ほどの医療圏で、人口減少と高齢化は喫緊の課題です。集住の進行や在宅患者の増加など、外部環境の変化に伴い刻一刻と変化する医療ニーズへ柔軟に対応していくため、院内および患者のデータを集約・共有することによる機動性の向上とその実現を支える安全かつ弾力性あるクラウド環境の活用を進めています。データのデジタル化とモバイル端末での共有体制の整備は、2024 年の能登半島地震での緊急対応においても効果を発揮しました。 ご講演は 社会医療法人財団董仙会 恵寿総合病院 神野 正隆 様 より頂きました 地域医療の提供においては、他院との連携も不可欠です。カルテを基に転院先等に患者の情報を迅速かつを十分伝えることが理想ですが、多忙な医師の業務の中で時間の捻出と書き漏らしができない心理的なプレッシャーが課題でした。 そこで、生成 AI , Amazon Bedrock を通じ利用可能な Anthropic Claude 3.5 を利用しカルテからの退院サマリの作成、提案を試行され精度及び効果の検証を行われました。結果、退院早期の 5 日以内で 65.5% の作成率だったところ 81.1% に改善、さらに医師の心理的負担も優位に下がったと発表頂きました。 このように恵寿総合病院様は、生成 AI やデータ活用を通じて、限られた医療資源の中で持続可能な地域医療の実現に取り組んでいます。単なるデジタル化ではなく、医療サービスのプロセスそのものを変革する真の DX を推進されています。 東京大学医学部附属病院様 : 現場の業務改善から始める不退転の改革 冒頭でご紹介した通り、国立大学病院ではより経営状況が深刻です。42 の国立大学病院のうち 32 病院が赤字であると述べましたが、東京大学医学部附属病院様もその一つとして含まれています。効果の高い薬の開発は患者にとっての恩恵である一方、病院経営を圧迫しています。例えば、脊髄性筋萎縮症 (SMA) に対する遺伝子治療薬「ゾルゲンスマ」は 1 回の投与で 1 億円以上の費用がかかりますが、病院の利益は数百円程度に留まります。診療報酬の支払いには 2 ヶ月程度のタイムラグがあり、手続き等で遅延するとそれだけで資金ショートのリスクが高まります。このような状況下では医療サービス自体の提供形態の変化などが求められますが、その議論は道半ばです。 ご講演は東京大学医学部付属病院 企画情報運営部 副部長 井田 有亮 様 より頂きました このような状況下で、東京大学医学部附属病院様は、医療制度及び医療サービスの改革を待つだけでなく、できることから着手する業務改革を進めています。特に、クラウドサービスを活用した院内インフラの設備投資最適化や、生成 AI を活用した医師業務の効率化を目指しています。医師の書類作成業務効率化では、診療情報提供書と退院サマリからどの程度の精度で返書の文章を生成できるか検証されています。診療情報提供書は PDF 、また退院サマリは複雑な Excel シートの場合もあるためスキャンした画像でも作成できるか検証され、各診療科の医師から実際使えそうなフィードバックが得られています。 今後は退院サマリ、看護サマリなど病院内での文書作成業務へのさらなる横展開を構想されています。 医療現場でセキュリティを担保した PoC を実現する AWS の支援 東京大学医学部附属病院様で利用された生成 AI の検証用環境は AWS がオープンソースで公開している Generative AI Use Cases ( 通称 GenU ) で構築されています。SaaS 等の形式で生成 AI の機能を利用する場合、入出力データの転送や保管について院内の基準に適合しない場合もあると思います。GenU は、ユーザー認証に加えてアクセス元の IP アドレス制限を行うことで限定されたユーザー、環境からのみアクセスを許可できます。GenU が利用する AWS の生成 AI サービスである Amazon Bedrock では送受信されるデータは暗号化されておりデータが第三者に参照されること、またモデル開発者の学習に使用されることもありません。Amazon Bedrock は東京リージョンでも利用できるため、ユーザーの利用とデータの流通は国内に閉じることが可能です。オープンソースであるため AWS の利用料のみでどんなお客様やパートナーの方も利用することができ、 医療情報学連合大会 ではネットワンシステムズ様が GenU のユースケースを医療向けに拡張したデモを展示されていました。 “Use Cases” の名前の通り、チャットや音声認識からの要約など「よく使う」ユースケースがデフォルトで組み込まれており、また「ユースケースビルダー」の機能を使用すれば画面操作のみで追加機能を開発し共有することもできます。 持続的な地域医療の実現に向けた AWS の支援 : 浜松医科大学様との連携 国立大学病院は地域医療の柱のひとつであり、東京大学医学部附属病院様が進めるように業務や医療提供のあり方の変革は喫緊の課題です。このような状況下で、 AWS は 2024 年 11 月、国立大学法人浜松医科大学様と包括連携協定を締結し 、静岡県内において持続可能な保健・医療・介護サービスの実現に向けた医療体制の実現とそれを支えるデジタルインフラの構築に向けて連携していくことを発表しました。浜松医科大学様は静岡県の地域医療体制の中核として、医療データの活用に関しては県内の各医療機関の診療情報を共有する医療情報基盤の実現を目指しています。AWS は、クラウドサービスや生成 AI ソリューションの提供を通じて、安全性の高い医療データ管理基盤の構築や医療機関間のデータ共有、連携の効率化を技術面から支援します。 本連携の先駆けとして、2024 年 4 月施行の医療従事者の働き方改革に対応するため、医療現場における生成 AI 活用プロジェクトを開始します。このプロジェクトでは、各職種の専門性を活かしたタスクシフトを行い、患者により質の高い医療を提供することを目指します。続く 2029 年には浜松医科大学の電子カルテシステム更新にあたり、浜松医療センターとのクラウドサービスを活用したシステム統合も検討しています。 体調が悪いときに地元の病院へ行けば一定の金額で治療を受けられる、私たちがあたり前と認識している日本の医療インフラは、「あたり前」ではない変革、チャレンジなくして維持できない局面に差し掛かっています。AWS は安全かつ柔軟、そして迅速に構築可能なクラウドと生成 AI の環境を提供することで、私たちの子供世代が定年を迎えるころでも変わらず持続可能である地域医療の実現に向けた医療実務者の皆様のチャレンジを支援していきます。本記事を読んでいる方はエンジニアの方が多いと思いますが、IT サービスに関連する会社だけでなく医療の現場でも IT のプロが求められていることを知っていただければ幸いです。

本記事は 2024 年 11 月 7 日に Migration & Modernization Blog で公開された「 AWS for VMware at re:Invent 2024 – Attendee Guide 」を翻訳したものです。 AWS re:Invent は、2024 年 12 月 2 日から 12 月 6 日までラスベガスで開催されます。クラウドジャーニーを加速し、イノベーションを推進する、学びと刺激的な移行ストーリーの変革的な 5 日間にご参加ください。AWS リーダー陣による基調講演、イノベーショントーク、インタラクティブセッション、re:Play でのライブ音楽やゲームなどの楽しいアクティビティなど、参加者が最新のクラウドコンピューティングテクノロジーとトレンドについて学び、ネットワーキングができる、多くの刺激的な機会があります。 2,000 を超えるセッション から選択して参加することができます。VMware ベースのワークロードをクラウドに移行する上で AWS がどのように役立つかを知りたい場合は、移行と変革のジャーニーに役立つ 数十のセッション をご検討ください。本稿では、ニーズに役立つ最適なセッションをご紹介します。現地に参加できない場合でも、多くのブレイクアウトセッションをオンデマンドで視聴したり、基調講演のイノベーショントークを ライブ で視聴したりできます。 Expo でお会いしましょう Expo で AWS for VMware チームに会いましょう! 知識と楽しみがある Expo では、あらゆる種類のエキサイティングなアクティビティが待っています。AWS Village に立ち寄って、AWS エキスパートと会話ができます。AWS for VMware チームは、次の時間帯に AWS for VMware ブースにいます。 12 月 2 日 | 午後 4:00 ～ 午後 7:00 (ウェルカムレセプション) 12 月 3 日 | 午前 10:00 ～ 午後 6:00 12 月 4 日 | 午前 10:00 ～ 午後 6:00 12 月 5 日 | 午前 10:00 ～ 午後 4:00 ハイライトをご覧ください: Amazon Elastic VMware Service: AWS でモダナイゼーションの旅を始めましょう Amazon Elastic VMware Service (Amazon EVS) は、既存のスキルと使い慣れたソフトウェアで、VMware ベースのワークロードを AWS に移行して稼働するためのシンプルな方法です。主な機能について学び、Amazon EVS が提供するシンプルさ、柔軟性、セキュリティ、コントロールから VM がどのように恩恵を受けるかをご覧ください。このソリューションを立ち上げたチームに参加して、既存の VMware Cloud Foundation (VCF) サブスクリプション、VMware 投資、および好みのツールを活用しながらクラウドのメリットを活用する方法を理解しましょう。AWS に VCF 環境をデプロイする方法と、Amazon EVS が特定のニーズを満たすのにどのように役立つかを学ぶことができます。 計画をしましょう ライブで参加できるセッションを見つけやすくするために、日時別にまとめたアジェンダを用意しました。各リストにはセッションの種類とコンテンツのレベルが記載されています。セッションの種類とレベルの詳しい説明については、コンテンツページをクリックしてください。 12 月 2 日(月) 午前 HYB201 | AWS wherever you need it: From the cloud to the edge (Breakout session) | 200 Level | 10:00 AM | Venetian, Titian 2304 クラウドからエッジまで必要な場所に AWS を： ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、デジタル社会のニーズにより、オンプレミスまたはエッジに残るワークロードもあります。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、AWS IoT などの AWS のサービスが、マルチプレイヤーゲーム、高頻度取引、医療用画像処理、スマート製造、データレジデンシー要件のある生成 AI アプリケーションなどのハイブリッドクラウドおよびエッジコンピューティングワークロードをどのようにサポートするかを学びます。 MAM233-S | Disrupt the status quo: How to stop waiting & start innovating on AWS (sponsored by RapidScale) (Breakout session) | 200 Level | 10:00 AM | MGM Grand, Chairmans 370 停滞の打破：AWS でイノベーションを始める方法： 現状維持はイノベーションを阻害します。移行のための魅力的なビジネスケースが作れないこと、収益に影響を与えるアプリケーションのモダナイゼーション、データと AI 戦略の定義することなど、成功する企業とそれを推進する人々は、真のイノベーションを起こすために停滞を克服する必要があります。このセッションでは、セキュリティ、最適化、AI、移行の課題についてビジネスリーダー達が議論します。彼らがこの停滞を克服して AWS でイノベーションを実現した方法を学びましょう。このプレゼンテーションは、AWS パートナーの RapidScale によって提供されます。 MAM102-R | An AWS guide for VMware administrators (Chalk Talk) | 100 Level | 10:30 AM | MGM Grand, Boulevard 169 (Option 1) VMware 管理者向けの AWS ガイド： 初めて AWS への移行に着手する VMware 管理者であれば、このチョークトークに参加して、基礎を身に付け、使い慣れた VMware 環境と AWS の間の知識をシームレスに橋渡ししましょう。AWS マネジメントコンソール、Amazon EC2、Amazon VPC、および VMware 環境に類似したその他の AWS サービスについて理解を深めましょう。ネイティブ AWS ツール、パートナーのサービス、トレーニング、インセンティブプログラムなどの移行ツールを調べて、移行を加速させましょう。AWS 上の VMware ワークロードの移行戦略とモダナイゼーションパスについて学びましょう。ご質問にもお答えします。 MAM104 | AWS for VMware migrations: Successes, roadmaps, & strategies (Breakout session) | 100 Level | 11:30 AM | Caesars Forum, Summit 232. Content Hub: Turquoise Screen AWS for VMware マイグレーションについての成功事例、ロードマップ、戦略： VMware オンプレミス環境を AWS に移行することを検討しており、最適なアプローチに関するガイダンスをお探しですか？このセッションで、移行の先駆者たちが一堂に会します。さまざまなグローバル組織が、計画から実行まで、クラウドへの移行をどのように加速させたかを直接お聞きください。移行を効率化した信頼できるツール、戦略、教訓の共有から、移行を進めるためのインサイトを得ることができるでしょう。さらに、スピーカーからモダナイゼーションロードマップとイノベーション戦略を聞くこともできます。移行を始めたばかりでも、ハードルを乗り越えている場合でも、クラウド変革を推進するための実用的なインサイトが得られるでしょう。 HYB308 | Migrating your VMware workloads with on-premises dependencies (Breakout session) | 300 Level | 11:30 AM | MGM Grand, Grand 120 オンプレミスに依存した VMware ワークロードの移行： VMware ワークロードのほとんどは簡単にクラウドに移行できますが、アプリケーションの相互依存性、データレジリエンシー要件、またはタイムラインの制約により、オンプレミスに残す必要があるワークロードもあります。このセッションに参加して、AWS Outposts や AWS Local Zones などの AWS ハイブリッドおよびエッジサービスを使用して、自身のペースで移行し、モダナイズする方法を学びましょう。Outposts を使用したさまざまな移行パスと、クラウドへの移行を簡素化および加速するために使用できる移行ツールとプログラムについて詳しく説明します。 12 月 2 日(月) 午後 MAM302 | Virtual machine to AWS: Rapid migration & modernization (Workshop) | Level 300 | 12:00 PM | MGM Grand, Grand 117 仮想マシンから AWS に高速に移行し、モダナイゼーションする方法： このワークショップに参加して、仮想環境、物理環境から Amazon EC2 への移行プロセスをガイドしてもらいましょう。VMware のコストとライセンスを削減し、AWS グローバルインフラストラクチャの規模、セキュリティ、柔軟性を活用してイノベーションを加速したいとお考えの場合は、このワークショップで AWS への移行を成功させるためのナレッジとツールを学ぶことができます。エキスパートのプレゼンターが移行プロセスを紹介し、モダナイゼーションへの道のりにおける主要な考慮事項、ベストプラクティス、一般的な課題を取り上げます。参加するにはノートパソコンを持参する必要があります。 EUC204-R | Accelerate your data center exit with Amazon WorkSpaces Core (Chalk Talk) | Level 200 | 2:00 PM | MGM Grand, 307 Amazon WorkSpaces Core でデータセンター移行を加速： オンプレミスのセルフマネージの仮想デスクトップインフラストラクチャ (VDI) はコストがかかり、IT の俊敏性を制限します。さらに、VDI ソフトウェアの価格上昇の可能性に対する懸念から、組織はクラウドへの移行計画を加速させています。このチョークトークでは、オンプレミスの VDI ソリューションを非常にスケーラブルで信頼性の高い AWS クラウドに移行するための考慮事項について説明します。Citrix、Omnissa、Workspot、Leostream の既存の VDI ソフトウェアを使用して Amazon WorkSpaces Core を活用し、コストを削減し、変化するビジネス要件に合わせて迅速に拡張させる方法を学びます。また、実現までの時間を短縮する VDI 移行の実行計画を作成する方法も学びます。 HYB313-R | Extending Amazon EKS clusters from the cloud to the edge (Chalk Talk) | Level 300 | 3:00 PM | Caesars Forum, Academy 414 Amazon EKS クラスタをクラウドからエッジに延伸： リージョン、AWS ローカルゾーン、AWS Outposts 全体で Amazon Elastic Kubernetes Service (Amazon EKS) を活用し、分散アプリケーションのレイテンシーを最小限に抑え、パフォーマンスを向上させる戦略について詳しく説明します。このチョークトークでは、実際のシナリオに基づいてアプリケーションを EKS クラスターにデプロイし、統一されたコントロールプレーンを維持しながら、Outposts とローカルゾーンをシームレスに統合する方法を説明します。実際のユースケースとベストプラクティスを検討することで、分散された環境全体で回復力がありスケーラブルなアプリケーションを設計するための実用的なインサイトを得ることができます。この講演は AWS Well-Architected フレームワークに準拠しており、一貫性とセキュリティのために AWS のデプロイメントを最適化できるようにします。 HYB303 | Step-by-step migration of on-premises VMware workloads to AWS Outposts (Workshop) | Level 300 | 3:30 PM | MGM Grand, Grand 111 オンプレミスの VMware ワークロードを AWS Outposts に段階的に移行： アプリケーションの相互依存性、データレジリエンシー要件、または移行タイムラインの加速化のためにオンプレミスに残す必要がある VMware ワークロードの場合、これらのワークロードを AWS Outposts に迅速にリホストし、自身のペースでモダナイゼーションできます。このワークショップでは、仮想化されたワークロードを AWS Outposts に移行するハンズオンを提供します。プランニング戦略、移行ツール、ベストプラクティスについて学び、移行後の操作と回避すべき落とし穴に関する専門家のインサイトをお聞きください。参加するにはラップトップを持参する必要があります。 MAM214 | Gilead Sciences’ AWS migration: From VMware to cloud transformation (Breakout) | Level 200 | 4:30 PM | MGM Grand, Grand 122 Gilead Sciences における AWS 移行、VMware からクラウドへの変革： Gilead Sciences が AWS プロフェッショナルサービスとグローバルなデジタル変革をどのように推進したかをご覧ください。オンプレミスの VMware から AWS ネイティブサービスに 2,000 台を超えるサーバーを移行し、1,400 台を超えるシステムを廃止したことからヒントを得てください。この取り組みを先導した Gilead のリーダーから、移行アプローチ、活用した AWS ツールとサービス、ワークロードを AWS に移行するためのベストプラクティスについて共有します。AWS を利用することで、Gilead はモダナイゼーションとイノベーションを推進できました。Gilead がデータを最大限に活用し、AI などの新しいテクノロジーを統合してビジネス目標を達成する方法についてのインサイト得てください。 12月3日(火) 午後 MAM237-NEW | New Launch – Deep dive into Amazon Elastic VMware Service (Chalk Talk) | Level 200 | 4:30PM | Caesars Forum, Level 1, Alliance 305 ニューリリース – Amazon Elastic VMware Service の詳細： Amazon Elastic VMware Service (Amazon EVS) は、既存のスキルと使い慣れたソフトウェアで、VMware ベースのワークロードを AWS に移行して実行するためのシンプルな方法です。このチョークトークでは、サービスコンソールと API を使用して、AWS 上で完全に機能する VCF ベースの環境の構成とデプロイメントについて説明します。VMware ESXi、vCenter、NSX、および SDDC Manager への無制限の管理者アクセスにより、ネットワーク、コンピューティング、およびストレージ構成を制御できます。AWS の専門家と交流し、Amazon EVS の基礎を理解してください。 EUC204-R1 | Accelerate your data center exit with Amazon WorkSpaces Core (Chalk Talk) | Level 200 | 1:00 PM | Wynn, Lafite 1 (Option 2) Amazon WorkSpaces Core でデータセンター移行を加速： オンプレミスのセルフマネージの仮想デスクトップインフラストラクチャ (VDI) はコストがかかり、IT の俊敏性を制限します。さらに、VDI ソフトウェアの価格上昇の可能性に対する懸念から、組織はクラウドへの移行計画を加速させています。このチョークトークでは、オンプレミスの VDI ソリューションを非常にスケーラブルで信頼性の高い AWS クラウドに移行するための考慮事項について説明します。Citrix、Omnissa、Workspot、Leostream の既存の VDI ソフトウェアを使用して Amazon WorkSpaces Core を活用し、コストを削減し、変化するビジネス要件に合わせて迅速に拡張させる方法を学びます。また、実現までの時間を短縮する VDI 移行の実行計画を作成する方法も学びます。 STG337 | Migrate any VMware workload from anywhere to improve your TCO (Chalk Talk) | Level 300 | 1:00 PM | MGM Grand, 305 あらゆる VMware ワークロードを移行して TCO を改善： 複雑な VMware 環境がコストを押し上げ、管理オーバーヘッドを増加させているという問題を抱えていませんか? このセッションでは、VMware ワークロードを移行することで管理性を向上させ、総所有コストを削減する方法をご紹介します。Amazon FSx for NetApp ONTAP が iSCSI 経由でブロックストレージを提供するコンピューティング用に Amazon EC2 に移行する方法を学びます。移行前と移行後のアーキテクチャをガイドし、ワークロードがどこにあってもシームレスなリフトアンドシフトを実行するためのステップバイステップのアプローチを提供します。移行によってエンタープライズグレードのパフォーマンス、コスト効率、および簡素化された運用がどのように実現されるかについて、実用的なインサイトを得られます。 NTA204| Transitioning from VMware to native AWS (Chalk Talk) | Level 200 | 4:30 PM | Caesars Forum, Academy 414 VMware からネイティブ AWS への移行： vSphere CLI と AWS CLI には多くの類似点があります。このチョークトークでは、一般的な vSphere アクティビティについて説明し、VMware から AWS への移行を容易にする AWS CLI コマンドについて詳しく説明します。 MAM218 | Technical decisions for a seamless migration from VMware to AWS (Chalk Talk) | Level 200 | 4:30 PM | Mandalay Bay, South Pacific D VMware から AWS へのシームレスな移行のための技術的な決定 ： VMware ベースのワークロードを AWS に移行するには、慎重な技術的な決定が必要です。このチョークトークでは、シームレスな移行のためのロードマップを提供し、データドリブンなビジネスケースの開発、適切な検出ツールとアセスメント、AWS 基盤の確立、適切な移行およびモダナイゼーションツールの選択などの重要な側面を取り上げます。参加者は、AWS Application Discovery Service、AWS Application Migration Service、および同等の AWS パートナーツールなど、最も一般的に使用される AWS 移行サービスに詳しくなるでしょう。各フェーズに関係する主要な技術的決定に関するインサイトを得ることで、AWS クラウドのパワーを活用しながら停止を最小限に抑え、自信を持ってマイグレーションジャーニーを推進できるようになります。 MAM202-R | From VMs to cloud-native: An AWS modernization journey (Workshop) | Level 200 | 4:30PM | Mandalay Bay, Lagoon F (Option 1) VM からクラウドネイティブへ、AWS のモダナイゼーションの旅 ： このワークショップでは、AWS モダナイゼーションパスウェイを使用して、モノリシックなワークロードを疎結合の分散型マイクロサービス アーキテクチャにすばやく分解する方法を学びます。実際の移行シナリオを順に説明します。まず、VMware ベースのアプリケーションを AWS に移行し、その後、それらのアプリケーションをモダナイズするための手順を順を追って説明します。AWS のエキスパートが、モノリシックアプリケーションを最新のクラウドアーキテクチャに変換するためのベストプラクティスを共有します。モノリシックアプリケーションをコンテナ化し、マネージドデータベースに移行し、アプリケーションをサーバーレスに移行する際に、AWS App Runner、Amazon Aurora、AWS Lambda などの AWS サービスを活用する方法を学びます。参加するには、ラップトップを持参する必要があります。 MAM238-INT | Automating migration and modernization to accelerate transformation (Innovation Talk) | Level 200 | 5:30 PM | Venetian, Palazzo Ballroom B 移行とモダナイゼーションの自動化による変革の加速 ： 多くの組織は、既存のアプリケーションとそこに閉じられたデータから価値を引き出すことに苦労しています。このトークでは、AWS が最も複雑な移行とモダナイゼーションのタスクを簡素化して、レガシーシステムの変革を加速し、クラウド イノベーションを実現する方法について説明します。チームを横断する移行とモダナイゼーションにおいて、検出、計画、実行し、アプリケーションを最新のアーキテクチャにアップグレード、リプラットフォーム、リファクタリングする方法を変える画期的な AWS サービスについて学びます。ミッションクリティカルなアプリケーションとデータをクラウドに効率的に移行および改善して、運用コストとライセンス料を削減し、イノベーションを加速し、レガシーコードベースのメンテナンス遅延のリスクを軽減する方法を見つけます。 12 月 4 日(水) 午前 TNC107 | Virtual machines to AWS rapid migration and modernization (Bootcamp) | Level 100 | 8:00 AM | Mandalay Bay, Breakers K 仮想マシンから AWS への迅速な移行とモダナイゼーション：  AWS パートナー向けのブートキャンプです。AWS Application Migration Service を利用して、最小限のアーキテクチャ変更でワークロードを AWS クラウドに移行するリホスト (リフトアンドシフト) 移行戦略に焦点を当てています。移行プロジェクトに携わるテクニカルアーキテクト、マイグレーションスペシャリスト、システム管理者、プロジェクトマネージャー向けのこのブートキャンプでは、Application Migration Service を使用して移行を実行する方法を学習します。このブートキャンプの前提条件には、AWS アカウントへのアクセス、AWS マネジメントコンソールと Application Migration Service、Amazon VPC、AWS Identity and Access Management (IAM)、AWS Elastic Disaster Recovery の基本的な知識が含まれます。参加にはご自身のラップトップを持参する必要があります。 HYB310 | Addressing data residency requirements with hybrid and edge services (Chalk Talk) | Level 300 | 8:30 AM | MGM Grand, Boulevard 158 ハイブリッドおよびエッジサービスによるデータレジデンシー要件への対応： データレジデンシーは、個人識別情報 (PII)、財務データ、医療データ、国家安全保障に関する情報などの機密情報を収集して保存する組織にとって重要な考慮事項です。複数の地域で事業を展開する組織がデータレジデンシー要件を満たしながらイノベーションを推進できるように、AWS は AWS Regions, AWS Dedicated Local Zones, AWS Local Zones, and AWS Outposts などの複数のグローバルインフラストラクチャサービスを提供しています。このインタラクティブなチョークトークでは、これらのインフラストラクチャサービスが、データレジデンシーのニーズを満たしながらデジタルトランスフォーメーションを加速するのにどのように役立つかを学びます。 MAM315 | Simplify VMware server migrations via AWS Migration Hub and Amazon Q (Workshop) | Level 300 | 9:00 AM | Mandalay Bay, Islander I AWS Migration Hub と Amazon Q による VMware サーバーの移行のシンプル化： このワークショップでは、VMware サーバーを AWS に移行する実践的な経験を積むことができます。AWS Migration Hub Journeys テンプレートを使用して、2 つのサンプルアプリケーションをシームレスかつ効率的に移行する方法を学びます。AWS Migration Hub を活用して、反復的なタスクの実行を高速化します。最後に、生成 AI を使用して Amazon Q でカスタムビジネスアプリケーションを作成し、移行プロセス中にアプリケーションチームにコンシェルジュサポートを提供し、信頼できる移行リソース集で強化する方法を学びます。参加するには、ラップトップを持参する必要があります。 KUB310 | Amazon EKS for edge and hybrid use cases (Breakout Session) | Level 300 | 10:00 AM | Wynn, Lafite 4. Content Hub: Turquoise Screen Amazon EKS のエッジおよびハイブリッドユースケース： 製造、医療、通信、金融サービスなどの業界では、低レイテンシー、データ依存性、データ主権、またはその他の規制上の理由により、オンプレミス、エッジ、またはハイブリッドシナリオで実行する必要があるワークロードがあります。データ依存のワークロードは、データが AWS サービスに配置されてから完全に移行する必要がある場合があります。このセッションでは、Amazon EKS Anywhere などのサービスを使用してコンテナワークロードをオンプレミスで実行し、VMware ベースのワークロードのモダナイゼーションをサポートする Production Ready のアーキテクチャについて説明します。 HYB401 | AWS hybrid cloud and edge computing from the lens of VMware architects (Chalk Talk) | Level 400 | 10:00 AM | MGM Grand, 307 VMware アーキテクトの視点から見た AWS ハイブリッドクラウドとエッジコンピューティング : このチョークトークでは、AWS Outposts の観点から Amazon EC2 のインスタンスの回復性、配置グループ、自動スケーリングの概念について説明し、VMware アーキテクトが High Availability (HA)、Distributed Resource Scheduler (DRS)、アフィニティグループ、ストレッチクラスターなどの VMware 機能とどのように類似点を見出すことができるかについて説明します。また、VPC 内ルーティングを使用して同じロケーションにある 2 つの Outposts 間で復元力のあるアーキテクチャを設計する方法についても説明します。さらに、AWS Elastic Disaster Recovery を活用してオンプレミスのワークロードを AWS Outposts に移行する方法についても説明します。 MAM239-S | The secret to cloud success: What happens after migration? (sponsored by Trianz | Concierto) (Lightning Talk) | Level 200 | 11:30 AM | Venetian, Hall B クラウド成功の秘訣: 移行後に何が起こるか? (Trianz | Concierto 提供) ： なぜ企業はクラウドに移行すべきなのでしょうか? 顧客にとっての企業の価値を変革するには、大きく視点を変えることが必要です。この変革は、分析、予測モデル、および生成 AI によって推進されます。これらには、クラウドだけが提供できる堅牢なコンピューティング、ストレージ、およびサービスが必要です。クラウド移行は、運用効率の向上だけではありません。変革に必要な技術基盤を確立し、移行中および継続的な管理と最適化において新たな機会を切り開きます。このライトニングトークでは、Concierto がどのように移行を加速し、クラウド運用を拡大したのかを学べます。AWS パートナーである Trianz、Concierto によるプレゼンテーションです。 12 月 4 日(水) 午後 MAM102-R1 | An AWS guide for VMware administrators (Chalk Talk) | Level 100 | 4:00 PM | Wynn, Montrachet 1 (Option 2) VMware 管理者向けの AWS ガイド： 初めて AWS への移行に着手する VMware 管理者であれば、このチョークトークに参加して、基礎を身に付け、使い慣れた VMware 環境と AWS の間の知識をシームレスに橋渡ししましょう。AWS マネジメントコンソール、Amazon EC2、Amazon VPC、および VMware 環境に類似したその他の AWS サービスについて理解を深めましょう。ネイティブ AWS ツール、パートナーのサービス、トレーニング、インセンティブプログラムなどの移行ツールを調べて、移行を加速させましょう。AWS 上の VMware ワークロードの移行戦略とモダナイゼーションパスについて学びましょう。ご質問にもお答えします。 HYB313-R1 | Extending Amazon EKS clusters from the cloud to the edge (Chalk Talk) | Level 300 | 4:00 PM | Wynn, Lafite 1 (Option 2) Amazon EKS クラスタをクラウドからエッジに延伸： リージョン、AWS ローカルゾーン、AWS Outposts 全体で Amazon Elastic Kubernetes Service (Amazon EKS) を活用し、分散アプリケーションのレイテンシーを最小限に抑え、パフォーマンスを向上させる戦略について詳しく説明します。このチョークトークでは、実際のシナリオに基づいてアプリケーションを EKS クラスターにデプロイし、統一されたコントロールプレーンを維持しながら、Outposts とローカルゾーンをシームレスに統合する方法を説明します。実際のユースケースとベストプラクティスを検討することで、分散された環境全体で回復力がありスケーラブルなアプリケーションを設計するための実用的なインサイトを得ることができます。この講演は AWS Well-Architected フレームワークに準拠しており、一貫性とセキュリティのために AWS のデプロイメントを最適化できるようにします。 EUC204-R2 | Accelerate your data center exit with Amazon WorkSpaces Core (Chalk Talk) | Level 200 | 5:30 PM | MGM Grand, 305 (Option 3) Amazon WorkSpaces Core でデータセンター移行を加速： オンプレミスのセルフマネージの仮想デスクトップインフラストラクチャ (VDI) はコストがかかり、IT の俊敏性を制限します。さらに、VDI ソフトウェアの価格上昇の可能性に対する懸念から、組織はクラウドへの移行計画を加速させています。このチョークトークでは、オンプレミスの VDI ソリューションを非常にスケーラブルで信頼性の高い AWS クラウドに移行するための考慮事項について説明します。Citrix、Omnissa、Workspot、Leostream の既存の VDI ソフトウェアを使用して Amazon WorkSpaces Core を活用し、コストを削減し、変化するビジネス要件に合わせて迅速に拡張させる方法を学びます。また、実現までの時間を短縮する VDI 移行の実行計画を作成する方法も学びます。 12 月 5 日(木) 午前 MAM103 | The future of your VMware-based workloads with AWS (Breakout) | Level 100| 11:00 AM | Mandalay Bay, South Seas F AWS による VMware ベースのワークロードの将来: VMware ベースのワークロードに適した移行先のクラウドを選択することは、ビジネスにとって非常に重要です。このセッションに参加して、AWS がお客様と協力してこの道のりを進む方法を学びましょう。AWS は、クラウドジャーニーを支援するための適切なガイダンスとして実証済みの移行パスと目的別のサービスを提供します。移行、モダナイゼーション、イノベーションの適切な組み合わせを実現し、現在および将来のビジネス目標を満たすために利用可能なオプションとパスを見つけてください。AWS と AWS パートナーは、VMware 環境のシームレスな変革の支援に尽力しています。 12 月 5 日(木) 午後 MAM119-New | New Launch – Amazon Elastic VMware Service: Start your modernization journey (Breakout) | Level 100 | 2:30 PM | Mandalay Bay, Level 3 South, South Seas A ニューリリース – Amazon Elastic VMware Service: モダナイゼーションの旅をはじめましょう： Amazon Elastic VMware Service (Amazon EVS) は、既存のスキルと使い慣れたソフトウェアで、VMware ベースのワークロードを AWS に移行して稼働するためのシンプルな方法です。主な機能について学び、Amazon EVS が提供するシンプルさ、柔軟性、セキュリティ、コントロールから VM がどのように恩恵を受けるかをご覧ください。このソリューションを立ち上げたチームに参加して、既存の VMware Cloud Foundation (VCF) サブスクリプション、VMware 投資、および好みのツールを活用しながらクラウドのメリットを活用する方法を理解しましょう。AWS に VCF 環境をデプロイする方法と、Amazon EVS が特定のニーズを満たすのにどのように役立つかを学ぶことができます。   MAM202-R1 | From VMs to cloud-native: An AWS modernization journey (Workshop) | Level 200 | 12:00 PM | Mandalay Bay, Lagoon F (Option 2) VM からクラウドネイティブへ、AWS のモダナイゼーションの旅 ： このワークショップでは、AWS モダナイゼーションパスウェイを使用して、モノリシックなワークロードを疎結合の分散型マイクロサービス アーキテクチャにすばやく分解する方法を学びます。実際の移行シナリオを順に説明します。まず、VMware ベースのアプリケーションを AWS に移行し、その後、それらのアプリケーションをモダナイズするための手順を順を追って説明します。AWS のエキスパートが、モノリシックアプリケーションを最新のクラウドアーキテクチャに変換するためのベストプラクティスを共有します。モノリシックアプリケーションをコンテナ化し、マネージドデータベースに移行し、アプリケーションをサーバーレスに移行する際に、AWS App Runner、Amazon Aurora、AWS Lambda などの AWS サービスを活用する方法を学びます。参加するには、ラップトップを持参する必要があります。 XNT204 | Licensing commercial software on AWS (Breakout) | Level 200 | 12:30 PM | Wynn, Lafite 4 AWS における商用ソフトウェアのライセンス: AWS は、エンタープライズワークロード向けにさまざまな移行パスを提供していますが、すべてのライセンスオプションをナビゲートするのは混乱を招く可能性があります。このセッションでは、サポート終了、Microsoft、VMware、および Oracle ワークロード向けの AWS Optimization and Licensing Assessment (AWS OLA)、および VMware などの商用ハイパーバイザーの高コストへの対処方法など、Microsoft ソフトウェアのライセンスオプションについて学習します。ソフトウェアライセンス製品とアプリケーションを、クラウドに最適なオープンソーステクノロジーに置き換えることで、将来に備え、ライセンスコンプライアンスのビジネスから脱却できます。 PEX206 | Capitalizing on the opportunity for migrations and modernization (Breakout) | Level 200 | 4:00 PM | Caesars Forum, Summit 232 移行とモダナイゼーションの機会の活用： このセッションでは、繰り返し可能なビジネスエンジンを構築する戦略について紹介します。パートナーがどのように最先端の生成 AI テクノロジーを使って、Microsoft および VMware のワークロードを変革しているのかみてみましょう。効果的なクラウドアセスメントのアプローチを理解し、モダナイゼーションの候補となるワークロードを選定する方法を学びます。AWS への移行とモダナイゼーションの道のりを理解し、Amazon Q の生成 AI を活用して Java および .NET アプリケーションのリファクタリングを加速する方法を学びます。パートナーがマイグレーションアクセラレーションプログラム (MAP) を最大限に活用して、お客様に優れたエクスペリエンスを提供する方法を学びます。 AWS パートナーを対象としたセッションです。 新たな可能性を切り開く準備はできましたか? AWS for VMware チームはラスベガスでお会いできるのを楽しみにしています。 Expo の AWS for VMware ブー​​スにぜひお越しください。AWS が VMware ベースのワークロードのクラウドジャーニーをどのように支援できるかについては、 AWS for VMware ページ をご覧ください。 翻訳は、ソリューションアーキテクトの齋藤が担当しました。原文は こちら 。 著者について Patrick Kremer Patrick Kremer は、VMware ワークロードの移行を専門とするシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に入社し、15 年以上にわたる VMware の経験を活かして、お客様の移行とモダナイゼーションを支援しています。彼は 認定 AWS ソリューションアーキテクトプロフェッショナルであり、教育とブログに情熱を注いでいます。 Bianca Velasco Bianca Velasco は AWS のプロダクトマーケティングマネージャーで、AWS での VMware ベースのワークロードの移行と変革に注力しています。彼女はマーケティングとテクノロジーの分野で 6 年以上の経験があります。AWS 以外では、ボランティア、ダンス、ボルダリングを楽​​しんでいます。 Rodney Bozo Rodney Bozo は、エンタープライズ アプリケーション、移行、モダナイゼーションを専門とするソリューションアーキテクトリーダーです。彼は 20 年以上 IT 業界で働いており、高等教育、コンサルティング、ソフトウェア、クラウド企業で働いた経験があります。彼は情報システム技術の修士号と MBA を取得しており、AWS 認定、Microsoft 認定、Certified Information Systems Security Professional (CISSP) 認定など、さまざまな業界の認定資格も持っています。

本稿は、2024年7月15日に公開された “ Protect against bots with AWS WAF Challenge and CAPTCHA actions ” を翻訳したものです。 ボットの脅威から保護するためには、TCP や HTTP ペイロードの署名のようなリクエストのネットワークレベルでの特性を超えて、クライアント環境の洞察が必要とされます。 AWS WAF は、CAPTCHA や Challenge アクションを利用して、モバイルデバイスまたはブラウザ上でクライアント側とインタラクションを行い、AWS WAF による許可の前にクライアント環境を理解します。Challenge はクライアント(ブラウザまたはモバイルデバイス)がサイレントに課題を解決することを要求します。CAPTCHA はユーザーのブラウザに人間が解く必要がある課題を提示します。 これらのアクションは、ネットワークからのリクエストで得られる以上にリクエスト元のクライアント環境の可視性を高めることで、Allow、Count や Block アクションを補完します。この可視性は正当なユーザーへのインパクトを最小限に抑えながら、ボットトラフィックを特定して、管理するために有用なメカニズムです。 この投稿では、Challenge や CAPTCHA アクションの動作とそれらを利用した特定のボットの脅威の緩和について説明してします。 Challenge や CAPTCHA アクションがボットを特定し管理するための動作 Challenge や CAPTCHA アクションはブラウザまたはモバイルデバイスとのインタラクションを伴います。このインタラクションは、3 つのステージで構成されます : クライアントがサイレントに課題を解く必要があるチャレンジ (Challenge) またはパズルを解く人間とのインタラクションを必要とするチャレンジ (CAPTCHA) クライアント環境を調査してフィンガープリントを生成するクライアント側のスクリプト AWS WAF が課題の解答を検証してクライアントセッションを一意に識別するトークンを生成するためにフィンガープリントを使用する。このトークンは、以降のリクエストに含まれるもので、CAPTCHA や Challenge アクションをパススルーできるかを検証するためのもの このインタラクションは 2 つの方法で処理されます : AWS WAF 統合 SDKs : アプリケーションを AWS WAF に統合することで、これらのステージがアプリケーションやユーザー体験にどのように適合するかを明示的に管理できます。これは、AWS が推奨するアプローチです。 インタースティシャルなインタラクション : AWS WAF はページロードの際に課題を渡すインタースティシャルを含むカスタムレスポンスを提供することでインタラクションのステージを完了します。 これらの 2 つのケースで Challenge や CAPTCHA アクションがユーザーやクライアントとどのようにインタラクションするかを説明します。 Challenge アクションがクライアントとどのようにインタラクションするか Challenge アクションはユーザーの対応なしにクライアント環境でサイレントチャレンジを実行し、ユーザー体験に明らかな影響を与えることを意図しません。Challenge はクライアントが計算量の高いタスク (proof of work) を完了することを要求します。このアプローチは、アプリケーションにエンゲージしようと試みるボットオペレーターに対してコストを増大させながら、ユーザー環境を評価するためのシームレスなメカニズムを正当なユーザーに提供することを意図しています。 統合 SDK なしで Challenge アクションを利用する (インタースティシャルなインタラクション) デフォルトで、Challenge アクションはサイレントにチャレンジを完了する JavaScript チャレンジペイロードを利用して HTML リクエスト (Accept: text/html) に応答します。その後、ユーザーは Challenge を要求する後続のルールを通じてリクエストを許可するトークンを利用して、自動的にオリジナルページにリダイレクトされます。図 1 にこのインタラクションのワークフローを示します。 図 1 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間のインタースティシャルな Challenge のシーケンスダイアグラム アプリケーション統合 SDK を用いた Challenge アクションを利用する もし、アプリケーション統合 SDK にインテグレーションされていない場合、Challenge アクションをトリガーする非 HTML リクエストは、アセットやフェッチリクエストを中断する HTTP 202 レスポンスを返します。そのため、リクエストがサブミットされる前にクライアントがチャレンジを完了して、クライアントがトークンを取得できるようにアプリケーション統合 SDK をインテグレーションすることを推奨します。図 2 のワークフローでこのインタラクションを説明します。 図 2 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における SDK 統合利用時の Challenge のシーケンスダイアグラム アプリケーション統合 SDK を利用したインテグレーションでは、AWS WAF Bot Control または AWS WAF Fraud Control などの少なくとも一つの Amazon マネージドルールを使用する必要があります。投稿済みの「 Use AWS WAF CAPTCHA to protect your application against common bot traffic 」や「 Prevent account creation fraud with AWS WAF Fraud Control – Account Creation Fraud Prevention 」を参照してください。2 つのタイプのアプリケーション統合 SDK を利用できます。 JavaScript SDK : この SDK は、ブラウザベースのアプリケーション、特に AWS WAF のルールにより API エンドポイントが一般的にボットの攻撃から保護されているシングルページアプリケーション (SPA) に最適です。それぞれのリクエストで生成され、利用できるトークンを確保するために JavaScript SDK をインテグレートする 3 つのパートがあります。 必須: HTML の head に JavaScript を埋め込みます。これにより、ページロード時にチャレンジが実行されます。 推奨: フェッチ呼び出しを アプリケーション統合 SDK のフェッチラッパー (AwsWafIntegration.fetch) を使うように更新します。これにより、リクエストを送信する前に必ずトークンを取得できます。別の方法として、 AwsWafIntegration.getToken() を使って AWS WAF トークンを取得 し、x-aws-waf-token ヘッダーを設定できます。 アプリケーションがドメイン間でリクエストを行う場合、 トークンドメイン を設定します (例えば、www.example.com から api.example.com への API リクエスト)。 Mobile SDK : この SDK は、Android と iOS の両方で利用できます。基本的なワークフローは、 AWS ドキュメント で説明されている JavaScript SDK と同様です。 参考 : Challenge アクションを利用した DDoS 脅威からアプリケーションを保護する ボットオペレーターは、数万のボットを使って同時に小さなリクエストを起動することで、アプリケーションを標的にすることができます。すべてのボットからの同時リクエストの総数はアプリケーションを圧倒する可能性がありますが、IP 当たりのリクエスト数が AWS WAF のレートリミットルールの閾値である 1 分間に 100 リクエストを下回ります( 2024 年 8 月 30 日の アップデート により、レートリミットの最低閾値を 10 リクエストに設定できるようになりました)。リクエストがアプリケーションに転送される前にチャレンジを完了する必要がある AWS WAF ルールを設定することで、これらの脅威の影響を最小限に抑えることができます。これにより、ボットオペレーターが proof of work を完了する必要があり、オペレーターのコストが増加します。ここでは、エンドポイント /account に対して、すべてのリクエストでチャレンジの完了が必要となる独自のAWS WAFルールを設定します: AWS WAF Console を開き、次のいずれかを実行する 新しい web ACL を作成するために、 Create web ACL を選択する 既存の web ACL を編集するために、ACL の名前を選択する Rules タブより、Add Rules のドロップダウンから Add my own rules and rule group を選択する Rule 定義にて ルール名を Name に入力する ルールタイプを Regular rule のままにする Statement 定義にて図 3 で示すように次の情報を入力する Inspect では URI path を選択する Match type では Exactly matches string を選択する String to match では /account を入力する Action 定義では Challenge を選択する 図 3 : Challenge アクションに関する AWS WAF コンソールの構成 web ACL にルールを追加するために、 Add rule を選択する web ACL でのルールの優先順位を設定して、 Save を選択する オプション: AWS WAF Bot Control または AWS WAF Fraud Control rule group を利用するなら、AWS WAF アプリケーション統合 SDK をアプリケーションにインテグレーションする AWS WAF コンソールに戻る Application Integration を選択する アプリケーション統合を有効にする Web ACLs に対して構成 web ACL がデプロイされたリージョンをドロップダウンボックスから選択する Web ACL Name を選択する JavaScript SDK 構成を拡張する アプリケーションにコードをコピーする 先の説明のようにアプリケーション内で SDK を設定する CAPTCHA アクションがクライアントとどのようにやりとりするか CAPTCHA アクションでは、リクエストが成功する前に人間がパズルを解く必要があります。このパズルは、ユーザーが人間であることを証明することが目的です。図 4 は、ユーザーが解く必要のある 2 種類のパズルを示します。 図 4 : AWS WAF CAPTCHA の課題 アプリケーション統合 SDK を利用せず CAPTCHA アクションを使用する アプリケーションに対して統合 SDK を利用せず CAPTCHA アクションを使用する場合、CAPTCHA アクションをトリガーとする HTML(Accept: text/html) へのリクエストは、CAPTCHA パズルを提示するページを返し、バックグラウンドでチャレンジを解決します。CAPTCHA を解決した後、AWS WAF がトークンを発行し、トークンの有効期限まで CAPTCHA アクションを含むルールを通過する後続のリクエストを許可します。トークンについては後で詳しく説明します。図 5 のワークフローは、ユーザー、ブラウザ、AWS WAFの相互作用を示します。 図 5 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間におけるインタースティシャルな CAPTCHA でのインタラクションのシーケンスダイアグラム CAPTCHA JavaScript API を用いた CAPTCHA アクションを利用する CAPTCHA JavaScript API は、CAPTCHA アクションで保護されたリソースにリクエストが送信される前にいつでも、フロントエンド Web アプリケーション内で CAPTCHA パズルを表示する機能を提供します。これにより、バックグラウンドでもチャレンジが完了します。text/html ではないアセット(画像、JavaScript) やフェッチリクエストが、フロントエンド Web アプリケーションとユーザー体験を中断する可能性のある HTTP 405 レスポンスコードを受け取るため、これが推奨されるアプローチでです。図 6 のワークフローは、AWS WAF トークンを生成するために必要なインタラクションを示しています。投稿済みの「 Use AWS WAF CAPTCHA to protect your application against common bot traffic 」でアプリケーションに CAPTCHA JavaScript API をインテグレーションするための手順や React で CAPTCHA JavaScript API をインテグレーションする コードサンプル について記載しています。AWS WAF CAPTCHA は、モバイルデバイスではサポートされていません。 図 6 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における CAPTCHA SDK でのインタラクションのシーケンスダイアグラム 参考 : IP 評価に基づいて人間が CAPTCHA を完了することを要求する IP 評価ルールは、ボットや他の脅威トラフィックに一般的に関連付けられている IP アドレスを特定し、ブロックすることに役立ちます。例えば、AWSManagedIPDDoSList ルールを使用することで、AWS 脅威インテリジェンスが DDoS アクティビティを特定して関連する IP トラフィックをブロックできます。もし、正規のユーザーがボットオペレーターが管理するネットワーク上の別のデバイスと同じ IP アドレスを共有している場合、問題になる可能性があります。代わりに、アプリケーションへのリクエストを送信する前に CAPTCHA を解決することを正規のユーザーに要求することで、このルールを通じて正規のユーザーを許可できます。 AWS WAF Console を開き、次のいずれかを実行する 新しい web ACL を作成するために、 Create web ACL を選択する 既存の web ACL を編集するために、ACL の名前を選択する Rules タブより、Add Rules のドロップダウンから Add managed rule groups を選択する web ACL に Amazon IP reputation list ルールを追加する。そのとき、ルールを編集するために Edit を選択する Amazon IP reputation list rules に対して以下を参照 図 7 で示すように、 AWSManagedIPDDoSList に CAPTCHA を選択する 図 7 : CAPTCH で上書きした Amazon IP reputation rule の設定 設定を保存するために、 Save を選択する web ACL に Amazon IP reputation list rules ルールグループを追加するために、 Add rules を選択する web ACL でのルールの優先順位を設定して、 Save を選択する オプション: CAPTCHA JavaScript SDK を利用してアプリケーションにインテグレートする トークンがどのように動作するか Challenge および CAPTCHA アクションの結果、AWS WAF はトークンを生成します。トークン自体は暗号化、改ざん防止がされており、aws-waf-token の cookie として実装されます。トークンはユーザーには意識されないものですが、クライアントセッションを識別するのに役立つ詳細情報を含んでいます。これらの詳細には以下のものが含まれます: タイムスタンプ : トークンが生成された時間。デフォルトでは、クライアントは 5 分間再チャレンジされません。ウェブACL のためのイミュニティ時間の設定については、 AWSのドキュメント に記載があります。 ブラウザのフィンガープリント : クライアントのブラウザ環境のデータポイントの集合体から生成されたハッシュ。これにはブラウザのプラグイン、JavaScript の環境、および他の特性が含まれます。 解決済みのパズルタイプ : Challenge または CAPTCHA (あるいはその両方)が完了したかどうか。 トークンドメイン : AWS WAF が受け入れるリクエストを送信しているドメイン。デフォルトでは、クライアントのホスト名に、たとえば、www.example.com などに基づいて設定され、またトークンクッキーに対して使用するようにセットされます。このクッキーとトークンは、リクエストごとに www.example.com へ送信されます。 このドキュメント にあるようにフロントエンドアプリケーションや WebACL でトークンドメインを更新することができます。これは、www.example.com で実行されるシングルページアプリケーション (SPA) や api.example.com で実行される API などがある場合に便利です。トークンドメインを .example.com に設定するとブラウザが example.com 配下のすべてのサブドメインでトークン/クッキーを送信します。トークンドメインの設定の詳細については、 ドキュメント をご覧ください。 ボットトラフィックの管理のために、Challenge、CAPTCHA およびトークンがどのように使用されるか これらのアクションと生成されたトークンには、ボットトラフィックの識別と管理に役立つ以下のような特徴があります: 完全なクライアントを要求 : Challenge アクションと CAPTCHA アクションはクライアント側のスクリプトを実行できるクライアントを必要とします。これにより、JavaScript を実行できないシンプルな HTTP リクエストベースのボットを抑制します。 ボットオペレーターのコストを上げる : Challenge と CAPTCHA パズルを解決するためには、ボットオペレーターがより高度なボットの構築と運用に投資する必要があります。これは、アプリケーションを使うボットにとってさらなる参入障壁となります。 クライアントを一意に識別 : 同一の IP アドレスを共有したり、IP アドレスを切り替えたりするクライアントも一意のトークンによって区別できるため、単一のホスト/ IP から複数のクライアントを簡単に模倣することができません。 クライアント環境のフィンガープリント : トークンで提供されるフィンガープリントは、ボットの自動化の兆候となるブラウザやモバイルデバイスの設定を識別するのに使えます。 結論 この投稿では、AWS WAF を用いた Challenge や CAPTCHA の動作や高度なボットの脅威を緩和するためのこれらの使い方について説明しました。 CAPTCHA and Challenge actions best practices のドキュメントでは、これらのアクションを最大限に活用するガイダンスが提供されています。 著者について David MacDonald David は、ニュージーランドのスタートアップ企業がセキュアでスケーラブルなソリューションを構築できるよう支援をするシニアソリューションアーキテクトです。彼のキャリアのほとんどは、様々な業界に対してサービスを提供する SaaS プロダクトの構築と運用に費やされています。 Jess Izen Jess Izen は、AWS WAF のシニアソフトウェア開発エンジニアとして、Bot Control や Fraud Control のようなプロダクトを構築しています。彼女は、パフォーマス重視で同時実行される Rust サービスや Kafka や Redis/Valky などの技術を含む分散システムの開発に取り組むことを好みます。時間があるときには、自転車に乗ったり、アマチュアのムエタイに出場したりしています。 LinkedIn で彼女と繋がることができます。 翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。

11 月 27 日、 Amazon FSx for Lustre での Elastic Fabric Adapter (EFA) と NVIDIA GPUDirect Storage (GDS) のサポート開始を発表しました。EFA は、高レベルのノード間通信を必要とするアプリケーションを大規模に実行できるようにする、Amazon EC2 インスタンス用のネットワークインターフェイスです。GDS は、ローカルストレージまたはリモートストレージと GPU メモリ間の直接データパスを作成するテクノロジーです。これらの機能強化により、EFA/GDS サポートを備えた Amazon FSx for Lustre では、以前の FSx for Lustre バージョンと比較して、クライアントあたりのスループットが最大 15 倍 (最大 1,500 Gbps) 向上しました。 FSx for Lustre を使用すると、深層学習トレーニング、創薬、財務モデリング、自動運転車開発など、最も高いパフォーマンスが要求されるアプリケーションを構築して実行できます。データセットが増え、新しいテクノロジーが誕生するにつれて、Amazon EC2 P5 、 Trn1 、 Hpc7a などのますます強力な GPU インスタンスや HPC インスタンスを採用できるようになります。これまで、FSx for Lustre ファイルシステムにアクセスする場合、従来の TCP ネットワークを使用すると、個々のクライアントインスタンスのスループットは 100 Gbps に制限されていました。この採用により、大規模なデータセットにアクセスする際に、最先端の EC2 インスタンスの増加するネットワーク帯域幅を最適に活用するために必要となるパフォーマンスを提供する、FSx for Lustre ファイルシステムの必要性が高まっています。 FSx for Lustre の EFA と GDS のサポートにより、アプリケーションで P5 GPU インスタンスと NVIDIA CUDA を使用した場合、クライアントインスタンスあたり最大 1,500 Gbps のスループット (以前のスループットの 15 倍) を実現できるようになりました。 この新機能によって、最も強力なコンピューティングインスタンスのネットワーク帯域幅を最大限に活用し、 機械学習 (ML) と HPC のワークロードを高速化できます。EFA は、オペレーティングシステムをバイパスし、 AWS Scalable Reliable Datagram (SRD) プロトコル を使用してデータ転送を最適化することで、パフォーマンスを向上させます。GDS は、CPU をバイパスして冗長なメモリコピーを排除し、ファイルシステムと GPU メモリ間の直接データ転送を可能にして、パフォーマンスをさらに向上させます。 これが実際にどのように機能するかを見てみましょう。 EFA 対応の Amazon FSx for Lustre ファイルシステムの作成 はじめに、 Amazon FSx コンソール で、 [ファイルシステムを作成] を選択してから、 [Amazon FSx for Lustre] を選択します。 ファイルシステムの名前を入力します。 [デプロイとストレージタイプ] セクションで、 [永続的、SSD] と新しい [EFA 対応] オプションを選択します。 [ストレージ単位あたりのスループット] セクションで [1,000 MB/s/TiB] を選択します。これらの設定では、 [ストレージ容量] に 4.8 TiB と入力します。これは、これらの設定でサポートされる最小容量です。 ネットワーキングには、 デフォルトの仮想プライベートクラウド (VPC) と EFA 対応のセキュリティグループ を使用します。他のすべてのオプションはデフォルト値のままにします。 すべてのオプションを確認して、ファイルシステムの作成に進みます。数分後、ファイルシステムは使用できる状態になります。 Amazon EC2 インスタンスからの EFA 対応の Amazon FSx for Lustre ファイルシステムのマウント Amazon EC2 コンソール で、 [インスタンスを起動] を選択し、インスタンスの名前を入力して、Ubuntu Amazon マシンイメージ (AMI) を選択します。 [インスタンスタイプ] では、 [trn1.32xlarge] を選択します。 [ネットワーク設定] では、デフォルト設定を編集し、FSx Lustre ファイルシステムで使用されているのと同じサブネットを選択します。 [ファイアウォール (セキュリティグループ)] では、FSx for Lustre ファイルシステムが使用する EFA 対応のセキュリティグループ、デフォルトのセキュリティグループ、Secure Shell (SSH) アクセスを提供するセキュリティグループの 3 つの既存のセキュリティグループを選択します。 [高度なネットワーク構成] では、 [インターフェイスタイプ] として [ENA と EFA] を選択します。この設定がないと、インスタンスは従来の TCP ネットワークを使用し、FSx for Lustre ファイルシステムとの接続のスループットは 100 Gbps に制限されます。 スループットを向上させるには、インスタンスタイプに応じて EFA ネットワークインターフェイスを追加できます。 インスタンスを起動し、インスタンスの準備が整ったら、 EC2 Instance Connect を使用して接続し、 「FSx for Lustre ユーザーガイド」の Lustre クライアントのインストール と EFA クライアントの設定 の手順に沿って操作します。 次に、 EC2 インスタンスから FSx for Lustre ファイルシステムをマウント する手順に沿って操作します。 マウントポイントとして使用するフォルダを作成します。 sudo mkdir -p /fsx FSx コンソールでファイルシステムを選択し、 DNS 名 と マウント名 を検索します。これらの値を使用して、ファイルシステムをマウントします。 sudo mount -t lustre -o relatime,flock file_system_dns_name@tcp:/mountname /fsx EFA をサポートし、Lustre バージョン 2.15 以降を使用しているクライアントインスタンスから EFA 対応ファイルシステムにアクセスすると、EFA が自動的に使用されます。 知っておくべきこと EFA と GDS のサポートは、persistent 2 が提供されているすべての AWS リージョン の新しい Amazon FSx for Lustre ファイルシステムで、追加費用なしで今すぐご利用いただけます。顧客が EFA をサポートするクライアントインスタンスから EFA 対応ファイルシステムにアクセスすると、FSx for Lustre は、追加の設定なしで自動的に EFA を使用します。EFA をサポートしている EC2 クライアントインスタンスのリストについては、「Amazon EC2 ユーザーガイド」の サポートされているインスタンスタイプ を参照してください。この ネットワーク仕様表 では、高速コンピューティングカテゴリーのインスタンスタイプのネットワーク帯域幅および EFA サポートについて説明しています。 Lustre ファイルシステムの FSx で EFA 対応インスタンスを使用するには、カーネル 6.8 以降を搭載した Ubuntu 22.04 で、Lustre 2.15 クライアントを使用する必要があります。 クライアントインスタンスとファイルシステムは、 Amazon Virtual Private Cloud (Amazon VPC) 接続 内の同じサブネットに配置されている必要があることに注意してください。 GDS は EFA 対応のファイルシステムで自動的にサポートされます。GDS を FSx for Lustre ファイルシステムで使用するには、クライアントインスタンスに NVIDIA Compute Unified Device Architecture (CUDA) パッケージ 、 オープンソースの NVIDIA ドライバー 、 NVIDIA GPUDirect Storage Driver がインストールされている必要があります。これらのパッケージは AWS 深層学習 AMI にあらかじめインストールされています。その後、CUDA 対応アプリケーションを使用して、ファイルシステムと GPU 間のデータ転送に GPUDirect Storage を使用できます。 デプロイを計画する際には、EFA 対応のファイルシステムは、EFA 対応でないファイルシステムよりも最小ストレージ容量の増加が大きいことに注意してください。例えば、1,000 MB/s/TiB スループット階層を選択した場合、EFA 対応ファイルシステムの最小ストレージ容量は 4.8 TiB ですが、EFA が有効になっていない Lustre ファイルシステムの FSx では 1.2 TB です。既存のワークロードの移行を検討している場合は、 AWS DataSync を使用して、既存のファイルシステムから EFA と GDS をサポートする新しいファイルシステムへデータを移動できます。 柔軟性を最大限に高めるため、FSx for Lustre は EFA ワークロードと非 EFA ワークロードの両方との互換性を維持しています。EFA 対応のファイルシステムにアクセスすると、EFA 以外のクライアントインスタンスからのトラフィックは、 Elastic Network Adapter (ENA) を使用して自動的に従来の TCP/IP ネットワーク経由で流れるため、追加の設定なしですべてのワークロードにシームレスにアクセスできます。 詳細なセットアップ手順やベストプラクティスなど、FSx for Lustre での EFA および GDS サポートの詳細については、 Amazon FSx for Lustre のドキュメント をご覧ください。今すぐ使用を開始して、クラウドの GPU インスタンスで利用可能な最速のストレージパフォーマンスをご体験ください。 – Danilo 原文は こちら です。

Amazon Elastic Block Store (Amazon EBS) のスナップショットを AWS リージョンやアカウント内または AWS リージョンやアカウント間でコピーするときに、希望する完了時間 (15 分〜48 時間) を指定できるようになりました。これは、重要なワークロードの時間ベースのコンプライアンス要件とビジネス要件を満たすのに役立ちます。例: テスト – テストデータ管理 (TDM) 計画の一環として、最新のデータをタイムリーに配布する。 開発 – 定期的かつ頻繁に、更新済みのスナップショットデータを開発者に提供する。 ディザスタリカバリ – 目標復旧時点 (RPO) を満たすために、重要なスナップショットがコピーされていることを確認する。 どのようなユースケースでも、この新機能によって、一貫性のある予測可能なコピーが提供されます。これは、標準コピーのパフォーマンスや信頼性には影響しません。それぞれの状況に適したオプションとタイミングを選択できます。 時間ベースのスナップショットコピーの作成 時間ベースのスナップショットコピーは、 AWS マネジメントコンソール 、CLI ( copy-snapshot )、または API ( CopySnapshot ) から作成できます。この記事の執筆中に、2 つの EBS ボリューム (100 GiB と 1 TiB) を作成し、それぞれにファイルを格納して、スナップショットを作成しました。 時間ベースのスナップショットを作成するには、通常どおりソースを選択して、 [アクション] メニューから [スナップショットをコピー] を選択します。コピーの説明を入力し、送信先として us-east-1 AWS リージョンを選択して、 [時間ベースのコピーを有効にする] を選択し、(これは時間が重視されるスナップショットであるため) 15 分という 完了期間 を入力します。 [スナップショットをコピー] をクリックすると、送信先のリージョンで作成中の他のアクティブなコピーによって消費されるスループットが原因で、アカウントのスループットクォータをまだ超えていない場合にのみ、リクエストが受け入れられます (コピーは 保留中 になります)。アカウントレベルのスループットクォータを既に超えている場合は、コンソールにエラーが表示されます。 [コピー時間計算ツールを起動] をクリックすると、スナップショットで達成可能な最小コピー時間をより正確に把握できます。計算ツールを開き、アカウントのスループット制限を入力して、評価期間を選択します。 その後、計算ツールは、以前のスナップショットコピーの過程で収集された履歴データを使用して、達成可能な最小完了時間を提示します。この例では、過去 24 時間に 1,800,000 MiB をコピーしました。時間ベースのコピーがあり、現在のアカウントのスループットクォータが 2,000 MiB/秒の場合、これだけの量のデータを 15 分でコピーできます。 コピーの進行中は、コンソールを使用するか、 DescribeSnapshots を呼び出して結果の 進行状況 フィールドを調べることで、進行状況をモニタリングできます。次の Amazon EventBridge イベントを使用してアクションを実行することもできます (コピー操作が複数リージョンにまたがる場合、イベントは送信先リージョンに送信されます)。 CopySnapshot – コピー操作が完了した後に送信されます。 CopyMissedCompletionDuration – 期限が過ぎてもコピーがまだ保留中の場合に送信されます。 知っておくべきこと これでほぼすべてです! 時間ベースのスナップショットコピーについて知っておくべきことは次のとおりです。 CloudWatch メトリクス – SnapshotCopyBytesTransfer メトリクスは、送信先リージョンで出力され、ソースリージョンとターゲットリージョンの間で転送されたデータ量をバイト単位で反映します。 期間 – 所要時間は 15 分から 48 時間までで、15 分単位で指定できます。コピーごとに指定できます。 同時実行 – スナップショットをコピーしているときに、同じスナップショットのコピーを同じ送信先に 2 回目に開始した場合、2 つ目のコピーの保存期間は、最初のコピーが完了した時点で開始されます。 スループット – ソースと送信先の各ペアには、アカウントごとにデフォルトで 2,000 MiB/秒の制限があります。RPO を満たすためにスループットを増やす必要がある場合は、 AWS サポートセンター で増加をリクエストできます。スナップショットあたりの最大スループットは 500 MiB/秒で、これ以上増やすことはできません。 料金 – 料金情報の詳細については、 Amazon EBS の料金 ページを参照してください。 リージョン – 時間ベースのスナップショットコピーは、すべての AWS リージョンで利用できます。 – Jeff ; 原文は こちら です。

本記事は、2024/11/06 に公開された Reduce your compute costs for stream processing applications with Kinesis Client Library 3.0 の翻訳記事です。翻訳は Solutions Architect の Lee Rui が担当しました。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータを容易にキャプチャ、格納できるサーバレスのデータストリーミングサービスです。Kinesis Data Streams は、すぐに利用可能な多くの統合を使用してストリームに送信されたデータを処理する柔軟性を提供するだけではありません。コンピューティングフリートにデプロイ可能な、カスタムストリーム処理アプリケーションを構築する機能も提供しています。 カスタムストリーム処理アプリケーションを構築する際、開発者は通常、リアルタイムで高スループットデータを処理するために必要な分散コンピューティングの管理に課題に直面します。この課題に対処するのが Kinesis Client Library (KCL) です。多くの AWS 顧客が、KCL を活用して分散システムの複雑さを気にすることなく、Kinesis Data Streams でカスタムストリーム処理アプリケーションを運用しています。KCL は Kinesis Data Streams API を使用してストリームからデータを読み取り、複数のワーカー間でのストリーム処理のロードバランシング、フェイルオーバーの管理、処理済みレコードのチェックポインティングなどの複雑な処理の実装を肩代わりしてくれます。KCL はこれらの複雑な処理を開発者の代わりにハンドリングすることで、開発者がストリーミングデータ処理のコアビジネスロジックの実装に集中できるようになります。 アプリケーションが処理する時間あたりのデータ量が増加するにつれて、顧客はストリーム処理アプリケーションの計算コストを削減したいと考えるようになります。以前のバージョンの KCL と比較し、最大 33% のストリーム処理コストを削減することが可能な、Kinesis Client Library 3.0 のリリースを紹介できることを喜ばしく思います。KCL 3.0 は、新しいロードバランシングアルゴリズムを採用しています。このアルゴリズムは、ワーカーのリソース利用状況を継続的に監視し、処理を均等に再配布することで、同じデータをより少ない計算リソースで処理できるようにします。 この投稿では、サンプルワークロードをベースにストリーム処理におけるロードバランシングの課題について説明し、ワーカー間での不均一なロード分散がどのように処理コストを増加させるかを示します。次に、KCL 3.0 がこの課題にどのように対処して計算コストを削減するかを示しつつ、KCL 2.x から 3.0 へ容易にアップグレードできる手順を説明します。さらに、KCL 3.0 が提供する追加の利点についても説明します。これには、 AWS SDK for Java 2.x の使用と、AWS SDK for Java v1.x への依存の解消が含まれます。最後に、ストリーム処理アプリケーションを KCL 3.0 に移行する際のチェックリストも共有します。 カスタムストリーム処理アプリケーションの運用におけるロードバランシングの課題 リアルタイムのデータストリームを処理するお客様は、通常、高いスループットを並列処理するために、複数の計算リソースを利用します。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) などです。多くの場合、データストリームには、同じワーカーによって処理される必要があるレコードが含まれています。例えば、あるトラック会社が、数千台の車両から公開されるリアルタイムの位置座標を含むストリーミングデータを処理するために、それぞれ 1 つのワーカーを実行する複数の EC2 インスタンスを使用する場合があるとします。車両の経路を正確に追跡するには、各トラックの位置情報は同じワーカーによって処理される必要があります。このようなユースケースでは、お客様はデータストリームに公開される各レコードに対して、車両 ID をパーティションキーとして指定します。順序どおりに処理するために、Kinesis Data Streams は同じパーティションキーに属するデータレコードを単一のシャード (Kinesis Data Streams の基本的なスループット単位) に書き込みます。 ただし、ストリームのデータはパーティションキーに関連するトラフィックの変動により、シャード間で不均等に分散することがよくあります。たとえば、稼働中の車両は位置更新を頻繁に送信しますが、待機中の車両は更新頻度が低いといったことが考えられます。以前の KCL バージョンでは、ストリーム処理アプリケーションで各ワーカーが同数のシャードを並列処理していました。その結果、データの多いシャードを処理するワーカーはデータ処理の限界に達する一方で、データの少ないシャードを処理するワーカーは十分に活用されていませんでした。このワークロードの不均衡は、リソース活用とストリーム処理の効率化を目指すお客様にとって課題となっていました。 トラフィックがストリーム内のシャードで不均一な場合のサンプルワークロードを例として、KCL 2.6 でコンピューティングリソースの利用が不均一になる理由と、それがコストの増加につながる理由を一緒に見ていきましょう。 サンプルのワークロードでは、プロデューサーアプリケーションが 4 つのシャードに 2.5MBps のデータを発行しています。ただし、パーティションキーに関連するトラフィックパターンに基づいて、2 つのシャードが 1MBps ずつ、他の 2 つのシャードが 0.25MBps ずつ受け取っています。例のトラック運送会社であれば、2 つのシャードは稼働中の車両から、残りの 2 つのシャードは待機中の車両からデータを保存していると考えられます。このサンプルのワークロードでは、3 台の EC2 インスタンス (それぞれ 1 つのワーカーを実行) を使用して、KCL 2.6 でこのデータを処理しました。 最初は、3 つのワーカーに負荷が分散され、CPU 使用率は 50%、50%、25% で平均で 42% でした (次の図の 12:18 – 12:29 の時間枠を参照)。EC2 フリートが十分に活用されていないため、コスト効率を高めるために 1 つの EC2 インスタンス (ワーカー) をフリートから削除し、2 つのワーカーで運用してみました。しかし、ワーカーを削除すると、1 つの EC2 インスタンスの CPU 使用率がほぼ 100% に増加してしまいました。 これは、KCL 2.6 以前のバージョンでは、スループットやワーカーの CPU 使用率に関係なく、各ワーカーが同じ数のシャードを処理するように負荷を分散するためです。この場合、1 つのワーカーが 2 つの高スループットシャードを処理し、CPU 使用率が 100% に達し、別のワーカーが 2 つの低スループットシャードを処理し、CPU 使用率が 25% にとどまっていました。 一部のワーカーが過剰に利用され処理が遅延する可能性があるため、この CPU 使用率の不均衡によりワーカーコンピューティングフリートをスケールダウンできません。全体としてはフリートが十分に活用されていませんが、負荷の偏りがフリートのスケールダウンを妨げています。これにより、ストリーム処理アプリケーションの計算リソース費用が増えています。 次に、KCL 3.0 がこれらのロードバランシング課題にどのように対処しているかを見ていきたいと思います。 KCL 3.0 によるロードバランシングの改善 KCL 3.0 では、KCL ワーカーの CPU 使用率を監視し、ストリーム処理の負荷を再分散する新しいロードバランシングアルゴリズムが導入されました。新しいロードバランシングアルゴリズムでは、ワーカーがデータの処理限界に近いことや、ワーカー間の CPU 使用率の分散が大きいことを検知した場合、過剰に使用されているワーカーから使用率の低いワーカーへ負荷を再分散します。これにより、すべてのワーカー間でストリーム処理の負荷が均等化されます。その結果、ワーカー間の CPU 使用率の不均衡による過剰なキャパシティのプロビジョニングを回避でき、コンピューティングキャパシティを適切にサイジングすることで、コストを節約できます。 次の図は、KCL 2.6 と同じシミュレーション設定で KCL 3.0 の結果を示しています。 3 つのワーカーがある場合、KCL 3.0 は当初 KCL 2.6 と同様に負荷を分配し、平均 CPU 使用率は 42% でした (20:35 – 20:55 の時間枠)。しかし、1 つのワーカーを削除すると (赤い垂直点線で示されています)、KCL 3.0 はシャードの数だけでなく、シャードのスループット変動性も考慮して、1 つのワーカーから他の 2 つのワーカーに負荷を再配分しました。その結果、2 つのワーカーの CPU 使用率は約 65% となり、パフォーマンスリスクなしで計算リソースを安全にスケールダウンできました。 このシナリオでは、コンピューティングフリートのサイズを 3 つのワーカーから 2 つのワーカーに削減することができ、KCL 2.6 に比べて 33% のコンピューティングコストの削減を実現しました。 これはあくまでサンプルワークロードですが、1 秒あたり数ギガバイトのデータをストリーミングし、それを数百の EC2 インスタンスで処理する場合の潜在的なコスト節約効果はより高いものになるでしょう。 同じコスト削減の恩恵を、 Amazon Elastic Container Service (Amazon ECS)、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS Fargate 、または自身で管理する Kubernetes クラスターなどのコンテナ化された環境にデプロイされた KCL 3.0 アプリケーションでも実現できます。 その他の KCL 3.0 の利点 ストリーム処理コストの削減に加えて、KCL 3.0 にはいくつかの利点があります: Amazon DynamoDB の読み取り容量ユニット (RCU) の削減 – KCL 3.0 は、メタデータを格納する DynamoDB テーブルに対する読み取り操作を最適化により、KCL に関連する Amazon DynamoDB のコストを削減します。KCL は、シャードとワーカーの割り当てやチェックポイントなどのメタデータを DynamoDB に格納しています。 ワーカー間でのシャードの円滑な引き継ぎ – KCL 3.0 は、リバランシングやデプロイ時に、ある 1 つのワーカーから別のワーカーにシャードの処理が引き継がれる際のデータの再処理を最小限に抑えます。現在のワーカーが処理済みのレコードのチェックポイントを完了し、新しいワーカーが前のワーカーの最新のチェックポイントから作業を引き継ぐことができます。 AWS SDK for Java 1.x への依存関係の除去 – KCL 3.0 は、AWS SDK for Java 1.x への依存関係を完全に除去し、AWS の最新の SDK バージョンの使用を推奨しています。この変更により、KCL アプリケーションのパフォーマンス、セキュリティ、保守性が向上します。AWS SDK for Java 2.x の利点の詳細については、 AWS SDK for Java 2.x の機能を使用する を参照してください。 KCL 3.0 への移行 現在 KCL 2.x バージョンを使用している場合、アプリケーションコードを変更する必要はありません! 次の手順で KCL 3.0 に移行できます。 Maven (またはビルド環境) の依存関係を KCL 3.0 に更新してください。 clientVersionConfig を CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X に設定してください。 コードをビルドしてデプロイしてください。 すべての KCL ワーカーが更新されると、KCL 3.0 は自動的に新しいロードバランシングアルゴリズムを実行し、ワーカーのリソースを平準化します。詳細な移行手順については、 以前の KCL バージョンからの移行 をご覧ください。 KCL 3.0 を使用する際の主なチェックリスト ストリーム処理アプリケーションで Kinesis Client Library (KCL) 3.0 を使用することを決めた場合、次の点を確認することをお勧めします: KCL 3.0 に必要な適切な権限を追加したことを確認してください。KCL 3.0 は、DynamoDB で 2 つの新しいメタデータテーブル (worker metrics table, coordinator state table) とリーステーブルのグローバルセカンダリインデックスを作成および管理します。追加する必要がある詳細な権限設定については、 KCL コンシューマーアプリケーションに必要な IAM 権限 を参照してください。 KCL 3.0 で導入された新しいロードバランシングアルゴリズムは、ワーカー間の CPU 使用率を均等にすることを目指しており、ワーカーごとのリース数を均等にすることを目指すわけではありません。 maxLeasesForWorker パラメーターを低く設定すると、KCL のワークロードバランシング効果が制限される可能性があります。 maxLeasesForWorker パラメーターを使用する場合は、最適なロード分散のために、その値を増やすことを検討してください。 KCL アプリケーションで自動スケーリングを使用している場合、KCL 3.0 にアップグレードした後はスケーリングポリシーを見直すことが重要です。具体的には、平均 CPU 使用率をスケーリングのしきい値として使用している場合、この値を再評価する必要があります。ロードバランシングの不均衡により、一部のワーカーが高負荷になることを防ぐために、必要以上に高いしきい値を設定していた場合、この値を調整できるかもしれません。KCL 3.0 では、ロードバランシングが改善されているため、ワーカー間のワークロードがより均等に分散されます。KCL 3.0 を展開した後、ワーカーの CPU 使用率を監視し、パフォーマンスを維持しながら、リソース使用量とコストを最適化するためにスケーリングのしきい値を下げられるかどうかを確認してください。この手順により、KCL 3.0 の強化されたロードバランシング機能を最大限に活用できるようになります。 リースを適切に他のワーカーに引き継ぐために、 RecordProcessor クラスの shutdownRequested() メソッド内にチェックポインティングロジックを実装していることを確認してください。詳細については、 KCL 2.x から KCL 3.x への移行 のステップ 4 を参照してください。 まとめ KCL 3.0 のリリースでは、KCL アプリケーションのコスト効率とパフォーマンスを最適化できる大幅な機能強化が導入されました。新しいロードバランシングアルゴリズムにより、ワーカーインスタンス間の CPU 使用率がより均等になるため、適切なサイズのストリーム処理システムを構築し、コストを最適化できる可能性があります。チェックリストを確認しつつ、KCL 3.0 の機能を最大限に活用し、Kinesis Data Streams で効率的で信頼性の高いコスト最適化されたストリーム処理アプリケーションを構築しましょう。 著者について Minu Hong は、AWS の Amazon Kinesis Data Streams のシニアプロダクトマネージャーです。ストリーミングデータに関する顧客の課題を理解し、最適なソリューションを開発することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。 Pratik Patel は、シニアテクニカルアカウントマネージャーであり、ストリーミング分析の専門家です。AWS 顧客と協力し、ベストプラクティスを使用してソリューションを計画および構築するための継続的なサポートとテクニカルガイダンスを提供し、顧客の AWS 環境を運用上健全に保つのを積極的に支援しています。 Priyanka Chaudhary はシニアソリューションアーキテクトでデータ分析の専門家です。顧客の信頼できるアドバイザーとして、ウェルアーキテクトされた革新的な業界ソリューションを構築するための技術的なガイダンスとサポートを提供しています。

このブログは 2024 年 9 月 6 日に Chandan Murthy、Tilman Schroeder と Yue Ning によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 製造業では製品品質の向上、効果的なコラボレーション、開発コストの削減、市場投入までの時間短縮といった理由から、製品ライフサイクル管理（PLM）ソフトウェアを活用しています。AWS における PLM ソリューションは、企業が可用性とコンプライアンス要件を満たすと同時に、PLM のパフォーマンスの向上、コスト削減、データのサイロ化解消の実現に役立ちます。 Amazon FSx for NetApp ONTAP ストレージサービスを利用した AWS における PLM ソリューション は、高性能でスケーラブルなストレージと PLM ソフトウェアの堅牢なデータ管理機能の組み合わせにより、コラボレーションの強化、開発サイクルの加速、コスト削減を実現します。この戦略的な統合により、エンジニアリングチームはデータの完全性、セキュリティ、可用性を確保しながら、全体的な運用効率を最適化し、より効果的にイノベーションを推進することができます。 製品ライフサイクル管理（PLM） 製品ライフサイクル管理（PLM）ツールは設計、エンジニアリング、製造、サプライチェーン、変更管理プロセス全体におけるコラボレーション、イノベーション、効率性の向上を促進することで、初期コンセプトから廃棄に至るまで、製品のライフサイクル全体を管理することを可能にしています。産業および製造業の企業は Siemens Teamcenter などの PLM ソリューションを AWS に移行することでモダナイズし、コンプライアンス要件を満たしながらグローバルに分散したチームをサポートしつつ、IT コストの削減、パフォーマンスの向上、拡張性とセキュリティの向上というメリットを得ることができます。 Amazon FSx for NetApp ONTAP NetApp はエンタープライズ環境におけるミッションクリティカルなアプリケーションのサポートに長年高い評価を得ており、信頼性と拡張性に優れたストレージソリューションを 30 年以上にわたって提供してきた実績があります。Amazon FSx for NetApp ONTAP は NetApp の ONTAP オペレーティングシステムが持つ堅牢性と高度なデータ管理機能をクラウドで実現し、PLM システムの性能と耐障害性を高めます。 Forrester 社の調査 によると、Amazon FSx for NetApp ONTAP を利用することで運用効率が最大 45% 向上し、NetApp の業界をリードする SnapMirror などのデータレプリケーション機能によって移行に要する時間が最大 40% 短縮されたと報告されています。こうした恩恵は、重要なデータやアプリケーションへの継続的かつ中断のないアクセスが求められる PLM 環境では特に重要です。Amazon FSx for NetApp ONTAP を活用することで PLM システムの信頼性とパフォーマンスが向上するだけでなく、製品のイノベーションと開発を推進する複雑でデータ集約的なプロセスをサポートし、最終的に製品の市場投入を加速、運用コストを削減し、グローバル市場における競争力を維持することができます。 製品設計とエンジニアリングにおけるコラボレーションとデータの完全性 製品の設計やエンジニアリングの段階ではスピード、コラボレーション、データの完全性が不可欠です。Amazon FSx for NetApp ONTAP は CAD、CAE、PLM アプリケーションの集中的なデータ処理に必要な高性能でスケーラブルなストレージソリューションを提供します。このストレージサービスを利用することで、エンジニアリングチームはリアルタイムでコラボレーションを行い、地理的な制約を超えてシームレスに設計ファイルにアクセスし、共有することができます。これにより設計の反復サイクルが短縮され、生産性が向上します。また、堅牢なデータ保護と災害復旧機能により、重要な設計データの可用性とセキュリティが常に確保されます。 製品のライフサイクル全体を通じて、コラボレーションと統合は非常に重要です。設計・エンジニアリングチームを超えて、さまざまな場所やシステムにまたがる社内のステークホルダーや外部パートナーも巻き込む必要があります。Amazon FSx for NetApp ONTAP は低レイテンシでコスト効率の高いデータアクセスを提供することで、PLM、ERP（Enterprise Resource Planning）、MES（Manufacturing Execution Systems）などのシステムとの容易な統合を可能にし、透明性を高め、生産性を向上させます。さらに柔軟なストレージアーキテクチャと高性能なファイルシステムは、 PLM システムの多様なデータタイプと I/O パターンに対応し、CAD/CAE/CAM ファイルや仕様書から部品表、製造工程計画など、製品のライフサイクル全体にわたる多様なデータのニーズに最適なパフォーマンスを提供します。 Well-Architected PLM Solution on AWS この ホワイトペーパー （エンタープライズ環境における Amazon FSx for NetApp ONTAP を使用した Siemens Teamcenter の導入）では、クラウドで PLM ワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明しています。一般的に、重複排除、圧縮、自動データ階層化などの NetApp ONTAP の機能を有効にすることで、ストレージコストを最適化し、運用のオーバーヘッドが削減されます。NetApp ONTAP の高性能でスケーラブルなストレージにより、PLM アプリケーションの速度と応答性を向上させ、冗長性とディザスタリカバリによってデータの完全性と可用性が確保されます。暗号化、アクセス制御、監査、ロギングなどの重要なセキュリティ機能により、大切な PLM データの機密性、完全性、可用性を保護する安全な基盤を確立します。さらに、AWS クラウドの持続可能なインフラストラクチャを活用することができます。AWS クラウドの規模による恩恵として、一般的なオンプレミスのデータセンターよりも高いリソース利用率とエネルギー効率を達成することができ、ESG（Environmental Social and Governance）目標の達成に貢献します。 自動車業界のお客様事例 最近、PLM システムの近代化と最適化の必要性に直面していた大手自動車技術サプライヤーは、Siemens Teamcenter プラットフォームをオンプレミス環境から AWS に移行しました。この決断の背景には、クラウドの拡張性を活用し、業務効率を高め、製品の市場投入までの時間を短縮したいという要望がありました。同社は当初、他のストレージソリューションを検討しましたが、業務に不可欠なマルチプロトコルのサポートと効率的なクローン作成機能が不足していることがわかりました。マルチプロトコルのサポートや FlexClone テクノロジーなどの高度な機能により、Amazon FSx for NetApp ONTAP が最適な選択肢となりました。これらの機能は市場投入までの時間を短縮し、エンジニアリングチーム間のコラボレーションの強化に役立ちました。Amazon FSx for NetApp ONTAP の高いパフォーマンスと拡張性により、同社のエンジニアリングチームは大規模なデータでも遅延なく作業を進めることができます。また、Multi-Availability Zone オプションにより、ミッションクリティカルなワークロードに必要な高可用性とデータの耐障害性も実現しています。 図 1: Siemens Teamcenter アーキテクチャ Special thanks to: • Dimitrios Dovas (Teamcenter X Product Management, Siemens) • Donna Yasay (AWS Senior Leader, Solutions Architect – Automotive and Manufacturing) • Mekka Williams (Director – Innovation and Solutions, Office of the CTO, NetApp, Inc) • Yue Ning (AWS Senior Solutions Architect – Automotive and Manufacturing) • Charles Inglis (AWS Product Manager –- Technical for Amazon FSx for NetApp ONTAP) • Arunkumar Krishnan&nbsp;(AWS Senior Solutions Architect – HPC Storage SME) <!-- '"` --> 翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの向井が担当しました。 TAGS: AWS for Industrial , aws manufacturing , FSx NetApp , siemens Chandan Murthy Chandan Murthy は、AWSのシニアパートナーソリューションアーキテクトとして、AWSのパートナーが AWS プラットフォーム上で効率的でスケーラブルなソリューションを設計・構築するための支援に取り組んでいます。20 年の経験を持つ Chandan は、Teamcenter や Mendix などのプラットフォームにおける技術的なソリューション設計において堅実な経験を持っています。この専門知識と AWS での役割により、お客様が AWS のクラウドプラットフォーム上で PLM やローコード産業ソリューションを実装することを支援しています。 Tilman Schroeder 2018年から NetApp の Automotive &amp; Manufacturing 部門の CTO を務める Tilman Schroeder は、Automotive &amp; Manufacturing 部門における新たなテクノロジーの活用を主導しています。拡張性の高いサービスアーキテクチャの構築に注力し、製品ライフサイクル管理、HPC シミュレーション、機械学習オペレーション、自律走行などの重要な分野でイノベーションを推進しています。彼の仕事はグローバルな自動車会社がエンタープライズグレードの（ハイブリッド）クラウドソリューションを導入し、デジタルトランスフォーメーションを加速することを可能にします。その専門性と情熱は、企業がクラウドテクノロジーを活用して最も要求の厳しい最先端のワークロードを最適化できるよう支援することにあります。 Yue Ning Yue は、南カリフォルニアに在籍する AWS のシニアソリューションアーキテクトで、自動車および製造業のお客様を担当しています。深い技術知識と業界のトレンドに対する鋭い理解を組み合わせ、効率的で将来を見据えた製造プロセスを推進し、従来の製造プラクティスと新たなテクノロジーのギャップを埋め、AWS のお客様の全社的なデジタルトランスフォーメーションを促進することで知られています。