本ブログは Amazon QuickSight を使用した AWS Cost and Usage Reports （AWS CUR）（コストと使用状況レポート）の可視化についてご紹介します。 2部構成であり、今回は後編をご紹介します。 前編： AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用した AWS CUR の分析手順 後編： Amazon QuickSight のセットアップ、 AWS CUR の可視化、分析やダッシュボードの共有 Amazon QuickSight のセットアップ この手順では以下を含んだ Amazon QuickSight の初期設定を行います。 Amazon Athena へのアクセス許可 AWS CUR レポートが作成される Amazon S3 バケットへのアクセス許可 詳細の手順は以下をご参照ください。 Setup QuickSight for the first time “5.Select S3 Buckets You Can Access Across AWS, under Use a different bucket enter the CUR bucket name, choose Add S3 bucket and choose Finish.” は実施不要です。 Setup QuickSight IAM Policy は必要に応じて実施してください。 Amazon QuickSight のデータセットの作成 この手順では Amazon QuickSight のデータセットの作成を行います。データソースとして Amazon Athena から検索可能な AWS CUR のテーブルを設定します。 Amazon Athena からデータを Amazon QuickSight に読み込むことによって、 Amazon QuickSight でデータを確認することが可能になります。 詳細の手順は以下をご参照ください。 Create a dataset これで Amazon QuickSight を使って AWS CUR の可視化を行う準備ができました。 AWS CUR の可視化とダッシュボードの作成 Amazon QuickSight を使用した可視化の例として、下記のダッシュボードの作成を行います。 この手順では以下の3つのグラフを作成します。 AWSアカウント単位、プロダクトコード単位のコスト インスタンスタイプ、購入オプション（オンデマンド、スポット、リザーブドインスタンス）ごとの1時間ごとの Amazon EC2 インスタンスの使用状況 line_item_line_item_descrption（利用明細）別の日次のコスト line_item_line_item_descrption とは、利用明細の説明になります。例えば、利用明細の説明として特定の期間に利用した Amazon EC2 のインスタンスタイプを要約したものが記載されます。 詳細の手順は以下をご参照ください。 Create visualizations 設定項目名が分からない場合は Amazon QuickSight の言語設定を English に変えてご確認ください。 Amazon QuickSight のその他の可視化機能については以下のブログをご覧ください。 BIサービス Amazon QuickSight のセルフハンズオンキット日本語版を公開（随時更新） Amazon QuickSight の運用については以下のブログをご覧ください。 【開催報告＆資料公開】Amazon QuickSight のノウハウ総まとめ！ 〜BI設計から運用まで〜 作成した分析の共有とダッシュボードの公開 作成した分析やダッシュボードは共有することが可能です。 詳細の手順は以下をご参照ください。 Share your Analysis and Dashboard ダッシュボードの共有については特定のユーザーやグループを指定する方法、アカウント内の全ユーザーに共有する方法、インターネット上で共有する方法があります。 Amazon QuickSight API を使用して共有を設定することも可能です。 また、ダッシュボードを PDF としてエクスポートすることや、レポートを E メールで送付することも可能です。ぜひご要望に沿った形式でダッシュボードやレポートの共有をご活用ください。 詳細は Amazon QuickSight ダッシュボードの共有 をご参照ください。 前編、後編を通して、AWS CUR の内容を Amazon QuickSight を使用して可視化し、共有する事ができるようになりました。 AWS Cost and Usage Reports【AWS Black Belt】 Amazon QuickSight を使用した AWS CUR の分析については以下の AWS Black Belt Online Seminar でもご紹介していますのでご参照ください。 AWS Cost and Usage Reports【AWS Black Belt】 Cost and Usage Dashboard powered by Amazon QuickSight AWS CUR の可視化として、 Cost and Usage Dashboard powered by Amazon QuickSight が使用可能になりました。 AWS CUR のデータに対して、事前に定義された Amazon QuickSight の100以上のビジュアルを簡単に使用する事が出来ます。こちらもぜひご活用ください。 前編と後編を通じたまとめ クラウドのコストを最適化するためには、まず現在の使用状況を把握、分析することが重要です。書籍「AWS コスト最適化ガイドブック」からコストの可視化に関する記述を引用します。 “クラウド利用費用最適化の最初のステップは、 AWS サービスの利用状況の可視化です。クラウドは利用量によって利用費用が変動する従量課金形式が基本であるため、クラウドを効率的に最適化するためには、根拠となるクラウド利用費用と利用状況の情報の可視化は非常に重要です。可視化のポイントは、何をどこまで可視化するのか、という点にあります。可視化のための手間や得られた情報の保存にかかる費用など、すべてを可視化することが逆に最適化の足かせになってしまうことも考えられます。 無駄な監視や情報収集をしないために、まずは可視化の目的、すなわち、「どのような情報が得られたらどのようなアクションを実施したいのか」という点を明確に定めることで、必要な情報や粒度などが自然と定まります。例えば、各部門（あるいは各システム）の毎月（あるいは毎週）の予算が70％を超えたらアラートを上げる、90％を超えたら新規のインスタンスの立ち上げを認めないようにする、各部門あるいはシステム単位で Amazon EC2 の利用量の日単位での変化を収集し土日の稼働停止がどの程度できているか確認し、常時稼働のシステムについては後述する Savings Plans の適用を検討する、などといったように、可視化で何をしたいのかということが明確に示せるようになれば、可視化したい項目や粒度などが定まってくるでしょう。 ただし、クラウド利用費用の数字だけを可視化・報告するというのは、陥りがちな間違いです。「いくらかかっているのか」という情報だけでなく、「利用量や利用状況に対していくらかかっているのか」ということを可視化することで、その費用の妥当性が判断できるようになります。 AWS の各サービスには、クラウド利用費用がいくらになっているのか、という情報はもちろんのこと、利用者のサービスの利用状況も記録されています。この利用状況の情報を利用者が出力・集計したり、あるいは表やグラフなどの形式で過去の経緯や現在の状況を可視化したりすることができます。” 出典： AWS コスト最適化ガイドブック（門畑 顕博 (著), 仁戸 潤一郎 (著), 柳 嘉起 (著), 杉 達也 (著), 小野 俊樹 (著), 藤本 剛志 (著)） 本ブログでは、前編、後編を通じて、 AWS Well-Architected Framework の コスト最適化の柱 における5つのベストプラクティスのうち、 経費支出と使用量の認識 の可視化に着目してご紹介しました。 他にも、タグポリシーに関するワークショップや、その他のベストプラクティス「 コスト効率を考慮しながらリソースを利用する 」と「 需要を管理しリソースを供給する 」に関するワークショップもありますのでご活用ください。 カスタマーソリューションマネージャー　森川 賢、髙木 香里

本ブログは Amazon QuickSight を使用した AWS Cost and Usage Reports （AWS CUR）（コストと使用状況レポート）の可視化についてご紹介します。 2部構成であり、今回は前編をご紹介します。 前編： AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用した AWS CUR の分析手順 後編： Amazon QuickSight のセットアップ、 AWS CUR の可視化、分析やダッシュボードの共有 クラウドのコストを最適化するためには、まず現在の使用状況を把握、分析することが重要です。 AWS CUR では、課金されるすべての AWS のサービスについて、月単位、日単位または時間単位の使用量の粒度、料金、コスト、使用属性が提供されるため、使用状況の把握、分析に利用することができます。 今回ご紹介する方法は「月次で AWS の利用状況をまとめたレポートを作成し、関係者に報告する」といったユースケースにご活用いただけます。 Amazon QuickSight に AWS CUR の情報を取り込んだダッシュボードを作成していただくことで、ご関係者様がレポートをいつでも見ることができるようになり、ご担当者様も毎月のレポート作成作業が不要になります。 Amazon QuickSight に AWS CUR の情報を取り込んで可視化する方法はいくつかありますが、今回は Amazon Athena 経由で取り込む方法をご紹介します。Amazon QuickSight を使用した可視化のほか、Amazon Athena から SQL クエリを使用したアドホックな AWS CUR の分析も行えるようになります。 AWS Well-Architected Cost Optimization Workshop AWS Well-Architected Framework は、クラウド上でワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明しており、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性の6つの柱で構成されています。 また、AWS Well-Architected Framework に沿ったワークショップが用意されており、各柱のベストプラクティスに沿って構成されています。 コスト最適化の柱 では5つのベストプラクティスが用意されており、コストの可視化は 経費支出と使用量の認識 に含まれます。この5つのベストプラクティスに沿ったワークショップとして AWS Well-Architected Cost Optimization Workshop があり、コスト最適化を図るためのハンズオンを提供しています。 このワークショップを用いて、AWS CUR と Amazon QuickSight を使った可視化にフォーカスしてご紹介します。 AWS CUR （コストと使用状況レポート）の作成 この手順では以下の設定の AWS CUR を作成します。 リソース ID のインクルード 自動的に更新（少なくとも1日1回更新） 詳細度が時間別 Amazon Athena と統合 AWS CUR のデータの保存には、AWS CUR を作成した AWS アカウントが保有する Amazon S3 バケットを使用します。本手順ではレポートを保存する Amazon S3 バケットの作成も行います。 初回レポート作成までに最大24時間かかることがあります。詳細の手順は以下をご参照ください。 Configure a Cost and Usage Report Configure the CUR Bucket for your Cost Optimization Account 以降は必要に応じて実施してください。 AWS CloudFormation を用いた Amazon Athena のセットアップ この手順では以下を行います。  AWS CUR のファイルが正しく作成されている事の確認   AWS CloudFormation を使った AWS Glue , Amazon Athena のセットアップ この手順を実施すると Amazon Athena から AWS CUR を検索できるようになります。 詳細の手順は以下をご参照ください。 Automated CUR Updates and Ingestion Lab Prerequisites , Setup AWS Glue with CloudFormation の範囲を実施してください。 Multiple CURs は必要に応じて実施してください。 Amazon Athena から SQL クエリを使用して AWS CUR を分析する この手順では Amazon Athena から SQL クエリを使用して、 AWS CUR に対していくつか実際に検索を行います。どのようなデータが AWS CUR に保存されているかを確認することができますのでぜひお試しください。なお、この手順では個別の設定は行いません。 詳細の手順は以下をご参照ください。 Cost and Usage Analysis – SQL 以下のような点を確認することが可能です。上記URLに下記情報を抽出するクエリサンプルが記載されています。 上位のコスト タグ付けがされているリソースに対するコスト インスタンス購入オプションに対するコスト AWS CUR の各項目名や意味は以下をご参照ください。 AWS コストと使用状況レポート – データディクショナリ AWS Athena 上は項目名が全て小文字である点と、ヘッダーと明細項目名が“_”で接続されている点にご注意ください。なお、AWS CUR と Amazon QuickSight を直接連携する場合は上記 URL に記載の項目名になります。 前編のまとめ AWS CUR はAWS のコストと利用状況に関する最も細かく最も包括的なデータが含まれています。 なお、AWS リソースの使用量・使用料金に関するデータを可視化し、分析するためのツールとして、 AWS Cost Explorer というサービスもあります。AWS Cost Explorer よりも詳細または複雑な分析、過去12か月を超える期間での分析、独自のダッシュボードでの可視化を行いたいときに、 AWS CUR が使用できます。AWS CUR では取得出来て AWS Cost Explorer では取得できない情報の1つとして、Savings Plans / リザーブドインスタンスの詳細情報があります。 AWS Organizations で共有されている、他のアカウントで購入された Savings Plans / リザーブドインスタンスの割引効果や、他のアカウントで利用された Savings Plans / リザーブドインスタンスの割引効果といったものも算出ができます。 以上、 AWS CUR や Amazon Athena の設定、 Amazon Athena から SQL クエリを使用したアドホックな AWS CUR の分析手順をご紹介しました。後編では Amazon QuickSight の設定からご紹介します。 後編は こちら カスタマーソリューションマネージャー　森川 賢、髙木 香里

2023 年 11 月 26 日、 AWS Step Functions と Amazon Bedrock との最適化された統合を発表します。 AWS Step Functions は、開発者が分散アプリケーションを構築し、プロセスを自動化し、そして、マイクロサービスのオーケストレーションやデータと機械学習のパイプラインを作成するのに役に立つビジュアルワークフローサービスです。 9 月には、基盤モデルを使用した生成系 AI アプリケーションの構築および拡張が最も簡単な Amazon Bedrock が利用可能になりました。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Stability AI、Amazon などの主要プロバイダーの基盤モデルを提供し、プライバシーとセキュリティを維持しながら、お客様が生成系 AI アプリケーションを構築するために必要な幅広い機能を提供しています。Amazon Bedrock は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK から利用できます。 AWS Step Functions の Amazon Bedrock との新たな最適化された統合により、 220 以上の AWS サービス との統合に加え、Amazon Bedrock を使用して生成系 AI アプリケーションを構築するためのタスクをオーケストレーションできます。 AWS Step Functions によって、ワークフローを視覚的に開発、検査、監査できます。 以前は、ワークフローから Amazon Bedrock を使用するために AWS Lambda 関数を呼び出す必要があり、コードの追加や、アプリケーションの実装コストを増やす必要がありました。 AWS Step Functions は、Amazon Bedrock のための 2 つの新しい最適化された API アクションを提供します。 InvokeModel – この統合により、モデルを呼び出し、入力されたパラメーターを使用して推論を実行できます。この API アクションを利用して、テキスト、画像、埋め込みモデルの推論を実行できます。 CreateModelCustomizationJob – この統合により、基盤モデルをカスタマイズするためのファインチューニングジョブが作成されます。パラメーターで、基礎モデルとトレーニングデータの場所を指定します。ジョブが完了すると、カスタムモデルが利用可能になります。これは非同期 API であり、この統合により、AWS Step Functions は ジョブを実行 し、次の状態に進む前にジョブの完了を待つことができます。これは、ステートマシンの実行がモデルのカスタマイズジョブの作成中に一時停止し、ジョブの作成が完了すると自動的に再開されることを意味します。 InvokeModel API アクションは最大 25 MB までのリクエストとレスポンスを受け付けます。しかし、AWS Step Functions ではステートの入出力ペイロードに 256 KB の制限があります。この統合でより大きなペイロードをサポートするために、 InvokeModel API がデータを読み込み、結果を書き込む Amazon Simple Storage Service (Amazon S3) バケットを定義することができます。これらの設定は、設定セクションの API パラメーターという項目で提供されます。 Amazon Bedrock と AWS Step Functions を使い始める方法 始める前に、Amazon Bedrock が利用可能な地域でステートマシンを作成することを確認してください。 この例では、 us-east-1   (US バージニア地域) を利用します。 AWS マネジメントコンソールから、新しいステートマシンを作成します。“bedrock” と検索すると、利用可能な 2 つの API アクションが表示されます。 InvokeModel をステートマシンにドラッグします。 右側のメニューでステートの設定ができるようになりました。まず、使用する基盤モデルを定義できます。一覧からモデルを選択するか、入力からモデルを取得します。 次に、モデルパラメーターを設定する必要があります。テキストボックスに推論パラメーターを入力するか、Amazon S3 からパラメーターを読み込むことができます。 API アクション設定の項目をスクロールすると、宛先となる S3 バケットなど、API の追加設定オプションを指定できます。この宛先となる S3 バケットが指定されている場合、API アクションは、ステート出力セクションではなく、指定されたバケットに API レスポンスを格納します。ここでは、リクエストとレスポンスのコンテンツタイプを指定することもできます。 ステートマシンの設定が完了したら、作成して実行できます。ステートマシンが実行されると、実行の詳細を視覚化し、Amazon Bedrock のステートを選択すると、その入出力を確認できます。 AWS Step Functions を利用すると、必要に応じて広範囲にステートマシンを構築し、さまざまなサービスを組み合わせて多くの問題を解決できます。 たとえば、AWS Step Functions と Amazon Bedrock を利用して、プロンプトチェーンを使用したアプリケーションを作成できます。 これは、非常に長く詳細なプロンプトではなく、複数の小さくてシンプルなプロンプトを FM に渡すことで、複雑な生成系 AI アプリケーションを構築する技術です。 プロンプトチェーンを構築するには、Amazon Bedrock を複数回呼び出して、小さなプロンプトごとに推論を得るステートマシンを作成できます。 並列ステート を使用して、これらすべてのタスクを並行で実行でき、 AWS Lambda 関数を利用すれば、並列タスクの応答を 1 つの応答に統合して結果を生成することができます。 今すぐ利用可能 AWS Step Functions の Amazon Bedrock との最適化された統合は、Amazon Bedrock が利用可能な AWS リージョンに限定されています。 AWS Step Functions コンソール からサンプルプロジェクトを試すことで、AWS Step Functions と Amazon Bedrock を使い始めることができます。 – Marcia 原文は こちら です。

AWS App Runner は、インフラやコンテナの経験がなくても、コンテナ化された Web アプリや API をビルド、デプロイ、実行できるフルマネージドなコンテナアプリケーションサービスです。App Runner はインフラ構成の複雑さを抽象化します。実際、 Wix ・ Hubble ・ Cox やその他多くの企業が、App Runner を利用することでサーバー管理にかける時間を減らし、イノベーションを加速することに集中しています。App Runner では ソースコード または コンテナイメージ から直接、スケーラブルでセキュアなWeb アプリとしてデプロイできます。これらは高速でシンプルで、かつコスト効率の高い方法です。 本日(2023/12/07) 、App Runner のコンテナイメージベースのデプロイ速度の改善をリリースしました。 ベンチマークでは、コンテナイメージサイズに応じて、 リリース前と比較してデプロイ時間が約 30 ～ 40% 短縮しました。 この機能強化により、コンテナイメージリポジトリからイメージをダウンロードできない場合の App Runner の動作も改善されます。 以前は、App Runner がイメージをダウンロードできない場合、ステータスを failed にする前に 10 分間リトライしていました。 App Runner は、コンテナイメージのダウンロードができない何らかの要因があった場合、デプロイのステータスを直ちに failed にするようになりました。 今回の機能改善は自動的に適用され、すべての App Runner ユーザーがメリットを得ることができます。既存の App Runner サービスを更新する必要はありません。 どれだけ速くなったのかを実際に計測 コンテナ化されたアプリケーションの場合、コンテナイメージの大きさは、デプロイ時間やアプリケーションの起動時間に影響します。 より小さなコンテナイメージを使うほど、アプリケーションの起動時間は短くなり、デプロイも速くなります。 これは、コンテナイメージのダウンロードが、アプリケーションのデプロイに最も時間のかかるタスクの 1 つであるためです。 App Runner の今回の機能改善の効果を、コンテナイメージの大きさごとに計測することを目指しました。 デプロイ時間の改善を測るために、 hello-app-runner コンテナイメージを利用しました。 hello-app-runner コンテナイメージは 261 MB です。 次に、50 MB のファイルを大量に生成することで、イメージの大きさを人為的に大きくしました。1 GB、2 GB、および 3 GB の 3 つのイメージを用意しました。 必要な大きさのコンテナイメージを用意したら、それらを使用して App Runner サービスを作成し、サービスのステータスが Healthy になるまでにかかる時間を機能改善の前後で比較しました。 各イメージを 10 回デプロイし、平均値を測定して外れ値を除外しました。 下の表は、デプロイ時間の改善を示しています。 下のグラフは、サービスのステータスが Healthy になるまでの時間を秒単位で示しています。 コンテナイメージの大きさが 1 GB 未満の場合、 デプロイ時間は約 2 分短縮しています 。 大きなイメージの場合、5 分近くの短縮しています。 すでに利用可能です 今回の機能改善は、App Runner を利用可能なすべての AWS リージョンで適用されています。デプロイプロセスが 1 分短くなると、アプリケーション開発やリリースサイクルに大きな影響をもたらすでしょう。App Runner を使うことでみなさまが、みなさまのお客様により迅速にアプリケーションを届けられることを願っています。 このリリースは、ユーザーのみなさまが 大規模な Web アプリや API を、より手軽に実行できるようにするための継続的な取り組みの一環です。 App Runner の最近の機能強化については、 リリースノート をご覧ください。 AWS App Runner における今後の機能開発の詳細については、 App Runner roadmap on GitHub をご覧ください。 また、 AWS re:Post for AWS App Runner でフィードバックや質問もお待ちしています。 翻訳はソリューションアーキテクトの濵が担当しました。原文は こちら です。

