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

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

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

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

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

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

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

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

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

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

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

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

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

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

本稿は、2024 年 11 月 25 日に AWS Blog で公開された “What’s Next for VMware Workloads on AWS?” を翻訳したものです。 AWS と VMware (現在は Broadcom の一部) は、VMware のお客様が、クラウドのスケーラビリティ、俊敏性、コスト面でのメリットを実現し、VMware ベースのワークロードを AWS へ簡単に移行・モダナイズできるようにするため、2016 年から投資とイノベーションを行ってきました。過去 1 年間に行われた VMware 関連の何百件もの会話の中で、お客様もパートナーも、AWS で VMware ベースのワークロードを実行する際のエクスペリエンスを向上させるオプションを探している、という声を多くいただきました。 AWS は、VMware ベースのワークロードをクラウドで実行するにあたり、VMware のお客様に最も多くの選択肢と柔軟性を提供することに全力を注いでいます。また、お客様のニーズをサポートするために、移行とモダナイゼーションのパス、プログラム、パートナーシップを拡大し続けています。Broadcom の VMware Cloud on AWS マネージドサービスを選択したお客様以外にも、使い慣れた VMware ツールと組み合わせて AWS の弾力性と拡張性を簡単に利用できる、ファーストパーティの AWS サービスを好むお客様もいると聞いています。 AWS における VMware のニーズへの対応 — Amazon Elastic VMware Service Amazon Elastic VMware Service (Amazon EVS) のプレビューを開始したことをお知らせできることを嬉しく思います。これは、お客様が Amazon Virtual Private Cloud (Amazon VPC) 内で VMware Cloud Foundation (VCF) を実行するための新しいネイティブ AWS サービスです。この新しいサービスにより、お客様は VMware Cloud Foundation のライセンスポータビリティ資格を利用して、VMware ベースのワークロードを AWS の他のアプリケーションと並行して AWS 上で実行できます。Amazon EVS はデプロイを簡素化し、すぐに使用できる VCF 環境を提供するため、お客様はオンプレミスで既に使用しているものと同じ VCF ソフトウェアを使用しながら、VMware ベースの仮想マシンを AWS へ迅速に移行できます。 Amazon EVS は、リファクタリングやプラットフォーム変更を行わずに、AWS の俊敏性、コスト削減、拡張のメリットを引き出します。お客様は、Amazon EVS のガイド付き設定と自動デプロイを使用すれば、わずか数時間で完全な VCF 環境をセットアップでき、AWS 上でアプリケーションを移動、拡張、スケーリングできます。Amazon EVS を利用すると、お客様固有のワークロードに合わせて高度に最適化されたインフラストラクチャを柔軟かつ制御できるようになり、IP アドレスの変更、スタッフの再トレーニング、運用ランブックの書き直しを行うことなく、オンプレミスネットワークの拡張やワークロードの移行を自由に行えます。Amazon EVS のお客様は、バックアップ、ディザスタリカバリ、ストレージ用のサードパーティ製ツールを含め、使い慣れた VCF の機能やツールを管理、監視、自動化に使用できます。お客様は、他の AWS ネイティブ機能を使用してこれらのワークロードを簡単に強化し、時間をかけてモダナイズすることを検討できます。 お客様やパートナーにネイティブの AWS ソリューションを提供すると同時に、AWS サービスによるモダナイゼーションへの道筋を提供することで、VMware ユーザーに最高のクラウド体験を提供するという取り組みを継続できることを嬉しく思います。 re:Invent 2024 で詳細をご確認ください Amazon Elastic VMware Service は re: Invent 2024 でプレビュー版としてリリースされる予定です。Amazon EVS の特徴と機能に関する詳細なセッションに、対面またはオンラインで参加してください。 Amazon EVS に関心のあるお客様やパートナー様は、AWS の担当者にお問い合わせください。 マイグレーション &amp; モダナイゼーション イノベーショントーク 太平洋標準時 12 月 3 日（火） | 午後 5 時 30 分 – 午後 6 時 30 分 スピーカー：Asa Kalavede, バイスプレジデント, マイグレーション &amp; モダナイゼーション, AWS AWS for VMware エキスポ・ブース AWS Expo Hall ではデモンストレーションや、Amazon Elastic VMware Service の専門家に会って話を聞くことができます。 AWS for VMware 専用ブレイクアウト・セッション Amazon EVS ブレイクアウトを含む、AWS for VMware に特化したテクニカルセッションにご参加ください。 AWS for VMware re:Invent 2024 参加者ガイド re:Invent における AWS for VMware 関連のすべての学習機会をご活用ください。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。 Steven Jones Steven は EC2 の商用アプリケーション担当ゼネラルマネージャーとして、SAP、VMware、Red Hat Open Shift on AWS の製品戦略、エンジニアリング、カスタマーサクセスチームを率いています。AWS 内のこれらの事業分野により、エンタープライズのお客様は、最も要求の厳しいワークロードをクラウド上で実行できます。AWS で 13 年の経験を持つ Steven は、革新的なソリューションを提供し、パフォーマンスを拡大し、複数のセグメントや業種にわたる成長を促進してきた実績があります。スティーブンは、AWS を最も顧客中心のクラウドプラットフォームにし、ビジネスクリティカルなワークロードを実行するのに最適な場所にすることに情熱を注いでいます。彼は AWS の SAP 技術戦略の原動力となり、ハイパースケールプラットフォーム上における SAP ワークロードの一般的なサポートや、メモリ量の多い SAP HANA ワークロードをサポートするクラウドネイティブインフラストラクチャなど、業界初となる数々の成果を市場にもたらしてきました。また、お客様が VMware ベースの環境を AWS にシームレスに移行および拡張できるようにする VMware ビジネスの監督も行っています。クリエイティブなアイディエーション、抽象化、システムパフォーマンスのスキルを活かして、お客様、パートナー、そして AWS に価値を創造しています。

