本日、強化された AWS Pricing Calculator が、請求とコスト管理コンソールからパブリックプレビュー機能として利用できるようになったことを発表致します。新機能では、新しいワークロードや既存の AWS 使用量の変更についてディスカウントを含めた正確なコスト見積もりを行うことができます。これにより、あるリージョンから別のリージョンへのワークロード移行、既存のワークロードの変更もしくは新しいワークロードの計画やコミットメント購入計画などについて時間を節約しコスト見積もりの正確性を向上させることができます。 既存の Web サイトとしての Pricing Calculator と異なり、強化された Pricing Calculator を開始するには開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。 AWS Pricing Calculator のこれまでの歩み 最もよくある一般的な質問の 1 つは、” AWS 上でワークロードを実行するとどのくらいコストがかかりますか？” というものです。これに応えるために、2007 年に AWS Simple Monthly Calculator をローンチしました。これは、最新の料金変更に対応し、簡単にコスト見積もりを行えるツールです。2018 年には、 AWS Pricing Calculator をローンチしました。シンプルな UI で幅広いサービスに対応しており Pricing Calculator はすぐに AWS ワークロードのコストを見積もるための頼りになるリソースとなりました。2023 年には、 1 つのツールですべてのアーキテクチャのニーズに対応した料金を調査できるよう Simple Monthly Calculator の廃止 を決定しました。これ以来、Pricing Calculator の機能を向上させ拡張し続けてきました。 本日のローンチ以前は、AWS Pricing Calculator を利用して AWS 上のワークロードのコスト影響を評価できました。しかし、ディスカウントについては自分自身で計算する必要がありました。さらに、変更を加える場合にはまず既存の使用量を収集する必要がありました。また、コストの見積もりを保存したりチームで共有するための出力や管理プロセスを構築する必要がありました。 強化された Pricing Calculator （パブリックプレビュー） お客様からのフィードバックを取り入れて、請求とコスト管理コンソールで利用できる新しく強化された AWS Pricing Calculator を開発しました。まず、AWS アカウントで Pricing Calculator にログインし、見積もりに過去の AWS 使用量をインポートできるようになりました。また、これらの見積もりをアカウントに直接保存し、今後のリファレンスとできます。次に、AWS が請求書を作成するために利用しているものと同じ計算ロジックを利用して AWS 請求全体のコストを見積もることができるようになりました。この機能により、Savings Plans や Reserved Instances などの様々なディスカウントが全体のコストにどのように影響するのかより詳しく理解するために役立ちます。最後に、ディスカウントを適用させながら、特定のワークロード（すべての AWS 使用量のサブセット）のコストをインタラクティブに見積もることができます。開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。それでは、詳細について見ていきましょう。 2 種類の見積もり 新しい Pricing Calculator の機能は、パブリックプレビューとして 2 種類のコスト見積もりをサポートしています。ワークロード見積もりと請求見積もりです。 ワークロード見積もり を利用すると、様々なワークロードやアプリケーションの変更によるコスト影響をインタラクティブにモデル化し、ディスカウントを適用した効果を自動的に含ませることができます。アプリケーションを所有している場合や、アプリケーションに関する財務もしくは組織内の使用量に関して責任を持っている場合は、こちらの見積もりが役に立ちます。ワークロード見積もりは、管理アカウント、メンバーアカウントとスタンドアロンアカウントすべての AWS アカウントで利用できます。 請求見積もり を利用すると、管理アカウントのユーザーは AWS サービスの使用量の変化に加えて、Savings Plans と Reserved Instances を含んだりコミットメント金額を調整した見積もりを作成できます。これはすべてのコストと使用量が一括請求で計算されることにより実行されます。一括請求での見積もりは、アカウント間で割引の共有を行いながら活用できるため、より長期間のコミットメントを含めたシナリオを評価したいお客様によって特に有益です。 おそらく皆さんは、この新しい Pricing Calculator の機能を活用する色々な方法について考えているのではないでしょうか？まさに、新しいビジネスをサポートするための既存ワークロードの拡張や新規ワークロードの追加、レジリエンシー、パフォーマンスもしくはコスト最適化などの理由による新しいリージョンへの移行や推奨されるライトサイジングの実装といったシナリオに活用できます。既存の Amazon EC2 の使用量を変更しながら新しく Amazon RDS を追加する必要があるユースケースについて、お客様が手短な回答を探している例について見てみましょう。 ワークロード見積もり あなたが所属するチームが m5d.16xlarge インスタンスの使用量を月あたり 355 時間から 1460 時間に増やすことを決めました。見積もりコストは増加しますが、他のワークロードを変化させた場合のコスト影響も一緒に確認したいとします。 自分のアカウントで Pricing Calculator にログインし、使用可能なパラメーターとしての日付範囲やフィルター（リージョン、アカウント、タグやコストカテゴリなど）を用いて過去のワークロードをインポートし、ワークロード見積もりを作成してください。EC2 サービスの使用量のみをインポートすることができます。これを実行するために、Amazon Elastic Compute Cloud サービスでフィルタリングし、新しい使用グループを作成して名前を付け、詳細を設定してサービスの使用量を編集してください。 図 1. ワークロード見積もりへ過去の EC2 使用量を追加した例 図 2. 既存 EC2 の使用量詳細の編集例 状態の列が “Modified” となり、フィルタリングされたベースライン使用量と変更された推定コストの比較をすぐに確認することができます。 図 3. ワークロード見積もりのランディングページ例 既存の EC2 使用量を変更することに加えて、チームはさらに新しく追加する Amazon Aurora MySQL データベースの使用量に関するコスト影響を把握したいと考えています。このような場合は、新しい Amazon Aurora の使用量を同じワークロード見積もりに加えることができます。これを行うために、“Amazon Relational Database Service” でフィルタし、新しいサービス使用量を加え、詳細を設定することでコストへの影響をすぐに確認することができます。 図 4. 新しく Amazon RDS ( Aurora 使用量）を追加した例 図 5. 新しい Amazon Aurora の詳細設定例 新しく Amazon Aurora の使用量を設定すると、Amazon Aurora の使用量をすぐに反映した見積もりをテーブルで再度確認できます。 図 6. 更新されたワークロード見積もりページ例 請求見積もり チームがワークロードの成長によるコストへの影響について理解した後に、増加した使用量をカバーする新しい Savings Plans を購入する必要があるとします。請求見積もりの機能により、Savings Plans と Reserved Instances の両方を含む AWS 請求全体のコストをモデル化することができます。例えば、m5d.16xlarge EC2 インスタンスの月あたりの使用量を 355 時間から 1460 時間へ増やし、この増加分をカバーするために $1.00/hour の EC2 Instance Savings Plans を追加購入するとします。この場合、請求見積もりを使用することで、全体への影響を把握できます。これを行うためには、新しい請求シナリオを作成し、先月の EC2 使用量をインポートします。次に、増加した使用量を反映させるために関連する使用量の行を変更し、さらに新しい Savings Plans を請求シナリオに追加します。これらの手順を完了させたら、‘Create report’ をクリックして請求シミュレーションを開始してください。 図 7. 請求見積もりページ例 シミュレーション結果が作成されると、請求見積もりのリストで確認することができます。見積もりのタイトルをクリックして、詳細を確認できます。請求見積もりの結果ページでは、一括請求ファミリーのコストと使用量に関する課税前の重要な情報が表示されます。上位 7 サービスと明細項目レベルで変更されたコストと使用量を確認できます。明細項目では、シナリオで使用量が変更された行とコミットメントでカバーされ変更された行やディスカウント適用に伴い変更された行が含まれます。 図 8. 請求結果ページ例 注意点 レイテンシー ：ワークロード見積もりでは、すぐにコスト見積もりを取得できます。請求見積もりでは、処理するデータのサイズに依存しますが、新しい設定の詳細を利用して完全な請求を計算する必要があるため、最大 12 時間の待ち時間が発生する可能性があります。これは非同期処理となり、完了するとメール通知を受け取ります。 Savings Plans コストモデリング ：時間あたりのコミットメント金額が異なる個別の Savings Plans を購入した場合のコストへの影響について分析するために、新しくローンチされた Savings Plans Purchase Analyer を利用し、様々な購入シナリオにまたがった推定削減額、カバレッジと使用率をインタラクティブにモデル化できます。もし、組織の使用量にまたがった既存のすべての Savings Plans、Reserved Instances とディスカウントに加えて、新しく追加したり変更した使用量、Savings Plans や Reserved Instances によるコスト影響を総合的に把握したいのであれば、Pricing Calculator の請求見積もり機能を利用してください。 結論 新しい Pricing Calculator の機能は、コスト計画に対する確信を高め、組織が必要とする重要なビジネスの意思決定に必要なクリティカルな回答を得るための処理を迅速にします。詳細については、 AWS Pricing Calculator の ユーザーガイド 、 API ドキュメント や 料金 を参照してください。（訳者注：ワークロード見積もりは、無料で作成できます。請求見積もりは、月 5 件まで無料で作成できますが、以降は 1 件あたり $2 の費用が発生します。） 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Jeremiah Myers Jeremiah は、AWS Billing and Cost Management services のシニアテクニカルプロダクトマネージャーです。クラウドコストの責任者がAWS 上の将来のワークロードをよりよく計画できる支援に注力しています。以前のキャリアでは、複数のグローバルソフトウェア製品をローンチし、ベンチャー企業をバックアップするスタートアップを共同成立しました。 Bowen Wang Bowen は、AWS Billing and Cost Management services のプリンシパルプロダクトマーケティングマネージャーです。財務やビジネスのリーダーがクラウドの価値と Cloud Financial Management を最適化する方法をより理解できるようにすることに重点を置いています。以前のキャリアでは、テックスタートアップの中国市場参入を支援していました。

Amazon Connect に、 生成 AI 、高度なセキュリティ機能、そして合理化されたボット管理を通じて、コンタクトセンター運用を強化する新機能を導入しました。これらのイノベーションは、セキュリティとコンプライアンスを維持しながら、有意義なやり取りの時間を増やすことで、組織がより良い顧客体験を提供するのに役立ちます。 コンタクトセンターの管理者は、セルフサービス解決率の最適化、エージェントのパフォーマンスの効率的な評価、データプライバシーコンプライアンスの維持といった課題に常に直面しています。さらに、会話型 AI インタフェースの構築と管理には、多くの場合、専門知識と複数のサービスにまたがる複雑な統合が必要とされます。 これらの課題に対応するため、Amazon Connect は以下のような機能を導入しました： ターゲットを絞ったキャンペーン向けの生成 AI を活用した顧客セグメンテーション オムニチャネルサポートのためのネイティブ WhatsApp Business メッセージング チャットでの顧客機微情報の安全な収集 Amazon Connect インターフェースでの会話型 AI ボット管理の簡素化 Amazon Q in Connect の新機能 また、Amazon Connect は Amazon Connect Contact Lens による新しい分析機能を追加し、ボットのパフォーマンスとコンタクトセンター運用の最適化が可能になりました。 これらの新機能により、最高水準のデータセキュリティと運用の卓越性を維持しながら、よりパーソナライズされた効率的な顧客体験を創出することができます。 生成 AI を活用した機能 Amazon Connectは、顧客との会話を自動化し強化するための新しい生成 AI 機能を統合しました。これにより、よりスマートなターゲティングとより効率的なコンタクトセンター管理が可能になります。 生成 AI セグメンテーションとトリガーベースのキャンペーン – 会話型プロンプトを使用して 顧客セグメント を作成する生成 AI 支援機能を活用します。これにより、組織は自然言語による説明を用いて正確な顧客セグメントを作成できるようになり、特定の顧客グループの識別とリーチがより容易になります。トリガーキャンペーンでは、カート放棄などの特定の顧客イベントに基づいて顧客とコミュニケーションを取ることができます。 提案機能からすぐに使い始めることもできます。 会話型AIボットの作成を簡素化し、Amazon Q in Connect で強化 – Amazon Connect のインターフェースで、 Amazon Lex の会話型 AI ボットの作成、編集、管理が直接行えるようになりました。さらにこれらのボットを顧客サービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect によって強化できます。Amazon Q in Connect は、コンタクトセンターのエージェントに推奨応答やアクションを提案するだけでなく、音声自動応答 (IVR) やデジタルチャネルを通じたエンドユーザーのセルフサービス対応もサポートしました。 この統合により、大規模言語モデル (LLM) を活用した高度な会話能力が提供され、従来の Amazon Lex の音声やチャットボット機能を大幅に拡張します。システムは、あらかじめ設定された応答パターンに合致しない顧客の質問に対して、設定済みのナレッジベースや顧客情報、Web コンテンツ、サードパーティアプリケーションのデータをインテリジェントに検索して回答します。管理者は、インスタンスごとにカスタムガードレールを設定し、回答生成の制限を定義したり、 Amazon Q in Connect のパフォーマンスを監視したりすることができます。 生成 AI を活用したエージェントの自動評価 : スーパーバイザーは生成 AI を使用して、最大で 100% のコンタクトを自動的に評価できるようになりました。 生成 AI を活用したコンタクトの分類 : 自然言語インテントを使用して、既存のセマンティックマッチ機能を改善しました。 インターフェースとツールの改善 ボットの管理とモニタリングの機能を強化し、自動化されたエクスペリエンスの作成と最適化が簡素化されました。 WhatsApp Business メッセージングとの連携 – WhatsApp Business メッセージングとネイティブに統合し、既存の Amazon Connect チャネル (音声、SMS、チャット、 Apple Messages for Business ) に加えて、 WhatsApp 経由でのサポートを顧客に提供可能になりました。Amazon Connect のオムニチャネル機能にこの機能が追加されたことによって、組織は Amazon Connect アプリケーション内で一貫したサービス提供と管理を維持しながら、顧客に応じたコミュニケーションチャネルで対応できるようになります。 Contact Lens 会話型 AI ボットダッシュボード – Amazon Connect で構築された会話型 AI ボットのパフォーマンスを監視するための分析機能を提供します。 コンタクトの詳細におけるセルフサービス音声 (IVR) の録音 – 音声録音を含む、セルフサービス対話の包括的な記録を提供します。 当日予測の改善 – 予測、キャパシティプランニング、スケジューリング機能の一部として、以前に公開された予測と当日予測の比較が可能になりました。 Salesforce Contact Center with Amazon Connect (プレビュー) – Amazon Connect のデジタルチャネルとユニファイドルーティングを Salesforce の顧客関係管理 (CRM) システムにネイティブ統合します。この 新しい統合 により、組織は Amazon Connect と Salesforce のチャネルの両方に単一のルーティングおよびワークフローシステムを使用し、通話、チャット、ケースを最適なセルフサービスまたはエージェントとの対話へインテリジェントに振り分けることができます。ご興味をお持ちの方は、 プレビューへの参加 にサインアップしてください。 チャットのセキュリティ強化 チャットにおけるセキュリティとコンプライアンスを強化する新機能により、機密情報の安全に取り扱うことが可能になります。 チャットでの機密顧客データの収集 – Amazon Connect のチャットおよびメッセージング に、チャット対話中の顧客機密情報を安全に扱うためのデータプライバシーオプションが追加されました。この機能は、個人を特定可能な情報 (PII) とペイメントカード業界 (PCI) データを保護し、データ保護規制へのコンプライアンスを促進します。 主なメリット Amazon Connect の最新機能は、生成 AI、強化されたセキュリティ、合理化されたボット管理を組み合わせることで、組織に以下のメリットをもたらします : 顧客体験の変革 – Amazon Connect は AI を活用したセグメンテーションを通じて顧客とのインタラクションを向上させ、パーソナライズされたエンゲージメント戦略を可能にします。新しい WhatsApp Business メッセージングはオムニチャネルサポート機能を拡張し、顧客の好むチャネルで対応します。さらに Amazon Q in Connect を含む高度なボット機能によりセルフサービスの解決率が向上し、より効率的な顧客体験を提供します。 セキュリティと運用の強化 – コンタクトセンターは、運用効率を維持しながら PCI 準拠のチャット機能によりセキュリティを強化できるようになりました。カスタム AI ガードレールは適切な応答生成を促進し、シンプルなボット管理インターフェースにより専門知識の必要性が排除されます。分析と予測機能は包括的なパフォーマンス監視を提供し、最適なコンタクトセンター運用のためのデータ駆動型の意思決定を可能にします。 価格と利用可能リージョン – これらの機能は、 Amazon Connect がサポートされている すべての AWS リージョン で本日から利用可能です。価格設定については、 Amazon Connect の料金ページ をご覧ください。実装ガイダンスについては、 Amazon Connect のドキュメント をご参照ください。 Elizabeth Fuentes 私の使命は、複雑な概念をわかりやすい説明に分解し、開発者が継続的にスキルと知識を広げられるようにすることです。カンファレンス、チュートリアル、オンラインリソースを通じて、私は自分の専門知識を世界中の開発者コミュニティと共有し、彼らが潜在能力を最大限に発揮するためのツールと自信を提供しています。実践的なアプローチと、複雑なものを簡素化するというコミットメントをもって、私は AWS テクノロジーの世界における成長と学習のきっかけとなるよう努めています。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。

この記事は Effective use: Amazon ECS lifecycle events with Amazon CloudWatch logs insights (記事公開日: 2023 年 12 月 22 日) を翻訳したものです。 導入 スタートアップ企業から大手企業まで、コンテナサービスの採用が増加傾向にあることが観察されています。この傾向は、アプリケーションのデプロイが容易になったことや、オンプレミス環境からクラウドへの移行がしやすくなったことが要因となっています。多くのお客様が選択するプラットフォームの一つが、 Amazon Elastic Container Service（Amazon ECS） です。Amazon ECS の強力でシンプルな特性により、お客様は単一のタスク管理から、企業全体のアプリケーションポートフォリオの監視、さらには数千のタスクの管理にまでスケールアップすることができます。Amazon ECS を利用することで、自社でコンテナオーケストレーションサービスを運用する際に伴う管理の負担が解消されます。 お客様と仕事をしていると、Amazon ECS イベントの活用をさらに高める価値ある機会があることに気づきました。ライフサイクルイベントは、サービスイベントをメトリクスやログと関連付けることで、トラブルシューティングに役立つ洞察を提供します。Amazon ECS は最新の100件のイベントのみを表示するため、過去のイベントを遡って確認することが難しい場合があります。 Amazon CloudWatch Container Insights を使用することで、この問題が解決されます。Container Insights は Amazon ECS のライフサイクルイベントを Amazon CloudWatch Log Group に保存するからです。この連携により、イベントを遡って分析することが可能となり、運用効率が向上します。 Amazon EventBridge は、アプリケーションをシームレスに接続するサーバーレスのイベントバスです。Container Insights と併せて、Amazon ECS はイベントソースとして機能し、Amazon CloudWatch Logs は Amazon EventBridge のターゲットとして動作します。これにより、Amazon CloudWatch Logs Insights を使用したインシデント後の分析が可能になります。 本記事では、Container Insights や Amazon EventBridge 、あるいはその両方を使用して、 Amazon CloudWatch Logs Insights のクエリ を通じて Amazon ECS のサービスイベントを効果的に分析する方法を説明します。これらのクエリは、開発および運用のワークフローを大幅に改善します。 前提条件 このテクニカルガイドで紹介する手法を実践するためには、お客様のアカウントで以下の機能が有効になっている必要があります。 アクティブなワークロードがある Amazon ECS クラスター Amazon EventBridge は、イベントを Amazon CloudWatch ログに直接ストリーミングするか、Amazon ECS CloudWatch Container Insights を有効にするように設定されている ここでは、Amazon CloudWatch Logs または Container Insights にイベントをストリーミングするように Amazon EventBridge をセットアップするための詳細なガイドを紹介します。 Walkthrough 有用なライフサイクルイベントパターン Elastic Container Service（Amazon ECS）が発行するイベントは、以下の4つのグループに分類できます： コンテナインスタンス状態変更イベント – これらのイベントは、Amazon ECS コンテナインスタンスの状態に変更があった場合にトリガーされます。これは、タスクの開始や停止、Amazon ECS エージェントのアップグレード、その他のシナリオなど、様々な理由で発生する可能性があります。 タスク状態変更イベント – これらのイベントは、タスクの状態に変更があるたびに発行されます。例えば、タスクが「PENDING（保留中）」から「RUNNING（実行中）」に移行する場合や、「RUNNING（実行中）」から「STOPPED（停止）」に移行する場合などです。また、タスク内のコンテナが停止した場合や、 AWS Fargate Spot キャパシティーの終了通知を受け取った場合にもイベントがトリガーされます。 サービスアクションイベント – これらのイベントは、サービスの状態に関する情報を提供し、INFO、WARN、ERROR に分類されます。サービスが安定状態に達した場合、サービスが継続的にタスクを配置できない場合、Amazon ECS API がスロットリングされた場合、またはタスクを配置するためのリソースが不足している場合に生成されます。 サービスデプロイメント状態変更イベント – これらのイベントは、デプロイメントが進行中、完了、または失敗した場合に発行されます。通常、サーキットブレーカーロジックとロールバック設定によってトリガーされます。 これらのイベントの詳細な説明と例、および考えられるユースケースについては、 Amazon ECS イベントのドキュメント を参照してください。 それでは、運用サポートにイベントを活用する実際の例をいくつか見ていきましょう。これらの例を、イベントパターンに基づいて4つのカテゴリに分類しました： タスクパターン、サービスアクションパターン、サービスデプロイメントパターン、ECS コンテナインスタンスパターン です。各カテゴリには一般的な使用例が含まれており、具体的なクエリとその結果を示しています。 Amazon CloudWatch Logs Insights クエリの実行方法 この記事の後半で紹介する Amazon CloudWatch Logs Insights クエリを実行するには、以下の手順に従ってください。 Amazon CloudWatch コンソール を開き、「 Logs(ログ) 」を選択し、次に「 Logs Insights（ログのインサイト） 」を選択します。 クエリを実行する Amazon ECS イベントとパフォーマンスログを含むロググループ「/aws/events/ecs/containerinsights/(クラスター名)/performance」を選択します。 目的のクエリを入力し、「 Run(クエリの実行) 」を選択して結果を表示します。 タスクイベントパターン シナリオ 1: このシナリオでは、運用チームが環境内で観察された HTTP ステータス 5XX （サーバーサイドの問題）エラーの原因を調査する必要がある状況に遭遇しています。そのために、彼らは Amazon ECS タスクが意図したタスクライフサイクルを正しく踏んでいるかどうかを確認しようとしています。チームは、タスクのライフサイクルイベントが 5XX エラーの原因となっている可能性を疑っており、効果的なトラブルシューティングと解決を行うために、これらの問題の正確な原因を絞り込む必要があります。 必要なクエリ クエリー入力: detail.containers.0.taskArn: 対象タスク ARN fields time as Timestamp, `detail-type` as Type, detail.lastStatus as `Last Status`, detail.desiredStatus as `Desired Status`, detail.stopCode as StopCode, detail.stoppedReason as Reason | filter detail.containers.0.taskArn = "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/6e81bd7083ad4d559f8b0b147f14753f" | sort @timestamp desc | limit 10 結果: サービスイベントがタスクライフサイクルの確認にどのように役立つかを見てみましょう。結果から、タスクの最終ステータスが以下のように進行したことがわかります： PROVISIONING > PENDING > ACTIVATING > RUNNING > DEACTIVATING > STOPPING > DEPROVISIONING > STOPPED これは タスクライフサイクルの流れ を確認するものであり、タスクは最初に「DEACTIVATED（非アクティブ化）」され、その後「STOPPED（停止）」されたことがわかります。このタスクの停止は、「Task failed container health checks（タスクがコンテナのヘルスチェックに失敗した）」という理由で、スケジューラ（ServiceSchedulerInitiated）によって開始されたことが確認できます。 同様に、クエリを使用して、ロードバランサーのヘルスチェックに失敗したタスクのライフサイクルの詳細を取得することもできます。結果は以下のようになります： 以下のクエリで、detail.containers.0.taskArn を目的のタスクARNに置き換えてください： fields time as Timestamp, `detail-type` as Type, detail.lastStatus as `Last Status`, detail.desiredStatus as `Desired Status`, detail.stopCode as StopCode, detail.stoppedReason as Reason | filter detail.containers.0.taskArn = "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/649e1d63f0db482bafa0087f6a3aa5ed" | sort @timestamp desc | limit 10 StopTask を呼び出して手動で停止されたタスクの別の例を見てみましょう。この場合、アクションは UserInitiated （ユーザーによって開始された）で、理由は Task stopped by user （ユーザーによってタスクが停止された）となっています： さらに、両方のケースにおいて、Desired State （必要なステータス）が（誰がタスクの停止を開始したかに関係なく）タスクの Last Status （前回のステータス）をどのように導いているかを確認することができます。 参考：タスクライフサイクル シナリオ 2: サービス内でタスクの失敗が頻繁に発生し、これらの問題の根本原因を診断する手段が必要となるシナリオを考えてみましょう。タスクは、リソースの制限やアプリケーションのエラーなど、さまざまな理由で終了する可能性があります。この問題に対処するために、サービス内のすべてのタスクの停止理由をクエリして、根底にある問題を明らかにすることができます。 必要なクエリ クエリー入力: detail.group: 対象のサービス名 filter `detail-type` = "ECS Task State Change" and detail.desiredStatus = "STOPPED" and detail.group = "service:circuit-breaker-demo" |fields detail.stoppingAt as stoppingAt, detail.stoppedReason as stoppedReason,detail.taskArn as Task | sort @timestamp desc | limit 200 ヒント: サービスの自動スケーリングが有効になっていて、サービスに頻繁なスケーリングイベントがある場合は、上記のクエリにさらにフィルターを追加して、スケーリングに関連するイベントを除外し、他の停止理由に焦点を絞ることができます。 filter `detail-type` = "ECS Task State Change" and detail.desiredStatus = "STOPPED" and detail.stoppedReason not like "Scaling activity initiated by" and detail.group = "service:circuit-breaker-demo" |fields detail.stoppingAt as stoppingAt, detail.stoppedReason as stoppedReason,detail.taskArn as Task | sort @timestamp desc | limit 200 結果: 結果では、サービス内のタスクの停止理由と、それぞれのタスクIDを確認することができます。これらの停止理由を分析することで、タスクの終了につながる具体的な問題を特定できます。停止理由に応じて、考えられる解決策には、アプリケーションの調整、リソース割り当ての調整、タスク定義の最適化、またはスケーリング戦略の微調整などが含まれる可能性があります。 シナリオ 3: セキュリティチームが特定のネットワークインターフェース、MAC アドレス、またはアタッチメント ID の使用に関する重要な情報を必要とするシナリオを考えてみましょう。Amazon ECS がタスクの開始と停止時に自動的に Elastic Network Interface（ENI）をプロビジョニングおよびデプロビジョニングすることは重要なポイントです。しかし、タスクが停止されると、Elastic Network Interface（ENI）や ENI に割り当てられた Media Access Control（MAC）情報を使用して、あるタスク ID を特定するための記録や関連性がすぐに利用できなくなります。Amazon ECS が自動的に ENI を管理する特性上、これらの識別子の履歴を追跡する能力が制限される可能性があるため、このようなデータを求めるセキュリティチームの要求に応えることが課題となります。 必要なクエリ クエリー入力: detail.attachments.0.details.1.value : 対象となる ENI ID 追加:タスク ARN とクラスター ARN の詳細の置換 fields @timestamp, `detail.attachments.0.details.1.value` as ENIId,`detail.attachments.0.status` as ENIStatus, `detail.lastStatus` as TaskStatus | filter `detail.attachments.0.details.1.value` = "eni-0e2b348058ae3d639" | parse @message "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/*\"" as TaskId | parse @message "arn:aws:ecs:us-east-1:111122223333:cluster/*\"," as Cluster | parse @message "service:*\"," as Service | display @timestamp, ENIId, ENIStatus, TaskId, Service, Cluster, TaskStatus ENI ID で検索するには、detail.attachments.0.details.2.valueの値を MAC アドレスに置き換えてください。 fields @timestamp, `detail.attachments.0.details.1.value` as ENIId, `detail.attachments.0.details.2.value` as MAC ,`detail.attachments.0.status` as ENIStatus, `detail.lastStatus` as TaskStatus | filter `detail.attachments.0.details.2.value` = '12:eb:5f:5a:83:93' | parse @message "arn:aws:ecs:us-east-1:111122223333:task/CB-Demo/*\"" as TaskId | parse @message "arn:aws:ecs:us-east-1:111122223333:cluster/*\"," as Cluster | parse @message "service:*\"," as Service | display @timestamp, ENIId, MAC, ENIStatus, TaskId, Service, Cluster, TaskStatus 結果: ENI ID により、ENI がプロビジョニングされたタスク/サービス/クラスターの詳細と、関連付いたタスクの状態が結果に表示されます。 ENI と同様に、 MAC アドレスでクエリを実行しても ENI の時と同じ詳細内容を確認できます。 サービスアクションイベントパターン シナリオ 4: 最も多くの障害が発生しているサービスを特定し、その解決を優先する必要がある状況に遭遇するかもしれません。これを達成するために、問題が発生している上位 N 個のサービスをクエリして特定したいと考えています。 必要なクエリ: filter `detail-type` = "ECS Service Action" and @message like /(?i)(WARN)/ | stats count(detail.eventName) as countOfWarnEvents by resources.0 as serviceArn, detail.eventName as eventFault | sort countOfWarnEvents desc | limit 20 結果: WARN イベントをフィルタリングし、サービス固有の発生を集計することで、即座に対応が必要なサービスを特定できます。たとえば、このケースでは ecsdemo-auth-no-sd というサービスが SERVICE_TASK_START_IMPAIRED エラーに直面しています。これにより、最も影響の大きい問題の緩和と、マイクロサービスエコシステム全体の信頼性向上にリソースを集中させることができます： サービス展開イベントパターン シナリオ 5: Amazon ECS のすべてのサービスには、INFO、WARN、ERROR のいずれかのイベントタイプがあることがわかっているので、これを検索パターンとして使用して、問題のあるサービスについてワークロードを分析することができます。 必要なクエリ: fields @timestamp as Time, `resources.0` as Service, `detail-type` as `lifecycleEvent`, `detail.reason` as `failureReason`, @message | filter `detail.eventType` = "ERROR" | sort @timestamp desc | display Time, Service, lifecycleEvent, failureReason | limit 100 結果: 以下の結果では、ecsdemo-backend サービスがタスクの正常なデプロイに失敗しており、これによって Amazon ECS のサーキットブレーカーメカニズムが作動し、サービスのデプロイメントが停止されています。テーブルの左側にある展開矢印を使用すると、イベントに関するより詳細な情報を得ることができます： サービス展開イベントパターン シナリオ 6: このシナリオでは、あなたは運用チームから通知を受け取りました。最近の Amazon ECS サービスへのデプロイメント後も、アプリケーションの以前のバージョンがまだ表示されているとのことです。新しいデプロイメントが予想通りに古いものを置き換えなかったという状況に直面しており、混乱や潜在的な問題を引き起こしています。運用チームは、デプロイメントプロセス中に発生したイベントの一連の流れを理解し、何が問題だったのか原因を特定し、デプロイメントを確実に成功するために必要な是正措置を実施したいと考えています。 必要なクエリ クエリー入力: resources.0: 対象サービス ARN fields time as Timestamp, detail.deploymentId as DeploymentId , detail.eventType as Severity, detail.eventName as Name, detail.reason as Detail, `detail-type` as EventType | filter `resources.0` ="arn:aws:ecs:us-east-1:12345678910:service/CB-Demo/circuit-breaker-demo" | sort @timestamp desc | limit 10 結果: デプロイメント中に何が問題だったのかを理解するため、サービスイベントを分析してみましょう。イベントの順序を調べることで、明確なタイムラインが浮かび上がります： サービスが最初は安定状態にあり（7行目）、デプロイメントは適切であった（6行目の ecs-svc/6629184995452776901）ことがわかります。 新しいデプロイメント（ecs-svc/4503003343648563919）が発生し、おそらくコードのバグがあったと思われます（5行目）。 このデプロイメントのタスクが起動に失敗しています（3行目）。 この問題のあるデプロイメントがサーキットブレーカーロジックをトリガーし、以前の正常なデプロイメント（4行目の ecs-svc/6629184995452776901）へのロールバックを開始しています。 最終的にサービスは安定状態に戻ります（1行目と2行目）。 このイベントの流れは、何が起こったかの時系列的な視点を提供するだけでなく、関連するデプロイメントと問題の潜在的な理由についての具体的な洞察も提供しています。これらのサービスイベントを分析することで、運用チームは問題のあるデプロイメント（つまり、ecs-svc/4503003343648563919）を特定し、さらに調査して根本的なコードの問題を特定し対処することができ、将来のデプロイプロセスの信頼性が高まります。 ECS コンテナインスタンスのイベントパターン: シナリオ 7: クラスター内のコンテナインスタンスに対する Amazon ECS エージェントの更新履歴を追跡したいと考えています。追跡可能な履歴があれば、エージェントに必要なパッチと更新がインストールされていることを確認できるため、セキュリティ基準への準拠が保証されます。また、問題のある更新があった場合にロールバックの検証も可能になります。この情報は、運用効率とサービスの信頼性に役立ちます。 必要なクエリ: fields @timestamp, detail.agentUpdateStatus as agentUpdateStatus, detail.containerInstanceArn as containerInstanceArn,detail.versionInfo.agentVersion as agentVersion | filter `detail-type` = "ECS Container Instance State Change" | sort @timestamp desc | limit 200 結果: 結果からわかるように、コンテナインスタンスのエージェントは v 1.75.0 でした。 エージェントの更新がトリガーされると、エージェントを更新するプロセスはシーケンス9で開始され、最終的にシーケンス1で完了しました。 当初、コンテナインスタンスは ECS Agent バージョン 1.75.0 で動作していました。 その後、シーケンス 9 で更新操作が開始され、新しい Amazon ECS エージェントバージョンが存在することが示されました。 一連のアップデートアクションの後、エージェントアップデートはシーケンス1で正常に終了しました。 この情報は、バージョン移行と更新手順の明確なスナップショットを提供し、ECS クラスターのセキュリティ、信頼性、および機能性を確保するために Amazon ECS エージェントの更新を追跡することの重要性を強調しています。 クリーンアップ サンプルクエリの探索が完了したら、追加のコストが発生しないように、Amazon EventBridge ルールと Amazon ECS CloudWatch コンテナインサイトを必ず無効にしてください。 結論 この記事では、トラブルシューティングに貴重なリソースである Amazon ECS イベントの可能性を最大限に活用する方法を探ってきました。Amazon ECS は、タスク、サービス、デプロイメント、およびコンテナインスタンスに関する有用な情報を提供します。Amazon CloudWatch Logs で ECS イベントを分析することで、時間の経過に伴うパターンの特定、他のログとのイベントの相関関係の把握、繰り返し発生する問題の発見、そして様々な形式の分析を行うことができます。 我々は、Amazon ECS イベントを検索し活用するための簡単でありながら強力な方法を概説しました。これには、予期せぬ停止を素早く診断するためのタスクのライフサイクルの追跡、セキュリティを強化するための特定のネットワーク詳細を持つタスクの特定、問題のあるサービスの特定、デプロイメントの問題の理解、そして信頼性のための Amazon ECS エージェントの最新状態の確認が含まれます。システムの運用に関するこの幅広い視点により、問題に積極的に対処し、コンテナのパフォーマンスに関する洞察を得て、スムーズなデプロイを促進し、システムのセキュリティを強化することができます。 その他の参考資料 ライフサイクルイベントの基本について説明したので、次はトラブルシューティングの目的で Amazon CloudWatch Log Insights コンソールでこれらのライフサイクルイベントをクエリするベストプラクティスを見てみましょう。 Amazon CloudWatch クエリのドメイン固有言語 (DSL) の詳細については、ドキュメント ( CloudWatch ログインサイトのクエリ構文 ) を参照してください。 Amazon ECS イベントの EventBridge をさらに処理することで、異常検出をさらにセットアップすることができます。これについては、「 Amazon EventBridge を利用した Amazon Elastic Container Service Anomaly Detector 」で詳しく説明されています。 翻訳はクラウドサポートエンジニアの桐生が担当しました。原文は こちら です。

本記事は 2024 年 11 月 21 日に公開された “ Amazon ElastiCache version 8.0 for Valkey brings faster scaling and improved memory efficiency ” を翻訳したものです。 2024 年 11 月 21 日、 Amazon ElastiCache で Valkey 8.0 のサポートを追加しました。 ElastiCache for Valkey バージョン 8.0 では、ElastiCache Serverless のスケーリングが高速化され、ノードベースのクラスターのメモリ最適化が実現されています。 このブログ記事では、これらの改善点をどのように活用できるかについて説明します。 ご存知ない方に説明しますと、 Valkey は、オープンソースのインメモリ型キーバリューデータストアです。Redis OSS の代替として使用できます。 Linux Foundation が管理しており、活発な開発者コミュニティからの貢献により急速に改善が進んでいます。 AWS は Valkey に積極的に貢献しています。AWS の Valkey への貢献について詳しくは、 Amazon ElastiCache と Amazon MemoryDB の Valkey サポート を発表 をご覧ください。 先月、価格を改定した ElastiCache バージョン 7.2 for Valkey を 発表 しました。 ElastiCache は、Valkey、Memcached、Redis OSS と互換性のあるフルマネージド型のキャッシングサービスで、99.99% の可用性を備えたモダンアプリケーション向けにリアルタイムでコスト最適化されたパフォーマンスを提供します。 ElastiCache は、マイクロ秒単位の読み取りと書き込みのレスポンスタイムで、1 秒あたり数百万のオペレーションまでスケールし、データベースとアプリケーションのパフォーマンスを向上させます。 ElastiCache Serverless のスケーリング改善 ElastiCache Serverless を使用すると、1 分以内にキャッシュを作成し、アプリケーションのトラフィックパターンに基づいて容量をスケーリングできます。 これまで、キャッシュの適切なサイジングはコストとパフォーマンスのバランスを取る作業でした。 ピーク時に十分なバッファを持った容量をプロビジョニングすることはできましたが、使用していない容量に対しても料金を支払う必要がありました。 あるいは、必要最小限の容量をプロビジョニングし、必要に応じて手動でスケーリングすることもできましたが、予期せぬトラフィックの急増が発生した場合にパフォーマンスのボトルネックに遭遇する可能性がありました。 私たちは、最も要求の厳しいワークロードでも容量計画を必要とせずにキャッシュを運用できるよう、ElastiCache Serverless をリリースしました。 リリース以来、多くのお客様から、バイラル化した(いわゆるバズった)ライブイベントなどに発生する突発的なトラフィックに対して、より迅速にアプリケーションをスケーリングできるようにしてほしいという要望をいただいています。 ElastiCache Serverless version 8.0 for Valkey は、急激な負荷変動や急速にスケールするワークロードへの対応を改善しました。 以前の ElastiCache Serverless では、10-12 分ごとに 1 秒あたりのリクエスト数 (RPS) を 2 倍にすることができました。 Valkey 8.0 では、ElastiCache Serverless は 13 分以内に 0 から 500 万 RPS までスケールでき、2-3 分ごとに対応可能な RPS を 2 倍にすることができます。 これらの改善をどのように実現したのか、そしてベンチマークの結果について見ていきましょう。 Valkey 8.0 では、AWS が新しいマルチスレッドアーキテクチャを通じて 100 万以上の RPS を達成するなど、大幅なパフォーマンス向上を実現しました。 新しい I/O スレッド実装により、メインスレッドと I/O スレッドが並行して動作し、コマンドの読み取りと解析、レスポンスの書き込み、I/O イベントのポーリングなどのタスクをオフロードできます。 この設計により、同期メカニズムを最小限に抑え、Valkey のシンプルさを維持しながらパフォーマンスを向上させています。 オープンソースの Valkey 8.0 における I/O マルチスレッドの具体的な改善点については、 Unlock 1 Million RPS: Experience Triple the Speed with Valkey をご覧ください。 これらの改善点は、ElastiCache Serverless version 8.0 for Valkey で活用され、より高速なバーストスケーリングとスケールアウト操作を処理できるようになりました。 オンデマンドでより多くのコアを有効化し、I/O スレッディングを最適化することで、ElastiCache Serverless は追加のスループットをサポートするために I/O スレッドを動的に割り当てることができます。 さらに、ElastiCache Serverless は、新しいシャードへのデータ移行を含む水平スケーリングを処理するために、追加の I/O スレッドを割り当てることができます。 この強化されたスケーリング機能により、ElastiCache Serverless は高トラフィックのシナリオやトラフィックの急増をより効果的に処理でき、高スループットと最小限のレイテンシーを必要とするアプリケーションに恩恵をもたらします。 ベンチマークデータ ElastiCache Serverless for Valkey 8.0 でアプリケーションワークロードをどれだけ迅速にスケールできるかを示すために、典型的なキャッシングのユースケースを選びました。 アプリケーションが 512 バイトの値をキャッシュし、読み取りと書き込みのトラフィックの比率がおよそ 80 対 20 であると仮定します。 このテストでは、アプリケーションのリクエストレートが 0 RPS から 500 万 RPS まで増加すると想定しています。 ElastiCache Serverless for Valkey バージョン 7.2 まず、以前のバージョンである ElastiCache Serverless version 7.2 for Valkey で実行されているワークロードを見てみましょう。 以下のグラフは、キャッシュに対するワークロードによって実行された 1 秒あたりのリクエスト数 (RPS) と、p50 および p99 レイテンシーを示しています。 グラフが示すように、ElastiCache Serverless for Valkey バージョン 7.2 は、グラフの紫色の線で示されているように、ピークの 500 万 RPS までスケールするのに約 50 分かかり、10 分ごとに RPS が効果的に 2 倍になっています。 この間、p50 読み取りレイテンシー (青線) は 1 ミリ秒未満を維持していますが、p99 レイテンシー (オレンジ色と赤色の線) は最大 9 ミリ秒まで上昇します。 ElastiCache Serverless for Redis バージョン 8.0 次に、ElastiCache Serverless for Valkyl バージョン 8.0 で実行されている同じワークロードを見てみましょう。 グラフからわかるように、ElastiCache Serverless version 8.0 for Valkey は、はるかに高速なスケーリングを実現し、0 から 500 万回/秒 のピークまで 13 分未満で到達し、実質的に 2 分ごとに対応可能な RPS を 2 倍にしています。 応答時間の特性は一貫しており、読み取り応答時間の 50 パーセンタイル値は 1 ミリ秒未満を維持し、応答時間の 99 パーセンタイル値は 7～8 ミリ秒まで上昇します。 結果の概要 以下の表は、ベンチマーク結果をまとめたものです。 ElastiCache モード ベースラインからピーク RPS に到達するまでの時間 p50 読み取りレイテンシー p99 読み取りレイテンシー ElastiCache Serverless version 7.2 for Valkey 50 分 800 マイクロ秒未満 8-9 ms ElastiCache Serverless version 8.0 for Valkey 13 分 800 マイクロ秒未満 7-8 ms メモリ使用量の改善 Valkey 8.0 では、ワークロードのメモリ使用量とリソース消費を削減するのに役立つ、重要なメモリ効率の改善が導入されています。 まず、この分野で AWS が OSS Valkey に貢献した改善点について見ていきましょう。 OSS Valkey 8.0 の主な機能強化の 1 つは、クラスター構成におけるメモリ管理の最適化です。 以前の Valkey のクラスターモードでは、16,384 個のハッシュスロットにデータを分散させており、特に大規模なデプロイメントでは大量のメタデータのオーバーヘッドが必要でした。 Valkey 8.0 では「スロットごとの辞書」モデルを採用し、スロットごとのメタデータ要件を削減することでメモリ使用量を低減しています。 このアップデートにより、キーあたり 32 バイトのメモリ削減が実現し、ワークロードのキーサイズによっては大幅なメモリ削減につながる可能性があります。 Valkey 8.0 の改善点に関する技術的な詳細については、 Storing more with less: Memory Efficiency in Valkey 8 をご覧ください。 では、これが Valkey の ElastiCache バージョン 8.0 でどのように実現されているかを見てみましょう。 Valkey 用の ElastiCache Serverless の価格設定では、これらのメモリ最適化を見込んで、潜在的なコスト削減を反映させました。 GB あたりおよび ECPU あたりの価格を引き下げ、ストレージの最小容量を 1 GB から 100 MB に削減し、Valkey 用の ElastiCache Serverless の価格を Redis OSS 版と比べて 33% 低く設定しました。 さらに、Valkey 8.0 では、SET データ構造を使用するユーザーは、SET の要素あたり 24 バイト少なくなり、さらなるコスト削減が可能になります。 クラスターモードで Valkey 8.0 を実行するノードベースのクラスターでは、このメモリ効率化によりあらゆる面でメモリ消費量が削減されます。 ベンチマークでは、16 バイトのキーと 100 バイトの値を使用する文字列のワークロードをテストしました。 同一のデータを Valkey 7.2 を実行するクラスターと Valkey 8.0 を実行するクラスターに格納し、この新しいリリースで実現できるメモリ削減量を明らかにしました。 サーバーレスキャッシュにデータを追加するためには valkey-benchmark ツールを使用しました。 src/valkey-benchmark \ -t set \ -n 10000000 \ -r 10000000 \ -d 100 Valkey 7.2 クラスターのメモリ使用量を確認しました: Valkey 7.2> DBSIZE (integer) 6322820 Valkey 7.2> INFO MEMORY # Memory used_memory:1491244824 used_memory_human:1.39G 次に、Valkey 8.0 クラスターのメモリ使用量を確認しました。 Valkey 8.0> DBSIZE (integer) 6319345 Valkey 8.0> INFO MEMORY # Memory used_memory:1192317904 used_memory_human:1.11G この特定のワークロードでは、ノードベースのクラスターのメモリ使用量が 1.39 GB から 1.11 GB に減少し、メモリ使用量が 20% 削減されました。 このメモリ使用量の削減は、このワークロードの種類に特有のものです。 ワークロードの詳細によって、メモリ使用量の削減量は異なる場合があります。 まとめ ElastiCache for Valkey バージョン 8.0 が、すべての AWS リージョンで利用可能になりました。 Redis OSS および Valkey 7.2 から Valkey 8.0 へ、ElastiCache Serverless キャッシュとノードベースの ElastiCache クラスターをアップグレードし、パフォーマンスとメモリ使用率の改善を活用することをお勧めします。 スケーリングの改善とメモリ効率の向上に加えて、ElastiCache for Valkey への移行はコスト削減にも役立ちます。 ElastiCache Serverless for Valkey は、他のエンジン向けの ElastiCache Serverless と比べて 33% 低価格で、ノードベースの ElastiCache for Valkey は 20% 低価格です。 ElastiCache Serverless for Valkey は、月額 6 ドルという低価格で始めることができます。 ElastiCache for Valkey のバージョン 8.0 の詳細については、What’s new ページをご覧ください。ElastiCache for Valkey の使用開始方法については、 Amazon ElastiCache for Valkeyの開始方法 の詳細な手順をご参照ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Abhay Saxena は、Amazon Web Services のインメモリデータベースチームのプロダクトマネージャーで、ElastiCache Serverless を担当しています。 ElastiCache チームに参加する前は、Amazon で 13 年以上プロダクトマネージャーとして勤務していました。 Rashim Gupta は AWS のシニアマネージャー、製品管理で、Amazon ElastiCache と Amazon MemoryDB の製品責任者を務めています。 AWS で 6 年以上の経験を持ち、コンピュート、ストレージ、データベースの分野でプロダクトマネージャーとして従事してきました。

本記事は 2024 年 11 月 12 日に公開された “ Use Amazon ElastiCache as a cache for Amazon Keyspaces (for Apache Cassandra) ” を翻訳したものです。 この投稿では、ブックアワードのデータを保存するために Amazon Keyspaces (for Apache Cassandra) テーブルを使用するアプリケーションのライトスルーキャッシュとして Amazon ElastiCache を使用する方法をご紹介します。Amazon Keyspaces にプログラムでアクセスするために Cassandra Python クライアントドライバー を使用し、ElastiCache クラスターに接続するために Redis クライアント を使用します。 Amazon Keyspaces は、スケーラブルで高可用性を備えた、フルマネージド型の Cassandra 互換データベースサービスで、どのようなスケールでも数ミリ秒の読み取りと書き込みのレスポンスタイムを提供します。 Amazon Keyspaces はサーバーレスであるため、クラスター内のノードを通じてワークロードのストレージと計算リソースをデプロイ、管理、維持する代わりに、テーブルに直接ストレージと読み取り/書き込みスループットリソースを割り当てます。 ほとんどのワークロードでは、Amazon Keyspaces が提供する 1 桁ミリ秒の応答時間で十分であり、Amazon Keyspaces が返す結果をキャッシュする必要はありません。 しかし、アプリケーションが読み取り操作でサブミリ秒の応答時間を必要とする場合や、読み取り集中型でありながらコストに敏感な場合、あるいはパーティションごとに 1 秒あたり 3,000 読み取りキャパシティユニット (RCU) を超えるような繰り返しの読み取りが必要な場合があります。 Amazon ElastiCache は、フルマネージド型で高可用性を備えた分散型の高速インメモリデータストアで、Amazon Keyspaces テーブルのキャッシュとして使用でき、読み取りレイテンシーをサブミリ秒レベルまで短縮し、読み取りスループットを向上させ、バックエンドデータベースのコストを増やすことなく、より高い負荷にスケールできます。 Amazon ElastiCache は、オープンソースのキーバリューストアである Valkey および Redis OSS と互換性があります。 この投稿で説明するアプローチとコードは、これらのエンジンの両方で動作します。 この投稿では、ライトスルーキャッシュ方式と遅延読み込みを使用しています。 ライトスルーキャッシュは、初期レスポンス時間を改善し、キャッシュされたデータを基盤となるデータベースと同期した状態に保ちます。 遅延読み込みでは、キャッシュミスが発生した場合にのみデータがキャッシュにロードされるため、キャッシュのリソース使用量が削減されます。 キャッシュ設計の詳細については、 キャッシングパターン と キャッシュ設計 を参照してください。 前提条件 Amazon Keyspaces への接続の前提条件 には、TLS 証明書のダウンロードと TLS を使用するための Python ドライバーの設定、関連する Python パッケージのダウンロード、そしてキースペースとテーブルへの接続設定が含まれます。 以下は、 Amazon Keyspaces SigV4 認証プラグイン を使用して Amazon Keyspaces テーブルに接続するための定型コードです。 from cassandra.cluster import * from ssl import SSLContext, PROTOCOL_TLSv1_2 , CERT_REQUIRED from cassandra.auth import PlainTextAuthProvider from cassandra_sigv4.auth import SigV4AuthProvider from cassandra.query import SimpleStatement import time import boto3 ssl_context = SSLContext(PROTOCOL_TLSv1_2) ssl_context.load_verify_locations('/home/ec2-user/sf-class2-root.crt') ssl_context.verify_mode = CERT_REQUIRED boto_session = boto3.Session() auth_provider = SigV4AuthProvider(boto_session) cluster = Cluster(['cassandra.us-east-1.amazonaws.com'], ssl_context=ssl_context, auth_provider=auth_provider, port=9142) session = cluster.connect() sigv4 プラグインを使用することが、推奨されるセキュリティのベストプラクティスです。ただし、Cassandra が認証とアクセス管理に使用する従来のユーザー名とパスワードとの下位互換性のために、 サービス専用の認証情報 を使用して Amazon Keyspaces に接続することもできます。 ElastiCache クラスターへの接続手順については、 ElastiCache への接続 を参照してください。 以下は、ElastiCache クラスターに接続するための定型コードです： from rediscluster import RedisCluster import logging logging.basicConfig(level=logging.ERROR) redis = RedisCluster(startup_nodes=[{"host": "keyspaces-cache.eeeccc.clustercfg.use1.cache.amazonaws.com", "port": "6379"}], decode_responses=True, skip_full_coverage_check=True) if redis.ping(): logging.info("Connected to Redis") Amazon Keyspaces テーブルスキーマ この例では、catalog というキースペースにある book_awards という名前の Amazon Keyspaces テーブルを使用して、ブックアワードに関するデータを保存しています。 パーティションキーは award と year のカラムで構成されています。 次のスクリーンショットに示すように、このテーブルには category と rank という 2 つのクラスタリングキーカラムがあります。 このキースキーマにより、パーティション全体にデータが均等に分散され、この投稿で説明するアクセスパターンに対応できます。 Amazon Keyspaces のデータモデリングのベストプラクティスについては、 データモデリングのベストプラクティス：データモデル設計のための推奨事項 を参照してください。 以下のスクリーンショットは、このテーブルのサンプルデータを数行表示しています。 次のセクションでは、Amazon Keyspaces の操作とそれらの操作のキャッシュ結果に関するサンプルコードスニペットを見ていきます。 このブログ記事のコードスニペットは参考用であり、入力の検証とエラー処理はサンプルには含まれていません。 単一行の INSERT および DELETE 操作 ライトスルーキャッシングプロセスでは、プライマリデータベースの更新直後にキャッシュが積極的に更新されます。 基本的なロジックは以下のようにまとめることができます： アプリケーションが Amazon Keyspaces の行を追加または削除します その直後に、キャッシュ内の行も追加または削除されます 以下の図は、ライトスルーキャッシング戦略を示しています。 以下のサンプルコードは、book_awards データに対する INSERT および DELETE 操作に対して、ライトスルー戦略を実装する方法を示しています。 #Global variables keyspace_name="catalog" table_name="book_awards" #Write a row def write_award(book_award): write_award_to_keyspaces(book_award) write_award_to_cache(book_award) #write row to the Keyspaces table def write_award_to_keyspaces(book_award): stmt=SimpleStatement(f"INSERT INTO {keyspace_name}.{table_name} (award, year, category, rank, author, book_title, publisher) VALUES (%s, %s, %s, %s, %s, %s, %s)", consistency_level=ConsistencyLevel.LOCAL_QUORUM) session.execute(stmt,(book_award["award"], book_award["year"], book_award["category"], book_award["rank"], book_award["author"], book_award["book_title"], book_award["publisher"])) #write row to the cache def write_award_to_cache(book_award): #construct Redis key name key_name=book_award["award"] + str(book_award["year"])+ book_award["category"] + str(book_award["rank"]) #write to cache using Redis set, ex=300 sets TTL for this row to 300 seconds redis.set(key_name, str(book_award), ex=300) #Delete a row def delete_award(award, year, category, rank): delete_award_from_keyspaces(award, year, category, rank) delete_award_from_cache(award, year, category, rank) #delete row from Keyspaces table def delete_award_from_keyspaces(award, year, category, rank): stmt = SimpleStatement(f"DELETE FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank=%s ;", consistency_level=ConsistencyLevel.LOCAL_QUORUM) session.execute(stmt, (award, int(year), category, int(rank))) #delete row from cache def delete_award_from_cache(award, year, category, rank): #construct Redis key name key_name=award + str(year)+ category + str(rank) #delete the row from cache if it exists if redis.get(key_name) is not None: book_award=redis.delete(key_name) プライマリーキーによる単一のブックアワードの取得 遅延ロードを使用した基本的なデータ取得ロジックは、以下のようにまとめることができます。 アプリケーションがデータベースからデータを読み取る必要がある場合、まずキャッシュをチェックしてデータが利用可能かどうかを確認します。データが利用可能な場合 (キャッシュヒット)、キャッシュされたデータが返され、呼び出し元にレスポンスが送信されます データが利用できない場合 (キャッシュミス)： データベースにデータを問い合わせます データベースから取得したデータをキャッシュに格納し、そのデータを呼び出し元に返します 以下の図は、データ取得のロジックを示しています。 このユースケースで想定される最も一般的なアクセスパターンの 1 つは、すべてのプライマリキーの列が既知の場合にブックアワードを要求することです。 レイジーローディング戦略では、アプリケーションはまずキャッシュからリクエストされたデータの取得を試みます。キャッシュに行が見つからない場合、データベースから行を取得し、将来の使用のためにキャッシュします。 TTL (Time to Live) は、キーの有効期限を秒単位で指定する整数値です。Valkey や Redis OSS では、この値に秒またはミリ秒を指定できます。この例では TTL 値を 300 秒に設定していますが、アプリケーションのニーズに応じて設定を変更できます。 さらに、Python の time ライブラリを使用して、データベースからの結果取得とキャッシュからの結果取得の応答時間を比較することができます。 #Global variables keyspace_name="catalog" table_name="book_awards" #Read a row def get_award(award, year, category, rank): #construct Redis key name from parameters key_name=award + str(year)+ category + str(rank) start=time.time() book_award=redis.get(key_name) end=time.time() elapsed=(end - start)*1000 #if row not in cache, fetch it from Keyspaces table if not book_award: print("Fetched from Cache: ", book_award) stmt = SimpleStatement(f"SELECT * FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank=%s ;") start=time.time() res=session.execute(stmt, (award, int(year), category, int(rank))) end=time.time() elapsed=(end - start)*1000 if not res.current_rows: print("Fetched from Database: None") return None else: #lazy-load into cache book_award=redis.set(key_name, str(res.current_rows), ex=300) print("Fetched from Database in: ", elapsed, "ms") return res.current_rows else: print("Fetched from Cache in: ", elapsed, "ms") return book_award 複数のパラメータに基づく結果セットの取得 ここでのもう 1 つの一般的なアクセスパターンは、「X 年の Y カテゴリーにおける上位 N 件の受賞データを取得する」と想定されています。 この記事では、リクエストパラメータを連結し、この連結された文字列を、リクエストパラメータに一致する賞のリストの Redis キーとして使用します。 #Global variables keyspace_name="catalog" table_name="book_awards" #Read one or more rows based on parameters def get_awards(parameters): #construct key name from parameters key_name="" for p in parameters: key_name=key_name + str(p) start=time.time() book_awards=redis.lrange(key_name, 0, -1) end=time.time() elapsed=(end - start)*1000 #if result set not in cache, fetch it from Keyspaces table if not book_awards: print("Fetched from Cache: ", book_awards) stmt = SimpleStatement(f"SELECT * FROM {keyspace_name}.{table_name} WHERE award=%s AND year=%s AND category=%s AND rank<=%s ;") start = time.time() res=session.execute(stmt, parameters) end=time.time() elapsed=(end - start)*1000 if not res.current_rows: print("Fetched from Database: None") return None else: #lazy-load into cache redis.rpush(key_name, str(res.current_rows)) redis.expire(key_name, 300) print("Fetched from Database in: ", elapsed, "ms") return res.current_rows else: print("Fetched from Cache: ", elapsed, "ms") return book_awards テストケース 最初のテストケースでは、単一行のデータ挿入、キャッシュヒット、キャッシュミス、データ削除のシナリオにおけるキャッシュと遅延ロードの動作を検証します。 def test_case_1(): book_award={"award": "Golden Read", "year": 2021, "category": "sci-fi", "rank": 2, "author": "John Doe", "book_title": "Tomorrow is here", "publisher": "Ostrich books"} #insert an award to the DB and cache write_award(book_award) print("Test Case 1:") print("New book award inserted.") #cache hit - get award from cache print("\n") print("Verify cache hit:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #let the cache entry expire print("\n") print("Waiting for cached entry to expire, sleeping for 300 seconds...") time.sleep(300) #cache miss - get award from DB and lazy load to cache print("\n") print("Entry expired in cache, award expected to be fetched from DB:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #cache hit - get award from cache print("\n") print("Verify that award is lazy loaded into cache:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) print(res) #delete the award from cache and DB print("\n") print("Deleting book award.") delete_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) #confirm the award was deleted from cache and DB print("\n") print("Verify that the award was deleted from cache and DB:") res=get_award(book_award["award"], book_award["year"], book_award["category"], book_award["rank"]) if res: print(res) このテストケースを実行すると、予想通り以下のような出力が生成されます。 キャッシュからデータを取得する場合は 1 ミリ秒未満の往復時間が観測され、データベースへの問い合わせの場合はミリ秒単位の応答時間が観測されます。 Test Case 1: New book award inserted. Verify cache hit: Fetched from Cache in: 0.3809928894042969 ms {'award': 'Golden Read', 'year': 2021, 'category': 'sci-fi', 'rank': 2, 'author': 'John Doe', 'book_title': 'Tomorrow is here', 'publisher': 'Ostrich books'} Waiting for cached entry to expire, sleeping for 300 seconds... Entry expired in cache, award expected to be fetched from DB: Fetched from Cache: None Fetched from Database in: 14.202594757080078 ms [Row(year=2021, award='Golden Read', category='sci-fi', rank=2, author='John Doe', book_title='Tomorrow is here', publisher='Ostrich books')] Verify that award is lazy loaded into cache: Fetched from Cache in: 0.4191398620605469 ms [Row(year=2021, award='Golden Read', category='sci-fi', rank=2, author='John Doe', book_title='Tomorrow is here', publisher='Ostrich books')] Deleting book award. Verify that the award was deleted from cache and DB: Fetched from Cache: None Fetched from Database: None 2 番目のテストケースでは、複数のパラメータに基づいて結果セットを取得する際のキャッシュと遅延ロードの動作を検証します。 このポストの Amazon Keyspaces テーブルスキーマ セクションで説明したように、Amazon Keyspaces テーブルには書籍の受賞データがあらかじめ読み込まれています。 このテストケースでは、データベースに新しい行を挿入する代わりに、事前に読み込まれたデータを扱います。 def test_case_2(): print("Test Case 2:") print("Get top 3 Must Read book awards for year 2021 in the Sci-Fi category") print("\n") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #cache-hit - get awards from cache print("\n") print("Verify cache hit on subsequent query with same parameters:") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #let the cache entry expire print("\n") print("Waiting for cached entry to expire, sleeping for 300 seconds...") time.sleep(300) #cache miss - get award from DB and lazy load to cache print("\n") print("Entry expired in cache, awards expected to be fetched from DB.") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) #cache hit - get award from cache print("\n") print("Verify that awards are lazy loaded into cache:") res=get_awards(["Must Read", 2021, "Sci-Fi", 3]) print(res) 遅延ロードとキャッシングのワークフローの動作を確認できます。 最初の呼び出しではキャッシュに結果が見つからないため、キャッシュの基盤となる Amazon Keyspaces テーブルからデータを取得し、キャッシュにロードします。 2 回目の呼び出しでは、キャッシュから結果を取得します。 キャッシュされた結果が期限切れになると、データベースから結果を再度取得し、キャッシュに遅延ロードされます。これにより、同じパラメータでの後続の get_awards 呼び出しでキャッシュからの高速な取得が可能になります。 キャッシュからのデータ取得では 1 ミリ秒未満の往復時間が、データベースへの往復ではミリ秒単位の往復時間が観察できます。 Test Case 2: Get top 3 Must Read book awards for year 2021 in the Sci-Fi category Fetched from Cache: [] Fetched from Database in: 21.03400230407715 ms [Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')] Verify cache hit on subsequent query with same parameters: Fetched from Cache: 0.36835670471191406 ms ["[Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')]"] Waiting for cached entry to expire, sleeping for 300 seconds... Entry expired in cache, awards expected to be fetched from DB. Fetched from Cache: [] Fetched from Database in: 32.64594078063965 ms [Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')] Verify that awards are lazy loaded into cache: Fetched from Cache: 0.3757476806640625 ms ["[Row(year=2021, award='Must Read', category='Sci-Fi', rank=1, author='Polly Gon', book_title='The mystery of the 7th dimension', publisher='PublishGo'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=2, author='Kai K', book_title='Time travellers guide', publisher='Publish123'), Row(year=2021, award='Must Read', category='Sci-Fi', rank=3, author='Mick Key', book_title='Key to the teleporter', publisher='Penguins')]"] スクリプト例 サンプルスクリプトとテスト関数は、この GitHub リポジトリ で確認できます。 検討事項 この投稿では、ブックアワードのデータに対する 2 つの最も一般的なアクセスパターンの結果をキャッシュする基本的な実装を紹介します。 アクセスパターンの性質に応じて、他にもデータをキャッシュする方法があります： パーティションキーの値のみに基づいて結果をキャッシュ（クライアント側でフィルタリング） – アプリケーションですべてのリクエストパラメータを処理する代わりに、パーティションキーの列のみ（例えば、賞と年）に基づいて結果セットをキャッシュすることができます。その他のフィルタリングはすべてクライアント側で処理されます。これは、異なるクエリ間で、このパーティションキー値を持つ少数の行のみを結果セットから除外する必要がある場合に有用です。結果セットを一度だけキャッシュし、クライアント側で異なるクラスタリング列の値やフィルタ条件を処理します。 すべてのキーパラメータを順序付け（例：昇順）してハッシュ化 – ハッシュ値をキャッシュ結果のキーとして使用できます。同じキーパラメータを使用して同じ結果が要求された場合、ハッシュは一貫性を保ち、キャッシュは必要な結果セットを返します。このオプションは、クエリが動的で、クエリ間でキー条件の順序が異なる場合に役立ちます。 すべてのクエリパラメータ（キー条件とフィルタ）を順序付け（例：昇順）してハッシュ化 – ハッシュ値をキャッシュ結果のキーとして使用できます。同じクエリパラメータが異なる順序で要求された場合でも、ハッシュは一貫性を保ち、キャッシュは必要な結果セットを返します。このオプションは、クエリパラメータとフィルタが動的で、クエリ間でパラメータの順序が異なる場合に役立ちます。 まとめ このブログでは、Amazon Keyspaces にデータを保存し、1 ミリ秒未満の読み取り応答時間が必要な、読み取りの多いコストに敏感なアプリケーションのキャッシュとして Amazon ElastiCache を使用する方法を紹介しました。 Amazon ElastiCache を使用することで、クエリの性質に基づいてカスタムキャッシュ戦略を柔軟に設計できます。 また、適切な TTL 値と共に、独自のキャッシュへのデータ投入とエビクションのロジックを設定することもできます。 詳細については、 ElastiCache クラスターの設計と管理 をご参照ください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Juhi Patil は、ロンドンを拠点とする NoSQL スペシャリストソリューションアーキテクトで、ビッグデータテクノロジーのバックグラウンドを持っています。 現在の役割では、お客様の Amazon Keyspaces および Amazon DynamoDB ベースのソリューションの設計、評価、最適化を支援しています。

この記事は 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) 認定など、さまざまな業界の認定資格も持っています。