本記事は、「 Disaster Recovery 5G Core Network on AWS 」（2023年6月26日公開）を翻訳したものです。 通信サービスプロバイダ（CSP）は、テレコム業界においてさらなる活用事例を見つけようとしています。AWS 上の 5G コアネットワークデプロイは、企業向けのプライベートネットワークや新たな 5G ネットワークの作成などの実用的なユースケースが挙げられて、ますます注目されています。AWS の ホワイトペーパー で強調されているように、AWS のグローバルクラウドインフラストラクチャである AWS Regions 、AWS  Availability Zones（AZ）、 AWS Local Zones 、 AWS Outposts は、ネットワークファンクション（NF）の特性に合わせて 5G コアネットワークをホストするための効果的かつ柔軟な環境を提供できます。一例として、ユーザプレーン機能（UPF）は、低遅延で処理するために AWS Local Zones や AWS Outposts に配置することができます。 5G NF on AWS のさまざまなユースケースの中でも、すでに 5G コアネットワークを構築している CSP にとって、魅力的なケースの1つは、AWS を利用した災害復旧（DR）です。この 5G DR ネットワークは、5G NF の障害、データセンターの完全停止、またはメンテナンスウィンドウに対するスケーラブルかつ即時の対策を目指しています。具体的には、この DR ネットワークは、計画されたメンテナンス、災害による予期せぬ停止に応じてのみ追加される環境であるため、迅速なスケールインとスケールアウトによってリソースのコストを最小限に抑える必要があります。従来の電気通信業界のデータセンターに冗長なネットワークを構築する場合と比較して、AWS は CSP が通常運用時にコストとエネルギー消費を最小限に抑えることを手助けできます。また、輻輳によるトラフィックの急増やメンテナンスイベントなどの変動的な需要にも迅速に対応できます。 この記事では、AWS を 5G ネットワークのもう1つの仮想データセンター環境として活用し、「災害耐性」と「災害回復」の目標を達成する方法について説明し、AWS における 3GPP の高可用性コンセプトや関連する AWS サービス（オートスケーリング、自動化ツール、ネットワークのコスト最適化など）を活用することに焦点を当てています。具体的には、 Amazon Elastic Compute Cloud（Amazon EC2） の Autoscaling 機能、 Amazon Elastic Kubernetes Service（Amazon EKS） の Horizontal Pod Autoscaling と Cluster Autoscaling 機能を使用して、DR 用の VPC 内のコンテナベースのネットワークファンクション（CNF）のフットプリントを最小限に抑えることができます。また、トラフィックの急増に対応するための迅速なスケールアウトもできます。 さらに、コストとエネルギーを最適化するために、 Graviton インスタンスで 5G コア NF をホストすることも検討できます。この記事では、まず DR モデルと戦略を説明します。そして、最初に 5G ネットワークのケースにどのように適用されるかを説明し、次に 3GPP アーキテクチャを活用してこの DR 目標を達成する方法や、いくつかのオープンソースの例を用いて EC2 Autoscaling、Cluster Autoscaling、およびその他の機能などの AWS サービスをどのように活用できるかといった重要なアイデアを示します。 AWS での 5G コアネットワークの DR モデル こちらの DR に関する 記事 と ホワイトペーパー で説明されているように、DRには2つの目標があります。リカバリタイムオブジェクティブ（ RTO ）は、サービスの中断と復旧の間の許容遅延時間を意味し、リカバリポイントオブジェクティブ（ RPO ）は、最後のデータ復旧ポイントからの許容時間を意味します。AWS 上で実行される一般的なアプリケーションの場合、DR のための AWS サービスには AWS Elastic Disaster Recovery（ AWS DRS ）や Amazon Route 53 Application Recovery Controller（ Route 53 ARC ）などがあります。 しかし、5G コアネットワークアプリケーションでは、3GPP 標準に基づくネットワークインタフェースとプロトコルに対するより強い要件があります。AWS DRS などのサービスはコアネットワークのすべてのコンポーネントに常に適用できるわけではありません。この記事ではより包括的な視点から、3GPP の標準アーキテクチャのコンテキストで、AWS のサービスが DR 実装にどのように役立つかに焦点を当てます。 5G NF の場合、AMF、SMF、UPF などのコア機能コンポーネントは、5G 音声およびデータサービスの高速な復旧に重要な役割を果たすため、RTO がより重要です。一方、UDM は RPO と RTO の両方に強く影響されます。なぜなら、UDM は加入者のプロファイルと情報を扱うからです。各 NF には異なる目標があり、異なるタイプのDR戦略を適用すべきです。以下の図は、DR ホワイトペーパーで強調されている DR の 4つの戦略 を示しています。左から右へと進むグラフィックは、DR 戦略によって RTO と RPO が変わることを示しています。5G コア NF の場合、ミッションクリティカルなサービスを提供しているため、より短い RTO が求められる場合があります。 図1: 一般的なアプリケーションの DR 戦略 たとえば、先に述べたように、UDM はリアルタイムに近い RTO と RPO の両方が必要です。したがって、AWS 上の UDM の DR サイトを構築する場合、UDM を常にアクティブな状態に保つためには、従来のデータセンターの UDM と同期する必要があります。この場合、Hot-standby（Active-Active）戦略がより適切です。 一方、その他の NF には、Warm-standby、Pilot light、Backup ＆ Restore などの戦略をユースケースと NF の特性に基づいて適用できます。Backup ＆ Restore は、ミッションクリティカルではい、優先度の低いユースケース（1 時間未満という厳しい RTO が要求されない場合）に適用できます。データセンターと AWS の間に事前に確立された Amazon Direct Connect （もしくは帯域幅制限と安定性を備えた Site-to-Site VPN で代替可能）があれば、 AWS CloudFormation 、AWS Cloud Development Kit（ AWS CDK ）、 AWS CodePipeline などの AWS ツールを利用して、「NF の即時インスタンス化」を実現できます。インフラアズコード（ IaC ）の利点によってさらに加速化することも可能です。詳細については、こちらの AWS 記事 DR Architecture on AWS, Part II を参照してください。また、AWS 上での 5G NF デプロイ CI/CD パイプラインも迅速なサービス回復に貢献できます。詳細については、こちら AWS ホワイトペーパー CI/CD for 5G Networks on AWS を参照してください。 Cold-standby は、ミッションクリティカルでない 5G ネットワークユースケースに対して、コスト効果の高い選択肢です。この戦略では、すべての EC2 インスタンスがシャットオフ状態ですが事前に作成されており、通常運用時は DR サイトにトラフィックを処理させない状態になっています。そのため、Backup ＆ Restore よりも高速で、Warm-standby よりもコスト効果が高くなります。一方、Warm-standby は、テレコムの音声およびデータサービスの RTO を考慮して、AWS 上に DR 5G ネットワークを構築する最も実用的な方法です。この戦略では、DR サイトのほとんどの 5G NF が最小限のデプロイで少量のトラフィックを処理し、トラフィックカットオーバー時にトラフィックを処理できるように拡張します。これにより、5G ネットワークの災害耐性を実現しながら、サービスの連続性を確保することができます。5G NF が Amazon EKS 上に実装されている場合、一般的なオートスケーリンググループベースの機能だけでは、トラフィックの急増を吸収するための瞬時スケールの要件を満たせない場合があります。これは、必要な RTO が Kubernetes オートスケーリングアクションの一般的な応答時間よりも短いためです。そのため、この記事の後半では、Amazon EKS 環境でこのより速い Warm-standby を実現するための効果的な実装スキルを詳細に紹介します。最後に、コスト最適化の観点から、Graviton インスタンスはコストパフォーマンスの面で著しい利点を提供し、エネルギーの節約に関連する問題に取り組んでいます。 3GPP で定義された耐障害性メカニズムと AWS での活用 3GPP は、5G コアネットワークのネットワーク耐性を構築するため、NF Set と呼ばれるコンセプトを TS23.501 で定義しています。このコンセプトでは、NF は単一のインスタンスとして展開されるか、もしくは同じ NF の複数のインスタンスが NF Set を形成することができます。これにより、NF インスタンスが障害になった場合、 NF set 内の代替 NF インスタンスに置き換えて、代わりにリクエストされたサービスを提供したり、サービス要求の急増を処理したりできるため、サービスの冗長性とスケーラビリティが高まります。5GC ネットワークでは、AMF、SMF、UDM など、NF Set の概念をサポートする多くの NF があります。DR のユースケースでは、N2トラフィックを gNodeB から受け取る AMF set の利用により、AMF が各データセンターにある NF にトラフィックを転送します。次の図は、AMF set 構成の例です。AMF set はトラッキングエリアコード（TAC）ごとに構成され、AMF が 3つの異なるデータセンターに跨ってトラフィック負荷を分散し、障害時のスイッチオーバーを行います。3GPP では AMF set のロードバランシングのコンセプトも定義しており、各 AMF の Weight Factor を使用して、各データセンターの AMF の容量に基づいて UE の登録（Registration）を制御できます。 図2: 複数のデータセンターにまたがる3GPP NF Setのデプロイ AMF set のような NF set のコンセプトにより、NF のグループがデータセンター間でトラフィック負荷分散することができますが、Network Repository Function（NRF）は、AMF 以外の NF に対するトラフィック負荷のローカリゼーションすることができます。具体的には、3GPP の標準に従い、NRF は Nnrf_Management（nnrf-nfm）および Nnrf_Discovery（nnrf-disc）サービスを使用して、サービスを要求する他の NF（Consumers）にサービスを提供する NF（Producers）のステータスに関する情報を維持および提供することを担います。NRF サービス Nnrf_Management は、「NFRegister」の動作をサポートし、5GコアネットワークのすべてのNFがNRFに対してそれぞれのプロファイルを登録するために使用されます。登録プロセス中、NF は NFProfile の一部として、nfInstanceID、nfType、nfStatus、FQDN、IPv4/IPv6 アドレスなどの必須情報を NRF に送信し、オプションとして、優先度や地域など、NF Set に関連する情報も送信します。 図3: NRF への NF 登録と NRF へのサービスリクエストの例 NRF サービス Nnrf_NFDiscovery は、5G NF（Network Function）の「Consumer」に「Producer」の情報を提供するための「NFDiscover」という操作をサポートしています。通常、商用ネットワークがより高い可用性を実現するために、CSP は複数の Producer NF のインスタンスを展開します。3GPP では、Producer NF を発見するためのオプションが Consumer NF に提供されています。Consumer は、必要なサービスの要件に一致するすべての Producer NF の一覧リストを要求するか、追加のクエリパラメータで返されるリストを絞ることができます。Consumer NF が使用できるクエリパラメータの1つは、異なる Producer NF に対して NRF から返された優先度情報に基づいています。Consumer NF が使用できるもう1つのパラメータは、「preferred-locality（優先ローカリティ）」です。AMF setとNRF preferred-locality は、DR on AWS のユースケース、特に Pilot light、Warm-standby、または Hot-standby のために活用することができます。例えば、AMFの重み係数が既存のデータセンターと AWS 上の仮想 DR データセンターで同じ値で構成されている場合、DR サイトは Hot-standby モードで動作します。 障害時におけるオンプレミスデータセンターから VPC へのトラフィックシフト 一般的なオンプレミス商用 5G コアネットワークは少なくとも1つの DR サイトで展開されます。DR サイトの数は、CSP の戦略に依存します。さらに、1+1、N+1、または N+K いずれのモデルが採用されます。DR サイトの数に関係なく、オンプレミスの DR サイトには、アクティブサイト障害のトラフィックを引き継ぐために必要となる以上のリソースが常に割り当てられます。 CSP は、NF set のメカニズムを使用して、NF インスタンスのグループをアクティブサイト（または既存のデータセンター）と DR サイト（AWS 上の仮想データセンター）に分散させることができます。AWS 上の DR サイトでは、3GPP をサポートする 5G NF が既存のオンプレミスの NF set の一部として構成することができます。NF set の一部として追加できない 5G NF は、新しいインスタンスにデプロイできます。NRF のデプロイモデル（集中型または分散型）に応じて、DR サイトの NF はオンプレミスの中央集権型 NRF に登録するか、AWS 上のローカル NRF に登録することができます。ただし、いずれの NRF 展開オプションにおいても、Warm-standby 戦略では、DR サイトの NF は登録時に、オンプレミスの NF よりも低い優先度（AMF の場合は低い Weight Factor）を使用することが重要です。これにより、通常時はアクティブなオンプレミスサイトがトラフィックを継続的に処理し、災害、NF の故障、またはメンテナンスウィンドウの発生時にのみ、トラフィックが AWS 上の DR サイトに移行されます。 DR サイトがアクティブになると、AWS のスケーラビリティと弾力性を活用して NF の容量を拡張することも重要です。また、NF の登録プロセス中に「preferred-locality」情報を使用することで、トラフィックを DR サイトの 5G NF 内に保つことができます。これにより、レイテンシが低くなり、サービスリクエストの応答時間が向上します。 図4: AWS 上の 5GC ネットワーク DR サイト 通常時のシナリオでは、大部分のトラフィックはオンプレミスのアクティブサイトで処理されるため、CSP は AWS 上で最小限の DR サイトフットプリントから始めることができます。その後、障害のタイプに応じて、単一または複数の NF が次の章で説明する高速オートスケーリングメカニズムを利用し、適切なリソースまで拡張します。この戦略は、完全なオンプレミスサイトの故障だけでなく、部分的な故障のケースやオンプレミスのメンテナンスウィンドウの間にも適用することができます。 トラフィック急増を対応するための高速オートスケーリング 前章で説明したように、Warm-standby 戦略の場合、5G コア NF は最小のフットプリントで AWS に展開され、アクティブサイトのトラフィックの一部を処理します。しかし、プライマリサイトに障害が発生した場合、トラフィックがプライマリサイトから AWS 上の DR サイトに移行するため、大規模なトラフィックの急増が予想されます。この場合、5G NF と AWS のコンピュートプラットフォームの容量を迅速にオートスケーリングすることが重要です。5G NF のオートスケーリングは通常、Kubernetes HPA（Horizontal Pod Autoscaler）に基づいて行われます。ただし、POD のスケーリングだけではワーカーノードのスケールアウトに対応できません。5G NF は Amazon EKS を利用して AWS にデプロイされているため、この課題の解決策は Autoscaling Groups と関連しています。Amazon EKS は、Kubernetes のワーカーノードのデプロイと管理（スケールアウトを含む）に Autoscaling Group を利用します。ただし、Autoscaling Group の Cluster Autoscaler 機能は、5G のスケールアウトの要件に対しては遅すぎます。これは、Cluster Autoscaler がリアクティブな仕組みで、POD がスケジュールできないと判明した後にのみクラスターのスケーリングがトリガーされるためです。その代わりに、Autoscaling Group の Cold-standby 機能を利用することで、トラフィック急増する際に迅速に Amazon EKS ワーカーノードのスケールアウトを行うことができます。 図5: Amazon EKS ワーカーノードの状態変更による Cold-standby モデルの高速スケールアウト さらに、Cold-standby モデルの使用により、Amazon EKS ワーカーノードはワークロードをホストするために事前に設定されるだけではなく、使用されていない間は電源をオフにしてコストを節約することができます。これは、起動時のスクリプトによる特別なチューニングを必要とするワークロード（通常は Multus と DPDK を使用するワークロードなど）に特に有用です。これらのワーカーノードは、Amazon Elastic Container Registry（ Amazon ECR ）または他の場所から POD コンテナイメージを事前にダウンロードするなど、さまざまな事前処理を行うことができます。そのため、POD の起動時にコンテナの準備完了状態までの時間が短縮されます。Cold-standby ワーカーノードの自動化は、こちらの記事の GitHubリポジトリ で示されているカスタム Lambda 関数によって実現できます。 図6: Cold-Standby Amazon EKS ワーカーノードの自動起動プロセス カスタムメトリクスに基づいたスケーリングの自動化 Warm-standby 戦略では、プライマリサイトがメンテナンス中または災害/障害のためにダウンした時に、トラフィックの急増がアプリケーションのカスタムメトリクスで検知されます。例えば、AMF 登録試行数のメトリクスが急増します。Amazon Distro for Open Telemetry（ ADOT ）のアプリケーション Metrics Scraping を利用し、Cold-standby ノードの起動をトリガーするソリューションも利用できます。以下の図には、 Amazon Managed Prometheus サービスからカスタムメトリクスを収集するために KEDA を使用し、事前に定義されたトリガーと閾値に基づいてKubernetes ジョブをキックオフし、ワーカーノードをオンライン状態にするソリューションの一例が示されています。 図7:カスタムメトリックと KEDA を活用した高速オートスケーリング Hot-standby と Warm-standby の DR 戦略のコスト比較 5G コアの AWS とオンプレミスの地理的冗長ソリューションの TCO 比較はかなり複雑ですが、Warm-standby DR 戦略と前述した Cold-standby の仕組みの組み合わせによるコスト削減効果を検討することができます。例えば、全トラフィックを処理できる Hot-standby（Active-Active）サイトには、6つの m5.8xlarge EC2 インスタンスが必要であり、Warm-standby モードでは、一部分のトラフィックのみを処理するため、2つのm5.8xlarge EC2インスタンスが必要とします。そして、AWS 上の DR サイトへのトラフィックシフトが平均して毎月 4 時間で発生すると仮定します。したがって、毎月 4 時間のみ、DR サイトはすべてのトラフィックを処理するために追加の 4つの m5.8xlarge EC2 インスタンスが必要となります。 Hot-standby の場合、 AWS Calculator と US-East（Ohio）の EC2 インスタンスの saving plan 価格（64GB の EBS ストレージを搭載したインスタンスで、この記事作成時の価格）を使用すると、常時稼働している6つの m5.8xlarge EC2 インスタンスの年間費用は $47,830.32 になります。一方、Warm-standby の場合、 AWS Calculator for Warm Standby を使用して計算すると、コストは$16,914.60 になります。2つの常時稼働している m5.8xlarge EC2 インスタンスの年間費用 $15,943.44 と、毎月 4 時間稼働する 4 つの追加 m5.8xlarge EC2 インスタンスのオンデマンド価格による年間費用 $294.96、および 4 つの 64GB EBS ボリュームの年間費用 $676.20 が含まれます。 以下のグラフから分かるように、Warm-standby モードの利用により、Hot-standby（Active-Active）モードと比較して約 65% の節約が実現されます。 図8: 6つの m5.8xlarge EC2 インスタンスの Hot-standby と Warm-standby のコスト比較 CSP は、5GC ネットワークに対して、上記のアプローチを適用する際に、 AWS Calculator for EC2 を利用して EC2 インスタンスの数量を入力し、Warm-standby DR 戦略の実施による潜在的なコスト削減を推定することができます。 結論 5G モバイルコアネットワークは、音声通話やデータストリーミングなどのミッションクリティカルなサービスを提供するため、サービスの災害耐性を確保し、ネットワークコンポーネントの迅速な災害復旧の能力を持つことが重要です。障害や災害からのより良い保護を実現するために、従来のオンプレミスデータセンターではなくクラウド上に DR 5G ネットワークの構築を検討することが考えられます。また、この DR 5G ネットワークが限られた期間に使用されることが主な目的である場合（サービスの回復やトラフィックバーストの吸収）、クラウドの従量課金モデルとの相性が良いです。AWS は、CSP のお客様に対して、DR 仮想データセンターを構築するための環境だけでなく、この記事の GitHubリポジトリ のサンプルで示されているようなネットワークの自動化とスケーリングツールなどの支援も提供します。この高速スケーリングアウト能力を、Graviton インスタンスなどの適切なタイプ/サイズのインスタンスと組み合わせることで、CSPのお客様にとってコストとエネルギーの節約の利益を最大化することができます。AWS での通信事業者の 5G ユースケースの詳細については、 aws.amazon.com/telecom/contact-us にお問い合わせください。 著者について Ashutosh Tulsi Ashutosh Tulsi は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、通信サービスプロバイダー (CSP) や通信事業者 ISV パートナーと連携しています。彼は 4G/5G ネットワークの AWS クラウドへの移行を支援するソリューションを提供することで、CSP の運用効率向上とコスト効率向上を目標としています。 Neb Miljanovic Neb Miljanovic は、電気通信ベンダーのパブリッククラウドへの移行をサポートする AWS テレコパートナーソリューションアーキテクトです。彼は 4G/5G/IMS コアアーキテクチャに関する豊富な経験を持ち、その経験をクラウドネイティブな原則を使用して 4G/5G/IMS ネットワークファンクションの AWS への移行に応用することを使命としています。 Dr. Young Jung Dr. Young Jung は、AWS ワールドワイドテレコムビジネスユニットのプリンシパルソリューションアーキテクトであり、NFV 分野を専門としており、さまざまなグローバル通信パートナーと協力して、AWS 環境のパートナー向けにクラウドネイティブ 4G/5G NFV ソリューションの作成に貢献しています。 翻訳はソリューションアーキテクトの陳誠が担当しました。