はじめに みなさん、こんにちは。ソリューションアーキテクトの稲田です。AWS のソリューションアーキテクトとして三菱電機グループを 3 年間担当してきました。この記事では、三菱電機グループで生まれつつあるエンジニアコミュニティの物語をお伝えします。 日本を代表する総合電機メーカーである 三菱電機 。その名を聞けば、誰もが家電製品や電気設備を思い浮かべるでしょう。しかし、三菱電機グループの様々な部門の方々をご支援させていただいているうちに、私が目にしたのは、その印象とは少し異なる姿でした。 「 9 つの事業部と本社組織に分かれている ので、部門を超えたエンジニアの交流が難しいです。」と、 DX イノベーションセンター の辻尾さんは語りました。 通信システムエンジニアリングセンター の相川さんは次のように付け加えました。「クラウドに詳しくない部門では、他部門で解決済みとなっている悩みを抱えていたりすることが多いです。それぞれの部門が独自に問題解決を図っているのを見ると、もったいないと感じることがあります。」 図1 : 国内の主な事業所一覧 コングロマリット企業ならではの多様性。個別生産と量産、顧客層、技術、さらには物理的な距離。あらゆる面で「遠い」存在だった各部門を、どうやって「近く」することができるのか。そこに大きな可能性が眠っていました。 IoT・ライフソリューション新事業推進センターの小川さん が印象的な言葉を残しました。「三菱電機として AWS だけでなく、事業部門や製作所を超えた技術交流に可能性があると感じています。」小川さんは続けて、「各部門には素晴らしい技術や知見があります。それらを共有し、活用できれば、三菱電機全体としての競争力が大きく向上するはずです。ただ、これはおそらくコングロマリット製造業ではよくある課題だと思います。」と指摘しました。 この小川さんの言葉は、三菱電機が直面している状況と、そこに潜む可能性を端的に表していました。各部門には確かな技術力と豊富な経験を持つエンジニアたちがいます。彼らの力を結集できれば、どれほどの相乗効果が生まれるでしょうか。 その実現への道のりは、新たな挑戦の連続でした。長年培われてきた組織文化や、部門間の距離。それらを橋渡しし、エンジニアたちを繋ぐには、何か新しい仕掛けが必要でした。そして、その答えは意外なところから生まれることになります。 私が担当してからすぐの 2022 年 9 月、エンジニアたちの自発的な動きが始まりました。それが、Mitsubishi Electric AWS User Group (通称: MAWS-UG) の誕生につながります。MAWS は、三菱電機のエンジニアたちが AWS に関する知識や経験を共有し、部門を超えて交流するためのコミュニティです。 本記事は MAWS の誕生までの道のりや、具体的な活動内容、それがもたらした変化、直面している課題、そして今後の展望について深掘りしていきます。 Viva Engage チャンネルの立ち上げ：コミュニティの芽生え 三菱電機の各部門で個別に進められていた AWS 活用。その状況を変えるきっかけは、小川さんのちょっとした行動から始まりました。 2022 年 9 月、小川さんが Viva Engage チャンネルを立ち上げました。「最初は本当に手探りでした」と小川さんは当時を振り返ります。「AWS に関するちょっとした Tips を投稿し始めたのですが、しばらくは誰からも反応がなくて(笑)。でも、諦めずに続けました。」 図2: 小川さんが 1 人で投稿し続けた Tips 転機が訪れたのは、その 2 ヶ月後のことです。小川さんが AWS 主催のプライベート GameDay で優勝したことをきっかけに、社内でのプレゼンスが一気に高まりました。「優勝の報告を投稿したら、突然いろんな部門の方から連絡をもらえるようになりました。」と小川さんは嬉しそうに語ります。 この出来事を皮切りに、グループ会社との交流も始まりました。2023 年 10 月には re:Invent 事前交流会を開催。ラスベガスでの現地交流も実現し、部門を超えたエンジニアの輪が急速に広がっていきました。 AI 戦略プロジェクトグループの塚田さんは、この動きに早くから注目していました。「小川さんの GameDay 優勝のニュースを聞いて、すぐに Viva Engage チャンネルに参加しました。そこで初めて、他部門にも AWS に詳しい仲間がいることを知りました。」と語ります。 こうした動きは、AWS アカウントチームの目にも留まりました。AWS の担当者たちは、同じような悩みや課題を持つメンバーを積極的に引き合わせる役割を果たし、地理的に離れた拠点のエンジニアたちのコミュニティへの参加を実現しました。 MAWS の誕生：公式コミュニティへの進化に向けた挑戦 Viva Engage チャンネルの立ち上げをきっかけに、少しずつ交流や情報交換の文化が作られてきました。しかし、オフラインでの交流の場はまだ無く、まだ部署やグループ会社を跨いだ仲間としての意識ができづらいと感じていました。そこで、「僕らからその場を作っていきましょう！」と IT ソリューションビジネス・業務改革推進本部の紅林さんから小川さん、相川さんに話を持ちかけ、社内交流の場を作るべく動き出しました。 ここからすんなりと MAWS 設立かと思いきや、早速の壁にぶち当たります。「最初は場所を取ることすら大変でした。会議室のルールを見ると交流会の用途では借りることができなかったです(笑)。 そのため有志でひっそりと休憩スペースで集まりました。それが記念すべき第 0 回です。」と紅林さんは当時を振り返りました。 図3: 会議室が借りれずに休憩スペースで開催した第 0 回 MAWS-UG そんな中、転機が訪れました。DX イノベーションセンター長 朝日宣雄 氏が MAWS のエグゼクティブスポンサーとして名乗り上げたのです。 AWS Summit Tokyo 2019の基調講演 や AWS Executive Insights などの多数の登壇実績を持つ朝日氏は当時をこのように振り返ります。 「AWS は、 家電や設備機器のための IoT 共通プラットフォーム Linova の開発や家電統合アプリケーション MyMU 上の様々なサービス開発 において、大変お世話になってきました。また、三菱電機内の AWS 活用事例を共有するための MELCO Day も開催や Working Backwards 研修などを通じて、社内の AWS 利用も広がっていく中、社内のユーザーネットワークを小川さんはじめ若手エンジニアの皆さんが自発的に拡大されているのを知り、是非とも正式な活動となるようにお手伝いをしたいと思いました。組織の壁を越えたこのような活動は、まさに DX イノベーションセンターが目指す Serendie の想いと合致していますので、私も可能な限り参加したいと思っています。」 スポンサーを獲得したことで一気に加速し、その後 MAWS-UG と命名、Amazon Bedrock を使ってキャラクターも作成し、2024 年 4 月には念願の第 1 回を開催します。 図4: 三菱電機の「ワクワク コツコツ」 とマウスをかけ合わせたマスコットキャラクタ 「本当に感動的な瞬間でした。これまで孤軍奮闘してきた人たちが一堂に会して、同じ悩みや課題を共有し合う。そこには確かな手応えがありました。」と小川さんは語ります。 三菱電機インフォメーションネットワーク株式会社 の太田さんは「ずっとコミュニティ活動に憧れはありました。2019 年から JAWS-UG の支部運営に参加していたものの、社内へのアピールを上手くすることができず、プライベートでの個人参加を続けていました。遂に三菱電機グループ内 AWS ユーザーグループができて嬉しいです。」とコメントしました。 MAWS の誕生は、三菱電機グループのエンジニアたちにとって新たな時代の幕開けを意味します。部門の壁を越えて知識と経験を共有し、共に成長していく。そんな可能性がここから広がっていったのです。 図4: 第 1 回 MAWS-UG MAWS の成長と活動：エンジニアの輪の広がり MAWS の正式発足から、三菱電機のエンジニアコミュニティは急速な成長を遂げました。当初わずか数十人だったメンバーは、瞬く間に 300 人近くまで増加。この数字は、エンジニアたちの間で潜在的に存在していた「つながりたい」という願望を如実に表しています。 図5: MAWS メンバー数の推移と主要イベント 「最初は正直、これほど多くの人が集まるとは思っていませんでした。でも、蓋を開けてみれば、様々な部門から予想以上の参加があって。みんな同じような悩みを抱えているのだなと実感しました。」」と、MAWS の運営メンバーの一人、塚田さんは語ります。 MAWS の中核となる活動は、3ヶ月に一度開催されるLT 会と懇親会です。これらのイベントは、本社、横浜、関西、さらには AWS 目黒オフィスなど、様々な場所で開催されています。 「オフラインでの交流にこだわっています。」と小川さんは説明します。「確かにオンラインの方が参加しやすいかもしれません。でも、実際に顔を合わせて話すことで生まれる化学反応はやはり特別です。」 LT 会では、スポンサーによる 10 分間のプレゼンテーションと一般参加者による 5 分間の LT が行われます。テーマは多岐にわたり、最新の AWS 技術から業務での活用事例、さらには個人的な失敗談まで。「回を重ねるごとに LT の内容が濃くなっています。」と紅林さんは嬉しそうに語ります。「参加者からも『刺激になる』という声をよく聞きます。」 図6: 第 4 回 MAWS UG では KAG みのるん氏に特別 LT をしていただきました 特筆すべきは、これらのイベントの雰囲気づくりです。「あえて『三菱電機らしくない』雰囲気を作るように心がけています。」と紅林さんは笑います。「飲み物を片手に、リラックスした雰囲気で LT を聞く。そうすることで、より自由な発想や意見交換が生まれます。」 日常的なコミュニケーションの場としては、Microsoft Teams が活用されています。ここでは、AWS に関する質問や情報共有、さらには AWS アカウントチームとの直接対話も行われています。「以前は個別に問い合わせていた内容も、ここで共有することで、みんなで知見を蓄積できるようになりました。」と辻尾さんは評価します。 もちろん課題もあり、「まだまだ社内での認知度は十分とは言えません。」と相川さんは指摘します。「特に管理職層への浸透が今後の課題です。彼らの理解と支援があれば、より多くのエンジニアが参加しやすくなるはずです。」と紅林さんは加えます。 MAWS の活動は単なる情報共有の場を超えて、三菱電機のエンジニア文化を変革する原動力となりつつあります。部門の壁を越えた知識の共有、新たな技術への挑戦、そして何より「つながる」ことの喜び。MAWS は、三菱電機の未来を担うエンジニアたちの新たな絆を紡ぎ出しているのです。 MAWS がもたらした変化 MAWS の誕生から約 1 年。この短い期間で、三菱電機のエンジニアコミュニティは目に見える変化を遂げました。その影響は、個々のエンジニアのスキルアップだけに留まらず、部門を超えた協業にまで及んでいます。「例えば、ある案件で AWS サービスの使い方で悩んでいたときに、MAWS のコミュニティで質問したところ、別の部門の方から即座に解決策を教えてもらいました。これまでだったら、何日もかけて自分で調べていたでしょうね。」と小川さんは語ります。 このような事例は、MAWS がもたらした最も直接的な効果の一つです。さらに、その影響はより深いところにも及んでいます。 「エンジニアとしての自信にも繋がっています。」と、塚田さんは目を輝かせて話します。「MAWS での LT 会で発表する機会をいただいて、最初はうまく話せるのかと悩みましたが、多くの方から前向きなフィードバックをいただきました。それが自信になって、今では社外イベントの登壇や AWSのハッカソンにも参加するようになりました。」 実際、MAWS のメンバーによる社外活動も増えています。 JAWS-UG &nbsp;や、 Bedrock Night in 大阪 、AWS Summit での展示やセッション、さらには技術ブログの執筆など、三菱電機のエンジニアの存在感が、業界全体で高まっています。 MAWS が直面している課題 MAWS の活動は着実に成果を上げ、三菱電機のエンジニアコミュニティに新たな風を吹き込んでいます。しかし、その過程は決して平坦ではありません。 「最大の課題は、やはりコミュニティの存在や、技術的・文化的メリットをグループ内に周知していくことです」と相川さんは率直に語ります。「現在コミュニティに加入しているメンバーは、活動に関心がある人たちがメインです。しかし、グループ内には AWS をディープに利用していて困っている人や、知見を有する人たちがもっと沢山いるはずです。その人たちにも、もっと参加してほしいと考えています」 この課題に対して、MAWS は新たなアプローチを検討しています。「ついつい見過ごされがちな社内周知よりも、外部発信の方が効果的だと思い、今回のブログ化に踏み切りました」と相川さんは続けます。 もう一つの大きな課題は、新規参加者の継続的な獲得です。「初心者層に、『参加そのもののハードルが高そう』と敬遠されがちなので、定期的に社内向けに声がけを行っています」と小川さんは説明します。「特に、業務でクラウドに触っている人の参加が増えたらうれしいですね。困りごとや事例をたくさん持っているはずですから」と通信システムエンジニアリングセンターの杉村さんはコメントします。 組織文化の変革も重要な課題の一つです。「社風かもしれませんが、『とりあえずやってみよう、参加してみよう』という風潮があまりありません。この文化を変えていく必要があります。」と辻尾さんは指摘します。 MAWS の今後の展望：さらなる成長への道 MAWS の今後の展望について、辻尾さんは次のように語ります。「三菱電機のエンジニアを社外とつなげるためのコネクタになりたいと考えています。内製化やソフトウェア開発の文化が全く根付いていない現状を変えたいです。これから SaaS を展開していくためには、アジリティが大事。自分で判断して手を動かせるように、社外から直接情報を仕入れられるエンジニアを増やしたい。ソフトウェアに強くなることが重要です」 さらに、辻尾さんは具体的な目標も示します。「 2030 年までに 20,000 人の DX 人財を育成する 必要があります。このコミュニティで DX 人財育成の柱の一部を担いたいと考えています。できる人財がリードする、そんな環境を作りたいです。」 図7: 三菱電機が掲げる DX 人財強化 「MAWS は単なる技術コミュニティではありません」と紅林さんは締めくくります。「私たちは、三菱電機の未来を創造する原動力になりたいと考えています。エンジニア一人一人が自分の可能性を最大限に発揮できる環境を作り、そこから生まれるイノベーションで社会に貢献する。それが MAWS の究極の目標なのです」 MAWS の挑戦は、まだ始まったばかりです。課題は多いものの、そこには三菱電機の未来を変える大きな可能性が秘められています。エンジニアたちの情熱と創意工夫が、この巨大な組織にどのような変革をもたらすのか。その答えは、彼らの手の中にあるのです。 おわりに 本記事では、三菱電機グループにおける AWS ユーザーコミュニティ”MAWS”の誕生から現在までの軌跡をお伝えしてきました。一人のエンジニアの小さな行動から始まり、現在では 300 人を超えるメンバーを擁するコミュニティへと成長した MAWS の歩みは、大企業における草の根のエンジニアムーブメントの可能性を示しています。 部門の壁を超えた知識共有、技術交流の促進、そして何より「つながる」ことの価値。MAWS の活動は、三菱電機グループのエンジニア文化に確実な変化をもたらしています。 本記事では一部のメンバーの声しか紹介できませんでしたが、MAWSの活動は、実際にはより多くのメンバーによって支えられています。イベントの企画や運営に携わる方々、積極的に質問や情報共有をしてくださる方々、さらには静かにコミュニティを見守り支援してくださる方々など、様々な形で関わる全てのメンバーの存在が、MAWS の成長を支える原動力となっています。 課題はまだ残されていますが、それらに立ち向かう情熱と創意工夫は、このコミュニティの大きな強みとなっています。MAWS は今後も、三菱電機グループの DX 推進とエンジニア育成の重要な基盤となることでしょう。 最後に、本記事を通じて、大企業における技術コミュニティ形成のヒントを少しでも共有できていれば幸いです。MAWS の挑戦は、同様の課題を抱える他の組織にとっても、参考になる事例となるのではないでしょうか。 図8: 第 2 回 MAWS UG AWS Summit 前夜祭 今回インタビューをさせて頂いた MAWS の運営メンバーの方々 小川 雄喜 IoT・ライフソリューション新事業推進センター/IoT 推進部/PF 開発グループ所属。三度の飯より AWS とビールが好き！ JAWS-UG 第 1 回 Bedrock Claude Night や、 JAWS Festa 、 AWS Innovate など最近は色んな登壇にチャレンジしています。 相川 奈槻 通信システムエンジニアリングセンター ネットワークシステム部所属。三菱電機のテクニカルアーキテクト？です。社内 DX 部門に対する技術的な支援を行いながら、ネットワーク市場に関する動向調査とサービスの拡販支援を推進しています。好きなサービスは AWS IAM です。週末は美味しいものを食べ過ぎてしまいます。最近丸くなり過ぎました。 2024 Japan AWS All Certifications Engineers に選出されました。 辻尾 良太 DXイノベーションセンター プラットフォーム設計開発部所属。三菱電機のデジタル基盤「 Serendie 」の開発に携わっています。普段は鶏肉とたまごをよく食べます。悩みはカラスやハトによく糞を落とされることです。 2024 Japan AWS All Certifications Engineers に選出されました。JAWS-UG (E-JAWS) での登壇発表にもチャレンジしています。 紅林 俊之 ITソリューションビジネス・業務改革推進本部所属。旅とカメラと AWS が好き。訪問国数 50 カ国以上。2023 年に三菱電機に AWS エンジニアとして入社したばかりのソリューションアーキテクト？です。改善すること盛り沢山で社内で動き回っており、色々な人を巻き込みながら少しずつ改善に取り組んでいます。「やったほうがいい」と自分で思えることを仕事にしています。 杉村 みさき 通信システムエンジニアリングセンター ネットワークシステム部所属。ネットワーク・セキュリティシステムの提案支援を行っています。カメラが趣味で、MAWS のイベントでは写真撮影を担当しています。 2024 Japan AWS All Certifications Engineers に選出、「 IoT 技術者向け AWS セミナー 〜スマート製品・サービス開発の勘所〜 」で登壇。 塚田 真規 AI 戦略プロジェクトグループ所属。生成 AI 利活用を推進するために、生成 AI 開発基盤の整備や LLMOps の推進、普及を担当しています。アプリケーション開発よりもプラットフォーム構築が好きです。 JAWS-UG での登壇発表 にもチャレンジしています。 2024 Japan AWS All Certifications Engineers に選出されました。 太田 亮 三菱電機インフォメーションネットワーク株式会社、経営システム事業部所属。三菱電機およびグループ会社向けのシステム開発を行うシステムエンジニアです。主にビル事業向けのシステム提案・開発・保守を担当しています。2019 年から JAWS-UG 初心者支部 に運営として参加しています。 インタビュアー 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the second half of that. The following articles have also been published as serialized articles, so please be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half) ” Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 2) — First half ” 4. Key points of cloud utilization As introduced in the third chapter of the second blog in this series, the philosophy for our cloud-based smart meter relies on three main factors: flexible scalability through loosely-coupled architectures, realizing a high level of availability in our system, and having agility through our use of managed services. In order to maximize the benefits of the cloud (including TCO reduction) to the best of our ability, we’ve found that it is important to proceed development with the optimal combination of AWS services. However, AWS provides a wide variety of services which each have different features and usages, so it’s essential to master AWS’s full offerings so that you can match them to your own requirements along with correctly implementing appropriate security measures such as data protection and access control. Based on this approach, I think the following three points are particularly important when developing on the AWS cloud: First, properly understanding system and cloud architectures ourselves, as end-users Also making sure that your vendors correctly understand the cloud, embrace it, and have the proper workflow in place to implement it Finally, continuously making efforts to acquire new skills while improving your existing ones together as both end-users and vendors In other words, having the will to properly use the cloud is essential, but you can’t successfully use the cloud by will alone. After all, you have to select the appropriate system vendors that will actively accompany your company throughout your cloud journey, and make sure that they proceed with the development of your system while closely collaborating with your business. 4-1. Correctly understanding the cloud as end-users Looking back on the history of conventional system development, I believe that you have to correctly grasp the “big picture” of the application that you’re developing, so we are consistently making efforts to deepen our understanding of the system that we have in use from both a business and technology perspective in line with the above policy. At the same time, in order to talk about cloud, we ourselves must first understand the cloud (as we introduced in detail the fifth chapter of the second blog , Introduction of Common Infrastructure and System Control). In other words, I believe that by correctly understanding the underlying infrastructure, and by understanding it in depth, you can proceed with developing applications based on those layers and successfully cooperate with your system integrators. I’ve sometimes heard people say things such as “there’s no need to worry about the details – we own the system!” raised as a common discussion point related to using the cloud, but as a result of our efforts so far, we believe that by correctly understanding the cloud it’s possible to enjoy many benefits beyond mere ownership of the system itself. Speaking of security aspects that are particularly easy to focus on, when using AWS, AWS itself has obtained a wide variety of security measures and certifications to guarantee them. If we want to implement these measures, I believe we need to spend time examining and trying them out for ourselves. However, at the same time, in Japan we sometimes say “let the mochi shop take care of the mochi”, or as we might say in English: “leave it to the experts.” This means leaving the actual infrastructure development, maintenance, and operation (including security) to your system vendors while you focus on the business outcomes that you originally wanted to achieve, and making sure to prepare an environment for your vendor partners so that you can ensure those outcomes together as is mentioned in the shared responsibility model . 4-2 Vendors correctly understanding the cloud In order to properly utilize the cloud, it is very important to formulate your reasons and motives for using the cloud in the first place, such as how you’re going to tackle the overall transition to the cloud, your policies around the shift, and very importantly – organizing what you want to communicate to your system vendors. For example, if your messaging on what you want is unclear from the get-go, you might end up with a case of your servers having been simply migrated over to Amazon EC2 ; but in the case that your system has middleware, you of course wouldn’t be able to properly enjoy the intrinsic benefits of the cloud. In order to fully reap the cloud’s benefits, companies need to proceed with development while selecting various services and functions in the right places, such as creating a system concept that is rooted in the idea of a microservices architecture and which will make full use of AWS managed services as the building blocks of the system. Traditionally, I feel that vendors that have developed on on-premise server environments tend to move in the direction of building more similarly conventional systems on the cloud, so if you don’t clearly show and communicate your needs and intentions as users to those vendors, I think it is common to see situations where you could hit road bumps at even the brainstorming stage. As users, it is essential to actively and comprehensively encourage vendors to understand why using the cloud is necessary in specific cases. Equally important is encouraging vendors to consider the future potential of the system from the design stage. In other words, I think a change of mind from having a sense of security and focusing purely on what advantages there are with the cloud, to actually using the cloud yourself, is an important point. Additionally, since system vendors are responsible for development, it’s clear that not only end-users but also system vendors should realize this mindset change with their customers together. Therefore, you have to select system vendors that can run side by side with your company throughout the process, as proper use of the cloud cannot be realized unless you’re cooperating and coordinating together. As a major prerequisite for this, it is essential that the development vendor correctly understands the cloud in the first place. First, you can prevent a few problems and obstacles from occurring in system migration and operation by making sure that the systems your vendor has designed so far work correctly on the cloud, and appropriately incorporate and that cloud system’s specifications and requirements. Also, you can set yourself up for success in the long run by proceeding with a design and development philosophy that takes advantage of ideas such as microservices and serverless architecture, so that your managed services can be enjoyed to the fullest through a correct understanding of AWS services and their functions. Finally, a proper understanding of cloud security is also essential for building a robust system. In deepening such collaborative relationships, I think it is also effective for us to have a common infrastructure as explained in the fifth chapter of the second blog , which describes organizing a collaborative system in a way that shares an environment with your vendors. AWS Professional Services was key in their cooperation with us on this project by encouraging our vendors to make autonomous efforts, giving them technical support, and by supporting us through overall project promotion and management while constantly staying in close contact with us. 4-3. Continuously improving your cloud skills In general, it is extremely important to adopt technologies that are compatible with cloud services (such as containers or serverless setups), but it’s also extremely important that we’re continuously learning about those technologies. If we have a goal to adopt a new technology we can achieve that goal by merely introducing it into the system, but as mentioned in the my explanation relating to common infrastructure in the fifth chapter of the second blog , brushing up your technical skills is key. It’s essential to actually understand the AWS cloud while you use it, but in most cases, acquiring a new skillset such as this tends to come down to individuals taking their own time to learn the technology. However, I believe it’s key that you motivate those involved with the project to continuously be learning themselves and make it an essential part of your organizational strategy; this is what we’re trying to do with our smart meter project and the proper use of its data moving forward. 5. Conclusion In this blog we have introduced our smart meter system initiatives, mainly regarding our points of view and what to keep in mind in regard to how two projects with different personalities are being carried out simultaneously in parallel: a current generation system being shifted to the cloud, and the development of a next-generation system that’s cloud-native. The decision that both systems would involve the cloud was a major decision, and as introduced in the blog, after thorough internal discussions we were finally able to establish a consensus and begin moving forward. There have of course been many in-depth discussions from both the cloud-promoting side and the more conservative side, but so far, so good although there’s been great difficulty along the way. One additional story that I’d like to share is how we were able to exchange opinions with industry peers overseas through AWS’s introduction, and how it was interesting to hear stories of companies having had internal discussions similar to ours that still ended up with those companies adopting the cloud. I’ve always had the impression that corporations overseas are more progressive in comparison to those in Japan, but regardless of the country, I understood that companies around the world experience similar difficulty to ours when it comes to adopting the cloud, as in the end, it seems that no matter where you are there’s no such thing as a “hands off” approach to cloud migration. Also, depending on the country, we also learned that there are situations where regulators are restricting cloud use, or situations where OT systems can’t be integrated with the cloud in the first place. Thus, of course there are still issues that arise when it comes to introducing the cloud such as navigating discussions with cautious stakeholders or the existence of regulations, etc., but as indicated in this blog, I believe from the view point of future scalability, system flexibility, and having a proper environment for proper data utilization – utilizing the cloud is essential. I believe that in order to really use the cloud, both end users such as us and system vendors will continue to deepen our mutual understanding, and continue to refine our knowledge around the cloud. That knowledge and those skills will be continuously questioned though, with questions around what we’re aiming for and what kind of system we’re trying to introduce to accomplish that, etc, but I think the idea of a common infrastructure like with what we’ve implemented, and the account management and control that accompanies it, we’ve managed to give form to these ideas in one way. Also, regarding that philosophy, we owe a great deal to AWS, and above all, to the folks from AWS’s Professional Services team, who are truly experts among experts in the cloud space, without whom I think our activities would have easily come to a standstill. Our project is still a work-in-progress, but I would like to take this opportunity to thank them once again. I hope this blog will help our readers think about using the cloud for future system development. Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the first half of that. The following articles have also been published as serialized articles, so please be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half) ” Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 2) — First half ” 1. Introduction In this article, we have introduced our efforts in three parts. In the first session , we introduced the overall picture of discussions aimed at utilizing the cloud in our smart meter system. In the second session , we introduced the overall picture of next-generation smart meter systems, including technical perspectives, and our current efforts. The 3rd session, which is the last one, will focus on cloud migration of current smart meter systems, and introduce our thoughts and commitments related to cloud utilization and our efforts. 2. From on-premise to cloud utilization Our current smart meter system, as described in the first blog, is partly due to the background at the time when development was proceeding ahead of other electric power utility companies, and while there is no package solution for meter data collection and management systems like these days, we proceeded with system development through trial and error in cooperation with multiple system vendors, and built a system assembled based on the system vendor’s technology and specifications at our data center. Full-scale introduction of smart meters to customers began in 2012, and until implementation was completed in 100% households in March 2023, we have achieved continuous stable operation while the number of servers used in the current system has also increased along with the expansion in the number of smart meters installed. On the other hand, since it is a system developed in such situation, it is facing issues such as economic efficiency and future sustainability issues associated with adopting proprietary OS, commercial databases, and middleware, system blackboxing associated with dependency on system vendors for development and operation, and concealment of business processing logic, etc. Furthermore, the increase in server hardware associated with the expansion of smart meter deployment, and continuous occurance of the termination of server manufacturer maintenance. The impact range was wide, such as technical verification of OS and middleware associated with the outbreak, and not only in terms of cost but also in terms of human workload, both of which were increasing. In addition, due to recent major changes in social conditions, various issues have also become apparent, such as future uncertainty represented by delays in server hardware procurement delivery due to lack of semiconductors. And this complex situation has been a barrier to the expansion of flexible and advanced utilization of data collected from smart meters. If we operate the system in our own on-premise environment, we will fall into a situation similar to ours, and I think there are many cases where people experience to fall into a situation similar to ours and face issues of the same kind if operating the system in their own on-premise environment. We thought that utilizing cloud technology would be an option as a comprehensive solution to these issues, so we decided to aim for a cloud shift in the current smart meter system. 3. Cloud Utilization Policy for Current Smart Meter Systems In this chapter, we will introduce how to utilize AWS functions and services in our current system and our system migration policy. There are 3 policies we have set out. Initiatives for migrating current systems to the cloud Leave it to AWS to offload things that can be replaced with AWS cloud services Take full advantage of the flexibility unique to the AWS Cloud Incorporate technological innovations and new services from the AWS Cloud appropriately while proceeding with development 3-1. Offload to AWS cloud services On premises, it is necessary to individually deal with daily hardware failures such as disk failures, etc., but in the cloud, such failure response is offloaded to AWS, so we don’t need to be aware of it. Also, by increasing the offloading rate, infrastructure construction and operation and maintenance can be replaced by simply using services. In other words, there is no need to even set up a database, and the system and way of thinking about system construction will change drastically, such as simply selecting and using services (Figure 1). In our on-premise server system, middleware such as cluster software necessary to ensure reliability has been adopted by each system vendor, but we first positioned this kind of middleware as a target to break away from it. To achieve this, we will implement application improvements including Various things from each company using Amazon Elastic File System (EFS) , Amazon FSx , etc., and health checks of server groups utilizing Elastic Load Balancing (ELB) . In combination, while multi-AZ redundancy between sites has also been realized, the system reliability of the system as a whole has been improved. At the same time, it is also basic to break away from commercial databases. We did not take any way of thinking about DB on Amazon EC2 from the beginning of the study, and we are conducting migration studies that assume the use of Amazon Aurora or Amazon RDS like AWS managed services. This way of thinking about actively utilizing various managed services on AWS is the result of evaluating that utilizing managed services will surely lead to an improvement in reliability, operation maintainability, and a reduction in operational load. Figure 1. Offload IT infrastructure operations to AWS by utilizing AWS managed services 3-2. Utilizing the Flexibility Unique to the AWS Cloud In the cloud, there is the lightness of using resources when they are needed and discarded when they are no longer needed, and there is an advantage of “being able to go back.” For example, in the past, server resource sizing was carried out precisely, and then server procurement and implementation were carried out over time, but in the cloud, based on the idea of pay-as-you-go billing, where “you can use your favorite resources, when you like, and for as long as you like,” you can flexibly change the configurations and solutions decided at that point to better ones (Figure 2). In our study, changing instances is also flexible and simple, so we are proceeding with instance type selection while proceeding with desk studies and actual machine verification without closely performing resource sizing. Figure 2. Advantages of utilizing AWS from an IT infrastructure procurement perspective Also, in the past, it took a lot of time and money to set up the production environment and development environment, respectively. We are now actively utilizing Infrastructure as Code (IaC) in building IT infrastructure. By automating IT infrastructure deployment using IaC, human errors can also be avoided, and system configuration reviews can be handled flexibly while proceeding with application development (Figure 3). Figure 3. IaC benefits on AWS 3-3. Appropriately incorporating technological innovation and new services Even if the architecture was determined to be appropriate at the time of implementation, due to technological innovation associated with the passage of time since implementation, there are more options than at that time, so the range of considerations has expanded, and there is a possibility that a better configuration can be selected (Figure 4, Figure 5). For example, as we proceed with our consideration, there was an announcement in August 2023 that “ Network Load Balancer (NLB) will begin supporting security groups. ” At that time, NLB was not covered by security group chains, but as a result of design changes in response to this announcement, it was possible to ensure security with a simple mechanism by incorporating the chaining of security groups across the entire system. In the construction of next-generation smart meter systems that are currently underway, if better services and functions are similarly provided, the direction is to proceed with development while utilizing them. Figure 4. Expanding the provision of new services and features through technological innovation at AWS Figure 5. Expanding AWS services to include the field of analytics (excerpt) In this article, we have introduced the first three chapters regarding our efforts aimed at cloud adoption of smart meter systems. For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems at Kansai Transmission and Distribution, Inc. (Part 3) — Second half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the second half of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article will be in the latter half. Check out this link for the first half. Also, for the first contribution, please refer to “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half). ” 4. System Architecture Next, we’ll give you an overview of the next generation smart meter system architecture we’re considering. When implementing a loosely coupled architecture in line with the development policy described above, cooperation between subsystems is based on loose coupling. Specifically, in collaboration between subsystems from HES to MDMS and from MDMS to a meter data utilization platform that centrally manages data, it was designed so that data transfer with high elasticity and high real-time can be realized simultaneously while asynchronously linking between systems using Amazon SQS. By constructing a mechanism based on SQS, it is possible to receive meter reading values that occur in large quantities on a regular basis and event information that is transmitted in large quantities during power outages or restoration while buffering, can be linked to subsequent processing at high speed, and has an architecture that enables near real-time processing that maintains elasticity against large amounts of burst traffic. Also, within subsystems based on loosely coupled architectures, we will promote the use of microservices. Business logic is reviewed, functions are broken down, etc., using AWS Lambda etc. for usage calculation and instrument event processing, etc., a package-like application execution environment is realized in a container environment based on Amazon ECS and AWS Fargate, and then a loosely coupled architecture is built by linking APIs with Amazon S3, Amazon DynamoDB, etc. For future implementation of new functions for which the current system has not been decided, we will achieve flexible and agile development while utilizing serverless and containers with segmented functions. Keeping in mind improvements in operation and maintainability related to database security and version upgrades, etc., the policy is to set up a system centered on AWS managed services, etc., and along with this, not only S3, but also databases such as Amazon Aurora, Amazon KeySpaces, DynamoDB, and Amazon RDS for PostgreSQL We utilize various managed services, such as Amazon API Gateway for data linking. Toward future advanced utilization of meter reading value data, equipment information, etc. collected by smart meter systems and its revitalization, we will first centrally manage such information in a data store based on meter data utilization, and then advance develop a data utilization mechanism starting from this while using Lambda, API Gateway, etc. In order to advance data utilization, we plan to create an environment where easy data analysis is possible by linking Amazon QuickSight etc. with this data store, and also utilize AI/ML services from the trial and error stage so that they can be applied to business. Figure 6 shows an overall overview of the system we are developing. Figure 6. Architectural Overview of Our Next Generation Smart meter system 5. Introduction of common infrastructure and system control In our 15 years of smart meter work, we have faced various challenges. These included, for example, issues that lack flexibility in data utilization, such as overlapping functions between systems and complex collaboration methods etc., issues of economy and future sustainability associated with adopting system vendors’ own OS, commercial databases, and middleware, issues such as system blackboxing and concealment of business processing logic, and further future uncertainty, such as delays in server hardware procurement delivery due to semiconductor exhaustion. We believe that the root cause of these issues is that we were unable to develop under a unified system concept, and this time we are focusing on incorporating our own development concept. For that, it is necessary to correctly understand the system infrastructure on the AWS cloud, which we will now use as our development platform. In other words, instead of entrusting everything from the application layer to the infrastructure layer supporting it to the system vendor to develop the system, this time, after organizing the cloud infrastructure layer and common functions related to the entire system, such as AWS account management for applications on it, network functions, security measures, etc. as a “common foundation”, then we decide that we will control the whole thing including the development direction of the application layer by managing this common foundation. We believe that by correctly understanding the infrastructure layer and understanding it in depth, we can proceed with the development of applications based on this while firmly cooperating with system vendors. Since system vendors will also be able to focus on application development linked to business, we believe that as a result, it will be possible to secure system quality even more than before, and we will be able to obtain a reliable path for future data utilization. There are three points of effort for us to correctly understand and manage the cloud infrastructure layer, and to internalize future data utilization. The first is to split AWS accounts based on AWS’s multi-account strategy. By doing so, we will clarify the scope of responsibility and strengthen security aspects. Specifically, after managing the common infrastructure, AWS accounts are divided for each system vendor, and vendors are required to carry out system construction and maintenance within the account. Furthermore, connection points between systems are minimized and responsibility demarcation points are clarified. Necessary user IDs are also provided from the common infrastructure side. Figure 7 shows how to organize this based on the way of thinking about AWS’s multi-account strategy (*2). (*2) Decide Your AWS Environment Using Multiple Accounts In this way, the environments for development, testing and operation are separated and maintained, and the breakdown of responsibilities for each common infrastructure and subsystem within each environment is clearly divided by AWS accounts. As a result, system vendors will able to focus on application system development within the granted account, and they will also be responsible for system operation and maintenance. Figure 7. Splitting AWS accounts between systems to clarify areas of responsibility and enhance security The second is to clarify the scope of responsibility between AWS, system vendors, and us, based on the AWS shared responsibility model. Along with this, we manage things that require standardization, such as OS, as a common infrastructure and provide them to vendors. Variations between systems related to OS types and versions can be eliminated, which also leads to a reduction in TCO. The specific image is shown in Figure 8. Figure 8. Role and responsibility base on AWS shared responsibility model The third is getting help from AWS Professional Services. In order to achieve full use of the cloud, it is essential to introduce a common infrastructure, and on top of that, I think it is important to cooperate more closely with system vendors. This requires us as stakeholders to correctly understand the system and steadily respond to system expansions and changes associated with environmental changes; in other words, it is essential that we correctly understand AWS, and with the cooperation of AWS Professional Services, we are accelerating studies and acquisition of skills and knowledge. While cooperating with the members of AWS Professional Services from time to time, we are accelerating system development and proceeding with initiatives by receiving comprehensive support, such as PMO support for project promotion and education support for our members, while appropriately understanding a wide range of technical issues and trying to resolve them in a flexible and accurate manner. 6. Conclusion In this contribution, I introduced the status of efforts for next-generation smart meter systems utilizing AWS, including technical perspectives. Next time, I would like to introduce the cloud shift of the current smart meter system. The 3rd installment has been published as a serialized article below, so please be sure to check it out. Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the first half of the second efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the first half of that. The serial articles have also been published as serialized articles, so be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” 1. Introduction In this article, we will introduce our efforts in three parts. In the first session, we introduced the overall picture of discussions aimed at utilizing the cloud in our smart meter system. This time, I would like to introduce the overall picture of a next-generation smart meter system using AWS, and the current status of our efforts, including technical perspectives. (Figure 1) Figure 1. Smart meter system and scope of explanation in this article 2. Next Generation System Requirements In developing a next-generation smart meter system, we discussed the development concept internally based on 15 years of experience in the development, maintenance and operation of current smart meter systems, the summary contents of the next-generation smart meter system review meeting, external needs, and the latest technology trends. 15 years ago, when the current system was developed, basically only an on-premise environment was available, and although applications were developed from our point of view, the architecture, such as function arrangement and inter-system cooperation methods, depended on different vendors for each system, and the entire system was constructed through inter-vendor coordination. In other words, unified system development based on our concept was impossible, and as a result, there were overlapping functions between systems and complex inter-system cooperation, and as a result, restrictions on flexible data utilization. At the next generation smart meter system review meeting, it was pointed out that lower costs of renewable energy, advanced energy management, heightened interest in strengthening resilience, and furthermore, progress in introducing and expanding the distributed energy resources against the backdrop of the 2050 Carbon Neutrality Declaration etc. is expected more than ever. As a result, in next-generation power distribution platforms that aim for decentralization and multilayering, the necessity of upgrading to a new specification smart meter system has been compiled with the aim of responding to increased operation of power networks utilizing data, expansion of use of power data outside of the power sector, and diversification of transaction needs associated with the expansion of demand side resources. Based on changes in the internal and external environment, we established the Kansai Electric Power Transmission and Distribution Group Vision in August 2023, and announced our idea that we would like to continue evolving into an energy platformer that not only provides a stable supply of electricity, but also provides new value to customers and society by deepening and expanding the platforms that the transmission and distribution group has, such as network equipment, human resources and technology, and connections with customers and society all around the Kansai region. I believe that the key tool for this is a smart meter and a system for utilizing that data. Based on this background, the basic concept of a next-generation smart meter system is “unified management of data,” “consolidation of similar functions,” and “loosely coupled function arrangement that is difficult to influence each other,” and based on renewal plans for peripheral systems connected to smart meter systems, smooth transition from current smart meter systems to next-generation systems etc., a system capable of flexible and efficient operation into the future will be realized simply and at low cost It was also touted as a concept, and an RFP was carried out. To put it more simply, the system requires thorough expandability, flexibility for function development, and usability, leading to future transitions to current systems, requests for additional functions to smart meters, implementation of smooth business operations during a migration period from current to next generation systems, and furthermore, promoting cooperation between smart meter systems and peripheral systems, expanding the introduction of renewable energy, strengthening resilience, and steady response to diverse customer needs I would like to go ahead. Based on our 15 years of experience in developing and operating smart meter systems, we thought it was necessary to radically review the way we think about system development in order to realize what we are aiming for. While we understand that risk reduction can be achieved by continuing to adopt proven conventional technology, we recognize that there is a direction to correctly evaluate new technology and utilize it while controlling risk, and we believe that it is desirable to implement all systems to be built on the AWS cloud and use AWS services as much as possible, so we have begun development. The specific thoughts will be described in the next chapter and later. 3. Next Generation Smart Meter System Development Policy As introduced in the previous chapter, in next-generation smart meter systems, it is required that the usability of this system, which supports implementation flexibility and agility related to new function development, and resilience in the power transmission and distribution business, can be realized at a high level over the future, in anticipation of future systems that are currently uncertain, etc. When following the conventional way of thinking of monolithic system architectures, scaling up, function addition, and modifications require a lot of time for sizing and integrated function development, etc., and there is a tendency that restrictions on flexibility and agility of response occur. This time, we chose an approach using modern application development methods that aim to realize flexible system development while ensuring quality. By modularizing and dividing applications into smaller functional units using microservices and containers, which are important components of the idea of modern applications, we achieve scalability as a system and high flexibility and agility for future function implementation. Furthermore, by appropriately incorporating a loosely coupled architecture, the scope of influence during work or failure is limited, and the overall availability of the system is enhanced (Figure 2). Figure 2. Implementation image of loose coupling in our smart meter system Within the subsystem, attention is paid to ensuring loose coupling and scalability. Specifically, for example, data is placed in a database or S3, data transfer and reception are based on API collaboration, and an event-driven mechanism that triggers data events is adopted to achieve asynchronous inter-function collaboration. This makes it possible to simultaneously achieve fault tolerance, scalability, and flexibility even in large-scale, complex systems such as next-generation smart meter systems (Figure 3). Figure 3. Features of event-driven architectures Also, during system development, we actively utilized serverless and containers so that system vendors could focus on application development, and the basic principle was to use AWS managed services rather than individually constructed infrastructure, including databases, by system vendors. By utilizing various managed services of AWS, while ensuring scalability and security support with AWS services, we are also aiming to reduce the workload on our side by offloading the maintenance and operation of systems related to databases etc. to AWS, and the direction is to enjoy cloud benefits to the fullest (Figure 4). Figure 4. Benefits of Utilizing AWS Managed Services Furthermore, by centrally managing data on the AWS cloud, we will utilize AWS’s cutting-edge technology, such as data analytics services centered around that data lake and AI/ML services that continue to expand, and embody a path towards advanced data utilization in the future. By utilizing AWS analysis services, it is possible to determine usefulness and direction through trial and error immediately, easily, and easily from the initial stage where a need occurs without taking steps such as requirement definition, design, and construction. Use cases of meter data analysis have also been introduced on AWS (*1, Figure 5), and by referring to these, we will proceed so that we can work on data analysis and data utilization by using cutting-edge technology “when necessary, anytime, and easily” (*1) https://aws.amazon.com/jp/solutions/guidance/meter-data-analytics-on-aws/ Figure 5. Solution on AWS for Meter Data Analysis Based on this review background, we have formulated our system development policy as follows. Loosely coupled architecture enables scalability, flexibility for system development, and high availability Achieve scalability, agility, and operational optimization by utilizing managed services Utilizing AWS Data Analysis Services to Analyze and Utilize Smart Meter Data While sharing our system development policy with system vendors, we are proceeding with the development of next-generation smart meter systems on the AWS cloud. In this article, we have introduced the first three chapters regarding our efforts aimed at cloud adoption of smart meter systems. For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems at Kansai Transmission and Distribution Inc. (Part 2) — Second half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by Blake Horike, Riho Matsui, and Satoshi Aoyama.