実店舗に終焉はない 顧客の期待と行動が劇的に変化する中、世界中の小売業界は 10 年間変化の危機に瀕しています。パンデミックは、これまで大切にされてきた概念を覆し、オンラインショッピングの台頭を加速させました。現在、デジタル認知度の高い若い顧客の多くが街中に点在しています。逆説的ですが、これは実店舗の終焉を意味するものではありません。 実店舗は依然として小売売上高のほぼ80％を占めています 。 実店舗では、顧客が商品を見たり触れたり、パーソナライズされたサービスを楽しんだり、ブランドを体験したり、ソーシャルインタラクションを促進したりすることができます。そのため、一部の小売業者は、この新しくて不確実な環境で成功するために、ビジネス戦略において実店舗をリファクタリングしました。たとえば、 IKEA は市内中心部に複数の新しい店舗をオープンしており、オンラインプレーヤーは、この傾向に乗じて 実店舗に進出 しています。 小売業界が、物理チャネルとデジタルチャネルを統合し、顧客体験を向上させてビジネスの成長を促進するという変革を遂げているのも不思議ではありません。過去のサイロ化されたモデルは、もはや意味がありません。 オムニチャネル戦略は、消費者が期待する一貫性のあるシームレスな体験を提供するために、小売業界で徐々に普及しつつあります。Forresterによると 、将来の小売売上高の70％は「デジタルによる影響」を受ける可能性が高い とのことです。オムニチャネルの顧客は、1つのチャネルしか利用しない顧客よりも1.7倍の買い物をしているという結果が出ています。そのため、米国の小売業者は、 2021年に閉店した店舗数の約2倍の店舗出店を発表 したのです。 AWSとInfosysは、スマートストアの開拓を支援できます アマゾンウェブサービス（AWS）を活用したスマートストアソリューションの登場 は、将来の小売業界での成功を目指す小売業者にとって魅力的なソリューションとなっています。スマートストアソリューションは、クラウドベースのテクノロジーを活用して顧客と小売業者の両方の店舗体験を向上させる次世代の実店舗イノベーションとして機能します。次世代デジタルサービスの世界的リーダーである Infosys は、AWSと協力して、小売業者が実店舗の変革の可能性を最大限に引き出せるよう支援しています。 スマートストア戦略を採用し、業界におけるInfosysの長年の専門知識を活用することで、小売業者は最先端のテクノロジーとデータ主導の知見を活用して、オペレーションパフォーマンスを向上させ、ビジネスの成長を促進することができます。Infosysは、当社で最も実績があり経験豊富な AWS パートナーの 1 つとして、小売業者が AWS の機能を活用してスマートストアの可能性を解き放ち、最終的に小売業界での持続的な成功への道を開く上で重要な役割を果たしています。 最近の ブログ と 電子書籍「スマートストアの力を生かす」 で強調されているように、AWS スマートストアは次の 3 つの柱に基づいています。 店舗でのデジタル 店舗運営の強化 スムーズなチェックアウト AWSとInfosysは、これらの柱を支えるソリューションを提供できます。これらのソリューションは小売業者にとって以下のことを支援します。 業務と顧客イニシアティブの調整 差別化された、テクノロジーを活用した店舗内戦略の構築 効率性の向上 財務の改善 競争上の優位性を獲得 AWS と小売コンピテンシーパートナー の Infosys が、小売に焦点を当てたさまざまなサービスを通じて、小売業者のスマートストア導入をどのようにサポートできるかを見てみましょう。 店舗におけるデジタル InfosysのEquinox ソリューションは、あらゆるチャネルやタッチポイントでB2BやB2Cのバイヤーに、高度にパーソナライズされた充実したエクスペリエンスをサポートし、人間中心のデジタルコマースおよびマーケティングプラットフォームを提供します。将来を見据えた柔軟なInfosys Equinoxは、MACH-Xソリューション（マイクロサービス、APIファースト、クラウドネイティブ、ヘッドレス拡張を、オープンソーステクノロジー上に構築） 図1 — Infosys Equinoxは、ヘッドレスで人間中心のクラウドネイティブなデジタルコマースおよびマーケティングプラットフォームです。 店舗運営の強化 店舗管理者向けInfosys Intelligent Store Cockpit は、在庫、顧客の注文、人件費、バックオフィス全体にわたる統合的な洞察に基づく意思決定を可能にします。予測分析は店舗の混乱を防ぎ、スマートなバックオフィス業務はデータの不一致を最小限に抑えます。 エネルギー管理と設備監視は、スマートストアが先導するもう 2 つのオペレーション分野です。 Infosys EcoWatch は、直感的で使いやすいクラウドプラットフォームです。サステナビリティ計画、環境、社会、ガバナンス（ESG）レポート、パフォーマンス管理、分析、ダッシュボード、レポートと開示、ステークホルダー管理などの機能に対応しています。EcoWatchは、企業が将来を見据えたビジネス成果に向けて持続可能性に関するコンプライアンスを測定、管理、報告できるようにするテクノロジーイネーブラーです。 図 2 — Infosys EcoWatch プラットフォーム スムーズなチェックアウト Infosys Extended Store は、AWS上で稼働する店舗内のモバイル顧客チェックアウト体験を提供します。このクラウドベースのアプリケーションは、オンラインショッピングの利便性スピードと、顧客が楽しめる店舗での体験を融合させています。顧客は店舗を訪問してスマートフォンを使って商品をスキャンし、価格や実施中のプロモーションを確認したり、閲覧や買い物行動に基づいて商品に関するおすすめを受け取ったりできます。また、携帯電話からも支払いが可能なため、顧客は自分の判断で店員とやり取りできます。Extended Storeは、店舗内とオンライン体験を融合させた、どの小売業者でも使用できるフリクションレスなショッピング体験プラットフォームです。 図3 — Infosys Extended Storeは、セルフサービスと非接触型チェックアウトを可能にすることで顧客体験を向上させます Infosys Metaverse Foundry のInfosys XR視覚化プラットフォームは、ショールームの設計からeコマースサイトでの仮想試着技術の実現まで、さまざまな機能を備えた素材の3D視覚化を可能にするクラウドネイティブなオムニチャネルソリューションです。 店舗ナビゲーション用の Infosys自律システムプラットフォームSTALLY (Store Ally) : 最適化された小売アプリケーション向けの、自律的で費用対効果が高く、用途が広く、スケーラブルなプラットフォームです。STALLYはマルチモーダルの店内アシスタンスを提供し、お客様が商品の所在地を検索したり、店内ナビゲーションを行ったりするのに役立ちます。店舗マップやプラノグラムのデジタル化、買い物リスト内の商品の配置や商品リストを検索するモバイルアプリについて説明します。また、ガイド機能とセルフナビゲーション機能により、すべての製品ロケーションをカバーする最適なルートを計画できる自律型カートも備えています。 コンピュータビジョン 主導型トラッキング：店舗のCCTVカメラを搭載したコンピュータビジョンにより、小売店は顧客を識別し、その動きトラックし、ほぼリアルタイムのニーズ評価に基づいて状況に応じた支援を提供できます。また、プラノグラムコンプライアンス、トラフィック分析、小売収縮などの機能も含まれています。Infosysは、小売業者が実店舗でこれらのユースケースを実現できるようサポートできます。 小売業者がスマートストアに命を吹き込むのを支援する AWS とInfosysは、スマートストア戦略を実施する小売業者に、画期的なガイダンス、サービス、エクスペリエンスを提供しています。両社は協力して、顧客体験の向上、市場の変化への機敏な対応、オペレーション効率の向上を実現する包括的なソリューションポートフォリオを提供します。高度なテクノロジーとドメイン知識を活用することで、小売業者はパーソナライズされたエクスペリエンス、シームレスなオムニチャネルインタラクション、カスタマイズされたオファーを提供して、顧客ロイヤルティを高めることができます。 aws.amazon.com/retail/ で詳細を確認するか、 AWS と Infosys Retail にお問い合わせください。 Further Reading AWS でInfosysをご覧ください Kmart Australiaがマイクロフォーカスソリューションを使用してAWSへの移行を加速 Infosys Equinox でRetail 向けのマイクロサービスアーキテクチャを構築する方法 Infosys・エクイノックスとAWSで消費者直販戦略を成功に導く方法 小売業者がInfosys Cortex と Amazon Connect を使用してインテリジェントコンタクトセンターを構築する方法 レガシーワークロードの移行、クラウドネイティブアプリケーションの開発、AWS でのモダナイゼーション Justin Swaler Justin Swaler は、AWS のワールドワイド・フィジカル・リテール部門長として、フィジカル・リテールのグローバル戦略とソートリーダーシップをリードしています。Justin は、イノベーション戦略、リテールオペレーション、製品開発、エグゼクティブリーダーシップなど、消費財、リテール、戦略分野で15年以上の経験を持ちます。消費者体験を戦略的に革新し、組織を改革することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号、ケロッグ経営大学院でMBAを取得しています。 Ravindar Vanam Ravindar Vanamは、Infosys のコンシューマー、Retail、ロジスティクスのシニアディレクターです。小売業界の変革と店舗体験戦略を主導し、InfosysとAWSクラウドソリューションの総合的な専門知識を活用して、革新的なソリューションとサービスを顧客に提案することを専門としています。彼はさまざまなグローバル小売ブランドで25年以上働いてきた経験があり、小売業者の特定のニーズと課題を理解するのに役立ちます。 翻訳はソリューションアーキテクトの齋藤が担当いたしました。 原文 はこちらです。

なりすましや悪質業者の世界では、 AWS Amplify と Amplify UI FaceLivenessDetector コンポーネントが、本物のユーザーによってアプリが使用されているか確認するのに役立ちます。この一連のコンポーネントライブラリは、 Amazon Rekognition Face Liveness の機能を利用しています。機械学習や人工知能 (AI) の経験は必要ありません。 この完全にマネージドな機能は、なりすましを検出するのに利用する自分の顔を撮るために正面カメラを使用します。いくつかの簡単なステップで、React、Android、Swift アプリケーションにこの機能を追加できます。 このチュートリアルでは、アプリケーションにサインアップしたユーザーを認証する方法を紹介します。そのために新しいNext.js アプリを作成し、Amplify を設定し、認証機能を追加し、FaceLivenessDetector コンポーネントを追加します。AWS Lambda REST API を使用して、 Amazon Rekognition Liveness の機能と通信するエンドポイントを作成します。これらのエンドポイントは、ユーザーが本物かどうかを判断するのに役立つスコアを返却します。 前提条件 このチュートリアルでは以下のものが必要となります。 利用中の AWS アカウント NPM を利用してインストールされた Node アプリと権限の設定 まず、新しい Next.js アプリケーションを作成しましょう！このチュートリアルでは npm を使いますが、お好きなパッケージマネージャを使ってください。 $ npx create-next-app@latest --no-app このアプリケーションでは、Amplify で必要に応じて使用できる App Router は使用しません。Amplify で App Router を使用する際の詳細については、 Amplify UI Docs をご覧ください。 新しくできた Next アプリのディレクトリへ移動し、Amplify ライブラリをインストールします。 $ npm i @aws-amplify/ui-react-liveness @aws-amplify/ui-react aws-amplify まだインストールしていない場合は、Amplify CLI もインストールします。 $ npm i @aws-amplify/cli -g この先の手順には AWS アカウントが必要です。 こちら からサインアップすることができます。また、初めて Amplify CLI を使用する場合は、必ず amplify configure を実行してください。 Next アプリが Amplify を認識するように設定しましょう。ここでは CLI を使いますが、 Amplify Studio を使うこともできます。 init コマンドを実行します。 amplify init ? Enter a name for the project livenessnextexampleg The following configuration will be applied: Project information | Name: livenessnextexampleg | Environment: dev | Default editor: Visual Studio Code | App type: javascript | Javascript framework: react | Source Directory Path: src | Distribution Directory Path: build | Build Command: npm run-script build | Start Command: npm run-script start ? Initialize the project with the above configuration? Yes Using default provider awscloudformation ? Select the authentication method you want to use: AWS profile 全ての項目でデフォルトを選択し、進めることができます。こちらの手順でアプリ内に amplify フォルダが作成され、 src フォルダ内に aws-exports ファイルが作成されます。 Liveness のための認証機能を追加 認証されたユーザのみ FaceLivenessDetector コンポーネントを使用できるように、 Auth カテゴリ を追加しましょう。これにより、あなたのアカウントの下に Amazon Cognito ユーザーと ID プールが作成されます。 以下のコマンドを実行してください。 $ amplify add auth 電子メールとその他全ての設問をデフォルトの設定で選択します。 必ず変更をプッシュしてください！ $ amplify push 認証されていないユーザに Liveness の使用を許可する場合は、代わりに Manual Configuration を選択することをお勧めします。最も重要なプロンプトは Allow unauthenticated logins です。ここでは必ず Yes を選択してください。これでログインせずに Liveness サービスを使用できるようになります。また、未認証ロールの正しい権限をセットアップする必要があります。IAM 権限のセットアップで、 authRole の代わりに amplify-<project_name>-<env_name>-<id>-unauthRole を更新します。IAM 権限のセットアップ方法の詳細は次のセクションで説明します。 IAM 権限の設定 認証機能の追加後、IAM ロールを少し変更する必要があります。 authRole に Amazon Rekognition Face Liveness サービスへのアクセス権を与える必要があります。このロールはフロントエンドの権限として使用されます。 console コマンドを実行して AWS コンソールを開きます。 $ amplify console マネジメントコンソールが開いたら、 IAM を検索して開きます。 Roles をクリックし、あなたのために作成された Amplify ロールを検索してクリックします。これは、 amplify-<project_name>-<env_name>-<id>-authRole という形式になっており、 <project_name> 、 <env_name> 、 <id> を自分の情報に置き換えて検索してください。 Add Permissions を選択し、 Create Inline Policy を選択し、 JSON タブを選択し、以下を貼り付けます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rekognition:StartFaceLivenessSession" ], "Resource": "*" } ] } これにより、Rekognition サービスの開始、作成、および結果の取得の権限のみが与えられます。次に Review Policy を選択し、 Create Policy を選択します。 AWS Lambda バックエンド 権限と認証の設定ができたので、バックエンドアプリケーションを作成しましょう。Express を実行する Node.js の AWS Lambda Function を使用して REST API を追加します。Express クライアントを使用して、いくつかのエンドポイントをセットアップし、顔検出の結果を取得します。 ターミナルを開き、add api コマンドを実行します。 $ amplify add api 以下のオプションを選択してください。必ず /session エンドポイントを追加し、テンプレートとして Serverless ExpressJS function を選択してください。選択したカテゴリのラベルを記録しておいてください。後ほどフロントエンドのコードと接続するときに必要になります。 ? Select from one of the below mentioned services: REST Provide a friendly name for your resource to be used as a label for this category in the project: ·liveness Provide a path (e.g., /book/{isbn}): · /session Only one option for [Choose a Lambda source]. Selecting [Create a new Lambda function]. ? Provide an AWS Lambda function name: liveness ? Choose the runtime that you want to use: NodeJS ? Choose the function template that you want to use: Serverless ExpressJS function (Integration with API Gateway) Available advanced settings: - Resource access permissions - Scheduled recurring invocation - Lambda layers configuration - Environment variables configuration - Secret values configuration ? Do you want to configure advanced settings? No ? Do you want to edit the local lambda function now? Yes API Gateway とLambda Function 用の新しいフォルダがいくつか生成されます。 新しいライブラリを追加することから始めていきましょう。 amplify/backend/function/liveness/src フォルダに移動し、以下のコマンドを実行して Rekognition クライアントの正しい依存関係をインストールします。 $ npm i @aws-sdk/client-rekognition 先ほど作成した関数を更新する必要があります。 amplify/backend/function/liveness/src フォルダに移動します。 utils フォルダを追加し、 getRekognitionClient.js という新しいファイルを作成します。 以下のコードを追加します。このコードは Amplify アプリケーションを設定し、新しい Rekognition クライアントを作成しています。 const { Rekognition } = require("@aws-sdk/client-rekognition"); const getRekognitionClient = () => { const rekognitionClient = new Rekognition({ region: 'us-east-1' }); return rekognitionClient; }; module.exports = getRekognitionClient; 上記のコードスニペットの region をあなたのリージョンに合わせて更新してください。リージョンはバックエンドとフロントエンドのコード間で一致していなければならず、 FAQ に示されているように、そのリージョンで liveness が利用可能でなければなりません。 amplify/backend/function/liveness/src フォルダで app.js ファイルを開いてください。いくつかの GET、POST、PUT、DELETE のサンプル関数が表示されます。サンプル関数は削除してかまいません。独自の関数を追加します。 ファイルの先頭に import を追加します。これで、先ほど作成したユーティリティ関数を取り込むことができます。 const getRekognitionClient = require("./utils/getRekognitionClient"); create エンドポイントと get エンドポイントを追加しましょう。 create エンドポイントは新しい Liveness セッションを作成し、フロントエンドに返却します。 get エンドポイントは信頼値を計算し、返却します。 app.get("/session/create", async function (req, res) { const rekognition = getRekognitionClient(); const response = await rekognition.createFaceLivenessSession({}); return res.status(200).json({ sessionId: response.SessionId, }); }); app.get("/session/get", async function (req, res) { const rekognition = getRekognitionClient(); const response = await rekognition.getFaceLivenessSessionResults({ SessionId: req.query.sessionId, }); const isLive = response.Confidence > 90; res.status(200).json({ isLive }); }); ここでは Confidence の値にのみ注目していますが、必要に応じて API から監査画像や参考画像の境界ボックスなど、他の値を取得することもできます。 この例では、信頼度スコアが 90 以上であれば、その画像は実際のユーザーのものであると判断します。これは厳密なルールではないので、アプリケーションやそのニーズに応じて信頼度を高くしたり低くしたりする必要があるかもしれません。また、バックエンドの他の部分に対する将来のリクエストを認可する方法として、信頼度 ( Confidence ) の値を使用することもできます。 最後に、正しいポリシーを設定する必要があります。こちらのファイルを開いてください。 amplify/backend/function/liveness/custom-policies.json こちらのポリシーを入力してください　。これで Lambda は Liveness セッションの作成と結果取得のみできるようになります。 [ { "Action": [ "rekognition:CreateFaceLivenessSession", "rekognition:GetFaceLivenessSessionResults" ], "Resource": ["*"] } ] このファイルを保存し、変更をプッシュアップしてください！ $ amplify push フロントエンドのコードに移りましょう！ Next.js フロントエンド バックエンドが完成したので、次はフロントエンドのサインアップページを作成します。 Amplify Authenticator コンポーネントと FaceLivenessDetector を使用して、このプロセスをより簡単にします。 Next.js を利用する Amplify の設定 _app.tsx ファイルを開き、以下のコードを追加しましょう。 import type { AppProps } from "next/app"; import { Amplify } from "aws-amplify"; import { withAuthenticator } from "@aws-amplify/ui-react"; import "@aws-amplify/ui-react/styles.css"; import awsExports from "../aws-exports"; Amplify.configure(awsExports); function App({ Component, pageProps }: AppProps) { return <Component {...pageProps} />; } export default withAuthenticator(App); withAuthenticator 高階コンポーネントは、アプリケーション全体をラップし、サインインしたユーザーだけが先に進めるようにします。また、 Amplify.configure(awsExports) を実行してフロントエンドを設定し、先ほど追加した AWS の認証サービスとやり取りができるようにします。最後に、 @aws-amplify/ui-react/styles.css からスタイルをインポートします。 Next アプリケーションを起動すると、このようなログインページが表示されます。 Authenticator 続けて、 src に components という新しいフォルダを作成し、その中に Liveness.tsx という新しいファイルを追加します。 以下のコードを追加します。 import { useEffect, useState } from "react"; import { Loader, Heading } from "@aws-amplify/ui-react"; import { FaceLivenessDetector } from "@aws-amplify/ui-react-liveness"; import { API } from "aws-amplify"; export function LivenessQuickStart() { const [loading, setLoading] = useState<boolean>(true); const [sessionId, setSessionId] = useState<{ sessionId: string; } | null>(null); const [success, setSuccess] = useState(''); useEffect(() => { const fetchCreateLiveness = async () => { const response = await API.get("liveness", "/session/create", {}); setSessionId(response); setLoading(false); }; fetchCreateLiveness(); }, []); const handleAnalysisComplete = async () => { const data = await API.get("liveness", "/session/get", { queryStringParameters: { sessionId: sessionId?.sessionId, }, }); if (data.isLive) { setSuccess("User is live"); console.log("live"); } else { setSuccess("User is not live"); console.log("not live"); } }; const handleError = (error: Error) => { console.log("got error", error); }; return ( <> {loading ? ( <Loader /> ) : ( <> <FaceLivenessDetector sessionId={sessionId?.sessionId ?? "1"} region="us-east-1" onAnalysisComplete={handleAnalysisComplete} onError={handleError} /> <Heading level={2}>{success}</Heading> </> )} </> ); } 上記コードの region をあなたが利用しているリージョンに合わせて変更してください。リージョンはバックエンドで使用しているものと同じでなければなりません。 このコードはページが読み込みされるとすぐに /session/create を呼び出し、セッション情報を取得して createLivenessApiData useState に保存します。また、ローディングスピナーも削除します。 liveness は、REST api を追加したときに設定した API Gateway の名前です。この文字列は、選択した API Gateway に合わせて自由に変更してください。この値は aws-exports ファイルの aws_cloud_logic_custom にも記載されています。 handleAnalysisComplete 関数は、 sessionId を使って /session/get エンドポイントを呼び出し、信頼度スコア を返します。これは、次に何をすべきか決定するのに役立ちます。 このチュートリアルでは、返されたスコアに応じて ユーザーがいるかユーザーがいないのか をコンソールログに出力します。実世界の状況では、これを別の方法で処理したくなるかもしれませんし、スコアが低すぎる場合はユーザーに再試行させたくなるかもしれません。 最後に、この新しい Liveness コンポーネントをアプリケーションに追加してみましょう。 index.tsx ファイルを開き、以下のコードを追加します。 import { LivenessQuickStart } from "@/components/Liveness"; import { Button, useAuthenticator, View } from "@aws-amplify/ui-react"; export default function Home() { const { signOut } = useAuthenticator((context) => [context.signOut]); return ( <View width="600px" margin="0 auto"> <LivenessQuickStart /> <Button onClick={signOut} variation="warning"> Sign Out </Button> </View> ); } 全部試してみましょう！ テストする すべてのコードを更新した後、Next アプリを起動し、 localhost:3000 を開いて Create Account タブをクリックし、新規ユーザーを作成します。 サインアップ後、このページが表示されます。 顔検証の手順 このページが表示されない場合は、このページに影響を与えている可能性があるグローバルスタイルをすべて消去する必要があるかもしれません。 Begin check ボタンをクリックします。すると、もっと近づくように指示されます。あなたの顔が楕円で完全に埋まるように、できるだけ近づいてください。 楕円状の顔チェック すべてがうまくいけば、いくつかのフラッシュが表示され、コンソールにスコアが返されます！ページを更新して再挑戦することもできます。 クリーンアップ アプリケーションの検証が終わったら、 amplify delete を実行することで全てのリソースを削除することができます。 まとめ このチュートリアルでは、Next.js と REST API を使って Amplify Face Liveness コンポーネントをセットアップする方法を見てきました。Liveness についてさらに学びたい場合は、 公式ドキュメント をご覧ください。そこから、 国際化対応 や テーマ設定 など、 FaceLivenessDetector コンポーネント を完全にカスタマイズする方法について学ぶことができます。 Amplify についてもっと知りたい方は ドキュメント をご覧ください。また、 AWS の無料枠 で Amplify を試すこともできます。 私についての情報は Twitter の ErikCH で見ることができます！ この記事は、 Detect real users with AWS Amplify and Face Liveness を翻訳したものです。 翻訳はSolutions Architect の Takuya Setaka が担当しました。

この記事は “ Top-10 re:Invent 2023 Announcements Important for Healthcare and Life Sciences ” を翻訳したものです。 時折、ビジネスの運営方法を根本的に変える新しいテクノロジーが登場することがあります。 しかし、適切なツール（制御、安全対策、ユーザーエクスペリエンス）がなければ、新しいテクノロジーがもたらす期待は行き詰まる可能性があります。 過去1年間、創薬、精密医療、医療提供体制に革命をもたらす生成系AIの可能性に多くの人が魅了されてきました。 しかし、どのようなツールがこの業界の運用を後押しするのでしょうか。 イノベーションの精神を持って生まれた AWS には、業界を変革してきた確かな実績があります。 私たちは、テクノロジースタックのさまざまなレベルにおけるお客様のニーズに合った、幅広く深いツールキットとイノベーションを連携させることの重要性を認識しています。 これらは、画期的な技術の進歩を具体的な生産性へと転換するために不可欠な要素です。 re:Invent 2023 で、AWS は生成系 AI の力を活用する新しいツールを発表しました。これにより、ヘルスケアおよびライフサイエンス業界の変革が可能になります。 これらのツールにより、ビルダーやビジネスユーザーは、エンタープライズデータ用の AI アシスタントから、アプリケーションオーケストレーションエージェント、マルチモデル評価、チューニングや継続的なトレーニングまで、あらゆる段階で生成系 AI を活用できます。しかもコーディングは不要です。 これらは、オペレーション保護機能を備えたツールキットにパッケージ化されており、IDE、ビジネスインテリジェンスダッシュボードなど、業界で現在使用されているツールとの統合や、AWS コンソールへの直接的な統合が可能です。生成系 AI は、マルチモーダルで多様なプライベートなヘルスケアとライフサイエンスのデータセットが蓄積され、それを支えるデータ基盤が役立つのと同じくらい重要であると考えています。 だからこそ、今年導入された AI ツールとともに、AWS は新しい AI アプリケーションの需要を満たすために、データストレージ、データガバナンス、データコラボレーションの分野でさらにサービスを成熟させてきました。 今年開始されたサービスにより、生成系 AIを適用して医療従事者のワークフロー、患者体験、医療画像診断、ライフサイエンスの研究開発プロセス、臨床試験、バイオマニュファクチャリング、商業化を進化させるのにかかる時間が大幅に短縮されます。 実際、ライフサイエンス業界の 2 人の業界リーダーから、すでに AWS で生成系 AI を使用してビジネス部門、研究開発、顧客エンゲージメントを向上させているという話を伺うことができました。 ファイザー社の最高デジタル・技術責任者である Lidia Fonseca 氏が、CEO のアダム・セリプスキーと共にステージに上がり、同社が人工知能 ( AI ) と AWS をどのように活用して、2022 年に 13 億人を超える人々に医薬品とワクチン治療を提供する規模を達成したかについて話し合いました。 フォンセカ氏は、ファイザー社がどのようにしてデータを一元化し、強力なAI人材を育成し、クラウドで安全なグローバル基盤を構築し、年間数千万ドルの節約を実現したかを示しています。 ファイザー社 と AWS は、科学者がデータをより簡単かつ迅速に検索できるように、何百もの実験機器からのデータを集約する科学データクラウドを開発しました。 ファイザー社は AWS で、Amazon SageMaker と Amazon Bedrock の大規模言語モデルを使用する生成系 AI ソリューションである VOX を構築しました。これにより、研究開発を加速し、製品の生産量を予測し、より多くの医薬品を患者に届けることができます。 その基調講演は、こちらの オンデマンド配信 で視聴可能です、また、セッションの重要な 3 つのキーポイントはこちらの ブロク で確認することができます。 また、ギリアド社の Chief Innovation Officer である Marc Berson 氏が、AWS Director of Technology for Industries and Strategic Accounts である Shaown Nandi に加わり、生成系 AI が彼らの組織における新しい治療法の開発を加速させるのにどのように役立っているかについて語ってくれました。イノベーションセッションの動画は、こちらの オンデマンド配信 でご覧ください。 HCLS業界における新発表トップ10: 1. AWS HealthScribe は、生成系 AI を使用して患者と臨床医の会話から臨床記録を自動的に作成します。 患者の診察内容を書き起こし、予備的な臨床メモを生成し、インサイトを抽出することで、臨床医は診察の要点をすばやく再確認でき、内容の提案を簡単に承認、拒否、編集できます。 AI が生成するサマリーステートメントにはすべて、追跡可能な書き起こし資料が付属しているため、臨床医や筆記者は簡単に正確性を参照元と照らし合わせ検証でき、インサイトが生成されたソースを突き止めることができます。 医療業界向けに特別にトレーニングされた会話と生成系 AI サービスを統合して実装を簡素化します。 詳しくはこちらの ブログ をご覧ください。 HealthScribe は、 AWS HealthOmics 、 AWS HealthImaging 、 AWS HealthLake 、 Amazon Comprehend Medical など、増え続けるヘルスケアとライフサイエンスに焦点を当てたサービスのポートフォリオに加わりました。実際、AWS の CTO である Werner Vogels 氏が、基調講演で AWS HealthImaging と、それを使用して放射線科医のワークフローを改善する方法について取り上げているのを見ました。 基調講演セッションは、こちらの オンデマンド配信 から視聴できます。 2.&nbsp; Amazon Bedrock Agents を使用すると、生成系 AI アプリケーションが会社のシステムやデータソース全体で多段階のタスクを実行できます。 これにより、ヘルスケアとライフサイエンス全体で、医療システム、研究データベース、臨床試験システム、商用データベースなどの企業知識を必要とするタスクを自動化する機会が開かれ、それらのシステムへの組織的なアクセスが可能になります。 研究者にとっては、これを利用して、新しい研究プロジェクトに着手する前に、ある組織で実施された過去の研究を幅広く内部調査することができます。 臨床検査ラボや医療機関の場合、複数のトランザクションソフトウェアシステムとのやり取りを必要とする研究メンバーや患者の登録に使用できます。 バイオ薬品メーカーにとっては、これを利用して、さまざまなシステムにまたがるサプライチェーンの多段階の作業指示を自動化できます。 保険者の場合は、これを使用して複数段階の承認プロセスを自動化するアプリケーションを開発できます。 詳しくはこちらの ブログ のアナウンスをご覧ください。 Bedrock Agents は、新しい Bedrock Knowledge Bases と連携して、検索拡張生成 (RAG) を使用して情報を合成、要約、レコメンドするアプリケーションを作成しています。 詳しくはこちらの ブログ をご覧ください。 ヘルスケア、生物医学、生物学、化学における独自のデータモダリティを反映したカスタムモデルを構築したいデータサイエンスチームにとって、 Bedrock のファインチューニングと継続的な事前学習 はプロセスを簡素化します。 詳しくはこちらの ブログ の発表をご覧ください。 さらに、Amazon Bedrock では、単一の API でアクセスできる新しいモデルが追加されました。 Anthropic の Claude 2.1 では、長さが最大 200,000 トークン (約 500 ページの文書) の生物医学または研究のプロンプトを送信できます。詳しくはこちらの ブログ の発表をご覧ください。 Titan Multimodal Embeddings モデルでは、医療画像一式、臨床検査結果、医療記録など、さまざまな生物医学データを一度に提示できます。 詳しくはこちらの ブログ をご覧ください。 3. Amazon Q (プレビュー) は、お客様のビジネス、データ、コード、運用を理解するように設計された AI アシスタントで、モデルとデータを組織にとって安全に保つためのエンタープライズコントロールを備えています。 ヘルスケアおよびライフサイエンスのビジネスユーザーの場合、Amazon Q はプライベートデータセットまたはエンタープライズソフトウェアに接続して、臨床試験の臨床所見の分析、大量の研究開発データにわたる傾向の発見、製造記録からの要約の作成、コンプライアンス調査の準備などのタスクを実行できます。 詳細については、こちらの ブログ 発表をご覧ください。 ビジネスアナリスト にとって、QuickSight の Amazon Q は、データを調べ、重要な洞察をエグゼクティブサマリーにまとめ、ダッシュボードでは答えられないデータに関する質問に自信を持って答えることで、説得力のあるストーリーを生み出すことができます。詳しくはこちらの ブログ 発表をご覧ください。 開発者や IT プロフェッショナル にとって、Amazon Q は AWS でのアプリケーションの構築、ベストプラクティスの調査、エラーの解決、アプリケーションの新機能のコーディングに関する支援の提供を開始するのに役立ちます。 詳細については、こちらの ブログ 発表をご覧ください。 4. Amazon DataZone (プレビュー) 向けの新しい生成系 AI 機能 。 HCLS のお客様は、研究、臨床、製造、商業の各分野にわたって、大規模で複雑で増え続けるデータ資産を所有しています。 トレンド、合併、買収、売却によるビジネスの変化に伴い、メタデータとデータの理解は失われてしまいます。 このメタデータを手動で作成するのは、面倒で費用のかかる作業です。 DataZoneでの記述に関する AI レコメンデーションは、生成系 AI を使用して分析に必要なデータテーブルと列を特定し、データを見つけやすくします。 これにより、データ利用者 (データアナリスト、データエンジニア、データサイエンティストなど) は、よりコンテキスト化されたデータをすぐに利用して、分析に役立てることができます。 また、詳細な説明、考えられるユースケース、主要な列に基づいて検索結果が表示されるようになったため、説明が自動生成され、より充実した検索が可能になります。詳しくはこちらの ブログ 告知をご覧ください。 5. AWS Clean Room ML Differential Privacy (プレビュー) 。基礎となるデータを共有することなく、パートナーと機械学習を適用できます。 企業が類似する人口セグメントを作成するのを支援するために特化した最初のモデルをご紹介します。 AWS Clean Rooms ML lookalike を使用すると、独自のカスタムモデルをトレーニングできます。また、パートナーにレコードの少量のサンプルを持ち込んでもらい、協力して類似レコードのセットを拡張して作成してもらうことができます。しかも、全員の基盤となるデータを保護できます。 本日、これはマーケティングユースケース向けにリリースされ、今後数か月以内にヘルスケアモデルをリリースする予定です。 ユーザーは、今すぐこのサービスを試してみることから始めることができます。 詳しくはこちらの ブログ をご覧ください。 さらに、AWS Clean Rooms Differential Privacy は、ユーザーの再識別を防ぐのに役立つ新しいフルマネージド機能です。 これにより、コラボレーションに関するインサイトにおける個人のデータの寄与度がわかりにくくなります。 詳しくはこちらの ブログ をご覧ください。 &nbsp;6. NVIDIA が BioNemo を AWS に導入 : 創薬のための生成系 AI プラットフォームである NVIDIA BioNemo が Amazon SageMaker で利用できるようになりました。 これにより、製薬会社は自社のデータを使用してモデルのトレーニングを簡素化および迅速化できるため、創薬を加速できます。 詳しくはこちらの ブログ をご覧ください。 NVIDIA は、 ホスト型クラウドサービスとして MONAI も提供するようになりました。 NVIDIA MONAI クラウド API により、ソリューションプロバイダーは自社の医療画像プラットフォームに AI をより簡単に統合できるようになり、放射線科医、研究者、臨床試験チームがドメインに特化した AI モデルを構築するための強力なツールを提供できるようになります。 詳しくはこちらの ブログ 発表をご覧ください。 7. SageMaker Canvas による 基盤モデルのファインチューニングと自然言語データの準備をコードなしで行えます。 医療機関やライフサイエンス組織には、一般的な基盤モデルのトレーニングにはない独自の語彙があります。同時に、ファインチューニングをサポートする専任のデータサイエンスチームが不足しているお客様も多くいます。 Amazon SageMaker Canvas のこの新しい機能は、コーディング不要のアプリケーションでこのギャップを効果的に埋めます。 SageMaker Canvas は、コードを記述しなくてもモデルのファインチューニングと評価を実行できるようになりました。 詳しくはブログのアナウンスをご覧ください。 さらに、コードを使わずにデータを探索して準備したい HCLS のデータアナリストやデータサイエンティストは、Canvas の基盤モデルを利用した自然言語命令をデータの探索、分析、視覚化、変換に使用できるようになりました。 詳しくはこちらの ブログ 発表をご覧ください。 ヘルスケアやライフサイエンスのデータに基づいてまったく新しい基盤モデルを構築することが目標であれば、Amazon SageMaker HyperPod は大規模な分散トレーニングのための専用インフラストラクチャです。 SageMaker HyperPods は分散型トレーニング用のマネージドインフラストラクチャを提供するため、より迅速で費用対効果の高い FM トレーニングが可能になります。 また、クラスタの状態をアクティブに監視し、障害のあるノードを交換してチェックポイントからモデルトレーニングを再開することで、ノードとジョブの復元を自動化する監視機能も備えています。 詳しくはブログのアナウンスをご覧ください。 8. Amazon Neptune Analytics. ヘルスケアとライフサイエンスのデータチームは、データ間の関係を理解し、相関研究を行うためにナレッジグラフを作成しています。 データをグラフに保存することと分析を行うことは、別々の科学ツール、かつ複雑なパイプラインが必要で、 2 つのステップに分かれているためその運用が非常に困難でした。 Neptune Analytics では、グラフを保存して分析を実行するためのツールが 1 つになり、以前の AWS ソリューションと比較して 80 倍の速度が向上しています。 詳しくはこちらの ブログ をご覧ください。 他の種類のデータストアに基づいてナレッジベースを構築する場合、 Amazon OpenSearch Serverles 用の新しいベクトルエンジン、 Amazon DocumentDB 用のベクトル検索、 Amazon MemoryDB for Redis 用のベクトル検索を使用すると、基盤となるベクターデータベースインフラストラクチャを管理しなくても RAG アプリケーションを簡単に構築できます。 詳細については、次のブログシリーズをご覧ください。 ブログ 1 | ブログ 2 | ブログ 3 9. HCLS コンピューティングの進歩 EC2 Capacity Blocks for ML &nbsp;により、研究チームやデータサイエンスチームは Amazon EC2 P5 インスタンス の使用を将来の開始日に備えて予約することができます。 これにより、ヘルスケアチームとライフサイエンスチームは、信頼できる予算と時期の情報をもとに、LLM のテストと微調整を行うことができます。 詳しくはこちらの ブログ 発表をご覧ください。 Graviton4 は、現行世代の Graviton3 プロセッサーよりもコンピューティング性能が最大 30%、コア数が 50%、メモリ帯域幅が 75% 向上し、電子医療記録 (EHR) システムなどのワークロードにおいて最高のコストパフォーマンスとエネルギー効率を実現します。 新しい Graviton4 プロセッサを搭載した新しい Amazon EC2 R8g (プレビュー) インスタンスは、既存のメモリ最適化インスタンスよりも優れたコストパフォーマンスを実現します。 R8g インスタンスは、ビッグデータ分析、高性能データベース、インメモリキャッシュなど、最も要求の厳しいメモリ集約型ワークロードに適しています。 詳しくはこちらの ブログ 発表をご覧ください。 Trainium2 は、第 1 世代の Trainium チップよりも最大 4 倍速いトレーニングを実現するように設計されており、最大 100,000 チップの EC2 UltraClusters にデプロイできるため、ファンデーションモデル (FM) と大規模言語モデル (LLM) を短時間でトレーニングでき、エネルギー効率も最大 2 倍向上できます。 詳しくはこちらの ブログ をご覧ください。 10. HCLS ストレージの進歩 Amazon S3 Express One Zone は、S3 オブジェクトへの高速アクセスを必要とする HPC ワークロードを高速化し、コストを削減します。 これは、ゲノミクス、画像処理、シミュレーション、機械学習など、最も要求が厳しく、計算集約型の HCLS アプリケーションに必要なパフォーマンスを提供する新しいストレージクラスです。 1 桁ミリ秒という耐久性に優れたレイテンシーにより、お客様は EC2、EKS、ECS のコンピューティングリソースと同じアベイラビリティーゾーンにストレージを共存させることができます。 POSIX 権限をまだ必要とするワークロードでは、Amazon FSx for Luster が依然として優れた代替手段です。 詳しくはこちらの ブログ 発表をご覧ください。 Amazon FSx for NetApp ONTAP scale-out file systems。 HCLS のお客様の多くが、エンタープライズファイルストアを提供するために NetApp ONTAP のデプロイを設定、実行、スケーリングしています。 これで、フルマネージドでフル機能の ONTAP ファイルシステムをクラウドで起動して実行できるようになりました。 詳しくはこちらの ブログ 発表をご覧ください。 AWS EBS Snapshots Archive は、頻繁または高速に取得する必要のない、めったにアクセスされないスナップショット向けの低コストで長期にわたるストレージ階層で、ストレージコストを最大 75% 節約できます。詳しくはこちらの ブログ 発表をご覧ください。 Amazon EFS Archive は、1 年に数回またはそれ以下の頻度でアクセスされる長期間有効なファイルデータ向けにコストが最適化された新しいストレージクラスです。 詳しくはこちらの ブログ 発表をご覧ください。 re: Invent ブレイクアウトセッションのすべての動画は、以下のオンデマンド配信で視聴することができます。 ヘルスケアセッションの配信: HLC202 | Reimaging healthcare delivery by migration critical workloads- featuring Geisinger HLC204 | Improving patient outcomes using generative AI in healthcare – featuring UC San Diego Health HLC305 | Building a medical research platform with AWS HealthOmics – featuring Stanford AMZ204 | Beyond the EHR –Delivering timely, accessible care with One Medical – featuring One Medical CON320 | Building for the future with AWS serverless services – featuring Children’s National Hospital AIM213 | Enhance your document workflows with generative AI – featuring Centene IMP205 | Modern digital experiences to accelerate mission impact – featuring National Marrow Donor Program BIZ103 | How the U.S. Army uses AWS Wickr to deliver lifesaving telemedicine – featuring NETCCN IMP208 | Using data to prevent heart disease and sudden cardiac death – featuring Memorial Hermann Health System ライフサイエンスセッションの配信: LFS202 | Accelerating life sciences innovation with generative AI on AWS – featuring Gilead LFS203 | Building a life science data strategy to accelerate insights – featuring Johnson &amp; Johnson API310 | Scale interactive data analysis with Step Functions Distributed Map – featuring Vertex Pharmaceuticals BSI203 | Enhance your applications with Amazon QuickSight Embedded Analytics – featuring Honeywell Life Sciences ANT331 | Build an end-to-end data strategy for Analytics and Generative AI NTA204 | Accelerate your digital transformation with a robust cloud foundation – featuring Bristol Myers Squibb NTA213 | 0 to 25 PB in one year – featuring Caris Life Sciences AIM215 | Omics Innovation with AWS HealthOmics – Amgen’s Path to Faster Results – featuring Amgen AIM222 | Amazon Lex reshapes CX with conversational workflows and generative AI – featuring Abbott 先週のヘルスケア・ライフサイエンス分野のトップニュース: AWS and Accenture help Merck use cloud technology to reduce drug discovery time and accelerate clinical trial development. AWS joins forces with Amge n on generative AI solutions to accelerate advanced therapies. Apollo Previews New Version of its Multi-Disciplinary Medical Imaging Platform at RSNA 2023 Annual Meeting Pieces Pioneers “Sculpted AI” for Health Systems using Amazon Bedrock Baptist Memorial Health Care Selects Optimum Healthcare IT &amp; AWS for EHR Cloud Implementation EVERSANA Builds on Commitment to “Pharmatize” AI with Amazon Web Services, Introduces Transformative Medical &amp; Regulatory Review Solution Smart Reporting integrates LLM Technology built on AWS HOPPR foundation model for medical imaging. First medical imaging foundation model built on AWS. Philips launches HealthSuite Imaging, a cloud-based next generation of Vue PACS, with new AI-enabled clinical and operational workflows Radiology Partners Launches AI Integration Platform with AWS HealthImaging UK BioBank- World’s largest genetic project opens the door to new era for treatments and cures. Watch video here 非常に忙しい一週間でした。今後、re: Invent 2023 のエキサイティングな発表、ビデオ、サマリをお届けできることを楽しみにしています。それまでの間、ヘルスケアとライフサイエンスにおける生成系 AIの詳細については、次の Web サイトをご覧ください。 https://aws.amazon.com/health/gen-ai/ <!-- '"` --> Kelli Jonakin, Ph.D. Kelli Jonakin は、AWS のヘルスケア、ライフサイエンス、ゲノミクス業界のマーケティング担当ワールドワイドヘッドです。彼女は製薬研究のバックグラウンドを持ち、特にバイオ医薬品の開発とコマーシャルに重点を置いています。Kelli はコロラド大学で薬理学とシステム生物学の博士号を取得し、NIHのポスドク研究員としてウィスコンシン大学マディソン校で生化学を学びました。 Lee Tessler Lee Tessler, Ph.D. は、AWS のヘルスケアおよびライフサイエンス業界の主任技術ストラテジストです。研究開発、臨床試験、製造、患者エンゲージメントをモダナイズするためのクラウドアーキテクチャに焦点を当てています。AWS に入社する前は、バイオインフォマティクス、創薬、診断、ラボ機器、医薬品製造の分野で製品を発売していました。Lee は、セントルイスのワシントン大学で計算生物学の博士号を、ブラウン大学で理学士号を取得しています。 Chris McCurdy Chris McCurdy はグローバルソリューションアーキテクト兼マネージャーであり、アーキテクチャ、開発、チームリーダーとして 20 年以上にわたって実践的な経験を積んできました。過去 10 年以上にわたり、ヘルスケアおよびライフサイエンス業界の成功に注力してきました。彼はGxP/HIPAA コンプライアンスおよび IoT および AI/ML テクノロジーのエバンジェリストです。 James Wiggins James Wiggins は AWS のシニアヘルスケアソリューションアーキテクトです。彼は、テクノロジーを活用して組織が世界の健康にプラスの影響を与えるのを支援することに情熱を注いでいます。また、妻と3人の子供と過ごす時間も大好きです。 翻訳は Senior Business Development Manager の亀田が担当しました。

私たちは9 月に、 Amazon Bedrock のナレッジベースをプレビュー版として導入 しました。11月28日より、 Amazon Bedrock のナレッジベース が一般公開されました。 ナレッジベースを使用すると、 Amazon Bedrock の基盤モデル (FM) を社内のデータに安全に接続して、検索拡張生成 (RAG) を行うことができます。追加データにアクセスすると、FM を継続的に再トレーニングすることなく、モデルがより関連性が高く、コンテキスト固有の正確な応答を生成できます。ナレッジベースから取得するすべての情報には、透明性を高め、ハルシネーションを最小限に抑えるためのソース属性が付いています。これがどのように機能するのか興味がある場合は、RAGの入門書を含む私の 以前の投稿 をチェックしてみてください。 11月28日のリリースにより、フルマネージド型の RAG の体験や、Amazon Bedrock で RAG を使い始める最も簡単な方法がナレッジベースで提供されます。ナレッジベースは、ベクトルストアの初期設定を管理し、埋め込みとクエリを処理し、本稼働の RAG アプリケーションに必要なソースアトリビューションと短期記憶を提供するようになりました。必要に応じて、特定のユースケース要件に合わせて RAG ワークフローをカスタマイズしたり、RAG を他の人工知能 (AI) ツールやアプリケーションと統合したりすることもできます。 フルマネージド RAG エクスペリエンス Amazon Bedrock のナレッジベースが、お客様に代わってエンドツーエンドの RAG ワークフローを管理します。データの場所を指定し、データをベクトル埋め込みに変換する埋め込みモデルを選択し、Amazon Bedrockにベクトルストアを作成してベクトルデータを保存します。このオプションを選択すると (コンソールでのみ選択可能)、Amazon Bedrock がアカウントの Amazon OpenSearch Serverless にベクトルインデックスを作成します。ユーザーが何かを管理する必要はありません。 ベクトル埋め込みには、ドキュメント内のテキストデータの数値表現が含まれます。それぞれの埋め込みは、データのセマンティックまたはコンテキスト上の意味を捉えることを目的としています。Amazon Bedrock は、ベクトルストアへの埋め込みの作成、保存、管理、更新を行い、データが常にベクトルストアと同期することを保証します。 Amazon Bedrock は、埋め込みとクエリを処理し、本稼働の RAG アプリケーションに必要なソースアトリビューションと短期記憶を提供する、RAG 用の 2 つの新しい API もサポートするようになりました。 新しい RetrieveAndGenerate API の使用すれば、API 呼び出しで FM を指定して、ナレッジベースから関連情報を直接取得し Amazon Bedrock で結果から応答を生成できるようになります。これがどのように機能するかをお見せしましょう。 RetrieveAndGenerate API を使用する これを試すには、 Amazon Bedrock コンソール に移動し、ナレッジベースを作成して選択し、 [ナレッジベースをテスト] を選択します。このデモでは、 AWS の生成系 AI の PDF にアクセスするナレッジベースを作成しました。FM を指定するには、 [モデルを選択] で行います。 そこで、「アマゾン・ベッドロックとは?」と聞きます。 Amazon Bedrock は、背後でクエリを埋め込みに変換し、ナレッジベースにクエリを実行して、FM プロンプトに検索結果をコンテキスト情報として追加し、私の質問に対する FM 生成の回答を返します。複数の会話では、ナレッジベースが会話の短期メモリを管理して、よりコンテキストに沿った結果を提供します。 これは、 AWS SDK for Python (Boto3) で API を使用する方法の簡単なデモです。 def retrieveAndGenerate(input, kbId): return bedrock_agent_runtime.retrieve_and_generate( input={ 'text': input }, retrieveAndGenerateConfiguration={ 'type': 'KNOWLEDGE_BASE', 'knowledgeBaseConfiguration': { 'knowledgeBaseId': kbId, 'modelArn': 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-instant-v1' } } ) response = retrieveAndGenerate("Amazon Bedrock とは何ですか?", "AES9P3MT9T")["output"]["text"] RetrieveAndGenerate API の出力には、生成された応答、ソース属性、および取得されたテキストのチャンクが含まれます。私のデモでは、API 応答は次のようになります (簡潔にするために出力の一部が編集しています) 。 { ... 'output': {'text': 'Amazon Bedrock は、AWS のマネージド サービスで…'}, 'citations': [{'generatedResponsePart': {'textResponsePart': {'text': 'Amazon Bedrock は…', 'span': {'start': 0, 'end': 241}} }, 'retrievedReferences': [{'content': {'text': 'すべての AWS 管理サービス API アクティビティ...'}, 'location': {'type': 'S3', 's3Location': {'uri': 's3://data-generative-ai-on-aws/gaia.pdf'}}}, {'content': {'text': '...を使用して画像の一部を変更します。'}, 'location': {'type': 'S3', 's3Location': {'uri': 's3://data-generative-ai-on-aws/gaia.pdf'}}}, ...] ...}] } 生成された応答は以下のようになります。 Amazon Bedrock は、シンプルな API を介して生成系 AI のサーバーレスエクスペリエンスを提供するマネージドサービスです。テキスト生成、画像生成、会話型エージェントの構築などのタスクのために、Amazon やサードパーティの基盤モデルにアクセスできます。Amazon Bedrock を介して処理されたデータはプライベートで暗号化されます。 RAG ワークフローをカスタマイズする 取得したテキストのチャンクをさらに処理したり、検索結果の関連性スコアを確認したり、テキスト生成のための独自のオーケストレーションを開発したりする場合は、新しい Retrieve API を使用できます。この API は、ユーザークエリを埋め込みに変換し、ナレッジベースを検索し、関連する結果を返すため、セマンティック検索結果に基づいてカスタムワークフローをより詳細に構築できます。 Retrieve API を使用する Amazon Bedrock コンソールで、スイッチを切り替えて [応答を生成] を無効にします。 そして、もう一度「アマゾン・ベッドロックとは?」と聞きます。 今回、この出力には、テキストチャンクの元であるソースドキュメントへのリンクを含む検索結果が表示されます。 boto3 で Retrieve API を使用する方法は次のとおりです。 import boto3 bedrock_agent_runtime = boto3.client( service_name = "bedrock-agent-runtime" ) def retrieve(query, kbId, numberOfResults=5): return bedrock_agent_runtime.retrieve( retrievalQuery= { 'text': query }, knowledgeBaseId=kbId, retrievalConfiguration= { 'vectorSearchConfiguration': { 'numberOfResults': numberOfResults } } ) response = retrieve("Amazon Bedrock とは何ですか?", "AES9P3MT9T")["retrievalResults"] Retrieve API の出力には、取得したテキストチャンク、ソースデータのロケーションタイプと URI、および取得のスコアが含まれます。スコアは、クエリとより厳密に一致するチャンクを判断するのに役立ちます。 私のデモでは、API 応答は次のようになります (簡潔にするために出力の一部が編集しています) 。 [{'content': {'text': '...を使用して画像の一部を変更します。'}, 'location': {'type': 'S3', 's3Location': {'uri': 's3://data-generative-ai-on-aws/gaia.pdf'}}, 'score': 0.7329834}, {'content': {'text': '自然言語でユーザーに返します。...の場合'}, 'location': {'type': 'S3', 's3Location': {'uri': 's3://data-generative-ai-on-aws/gaia.pdf'}}, 'score': 0.7331088}, ...] RAG ワークフローをさらにカスタマイズするには、カスタムチャンク戦略を定義し、カスタムのベクトルストアを選択できます。 カスタムチャンク戦略 — データから効果的に取得できるようにするには、まずドキュメントを管理しやすいチャンクに分割するのが一般的です。これにより、情報をより効果的に理解して処理するモデルの能力が強化されるため、関連性の高い検索と一貫した応答の生成を改善できます。Amazon Bedrock のナレッジベースは、大量のドキュメントを管理します。 ナレッジベースのデータソースを設定するときに、チャンク戦略を定義できるようになりました。デフォルトのチャンキングは、データを最大 200 トークンのチャンクに分割し、質疑応答のタスクに最適化されています。データの最適なチャンクサイズがわからない場合は、デフォルトのチャンキングを使用してください。 また、カスタムのチャンクサイズを指定して、固定サイズのチャンクとオーバーラップさせることもできます。データの最適なチャンクサイズとオーバーラップ (ファイル属性、精度テストなどに基づく) がわかっている場合は、固定サイズのチャンキングを使用してください。チャンク間のオーバーラップが 0～20 パーセントの推奨範囲にあると、精度を向上させることができます。オーバーラップ率が大きいほど、関連性スコアが低下する可能性があります。 ドキュメントごとに 1 つの埋め込みを作成することを選択した場合、ナレッジベースでは各ファイルが 1 つのチャンクとして保持されます。Amazon Bedrock にデータをチャンクさせたくない場合は、このオプションを使用してください。例えば、ユースケースに固有のアルゴリズムを使用してデータをオフラインでチャンクしたい場合などに使用します。一般的なユースケースには、コードドキュメントが含まれます。 カスタムベクターストア — カスタムベクトルストアを選択することもできます。利用可能なベクトルデータベースのオプションには、 Amazon OpenSearch Serverless 用ベクトルエンジン 、 Pinecone 、 Redis Enterprise Cloud が含まれます。カスタムのベクトルストアを使用するには、サポートされているオプションのリストから新しい空のベクトルデータベースを作成し、ベクトルデータベースのインデックス名とインデックスフィールドとメタデータフィールドのマッピングを指定する必要があります。このベクトルデータベースは Amazon Bedrock 専用である必要があります。 RAG を他の生成系 AIツールやアプリケーションと統合する 多段階のタスクを実行し、会社のデータソースにアクセスして、より関連性が高くコンテキストを認識した応答を生成できる AI アシスタントを構築したい場合は、 Agents for Amazon Bedrock とナレッジベースを統合できます。 LangChain 用のナレッジベース取得プラグインを使用して、RAG ワークフローを生成系 AI アプリケーションに統合することもできます。 可用性 Amazon Bedrock のナレッジベースは現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。 詳細はこちら Amazon Bedrock のナレッジベース ナレッジベースのユーザーガイド コンソールの Amazon Bedrock –&nbsp; Antje 原文は こちら です。

11月27日、デジタル主権の要件を満たすのに役立つ 65 の一連の専用コントロールを AWS Control Tower に追加しました。 デジタル主権とは、デジタルアセットのコントロールであり、データレジデンシー、データが流れる場所、データの管理者を制御することをいいます。17 年前に AWS クラウドが 生み出されて 以来、当社は、お客様がデータを管理できるよう取り組んできました。 2022年 11 月、弊社は AWS Digital Sovereignty Pledge を立ち上げました。これは、クラウドで使用可能な一連の最先端の主権コントロールおよび機能を、AWS のすべてのお客様に提供するという当社のコミットメントです。それ以来、当社は、その方向性に基づいて、いくつかのステップを発表してきました。 AWS Nitro System は独立した第三者によって検証されており 、AWS のいかなる者も、AWS のホスト上のデータにアクセスできるメカニズムが含まれていないことが確認されています。当社は AWS 専有ローカルゾーン を立ち上げました。これは、AWS によって完全に管理されるとともに、お客様またはコミュニティ専用となるように構築され、お客様が指定した場所またはデータセンターに配置されるインフラストラクチャの一部です。そして最近では、新しい 欧州の独立主権リージョン の創設を発表しました。 デジタル主権をサポートする AWS Control Tower コントロールの導入は、データレジデンシー、きめ細かなアクセス制限、暗号化、回復力の機能のロードマップにおける追加のステップです。 AWS Control Tower は、安全なマルチアカウントの AWS 環境を設定および統制するためのシンプルかつ効率的な方法を提供します。これにより、ベストプラクティスのブループリントに基づいた ランディングゾーン が確立され、事前にパッケージ化されたリストから選択できるコントロールを使用してガバナンスを実現できます。ランディングゾーンは、 Well-Architected で、 AWS のベストプラクティス に準拠したマルチアカウントベースラインです。 コントロール は、セキュリティ、コンプライアンス、運用に関するガバナンスルールを実装します。 デジタルアセットに必要なコントロールのレベルは、業界や国によって大きく異なります。高度に規制された分野で事業を展開しているお客様は、欧州連合などの特定の国または地域にデータを維持する義務を負っている場合があります。データ暗号化や暗号化キーの保管場所などに関連する義務を負っているお客様もいます。さらに、デジタル主権の要件は急速に進化しており、必要なすべてのコントロールを定義して実装することが困難になっています。多くのお客様から、AWS の全サービスを活用するか、またはイノベーション、変革、成長の妨げになる可能性がある、機能が限定されたソブリンクラウドソリューションのいずれかを選択する必要があるのではないかという懸念の声が寄せられています。当社は、お客様がこのような選択をする必要はないと確信しています。 AWS Control Tower は、データの保存場所、転送先、処理される場所を大規模に管理するために必要なコントロールを定義、実装、管理するのにかかる時間を短縮するのに役立ちます。 AWS Control Tower は、有効なコントロール、コンプライアンスステータス、および複数のアカウントにわたるコントロールの証拠についての統合ビューを提供します。この情報は、コンソールで、または API を呼び出すことで確認できます。要件と AWS サービスが進化する中で、AWS Control Tower は、デジタル主権のニーズを継続的に管理するのに役立つ最新のコントロールを提供します。 追加されたコントロールの例をいくつかご紹介します。 オペレーターアクセス – Amazon Elastic Compute Cloud (Amazon EC2) 専有ホストが AWS Nitro インスタンスタイプを使用することを必須化します。 データに対するアクセスのコントロール – Amazon Elastic Block Store (Amazon EBS) スナップショットをパブリックに復元できないようになっていることを必須化します。 保管中および転送中の暗号化 (高度なキー管理戦略を含む) – EC2 インスタンスが AWS::EC2::Instance リソースタイプを使用して作成された場合に、インスタンス間の転送中の暗号化をサポートする AWS Nitro インスタンスタイプを使用することを必須化します。また、 Amazon Relational Database Service (Amazon RDS) データベースインスタンスで、サポートされているエンジンタイプのために指定した AWS KMS キーを使用するように保管中の暗号化が設定されていることを必須化します。 これらは 3 つのカテゴリからの 4 つの例にすぎません。65 の新しいコントロールが追加され、デジタル主権カテゴリグループでは 245 を超えるコントロールを使用できます。 詳細なリストは、AWS Control Tower のドキュメントでご覧いただけます 。 リージョン内での意図しないデータの保存やフローを防ぐために AWS Control Tower が使用する技術メカニズムの 1 つが、 リージョン拒否コントロール です。このパラメータを使用すると、システム管理者は、選択した AWS リージョンでの AWS サービスおよびオペレーションに対するアクセスを拒否できます。今日まで、リージョン拒否コントロールが適用できたのは、 ランディングゾーン 全体と、そのすべての組織単位 (OU) およびアカウントのみでした。このリリースにより、組織単位レベルで新しいリージョン拒否コントロールを設定し、独自のビジネスニーズに基づいて許可するサービスと IAM プリンシパルを選択できるようになりました。 開始方法を見てみましょう このデモでは、一連のリージョンで AWS サービスに対するアクセスを制限したいと考えていると仮定してみましょう。 AWS マネジメントコンソール を開き、 AWS Control Tower のページ に移動します。左側のナビゲーションウィンドウの [コントロールライブラリ] で、 [カテゴリ] &gt; [グループ] &gt; [デジタル主権] を選択します。 使用可能なコントロールのリストを確認できます。 有効にするコントロールを見つけて選択します: [組織単位についてリクエストされた AWS リージョンに基づいて AWS に対するアクセスを拒否] 。このコントロールの説明と、それが適用されるフレームワークのリスト( NIST 800 および PCI DSS ) が表示されます。 [コントロールを有効にする] を選択します。 次のページで、このコントロールを有効にする [組織単位] (OU) を選択します。 アクセスを許可する AWS [リージョン] を選択します。チェックがオフになっているすべてのリージョンでは、コントロールが強制されるとアクセスが拒否されます。 その後、サービスコントロールポリシー (SCP) を確認します。これには、リストされたサービスまたは API に対するアクセスを防ぐための Deny ステートメントが含まれています。オプションで、 NotActions を追加できます。これは例外のリストです。 NotActions にリストされているサービスまたは API は認可されます。この例では、3 つの API ( sqs:SendMessage 、 ec2:StartInstances 、 s3:GetObject ) を除くすべてを拒否します。 最後のページで、コントロールから免除される IAM プリンシパル (ユーザーまたはロール) のリストを追加します。これは例外リストです。また、いつものようにコントロールに AWS リソースのタグを付けます。 最後の画面 (ここには表示されていません) で、すべてのパラメータを確認し、 [コントロールを有効にする] を選択します。 [有効な OU] タブで、コントロールが有効になっている OU のリストを確認できます。 概要のページには、この OU のために有効になっているすべてのリージョン、API、および IAM プリンシパルが表示されます。残りはすべて拒否されます。パラメータはいつでも更新できます。 料金と利用可能なリージョン AWS Control Tower は、すべての商用リージョンと米国 GovCloud でご利用いただけます。 AWS Control Tower の利用には追加料金はかかりません。ただし、AWS Control Tower を設定すると、ランディングゾーンと必須コントロールを設定するように構成された AWS サービスのコストが発生し始めます。 Organizations や AWS IAM アイデンティティセンターなどの特定の AWS サービスは追加料金なしでご利用いただけます。ただし、 AWS Service Catalog 、 AWS CloudTrail 、 AWS Config 、 Amazon CloudWatch 、 Amazon Simple Notification Service (Amazon SNS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Virtual Private Cloud (Amazon VPC) などのサービスについては、これらのサービスの利用量に基づいて、料金をお支払いいただきます。ご利用の際に、ご利用分の料金のみをお支払いいただきます。詳細については、 AWS Control Tower の料金のページ をご覧ください。 新しい AWS Control Tower のコントロールは、デジタル主権の要件を満たすためのセーフガードを特定してデプロイする負担を軽減します。この一連のコントロールはフルマネージドであり、時間が経過する中で AWS サービスとデジタル主権の要件が進化するのに応じて更新されます。 今すぐ、 デジタル主権の要件をサポートするのに役立つ AWS Control Tower のコントロール を設定しましょう。 — seb 原文は こちら です。

AWS Partner-Led Support プログラムの参加者がお客様のサポートをさらに適切に行うのに役立つ一連の診断ツールが追加されました。 AWS Partner-Led Support のご紹介 この AWS パートナーネットワーク (APN) プログラムにより、AWS パートナーは、お客様がテクニカルサポートを利用する際の単一の窓口となることができます。お客様は、AWS に直接問い合わせる代わりに、サポートパートナーに問い合わせてテクニカルサポートを依頼します。多くの場合、パートナーが問題を直接解決できます。パートナーが問題を解決できない場合は、 AWS サポート プランを通じて AWS からガイダンスを受けます。 診断ツール これらは、AWS サポートエンジニアが AWS のお客様をサポートするために使用するツールと同じです。 お客様がパートナーに問い合わせてサポートを依頼すると、パートナーは、お客様の AWS アカウントにフェデレーションします。その後、新しい診断ツールを使用してお客様のメタデータにアクセスします。これは、問題を特定および診断するのに役立ちます。 このツールは、お客様が設定した一連の IAM ロール によって有効になります。このツールはメタデータと CloudWatch メトリクスにアクセスして整理できますが、お客様データにはアクセスできず、お客様の AWS リソースに変更を加えることもできません。パートナーがアクセスできる情報のタイプをいくつか次に示します。 EC2 キャパシティ予約 Lambda 関数のリスト GuardDuty の検出結果 ロードバランサーの応答 RDS および Redshift クラスター 各ツールは、ツールの実行時に選択された領域のリストに基づいて動作します。各ツールのすべての呼び出しはログ記録され、確認のために簡単にアクセスできます。また、各呼び出しからの出力は、いくつかの異なるリージョンのいずれかにルーティングできます。 これらのツールは AWS マネジメントコンソール から呼び出すことができ、社内ツール、オートメーション、統合をサポートするために API アクセスを使用できます。 詳細はこちら このサービスは現在、Partner-Led Support プログラムに参加しているパートナー向けに提供されています。詳細については、 AWS Partner-Led Support ページをご覧ください。 現在 AWS パートナーであり、プログラムについて詳しく知り、要件を満たして参加することを検討している場合は、 AWS パートナーセントラル にアクセスしてください。 AWS 診断ツールの詳細については、こちら をご覧ください。 – Jeff ; 原文は こちら です。

11月27日、 AWS B2B Data Interchange をリリースしました。これは、組織が EDI ベースのビジネスクリティカルなトランザクションの変革をクラウドの規模で自動化およびモニタリングできるようにするフルマネージドサービスです。このリリースにより、AWS は B2B ドキュメント交換の世界にオートメーション、モニタリング、伸縮性、従量制料金をもたらします。 電子データ交換 (EDI) とは、ビジネスパートナー間において、標準の電子フォーマットでビジネスドキュメントを電子的に交換することをいいます。E メールも電子的なアプローチではありますが、E メールで交換されるドキュメントは今でも、コンピュータシステムではなく、人間によって処理される必要があります。人間が関与するとドキュメントの処理が遅くなり、エラーも発生します。他方、EDI ドキュメントは受信者のシステム上の適切なアプリケーションに直接送信され、直ちに処理が開始されます。コンピュータシステム間で交換される電子ドキュメントは、企業のコスト削減、トランザクションワークフローの高速化、エラーの削減、ビジネスパートナーとの関係の改善に役立ちます。 EDI への取り組みは 1970 年代に始まりました。私は 1994 年に、ビジネスドキュメントの構造を定義する一連の標準である EDIFACT に関する論文 を読んだことを覚えています。しかし、出現から 50 年を超える期間が経過しているテクノロジーであるにもかかわらず、ビジネスアプリケーションのデータを解析、検証、マッピングし、EDI データ形式に変換するためにデプロイされた従来のセルフマネージド EDI ソリューションは、ビジネスの量の変化に応じてスケールすることが困難です。通常、通信およびコンテンツのエラーに対する運用上の可視性は高くありません。これらの課題により、企業は多くの場合、エラーが発生しやすい E メールによるドキュメント交換に依拠せざるを得なくなり、人間による作業が増え、コンプライアンスの管理がより困難になり、最終的には成長と俊敏性が制約されます。 AWS B2B Data Interchange は、データ変換と統合を加速するための、使いやすく、コスト効率の高いフルマネージドサービスです。ビジネスパートナーとの接続を確立し、ドキュメントをシステムのデータ形式にマッピングするという手間のかかる作業が不要になり、処理できないドキュメントを可視化できます。 ビジネスパートナーのオンボーディングと EDI データ変換のためのローコードインターフェイスを提供し、処理されたデータをビジネスアプリケーションや分析ソリューションに簡単にインポートできるようにします。B2B Data Interchange を利用すると、モニタリングデータに簡単にアクセスできるため、交換されるドキュメントの量と各ドキュメント変換のステータスをモニタリングするためのダッシュボードを構築できます。例えば、形式が誤っているドキュメントを変換したり、ビジネスアプリケーションにインポートしたりできない場合に備えて、アラームを簡単に作成できます。 大企業では、数千のビジネスパートナーを抱え、各パートナーとの間で数百種類のドキュメントが交換されることが一般的であるため、管理する必要がある組み合わせは数百万にのぼります。AWS B2B Data Interchange は、 AWS マネジメントコンソール を通じて利用できるだけでなく、 AWS コマンドラインインターフェイス (AWS CLI) および AWS SDK を使用してアクセスすることもできます。これにより、新しいビジネスパートナーとその特定のデータ変換をオンボーディングするアプリケーションやスクリプトを作成したり、新規または既存のダッシュボードにアラームやモニタリングロジックをプログラムで追加したりできます。 B2B Data Interchange は、 X12 EDI データ形式をサポートします。これにより、EDI ドキュメントを検証し、JSON や XML などのビジネスアプリケーションで想定される形式に変換することが容易になります。未処理のドキュメントと変換された JSON または XML ファイルは、 Amazon Simple Storage Service (Amazon S3) に保存されます。これにより、リアルタイムのビジネスデータ処理のためにイベント駆動型アプリケーションを構築したり、ビジネスドキュメントを既存の分析または AI/ML ソリューションと統合したりできます。 例えば、新しい EDI ビジネスドキュメントを受信した場合、 AWS Step Functions または Amazon EventBridge を利用して、追加のルーティング、処理、変換ロジックをトリガーできます。着信ドキュメントでエラーが検出された場合、E メールまたは SMS によってアラームメッセージが送信されるように設定したり、 AWS Lambda を利用して API 呼び出しや追加の処理ロジックをトリガーしたりできます。 仕組みを見てみましょう いつものように、このブログで仕組みを見てみましょう。私が大手小売企業のサプライチェーンの責任者であり、 船荷証券 、税関書類、 事前出荷通知 、インボイス、 受領証明書 などのドキュメントを交換するビジネスパートナーが何百もあると想像してみましょう。 このデモでは、 AWS マネジメントコンソール を使用して新しいビジネスパートナーをオンボーディングします。オンボーディングとは、ビジネスパートナーの連絡先の詳細、ビジネスパートナーと交換するドキュメントの種類、既存のビジネスアプリケーションによって想定される JSON 形式への技術データの変換、およびドキュメントの受信場所を定義することをいいます。 このリリースにより、EDI ドキュメントのトランスポートメカニズムの設定は B2B Data Interchange の外部で管理されます。通常は、 転送ゲートウェイ を設定し、ビジネスパートナーが SFTP または AS2 を使用してドキュメントを転送することを提案します。 サーバーを管理したり、アプリケーションパッケージをインストールして設定したりする必要はありません。わずか 4 つのステップで使用を開始できます。 最初に、ビジネスパートナーのプロファイルを作成します。 次に、トランスフォーマーを作成します。トランスフォーマーは、ソースドキュメント形式と、既存のビジネスアプリケーションのデータ形式 (JSON または XML) に対するマッピングを定義します。グラフィカルエディタを使用してサンプルドキュメントを検証し、変換の結果をコンソールから直接確認できます。標準の JSONATA クエリおよび変換言語を使用して、JSON ドキュメントへの変換ロジックを定義し、XML ドキュメントに変換する場合は標準の XSLT を定義します。 トランスフォーマーを作成したら、アクティブ化します。 3 番目に、取引機能を作成します。これにより、どの Amazon Simple Storage Service (Amazon S3) バケットが特定のビジネスパートナーからドキュメントを受信するか、および変換されたデータが保存される場所が定義されます。 S3 バケットポリシーで適切な許可が定義されていることを確認するための 1 回限りの追加の設定があります。 [ポリシーをコピー] を選択し、コンソールの [Amazon S3] ページに移動して、ポリシーを S3 バケットに適用します。1 つのポリシーでは B2B Data Interchange による着信バケットからの読み取りが許可され、もう 1 つのポリシーでは送信バケットへの書き込みが許可されます。 S3 バケットを設定する際には、S3 バケットで Amazon EventBridge をオンにすることも重要です。これは、新しいビジネスドキュメントの到達時にデータ変換をトリガーするために使用するメカニズムです。 最後に、B2B Data Interchange の設定に戻り、パートナーシップを作成します。パートナーシップは、お客様と個々の取引パートナーとの間の関係を確立する専用のリソースです。パートナーシップには、特定の取引パートナー、取引パートナーから受信する EDI ドキュメントの種類、およびそれらのドキュメントをカスタム JSON または XML 形式に変換する方法に関する詳細が含まれます。パートナーシップは、最初のステップで作成したビジネスプロファイルを、ステップ 2 で定義した 1 つまたは複数のドキュメントの種類および変換とリンクします。 ここでは、最後に受信した一連のドキュメントのステータスと、その変換のステータスをモニタリングすることもできます。詳細な履歴データを確認するには、コンソールに表示されるリンクを使用して Amazon CloudWatch に移動できます。 設定をテストするために、EDI 214 ドキュメントを着信バケットにアップロードすると、数秒後に、変換された JSON ドキュメントが宛先バケットに表示されます。 EventBridge からの Invocations と TriggeredRules CloudWatch メトリクスを使用して、ドキュメントの処理と変換のステータスを観察できます。そこから、CloudWatch Logs を利用して、通常どおりに ダッシュボード を構築し、 アラーム を設定できます。また、 AWS Lambda 関数 または AWS Step Functions を使用したワークフロー を作成することで、着信または変換されたビジネスドキュメントの追加のエンリッチメント、ルーティング、および処理を設定することもできます。 料金と利用可能なリージョン AWS B2B Data Interchange は現在、米国東部 (オハイオ、バージニア北部) と米国西部 (オレゴン) の 3 つの AWS リージョンでご利用いただけます。 1 回限りの設定料金や繰り返し発生する月間サブスクリプション料金はありません。AWS は、実際の使用量に基づいてオンデマンドで料金を請求します。1 か月ごとにパートナーシップごとの料金が発生するほか、変換されたドキュメントごとの料金もかかります。詳細については、 B2B Data Interchange の料金のページ をご覧ください。 AWS B2B Data Interchange を利用すると、取引パートナーとの関係を簡単に管理できるため、クラウドの規模で EDI ワークフローを自動的に交換、変換、モニタリングできます。インフラストラクチャのインストールや管理は必要なく、既存のビジネスアプリケーションやシステムと簡単に統合できます。AWS B2B Data Interchange API または AWS SDK を使用して、パートナーのオンボーディングを自動化できます。スケーラブルなフルマネージドインフラストラクチャと組み合わせることで、AWS B2B Data Interchange は、ビジネスの俊敏性を高め、運用をスケールするのに役立ちます。 詳細はこちら: AWS B2B Data Interchange のウェブページ コンソールにログイン さぁ、構築しましょう! — seb 原文は こちら です。

すべての重要なリソースの自動ゲームデーテストを実行することは、ランサムウェアやデータ損失イベントへの対応の準備ができているかどうかを判断するための重要なステップです。これにより、結果に基づいて適切な是正措置を講じ、これらのテストの成功または失敗などの結果をモニタリングする機会が得られます。最終的には、復元時間が組織の想定される目標復旧時間 (RTO) を満たしているかどうかを確認でき、より優れた復旧戦略を策定するのに役立ちます。 11月27日、 AWS Backup の新機能である復元テストを発表しました。これを使用することで、ストレージ、コンピューティング、データベース全体で AWS リソースの復元テストを実行できます。この機能を使用すると、復元テストプロセス全体を自動化し、ランサムウェアなどによってデータ損失が発生した場合に、バックアップを使用して正常に復元できるかどうかを今すぐ知ることで、後日予期しない事態が発生するのを回避できます。また、必要に応じて、組織および規制上のデータガバナンス要件の遵守を実証するために、復元ジョブの結果を使用できます。 仕組み AWS Backup での復元テストは、AWS Backup によってリカバリポイントが作成されるリソースの復元テストをサポートしており、次のサービスがサポートされています: Amazon Elastic Block Store (Amazon EBS) 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Aurora 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Elastic File Store (Amazon EFS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon DynamoDB 、 Amazon FSx 、 Amazon DocumentDB 、and Amazon Neptune 。AWS Backup コンソール、AWS CLI、または AWS SDK から復元テストを開始できます。 先ほど、EC2 インスタンスとこれらのインスタンスのバックアップを作成しました。その後、AWS Backup コンソールで復元テスト計画を作成しました。 この [全般] セクションでは、計画の名前、テスト頻度、[開始時刻]、および [次の時間以内に開始] を入力します。 [開始時刻] はテストの開始時刻を設定します。例えば、テスト頻度を毎日として設定する場合は、プランを毎日何時に実行するかを指定します。 [次の時間以内に開始] では、時間を設定すると、その時間以内に復元テストが開始されるよう指定されます。AWS Backup は、指定されたすべての復元ジョブを [次の時間以内に開始] の時間枠内に開始するよう最善の努力を尽くします。必要に応じて、これを極めて小さくすることも、大きくすることもできます。 [リカバリポイントの選択] セクションでは、この復元テスト計画の一部として、リカバリポイントの取得元とするボールトと、適格なリカバリポイントの期間を指定します。リカバリポイントの基準はデフォルトの選択のままにしました。また、この復元テスト計画では、ポイントインタイムリカバリ (PITR) によって生成されたリカバリポイントを含めることをオプトインしませんでした。 タグ付けはオプションであるため、このテストの目的ではタグを追加しませんでした。設定が完了したので、 [復元テスト計画を作成] を選択して続行し、この復元テスト計画を作成します。 復元テスト計画が作成されたら、リソースを割り当てます。まず、復元テストを実行する際に AWS Backup が引き受ける IAM ロールを指定します。クリーンアップ前の保持期間に関しては、コストを最適化するために、復元されたリソースを直ちに削除するというデフォルトの選択を維持しました。これに代えて、保持期間を指定することで、Amazon EventBridge (CloudWatch Events) を利用して独自のテスト (AWS Lambda など) を統合し、新しい PutRestoreValidationResult API を使用して検証ステータスを送り返して、復元ジョブで報告されるように設定することもできました。 以前に作成してバックアップした EC2 インスタンスがあり、このプランが Amazon EC2 リソースタイプ用であることを指定します。この EC2 リソースタイプのすべての保護されたリソースを選択範囲に含めます。リソースが非常に少ないため、オプションのタグは追加しませんでした。 復元にはデフォルトのインスタンスタイプを使用することにしました。追加のパラメータも指定しませんでした。そして、 [リソースを割り当てる] を選択します。 リソースが割り当てられると、復元テスト計画に関連するすべての情報が要約された形式で表示され、復元テストジョブがいつ実行されたのかを確認できるようになります。 ある程度の期間にわたって十分な復元を実行すると、 [保護された リソース] タブから復元されたすべてのリソースの [復元時間の履歴] を表示することもできます。 今すぐご利用いただけます AWS Backup での復元テストは、AWS 中国リージョン、AWS GovCloud (米国)、イスラエル (テルアビブ) を除く、AWS Backup が利用可能なすべての AWS リージョン でご利用いただけます。 詳細については、「 AWS Backup ユーザーガイド 」にアクセスしてください。ご質問は、 AWS re:Post for AWS Backup 宛てに、または通常の AWS サポートの連絡先を通じてご送信ください。 – Veliswa 原文は こちら です。

AWS マネジメントコンソール、Amazon FSx CLI、および AWS SDK を使用して、 Amazon FSx for NetApp ONTAP FlexGroup ボリュームを作成、管理、バックアップできるようになりました。FlexGroups は 20 ペタバイトにも対応でき、要求の厳しいワークロードでも優れたパフォーマンスを発揮します。今回のリリース前は、ONTAP CLI と ONTAP REST API を使用してのみ同ボリュームを作成できました (これらのオプションは引き続き使用できます)。また、今回のリリースで、FlexGroup ボリュームの Amazon FSx バックアップを作成できるようになりました。 FlexVol と FlexGroup FSx for ONTAP は、次の 2 つのボリュームスタイルをサポートしています。 FlexVol – 最大 300 TiB のストレージをサポートするため、このボリュームは汎用ワークロードに最適です。 FlexGroup – ボリュームあたり最大 20 PiB のストレージと数十億のファイルをサポートしているため、このボリュームは、要求の厳しい Electronic Design Automation (EDA)、耐震解析、ソフトウェア構築/テストのワークロードに最適です。 FlexGroup を使用する AWS マネジメントコンソールを使用して新しいファイルシステムを作成します 。 [Amazon FSx for NetApp ONTAP] を選択し、 [Next] (次へ) をクリックします。 [Standard create] (スタンダード作成) を選択し、ファイルシステムの名前 ( FS-JEFF-1 ) を入力し、デプロイタイプとして [Single-AZ] (シングル AZ) を選択します。 次のように、推奨スループットキャパシティを使用することも、明示的に指定することもできます。 上記の値から推測できるように、スループットはファイルシステムのホストに使用される高可用性 (HA) ペアの数によって決まります。シングル AZ ファイルシステムは、このようなペアで最大 6 つまでホストできます。マルチ AZ ファイルシステムは 1 つのペアに存在する必要があります。これらのオプションの詳細については、「 新規 – Amazon FSx for NetApp ONTAP のスケールアウトファイルシステム 」を参照してください。 [Network &amp; security] (ネットワークとセキュリティ)、 [Encryption] (暗号化)、 [Default storage virtual machine configuration] (デフォルトのストレージ仮想マシン設定) の順に選択したら、 FlexGroup ボリュームスタイルを選択し、初期ボリュームに名前を割り当て、推奨構成要素数をそのまま使用するか、自分で指定します。 次のページで選択内容を見直し、 [Create file system] (ファイルシステムを作成) をクリックします。 作成は昼休みにちょうどいい時間で行えます。ファイルシステムの初期ボリューム ( Vol1 ) を返却すると、すぐに使用できます。必要に応じて追加の FlexVol または FlexGroup ボリュームを作成できます。 知っておくべきこと FlexGroup ボリュームに関して留意すべき点がいくつかあります。 構成要素 – 各 FlexGroup ボリュームには 200 個もの構成要素を含めることができますが、推奨されるのは HA ペアあたり 8 個です。構成要素ごとに 300 TiB のサイズ制限があるため、HA ペアあたり最大 2.4 PiB のストレージを持つボリュームを作成できます。ONTAP は、構成要素間でファイルのバランスを自動的に調整します。 ファイル数 – NFSv3 を使用していて、1 つの FlexGroup ボリュームに数十億ものファイルを保存することが予想される場合は、ファイルシステムに関連付けられているストレージ仮想マシンで 64 ビットの識別子を必ず有効に してください。 バックアップ – 本日より、FlexGroup ボリュームのバックアップを作成できるようになりました。これにより、既に FlexVol ボリュームと同じフルマネージド型のビルトインオプションを利用できるようになります。 NetApp システムマネージャー – ONTAP CLI とブラウザベースの NetApp システムマネージャー を使用して、ONTAP ファイルシステム、ストレージ仮想マシン、およびボリュームで高度な操作を実行できます。管理エンドポイントと管理者の認証情報は、 ファイルシステムの詳細 ページにあります。 リージョン – どちらのボリュームスタイルも、 Amazon FSx for NetApp ONTAP がサポートされているすべての AWS リージョンでご利用いただけます。 料金 – プロビジョニングした SSD ストレージ、SSD IOPS、スループットキャパシティに対してお支払いいただき、キャパシティプールの使用量、バックアップ、SnapLock ライセンスには別途料金がかかります。詳細については、 Amazon FSx for NetApp ONTAP の料金 ページを参照してください。 – Jeff ; 原文は こちら です。

同じ AWS 組織の他のアカウントで共有されている VPC に、ONTAP ファイルシステム用のマルチ AZ FSx を作成できるようになりました。要望の多かったこの機能により、ネットワーク管理者とストレージ管理者の職務分担が明確になり、耐久性と可用性に優れ、複数の VPC からアクセスできるストレージを構築することが可能になります。 共有 VPC サポート 11月26日のリリース前は、別の AWS アカウントにより共有されたサブネットでシングル AZ の FSx for ONTAP を作成したり、所有しているサブネットでシングル AZ ファイルシステムとマルチ AZ ファイルシステムの両方を作成したりできました。 本日のリリースにより、複数のアベイラビリティーゾーンのファイルシステムでも同じことができるようになりました。マルチ AZ の FSx for ONTAP ファイルシステムは、シングル AZ ファイルシステムよりも可用性が高く、エンタープライズの大規模ストレージのニーズに対応してサポートするための優れた方法です。共有 VPC のこの新しいサポートにより、多くの企業が技術的および組織的な理由で複数の VPC を利用しているため、ネットワーク管理者とストレージ管理者が独立して作業しながら、マルチ AZ 配置で FSx for ONTAP を使用できます。 設定は簡単ですが、VPC 間で共有されていないサブネット間で IP アドレスの競合がないようにする必要があります。AWS Organizations をセットアップしていないので、このプロセスの一部を簡単に説明します。ネットワーク管理者 (所有者アカウント) として、 AWS Resource Access Manager (RAM) を使用して、VPC の適切なサブネットを Organizations 内の希望する参加者アカウントと共有します。 次に、私 (それらのアカウントの管理者) がリソース共有を受け入れます。 次に、新しい FSx for ONTAP 設定 を使用して参加者アカウントからのルートテーブルの更新を有効にし、 [Submit] (送信) をクリックします (これにより、FSx for ONTAP サービスに、参加者アカウントに代わって共有サブネットでルートテーブルエントリを変更する許可が付与されます)。 この時点で、参加者アカウントのストレージ管理者は、所有者アカウントによって共有されたサブネットに マルチ AZ の FSx for ONTAP ファイルシステムを作成できます。 この機能には追加料金はかかりません。FSx for ONTAP がサポートされているすべての AWS リージョンでご利用いただけます。 – Jeff ; 原文は こちら です。

AWS Step Functions HTTPS エンドポイントでは、サードパーティー API と外部サービスをワークフローに統合できるようになりました。HTTPS エンドポイントを使用すると、外部 API を呼び出して既存の SaaS プロバイダーと簡単に統合できます。例えば、支払い処理には Stripe 、コードコラボレーションとリポジトリ管理には GitHub 、営業やマーケティングのインサイトには Salesforce などがあります。このリリース前は、顧客は AWS Lambda 関数を使用して外部エンドポイントを呼び出し、認証とエラーをコードで直接処理する必要がありました。 また、ステートマシンをデプロイしたり実行したりすることなく、タスクの状態を個別にテストできる新しい機能も発表しました。 AWS Step Functions は、デベロッパーが分散アプリケーションの構築、プロセスの自動化、マイクロサービスの調整、データおよび機械学習 (ML) パイプラインの作成を簡単に行える視覚的なワークフローサービスです。Step Functions は 220 以上の AWS のサービスと統合され、組み込みのエラー処理、リアルタイムで監査可能なワークフロー実行履歴、大規模な並列処理など、デベロッパーが構築するのに役立つ機能を提供します。 HTTPS エンドポイント HTTPS エンドポイントは、AWS 外のサードパーティー HTTP ターゲットに接続できるようにするタスクステートの新しいリソースです。Step Functions は HTTP エンドポイントを呼び出し、リクエスト本文、ヘッダー、パラメータを配信し、サードパーティーサービスからレスポンスを取得します。GET や POST など、任意の HTTP メソッドを使用できます。 HTTPS エンドポイントは、 Amazon EventBridge 接続 を使用してターゲットの認証情報を管理します。これにより、使用する認証タイプが定義されます。これには、ユーザー名とパスワード、API キー、OAuth による基本認証などがあります。EventBridge 接続では、 AWS Secrets Manager を使用してシークレットを保存します。これにより、シークレットがステートマシンから除外され、ログやステートマシンの定義でシークレットが誤って公開されるリスクが軽減されます。 HTTPS エンドポイントの開始方法 HTTPS エンドポイントを使い始めるには、まず EventBridge 接続を作成 する必要があります。次に、新しい AWS Identity and Access Management (IAM) ロールを作成し、許可を付与する必要があります。これにより、ステートマシンが接続リソースにアクセスし、Secrets Manager からシークレットを取得し、HTTP エンドポイントを呼び出す許可を取得できます。 ステートマシンの実行ロールに含める必要があるポリシーは次のとおりです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret" ], "Resource": "arn:aws:secretsmanager:*:*:secret:events!connection/*" } ] } { "Version": "2012-10-17", "Statement": [ { "Sid": "RetrieveConnectionCredentials", "Effect": "Allow", "Action": [ "events:RetrieveConnectionCredentials" ], "Resource": [ "arn:aws:events:us-east-2:123456789012:connection/oauth_connection/aeabd89e-d39c-4181-9486-9fe03e6f286a" ] } ] } { "Version": "2012-10-17", "Statement": [ { "Sid": "InvokeHTTPEndpoint", "Effect": "Allow", "Action": [ "states:InvokeHTTPEndpoint" ], "Resource": [ "arn:aws:states:us-east-2:123456789012:stateMachine:myStateMachine" ] } ] } すべての準備が整ったら、ステートマシンを作成できます。ステートマシンに、サードパーティー API を呼び出すための新しいタスクステートを追加します。必要なサードパーティー URL を指すように API エンドポイント を設定し、正しい HTTP メソッド を設定し、以前に作成した接続の Amazon リソースネーム (ARN) をそのエンドポイントの 認証 として選択し、必要に応じて リクエスト本文 を指定することができます。さらに、これらのパラメータはすべて、ランタイムの際に JSON のステート入力から動的に設定できます。 これで、Step Functions を使用して外部からのリクエストを行うのが簡単になり、Step Functions が提供するすべての設定を利用して、一時的なエラーや一時的なサービスが利用できなくなった場合の再試行や、調査や解決に時間がかかる エラーのリドライブ などの エラーを処理 できます。 状態をテストする フィードバックサイクルを加速するために、個々の状態をテストする新しい機能も発表します。この新機能により、ワークフローの実行とは別に状態をテストできます。これは、エンドポイントの設定をテストする場合に特に便利です。ワークフローをデプロイしたり、ステートマシン全体を実行したりすることなく、入力を変更してさまざまなシナリオをテストできます。この新機能は、すべてのタスク、選択、およびパスステートで利用できます。 タスクを選択すると、Step Functions Workflow Studio にテスト機能が表示されます。 [Test state] (状態をテスト) を選択すると、タスクの状態をテストできる別のビューにリダイレクトされます。ステートマシンロールに適切な許可があること、呼び出すエンドポイントが正しく設定されていること、およびデータ操作が期待どおりに行えることをテストできます。 利用状況 Step Functions が提供するすべての機能により、支払いフロー、手動入力によるワークフロー、レガシーシステムへの統合など、さまざまな問題を解決できるステートマシンの構築がこれまでになく簡単になりました。Step Functions HTTPS エンドポイントを使用すると、ユーザーのクレジットカードに一度だけ請求され、エラーが自動的に処理されるようにしながら、一般的な支払いプラットフォームと直接統合できます。さらに、ステートマシンをデプロイする前でも、新しいテストステート機能を使用してこの新しい統合をテストできます。 新機能は、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、AWS イスラエル (テルアビブ)、中国、GovCloud リージョンを除くすべての AWS リージョンでご利用いただけます。 使用を開始するには、 AWS マネジメントコンソールの Step Functions にある 「Stripe を使用して請求書を生成」のサンプルプロジェクトを試してみるか、 AWS Step Functions デベロッパーガイド で詳細をご確認ください。 –&nbsp; Marcia 原文は こちら です。

11月26日、 Amazon GuardDuty ECS Runtime Monitoring を発表しました。これは、 AWS Fargate と Amazon Elastic Compute Cloud (Amazon EC2) の両方で実行される Amazon Elastic Container Service (Amazon ECS) クラスターで発生する潜在的なランタイムセキュリティ問題を検出するのに役立ちます。 GuardDuty は、さまざまな AWS データソースに対して、機械学習 (ML)、異常検知、ネットワークモニタリング、悪意のあるファイルの発見を組み合わせています。脅威が検出されると、GuardDuty はセキュリティの検出結果を生成し、自動的に AWS Security Hub 、 Amazon EventBridge 、 Amazon Detective に送信します。このような統合により、AWS とパートナーサービスのモニタリングを一元化し、対応を自動的に開始し、セキュリティ調査を実施するのに役立ちます。 GuardDuty ECS Runtime Monitoring は、ランタイムの脅威があることを示す、ファイルアクセス、プロセス実行、ネットワーク接続などのランタイムイベントを検出するのに役立ちます。何百もの脅威ベクトルと指標をチェックし、30 種類以上の検出タイプを生成できます。例えば、権限昇格の試み、クリプトマイナーやマルウェアによって生成されたアクティビティ、攻撃者による偵察を示唆するアクティビティを検出できます。これは GuardDuty の主要な検出カテゴリ に追加されるものです。 GuardDuty ECS Runtime Monitoring は、マネージド型の軽量セキュリティエージェントを使用して、個々のコンテナのランタイム動作の可視性を向上させます。AWS Fargate を使用する場合、エージェントをインストール、設定、管理、または更新する必要はありません。当社にお任せください。これにより、クラスターの管理が簡素化され、一部のタスクが監視されることなく放置されるリスクが軽減されます。また、セキュリティ体制を改善し、ランタイムの脅威に対して規制遵守を実現し、認証に合格するのにも役立ちます。 GuardDuty ECS Runtime Monitoring の検出結果は、コンソールに直接表示されます。GuardDuty は、検出結果を複数の AWS のサービスに送信したり、 セキュリティオペレーションセンター (SOC) に接続されたサードパーティーのモニタリングシステムに送信したりするように設定することもできます。 今回のリリースにより、Amazon Detective は GuardDuty ECS Runtime Monitoring からセキュリティに関する検出結果を受け取り、データのコレクションに含めて分析と調査を行えるようになりました。Detective は、潜在的なセキュリティ問題や疑わしいアクティビティの根本原因を分析、調査、迅速に特定するのに役立ちます。Detective は、AWS リソースからログデータを収集し、機械学習、統計分析、グラフ理論を使用して、リンクされたデータセットを構築してセキュリティ調査を簡単に実施できるようにします。 AWS Fargate で GuardDuty ECS Runtime Monitoring を設定する このデモでは、AWS Fargate がもたらすエクスペリエンスを紹介することにします。Amazon ECS を使用するときは、EC2 インスタンスに GuardDuty エージェントがインストールされているようにする必要があります。エージェントを手動でインストールするか、AMI に組み込むか、GuardDuty が提供する AWS Systems Manager ドキュメント を使用してインストールできます (コンソールのシステムマネージャーに移動し、[Documents] (ドキュメント) を選択して GuardDuty を検索します)。ドキュメントには、 EC2 インスタンスへのエージェントのインストールに関する詳細が記載されています 。 GuardDuty 管理者アカウントから運用する場合、 組織 レベルで GuardDuty ECS Runtime Monitoring を有効にして、すべての組織の AWS アカウントにあるすべての ECS クラスターを監視できます。 このデモでは、 AWS マネジメントコンソール を使用して Runtime Monitoring を有効にします。コンソールで GuardDuty ECS Runtime Monitoring を有効にすると、すべてのクラスターに影響します。 GuardDuty で GuardDuty ECS Runtime Monitoring エージェントを Fargate に自動的にデプロイさせたい場合は、 GuardDuty エージェント管理 を有効にします。個々のクラスターを自動管理から除外するには、それらに GuardDutyManaged=false というタグを付けることができます。コンソールで ECS Runtime Monitoring を有効にする前に、クラスターに必ずタグを付けています。自動管理オプションを使用したくない場合は、オプションを無効のままにして、 GuardDutyManaged=true というタグを付けて監視するクラスターを自由に選択できます。 Amazon ECS または AWS Fargate クラスター管理者には、クラスターのタグを管理する権限が必要です。 タスクにアタッチする IAM TaskExecutionRole には、プライベート ECR リポジトリから GuardDuty エージェントをダウンロードする許可が必要です。これは、 AmazonECSTaskExecutionRolePolicy マネージド IAM ポリシー を使用すると自動的に行われます。 Runtime Monitoring とエージェント管理が有効になっている場合の、このデモでのコンソールのビューは次のとおりです。 すべての ECS クラスターの カバレッジ統計 を評価することで、セキュリティエージェントのデプロイ状況を追跡できます。 モニタリングを有効にすると、他に何もする必要はありません。簡単なデモクラスターでどのような検出結果が検出されるか見てみましょう。 GuardDuty ECS ランタイムのセキュリティに関する検出結果をご覧ください GuardDuty ECS Runtime Monitoring が潜在的な脅威を検出すると、このようなリストに表示されます。 詳細を表示するには、特定の検出結果を選択します。 知っておくべきこと デフォルトでは、Fargate タスクはイミュータブルです。GuardDuty は、既存のタスクのコンテナを監視するエージェントをデプロイしません。既に実行中のタスクについてコンテナを監視する場合は、GuardDuty ECS Runtime Monitoring を有効にした後でタスクを停止して開始する必要があります。同様に、 Amazon ECS サービス を使用するときは、エージェントでタスクが確実に再開されるように、新しいデプロイを強制する必要があります。前述のように、タスクに Amazon ECR から GuardDuty モニタリングエージェントをダウンロードするための IAM 許可があることを確認してください。 GuardDuty エージェントはパフォーマンスにほとんど影響を与えないように設計されていますが、 Fargate のタスクサイズを計算する際に考慮する必要があります 。 自動エージェント管理を選択すると、GuardDuty は VPC エンドポイント も作成して、エージェントが GuardDuty API と通信できるようにします。このデモと同様、(継続的インテグレーションシナリオなどで) 一定期間後にクラスターを削除する目的で CDK または CloudFormation スクリプト を使用してクラスターを作成する場合、VPC エンドポイントを手動で削除して CloudFormation がスタックを削除できるようにする必要があることにご注意ください。 利用可能なリージョンと料金 AWS Fargate インスタンスと Amazon EC2 インスタンスで GuardDuty ECS Runtime Monitoring を使用できるようになりました。GuardDuty ECS Runtime Monitoring を利用できるリージョンの全リストについては、 リージョン固有の機能の提供状況 ページをご覧ください。 GuardDuty ECS Runtime Monitoring は 30 日間無料でお試しいただけます。GuardDuty を初めて有効にするときは、GuardDuty ECS Runtime Monitoring を明示的に有効にする必要があります。試用期間が終了すると、時間単位で vCPU ごとにモニタリングエージェントの料金が発生します。 GuardDuty 料金 ページですべての詳細をご確認いただけます。 今すぐ GuardDuty ECS Runtime Monitoring を有効にして 、コンテナの脅威に関するインサイトを得ましょう。 — seb 原文は こちら です。

Amazon FSx for NetApp ONTAP ファイルシステムを、これまでよりも最大 9 倍高速に作成できるようになりました。このサービスで既にそうであるように、ファイルシステムはフルマネージド型で、プライマリストレージへのレイテンシーはミリ秒未満、キャパシティプールへのレイテンシーは数十ミリ秒です。この新たなレベルのパフォーマンスにより、要求の厳しい Electronic Design Automation (EDA)、視覚効果 (VFX)、統計計算のワークロード (ほんの数例を挙げると) をさらにクラウドに移行できるようになります。 既存の FSx for ONTAP スケールアップ ファイルシステムは、アクティブ/パッシブ高可用性 (HA) 設定のサーバーペアで動作し、最大 4 GBps のスループットと 192 TiB の SSD ストレージをサポートできます。このサーバーペアは、1 つのアベイラビリティーゾーンの異なるフォールトドメインにデプロイすることも、2 つのアベイラビリティーゾーンにデプロイして、アベイラビリティーゾーンが使用できない場合でも継続的に利用できるようにします。 本日のリリースにより、2～6 組の HA ペアで駆動する ONTAP ファイルシステム向けのスケールアウト FSx を作成できるようになりました。スケールアップとスケールアウトのファイルシステムの仕様は次のとおりです (ファイルシステムを作成するときに、それぞれに希望の値を指定できるため、これらはすべて「最大」と記載されています)。 デプロイタイプ 読み取り スループット 書き込み スループット SSD IOPS SSD ストレージ アベイラビリティーゾーン スケールアップ 最大 4 Gbps 最大 1.8 Gbps 最大 16 万 最大 192 TiB シングルまたはマルチ スケールアウト 最大 36 Gbps 最大 6.6 Gbps 最大120 万 最大 1 PiB シングル 次のように、ファイルシステムに指定するスループット量によって、実際のサーバー設定が決まります。 指定スループット デプロイ タイプ HA ペア スループット (サーバーあたり) SSD ストレージ (サーバーあたり) SSD IOPS (サーバーあたり) &nbsp;4 GBps 以下 スケールアップ シングル 最大 4 GBps の読み取り 最大 1.1 GBps の書き込み (シングル AZ) 最大 1.8 GBps の書き込み (マルチ AZ) 1～192 TiB 最大 16 万 4 GBps 超 スケールアウト 最大 6 最大 6 GBps の読み取り 最大 1.1 GBps の書き込み 1～512 TiB 最大 20 万 選択肢の詳細については、 Amazon FSx for NetApp ONTAP のパフォーマンス をご覧ください。 スケールアウトファイルシステムを作成する AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) を使用するか、Amazon FSX CreateFileSystem 関数を呼び出すコードを記述することで、スケールアウトファイルシステムを作成できます。コンソールを使用して、まず Amazon FSx for NetApp ONTAP を選択します。 [Standard create] (スタンダード作成) を選択し、名前を入力し、 シングル AZ 配置を選択し、希望する SSD ストレージキャパシティを入力します。推奨スループットキャパシティを受け入れるか、ドロップダウンから値を選択するか、値を入力してオプションを確認することができます (これについては後ほど詳しく説明します)。 ドロップダウンには便利な魔法の機能があります。希望するスループットキャパシティを入力すると、1 つまたは複数のオプションが表示されます。 コンソールには、希望するスループットキャパシティと同じ数のオプションがいくつか表示されることがあります。ワークロードに適した選択を行う際に役立つガイドラインを以下に示します。 低スループット – 4 GBps 以下のオプションを選択した場合、1 つの HA ペアで実行することになります。これは、高いスループットが必要ない場合に選択する最も簡単なオプションです。 高スループットおよび/または高ストレージ – 最大スループットは、プロビジョニングする HA ペアの数に応じてスケールします。また、ペアの数が多いオプションを選択することで、余裕を最大限に活用し、プロビジョニングされたストレージを将来増やすことができます。 通常どおり、残りのオプションを選択して値を入力し、 [Next] (次へ) をクリックして設定を確認します。作成後に編集できない属性について適切な選択をしたことを確認し、 [Create file system] (ファイルシステムの作成) をクリックします。 休憩を取り上の階で何が起きているのかを確認し、犬に餌をやります。戻ってくると新しい 2 TB のファイルシステムが準備完了です。 ストレージキャパシティを増やしたり、6 時間ごとにプロビジョンド IOPS を変更したりできます。 現時点では、ファイルシステムが複数の HA ペアを使用している場合、プロビジョニングされたスループットキャパシティを作成後に変更することはできません。 今すぐご利用いただけます スケールアウトファイルシステムは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、欧州 (アイルランド) の各リージョンで利用でき、今すぐ作成して使用を開始できます。 詳細はこちら Amazon FSx for NetApp ONTAP Amazon FSx for NetApp ONTAP パフォーマンス – Jeff ; 原文は こちら です。

11月26日、 Amazon FSX for OpenZFS に、ファイルシステムからアカウントの別のファイルシステムにスナップショットを送信する機能が追加されました。 1 回の API 呼び出しまたは CLI コマンドでコピーをトリガーでき、あとは弊社が処理します。 rsync のようなコマンドを使って転送の状態を監視する必要はありません。サービスがお客様に代わってコピーを処理します。潜在的なネットワークの中断を管理し、転送が完了するまで自動的に再試行します。OpenZFS のネイティブな 送信 および 受信 機能を使用して、ブロックレベルでデータを段階的に転送します。 この新機能により、例えば、テスト環境や開発環境をより迅速かつ簡単に作成できるようになるため、 俊敏性 を維持できます。また、リードレプリカの管理を簡素化して パフォーマンス のスケールアウトを実現することでパフォーマンスが向上します。 Amazon FSX for OpenZFS は、オープンソースの OpenZFS ファイルシステム上に構築されたフルマネージド型ファイルシステムを起動、実行、スケールできるフルマネージド型ファイルストレージサービスです。FSX for OpenZFS を使用すると、アプリケーションやデータの管理方法を変更することなく、オンプレミスの ZFS ファイルサーバーを簡単に移行でき、高性能でデータ集約型の新しいアプリケーションをクラウド上に構築できます。 スナップショット は ZFS ファイルシステムの最も強力な機能の 1 つです。スナップショットは、ファイルシステムまたはボリュームの読み取り専用コピーです。スナップショットはほぼ瞬時に作成でき、最初はストレージプール内の追加のディスク容量を消費しません。スナップショットが作成されると、そのスペースは最初にスナップショットとファイルシステムの間で共有され、場合によっては以前のスナップショットと共有されます。ファイルシステムが変更されると、以前に共有されていたスペースはスナップショット固有のものになります。スナップショットは、古いデータを引き続き参照することで消費するディスク容量が増加するため、スペースが解放されなくなります。スナップショットは、非常に大規模なファイルシステムでも、オンデマンドでほぼ瞬時にロールバックできます。スナップショットを複製して新しいボリュームを作成することもできます。 スナップショットはブロックレベルのコピーです。変更されたファイルを検出するためにシステムが何百万ものファイルをトラバースしなければならない従来のファイルレベルのコピーよりも転送が効率的です。また、スナップショットはブロックレベルで増分なので、インクリメンタルスナップショットを転送する方が、ファイルベースのインクリメンタルコピーを転送するよりも効率的です。それには、前回のスナップショット以降に変更されたブロックのみが含まれます。 ZFS スナップショットのオンデマンドレプリケーションにより、基盤となるインフラストラクチャを気にすることなく、OpenZFS のネイティブ 送受信 機能を使用してテラバイトのデータを転送できます。ネットワークの中断やその他の種類のエラーの検出および管理は当社が行い、ファイルシステム間でデータを簡単に複製できるようにします。 この新機能を使用する主なユースケースは 2 つあります。 デベロッパーや品質保証 (QA) エンジニアは、オンデマンドのスナップショットを開発環境やテスト環境に送信することがあります。これにより、本番データを扱うことができるため、正確なテスト結果と開発結果が得られます。最新のスナップショットをテストの開始点として一貫して使用することで、開発プロセスおよびテストプロセスの効率が向上します。 データエンジニアは、オンデマンドレプリケーションを使用して、データセットで並行実験を実行することがあります。アプリケーションが大規模なデータセットを処理するとします。同じベースデータセットで複数のバージョンのデータ処理アルゴリズムを実行して、ユースケースに最適なチューニングを見つけたいと考えています。オンデマンドデータレプリケーションを使うと、ファイルシステムの同一のコピーを複数作成し、各実験を並行して実行できます。 仕組みを見てみましょう このデモを準備するために、 AWS マネジメントコンソール の FSx for OpenZFS セクション を使用します。まず、Amazon FSx for OpenZFS ボリュームを 2 つ作成します。次に、2 つのファイルシステム ( /zfs-filesystem1 と /zfs-filesystem2 ) を 1 つの Amazon Linux インスタンスに マウント します。1 つ目のボリュームでファイルを準備しましたが、オンデマンドレプリケーション後に 2 つ目のボリュームでも同じファイルが見つかるはずです。 2 つのボリューム間でデータを同期するには、 コンソールのスナップショットセクション に移動します。次に、[ スナップショットをコピーしてボリュームを更新 ] を選択します。また、スナップショットを新しい ZFS ボリュームにコピーすることもできます。 [Copy snapshot and update volume] (スナップショットのコピーとボリュームの更新) ページで、コピー先の ファイルシステム と ボリューム を選択します。ソーススナップショットも確認します。 [Source snapshot copy strategy] (ソーススナップショットのコピー方法) を選択し、フルコピーまたは増分コピーをリクエストします。準備ができたら、 [Update] (更新) を選択します。 しばらくすると、転送するデータの量によって異なりますが、コピー先ボリュームに新しいスナップショットが一覧表示されていることが分かります。このデモシナリオでは、ほんの数秒で完了しました。 Linux インスタンスに戻り、2 つ目のマウントポイント /zfs-snapshot にあるコンテンツを一覧表示します。牛形の ASCII アートが 2 つ目のファイルシステムにありますね 。 また、新しい FSx API ( CopySnapshotAndUpdateVolume と CopySnapshotAndCreateVolume ) を使用して、オンデマンド転送を自動化することもできます。 継続的な定期レプリケーションを設定するために、提供されている CloudFormation テンプレート を使用して自動レプリケーションスケジュールを作成します。デプロイすると、システムはソースファイルシステム上のボリュームのスナップショットを定期的に取得し、レプリケート先ファイルシステム上のボリュームへの増分レプリケーションを実行します。例えば、テスト目的で、開発ファイルシステムへのレプリケーションを 15 分に 1 回実行するようにスケジュールできます。 利用可能なリージョンと料金 この新機能は、FSx for OpenZFS が利用できるすべての AWS リージョンでご利用いただけます。 追加費用はかかりません。AWS は、アベイラビリティーゾーン間のネットワークデータ転送に通常の料金を請求します。 リモートファイルシステムが使用するストレージ量に対して、標準の FSx for OpenZFS 料金が発生します。 Amazon FSX for OpenZFS の新しいオンデマンドレプリケーションにより、ファイルシステムの増分スナップショットをアカウントの新しいボリュームに効率的に転送できます。これにより、デベロッパーや QA エンジニアは本番データのコピーを操作し、データエンジニアはデータセットで並行して実験を行うことができます。 今すぐ、 最初のオンデマンドレプリケーションを構築して設定しましょう 。 — seb 原文は こちら です。

 医療画像の分析は、病気の診断と治療において重要な役割を果たします。機械学習 (ML) 技術を使用してこのプロセスを自動化することで、医療従事者は特定のがん、冠状動脈疾患、眼科疾患をより迅速に診断できます。しかし、この分野の臨床医や研究者が直面する主な課題の 1 つは、画像分類のための ML モデルを構築することの時間と複雑さです。従来の方法では、コーディングの専門知識と ML アルゴリズムに関する幅広い知識が必要であり、これは多くの医療従事者にとって障壁となる可能性があります。 このギャップを解消するために、私たちは Amazon SageMaker Canvas を使用しました。これは臨床医のようなMLの非専門家がコーディングや専門知識を必要とせずに ML モデルを構築してデプロイができるようになるビジュアルツールです。このユーザーフレンドリーなアプローチにより、ML に関連する急な学習曲線がなくなり、臨床医は患者に集中できるようになります。 Amazon SageMaker Canvas には、ML モデルを作成するためのドラッグアンドドロップのインターフェイスが用意されています。臨床医は、使用したいデータを選択し、必要な出力を指定して、モデルが自動的に構築されてトレーニングされるのを見守ることができます。モデルがトレーニングされると、正確な予測が生成されます。 このアプローチは、ML を使用して診断と治療に関する意思決定を改善したいと考えている臨床医にとって理想的です。Amazon SageMaker Canvas を使えば、ML の専門家でなくても、ML の力を利用して患者を助けることができます。 医療画像の分類は、患者の転帰と医療効率に直接影響します。医療画像をタイムリーかつ正確に分類することで、疾患の早期発見が可能になり、効果的な治療計画とモニタリングに役立ちます。さらに、Amazon SageMaker Canvas のようなアクセスしやすいインターフェイスを通じて ML を民主化することで、幅広い技術的背景を持たない医療従事者を含め、幅広い医療従事者が医療画像分析の分野に貢献できるようになります。この包括的なアプローチは、コラボレーションと知識共有を促進し、最終的には医療研究の進歩と患者ケアの向上につながります。 この投稿では、Amazon SageMaker Canvas が医療画像を分類する機能について説明し、その利点について説明し、医療診断への影響を実証する実際のユースケースに焦点を当てます。 ユースケース 皮膚がんは重篤で潜在的に致命的な疾患であり、早期に発見されればされるほど、治療が成功する可能性が高くなります。統計的には、皮膚がん（基底細胞がんや扁平上皮がんなど）は最も一般的ながんの種類の1つであり、毎年 世界中 で数十万人が死亡しています。皮膚細胞の異常な成長によって現れます。 ただし、早期診断により回復の可能性が大幅に高まります。さらに、外科療法、X線療法、または化学療法が不要になったり、全体的な使用量が減少したりして、医療費の削減に役立つ可能性があります。 皮膚がんの診断プロセスは、皮膚病変の一般的な形状、大きさ、色の特徴を検査するダーモスコピー [1] と呼ばれる検査から始まります。その後、疑わしい病変は、がん細胞型を確認するために、さらにサンプリングと組織学的検査を受けます。医師は、視覚的な検出から始めて、複数の方法で皮膚がんを検出します。米国皮膚科学研究センターは、 ABCD （非対称性、境界、色、直径）と呼ばれる黒色腫の考えられる形状に関するガイドを開発し、医師が疾患の初期スクリーニングに使用しています。疑わしい皮膚病変が見つかった場合、医師は皮膚の目に見える病変の生検を行い、それを顕微鏡で調べて、良性または悪性の診断と皮膚がんの種類を調べます。コンピュータービジョンモデルは、疑わしいほくろや病変を特定するうえで重要な役割を果たします。これにより、より早く、より正確な診断が可能になります。 がん検出モデルの作成は、以下に概説するように、複数の段階からなるプロセスです。 健康な皮膚やさまざまな種類のがん性または前がん性病変のある皮膚から大量の画像データセットを収集します。このデータセットは、正確性と一貫性を確保するために慎重にキュレーションする必要があります。 コンピュータービジョン技術を使用して画像を前処理し、健康な皮膚とがん性のある皮膚を区別するための適切な画像を抽出します。 教師あり学習アプローチを使用して、前処理された画像で ML モデルをトレーニングし、モデルにさまざまな肌タイプを区別するように教えます。 精度や再現率などのさまざまな指標を使用してモデルのパフォーマンスを評価し、がん性皮膚を正確に識別し、誤検知を最小限に抑えるようにします。 このモデルを、皮膚科医やその他の医療従事者が皮膚がんの検出と診断に役立つ使いやすいツールに統合します。 全体として、皮膚がん検出モデルをゼロから開発するプロセスには、通常、多大なリソースと専門知識が必要です。このような場合に、Amazon SageMaker Canvas はステップ 2 から 5 までの時間と労力を簡素化するのに役立ちます。 ソリューションの概要 コードを書かずに皮膚がんのコンピュータービジョンモデルを作成する方法を実証するために、Harvard Dataverse が公開しているダーモスコピー検査用の皮膚がん画像データセットを使用します。 HAM10000 にある10,015枚のダーモスコピー画像からなるデータセットを使用して、皮膚がんのクラスを予測する皮膚がん分類モデルを構築します。データセットに関するいくつかの重要なポイント: データセットは、学術的な ML を目的としたトレーニングセットとして機能します。 色素性病変の分野におけるすべての重要な診断カテゴリの代表的なコレクションが含まれています。 データセットには、日光角化症と上皮内がん/ボーエン病（akiec）、基底細胞がん（bcc）、良性角化症様病変（日光性黒子/脂漏性角化症および扁平苔癬様角化症、bkl）、皮膚線維腫（df）、悪性黒色腫 (mel)、色素性母斑 (nv) および血管病変 (血管腫、被角血管腫、化膿性肉芽腫および出血、vasc) データセット内の病変の50％以上が組織病理学（ヒストー）によって確認されています。 残りの症例の根拠は、フォローアップ検査（ follow_up ）、専門家の合意（コンセンサス）、または生体内共焦点顕微鏡による確認（共焦点）によって決定されます。 データセットには複数の画像を含む病変が含まれており、 HAM10000_metadata ファイル内の lesion_id 列を使用して追跡できます。 Amazon SageMaker Canvas を使用してコードを記述することなく、複数の皮膚がんカテゴリの画像分類を簡素化する方法を紹介します。SageMaker Canvas の画像分類では、皮膚病変の画像が与えられると、その画像は良性またはがんの可能性のある画像に自動的に分類されます。 前提条件 ステップセクションで説明されているリソースを作成する権限を持つ AWS アカウントへのアクセス。 Amazon SageMaker を使用するための完全な権限を持つ AWS アイデンティティおよびアクセス管理 ( AWS IAM ) ユーザー。 ウォークスルー SageMaker ドメインのセットアップ ここ で説明する手順を使用して、Amazon SageMaker ドメインを作成します。 HAM10000 データセットをダウンロードします。 データセットのセットアップ Amazon Simple Storage Service ( Amazon S3 ) バケットをユニークな名前 ( image-classification-&lt;ACCOUNT_ID&gt; ) で作成します。ACCOUNT_ID はお客様固有の AWS アカウント番号です。 Figure 1 バケットの作成 このバケットに training-data と test-data という 2 つのフォルダーを作成します。 Figure 2 フォルダーの作成 トレーニングデータで、データセットで特定された皮膚がんのカテゴリーごとに、 akiec 、 bcc 、 bkl 、 df 、 mel 、 nv 、 vasc の 7 つのフォルダーを作成します。 Figure 3 フォルダーの一覧 データセットには多数の病変の画像が含まれており、 HAM10000_metadata ファイル内の lesion_id-column で追跡できます。 lesion_id-column を使用して、対応する画像を右側のフォルダーにコピーします (つまり、分類ごとに100枚の画像から始めることができます)。 Figure 4 インポートするオブジェクトのリスト (サンプル画像) Amazon SageMaker Canvas を使用する コンソールの Amazon SageMaker サービスに移動し、リストから Canvas を選択します。Canvas ページに移動したら、 Open Canvas ボタンを選択してください。 Figure 5 Canvas に移動 Canvas ページが表示されたら、 My models を選択し、画面の右側にある New model を選択します。 Figure 6 モデルの作成 新しいポップアップウィンドウが開き、モデルの名前として image_classify という名前を付け、 Problem type で画像解析を選択します。 データセットをインポートする 次のページで、 Import an Image dataset を選択し、ポップアップボックスでデータセットに image_classify という名前を付け、 Create ボタンを選択してください。 Figure 7 データセットの作成 次のページで、 Data Source を Amazon S3 に変更します。画像を直接アップロードすることもできます (つまり、 Local upload )。 Figure 8 S3 バケットからのインポート Amazon S3 を選択すると、アカウントにあるバケットのリストが表示されます。データセットをサブフォルダーに保持する親バケット (例: image-classification-&lt;ACCOUNT_ID&gt; ) を選択した後に training-data フォルダを選択し、 Create dataset ボタンを選択します。これにより、Amazon SageMaker Canvas はフォルダ名に基づいて画像にすばやくラベルを付けることができます。 データセットが正常にインポートされると、ステータス列の値が Processing から Ready に変わります。 次に、ページの下部にある Select dataset を選択してデータセットを選択します。 モデルを作成する Build ページに、Amazon S3 のフォルダ名に従ってデータがインポートされ、ラベルが付けられているのがわかります。 Figure 9 Amazon S3 のデータのラベリング Quick build ボタン (つまり、以下の画像で紫で強調表示されているコンテンツ) を選択すると、モデルをビルドするための 2 つのオプションが表示されます。1 つ目は Quick build で、2 つ目は Standard build です。名前が示すように、クイックビルドオプションは精度よりもスピードが優先され、モデルのビルドには約 15 〜 30 分かかります。標準ビルドはスピードよりも正確さを優先し、モデル構築が完了するまでに 45 分から 4 時間かかります。Standard build は、ハイパーパラメータのさまざまな組み合わせを使用して実験を実行し、バックエンドで (SageMaker Autopilot 機能を使用して) 多数のモデルを生成してから、最適なモデルを選択します。 Standard build を選択してモデルの構築を開始します。完了するまでに約 2 ～ 5 時間かかります。 Figure 10 Standard build の実行 モデルの構築が完了すると、Figure 11 に示すような推定精度を確認できます。 Figure 11 モデルの推論 Scoring タブを選択すると、モデルの正解率 (accuracy) に関する洞察が得られるはずです。また、 Scoring タブの Advanced metrics ボタンを選択すると、適合率 (precision)、再現率 (recall)、F1 値（適合率と再現率の調和平均）が表示されます。 Amazon SageMaker Canvas に表示される高度なメトリクス（Advanced metrics）は、モデルがデータに対して数値、カテゴリ、画像、テキスト、または時系列予測のどれを実行するかによって異なります。この場合、精度よりも再現率が重要であると考えています。なぜなら、がんの検出を見逃すことは、正しい検出よりもはるかに危険だからです。2 カテゴリ予測や 3 カテゴリ予測などのカテゴリ予測は、分類の数学的概念を指します。 高度なメトリクス の再現率は、すべての実際の陽性（TP + 偽陰性）のうち、真陽性（TP）の割合です。モデルによって陽性と正しく予測された陽性インスタンスの割合を測定します。高度なメトリクスの詳細については、こちらの「 あなたのモデルは最適ですか？ Amazon SageMaker Canvas の高度なメトリクス deep dive 」を参照してください。 Figure 12 高度なメトリクス これで、Amazon SageMaker Canvas でのモデル作成ステップは完了です。 モデルをテストする Predict ボタンを選択すると、 Predict ページに移動します。Predict ページでは、 Single prediction または Batch prediction を使用して独自の画像をアップロードできます。お好みのオプションを設定し、 Import を選択して画像をアップロードし、モデルをテストしてください。 Figure 13 自分の画像を使ったテスト まず、単一画像での予測から始めましょう。 Single predict を使用していることを確認し、 Import image を選択します。これにより、 Amazon S3 から画像をアップロードするか、 Local upload を実行するかを選択できるダイアログボックスが表示されます。この例では、 Amazon S3 を選択し、テストイメージがあるディレクトリを参照して、任意のイメージを選択します。次に、 Import data を選択します。 Figure 14 Single image prediction 選択すると、 Generating prediction results という画面が表示されます。以下に示すように、数分で結果が出るはずです。 それでは、バッチ予測を試してみましょう。 Run predictions で Batch prediction を選択し、 Manual から Create dataset を選択し、 BatchPrediction という名前を付けて Create ボタンを押します。 Figure 15 Single image prediction の結果 次のウィンドウで、Amazon S3 アップロードを選択したことを確認し、テストセットがあるディレクトリを参照して、 Import data ボタンを選択します。 Figure 16 Batch image prediction 画像が Ready になったら、作成したデータセットのラジオボタンを選択し、Generating predictions を選択します。これで、バッチ予測のステータスが Generating predictions になっているはずです。結果が出るまで数分待ちましょう。 ステータスが Ready になったら、データセット名を選択すると、すべての画像の詳細な予測を表示するページに移動します。 Figure 17 Batch image prediction の結果 バッチ予測のもう 1 つの重要な機能は、結果を検証できることと、予測を zip または csv ファイルでダウンロードして、さらに使用または共有できることです。 Figure 18 Download prediction これで、Amazon SageMaker Canvas を使用してモデルを作成し、トレーニングし、その予測をテストすることができたはずです。 クリーンアップ 左側のナビゲーションペインで Log out を選択して Amazon SageMaker Canvas アプリケーションからログアウトし、 SageMaker Canvas ワークスペースのインスタンス時間 の消費を停止し、すべてのリソースを解放します。 引用 [1]Fraiwan M, Faouri E. On the Automatic Detection and Classification of Skin Cancer Using Deep Transfer Learning . Sensors (Basel). 2022 Jun 30;22(13):4963. doi: 10.3390/s22134963. PMID: 35808463; PMCID: PMC9269808. まとめ 本記事では、ML 技術を用いた医療画像解析が皮膚がんの診断を迅速化する方法と、他の疾患の診断への応用について紹介しました。ただし、画像分類用の ML モデルの構築は、多くの場合、複雑で時間がかかり、コーディングの専門知識と ML の知識が必要です。Amazon SageMaker Canvas は、コーディングや専門的な ML スキルを必要としないビジュアルインターフェイスを提供することで、この課題に対処しました。これにより、医療従事者は急な学習なしで ML を使用できるようになり、患者のケアに集中できるようになります。 がん検出モデルを開発する従来のプロセスは、面倒で時間がかかります。これには、精選されたデータセットの収集、画像の前処理、ML モデルのトレーニング、パフォーマンスの評価、医療従事者向けの使いやすいツールへの統合が含まれます。Amazon SageMaker Canvas は前処理から統合までのステップを簡素化し、皮膚がん検出モデルの構築に必要な時間と労力を削減しました。 この投稿では、医療画像分類において、Amazon SageMaker Canvas が非常に有効であることを説明しました。私たちが調査した説得力のあるユースケースの 1 つは、皮膚がんの検出と、早期診断によって治療成績が大幅に向上し、医療費が削減されることが多いというものでした。 モデルの精度は、トレーニングデータセットのサイズや採用するモデルの種類などの要因によって異なる可能性があることを認識することが重要です。これらの変数は、分類結果のパフォーマンスと信頼性を決定する役割を果たします。 Amazon SageMaker Canvas は、医療従事者がより正確かつ効率的に病気を診断するのを支援する非常に貴重なツールとして役立ちます。ただし、医療従事者の専門知識や判断に取って代わるものではないことに注意することが重要です。むしろ、能力を強化し、より正確で迅速な診断を可能にすることで、彼らに力を与えます。意思決定プロセスにおいて人的要素は依然として不可欠であり、医療専門家と Amazon SageMaker Canvas などの人工知能 (AI) ツールとのコラボレーションは、最適な患者ケアを提供する上で極めて重要です。 翻訳はソリューションアーキテクト菊地が担当しました。原文は こちら です。 著者について Ramakant Joshi は AWS ソリューションアーキテクトで、分析とサーバーレスドメインを専門としています。ソフトウェア開発とハイブリッドアーキテクチャのバックグラウンドを持ち、お客様のクラウドアーキテクチャの近代化を支援することに情熱を注いでいます。 Jake Wen は AWS のソリューションアーキテクトで、ML、自然言語処理、ディープラーニングへの情熱に基づいています。彼は、企業のお客様がクラウドでのモダナイゼーションとスケーラブルな導入を実現できるよう支援しています。テクノロジーの世界以外でも、ジェイクはスケートボード、ハイキング、エアドローンの操縦に喜びを見出しています。 Sonu Kumar Singh は、分析ドメインを専門とする AWS ソリューションアーキテクトです。彼は、データ主導の意思決定を可能にし、それによってイノベーションと成長を促進することにより、組織の変革をもたらす変化を促進することに尽力してきました。彼は自分がデザインしたり作ったものがポジティブなインパクトをもたらすことを楽しんでいます。AWS では、お客様が AWS の 200 を超えるクラウドサービスから価値を引き出し、クラウドへの移行を支援することを目指しています。 Dariush Azimi は AWS のソリューションアーキテクトで、  機械学習、自然言語処理 (NLP)、Kubernetes によるマイクロサービスアーキテクチャを専門としています。彼の使命は、データストレージ、アクセシビリティ、分析、予測機能を含む包括的なエンドツーエンドソリューションを通じて、組織がデータの可能性を最大限に活用できるようにすることです。