この記事は Firework simplifies live ecommerce with Amazon IVS (記事公開日: 2023 年 4 月 10 日) を翻訳したものです。 ショッパブルビデオのスタートアップは、マネージド型ライブストリーミングサービスを採用して大規模環境での安定性を実現 消費者の行動と期待値は、大きく変化しました。この変化に対し、小売業者はライブストリームビデオなどの画期的な技術を使って顧客とのつながりを深め、買い物客がお気に入りのブランドに関わる方法を変えています。上手に活用すれば、これらのビデオはマネタイズ可能であり、ライブショッピングと呼ばれるライブストリーム e コマースには大きな収益機会があります。 Statista によると、2022 年の米国におけるライブショッピングの売上高は 170 億ドルと推定されており、2026 年までに 550 億ドルに達すると予測されています。これは、アジアですでに行われているもののごく一部に過ぎません。2021 年の マッキンゼーの報告書 によると、中国のライブストリームショッピングは 30 億ドルから 1,710 億ドルに成長しました。2017 年から 2020 年の間に、中国のライブコマース市場の価値は年平均成長率 (CAGR) 280% 以上で成長しました。 ショッパブルビデオのスタートアップで AWS パートナーの Firework は、 Amazon Web Services (AWS) を利用することで、ウェブサイトやアプリにライブ、およびオンデマンドビデオを簡単かつ迅速に統合できるダイナミックなプラットフォームを提供し、ブランドやクリエイターがこのトレンドを活用できるように支援しています。高品質と低レイテンシーが最も重要であるため、Firework は Amazon Interactive Video Service (Amazon IVS) を使用してライブコンテンツを配信しています。Amazon IVS は、インタラクティブなビデオ体験を迅速かつ簡単にセットアップできるように設計されたマネージド型ライブストリーミングソリューションです。プラットフォームを構築するためのソリューションを探す際、 Firework は、低レイテンシー、グローバルなスケーラビリティ、モバイルブロードキャスト用のソフトウェア開発キット (SDK) を理由として Amazon IVS を選択しました。 ※上記イメージの動画バージョンは、 原文 をご覧ください。 「ライブストリーミングをサードパーティのサイトに依存しているブランドは、それら企業の開発サイクルのなすがままになっており、エクスペリエンスの提供が制限されています。この機能を Web サイト内でネイティブに構築するには、バックエンドに 1 行のコードを追加するだけです。これにより、戦略に役立つ豊富な情報が手に入ります」と、Firework の CTO である Rick Zhuang 氏は説明します。「スピードと安定性は、ポジティブなライブストリーム体験に不可欠です。それ以下では取引が成り立たなくなります。AWS は高く評価されており、テクノロジーのグローバルリーダーです。Amazon IVS が当社のライブストリームを支えることで、お客様は世界中の大勢の視聴者に優れた体験を提供でき、シームレスな小売取引が可能になります。」 AWS 上に構築された Firework は、2020 年に初めてショッパブルビデオプラットフォームとして実装されました。このサービスは、37 カ国以上の幅広いブランドからすぐに採用されるようになりました。ライブ配信では最大 20 倍の ROI 向上効果があり、サイト滞在時間は最大 282% 増加、コンバージョン率は最大 307% 向上しています。1 秒あたり最大 900 万件のトランザクションをサポートできるこのプラットフォームは、AWS リソースの可用性を最大限に活用し、ライブストリーミング、ショートビデオホスティング、ニアリアルタイムの在庫トラッキング、インタラクティブなチャットと投票、トランザクション機能などをナビゲーションしやすいブラウザベースのインターフェイスに組み込んでいます。 Firework プラットフォームでは、ブランドが配信される前に、配信中に紹介したい購入可能なアイテムのリストを作成できます。また、Amazon IVS metadata API を介して、動画に同期されたインタラクティブな要素を段階的に配置することもできます。これにより、視聴体験をコンテンツの展示と最適なアライメントに保つことができます。また、Firework では、顧客やホストが Amazon IVS broadcast SDK を使用して携帯電話で簡単にライブ配信を行えるよう、再利用可能なライブ配信を含む録画済みのショッパブルビデオをホストできます。ライブコンテンツの不正使用や拡散を防ぐために、 Firework は Amazon IVS の再生認証機能を使用し、開発者が JSON Web Tokens (JWTs) で保護されたプライベートチャンネルを起動できるようにしています。 「コンテンツを視聴している人が誰で、彼らがどのように反応するかを把握できることは非常に有益です。Firework のユーザーは、視聴率だけでなく、コメント、投票、クイズの回答からも重要な情報を収集することができます。このソリューションを使用することで、さまざまな製品や配信ホストなどの変化を比較し、将来のライブ配信を微調整することができます」と Zhuang 氏は述べています。 Firework のシンプルな実装は、社内に開発リソースがない小規模なブランドにとって特に役立ちます。プラットフォームのコードをユーザーのウェブサイトやアプリに統合すれば、その全機能を使用するのは、ソーシャルメディアへの投稿を作成するのと同じくらい簡単です。さらに、プラットフォームの料金設定は視聴時間に基づいており、始めたばかりの企業のコストを最小限に抑え、実験を促します。 「結局のところ、私たちはデジタルストアフロントを再定義しつつあり、それが e コマースを変えるでしょう。一部のレガシーな小売業者のサイトは 10 年以上変わっていませんが、今では多くの人々が、インターネットを動画コンテンツを中心に利用しています。私たちのビジョンは、静的な画像の代わりに、スワイプ可能なインタラクティブな動画をサイトに掲載し、ショッピング体験を向上させることです」と、Zhuang 氏は締めくくります。 Amazon IVS に加えて、Firework プラットフォームは AWS Elemental MediaLive (MediaLive) を使用しています。MediaLive は高品質なストリームを作成する放送局レベルのライブ動画処理サービスで、 Instagram や Facebook などのサードパーティの SNS プラットフォームにライブストリームを再配信することで、顧客に真にグローバルな体験を提供しています。このプラットフォームでは、 Content Delivery Network (CDN) サービスである Amazon CloudFront も使用しており、AWS の Points of Presence (POP) を使用して、低遅延かつ高速な転送速度で安全にコンテンツを配信しています。 Amazon IVS による魅力的なライブストリームとインタラクティブな動画体験の構築の詳細は、 当社のウェブサイト をご覧ください。 AWS Partner spotlight Firework は、ライブストリームとショッパブルビデオを通じて、ブランドのデジタルストアフロントにライブコマースを提供します。 Amazon Interactive Video Service (Amazon IVS) によって支えられている Firework のビデオコマースソリューションは、ブランド、小売業者、出版社に対し、相互作用とコミュニティエンゲージメントをシームレスかつ大規模に促進する、簡単にデプロイできるライブストリームショッピングテクノロジーを提供します。   この記事は、Josh Walters と Akshara Shah によって書かれた Firework simplifies live ecommerce with Amazon IVS の日本語訳です。翻訳は、ソリューションアーキテクトの髙橋伸幸が担当しました。

2023 年 5 月アマゾン ウェブ サービス ジャパン合同会社 （以下、AWSジャパン）と新潟県は、 地域産業の活性化に向けて、 スタートアップ支援、デジタル人材の育成を軸とした DX を加速する包括的な連携を発表 しました。スタートアップ支援、地域産業のデジタルトランスフォーメーション支援、デジタル人材の育成支援、県行政の DX 支援、の 4 つの支援を軸として、県全体の包括的な DX に連携して取り組んでいくこととしています。 AWS と、AWS の認定トレーニングパートナーである トレノケート は、新潟県の地域のリーダーを育てる新しい取り組み、NINNO ACCADEMIA において、AWSのクラスルームトレーニング Developing on AWS を提供しました。今回はその取り組みをご紹介します。 写真左から、新潟県知事 花角 英世 氏、AWSジャパン代表執行役員社長 長崎 忠雄 「変革と挑戦　選ばれる新潟」の実現に向けた取り組み 新潟県では、首都圏への人口流出の加速、高齢化等の地域課題を解決するため、「変革と挑戦　選ばれる新潟の実現」を掲げて、スタートアップの創出、地域産業のDX化、デジタル人材の育成に力を入れています。具体的には、スタートアップ・IT企業の集積を目指すイノベーション拠点 NINNO （ニーノ）をオープンし、 J-Startup NIIGATA をはじめとした、地域のスタートアップや起業家人材育成支援等を行っています。 2023年10月に、NINNO において、DX 推進、起業家、CTO など地域のリーダーを目指す人材を育てることを目的とした人材育成事業 NINNO ACCADEMIA が開講されました。起業を志す人とスタートアップ、大手企業、行政、大学機関などが交流し、ヒト・モノ・カネの循環が生まれるイノベーションのエコシステムを新潟で創出していくことを目的としています。同事業は国土交通省の「インキュベーション施設等都市間連携プロジェクト」にも選定されており、2025 年までに累計 1800 人の受講者数を目指しています。 新潟発イノベーション人材育成に向けてー CTO人材の輩出も目指すNINNO ACCADEMIAー NINNO ACCADEMIA をリードされている、BSN アイネット執行役員 イノベーション推進室長の坂田 源彦 氏は、NINNO ACCADEMIA について、以下のように述べています。 「IT 活用が広まる中で、新潟における IT 人材は枯渇してきており、人材の争奪戦になっています。そんな中で、社会課題をなんとかしたいと考える地域のリーダーを育てる目的でこちらの NINNO ACCADEMIAを構想しました。新潟の地域・社会課題を解決していく人材を育てるために、様々なプログラムを提供しています。AWS トレーニングを提供しようと考えたきっかけは、2023 年 5月の AWS と新潟県の包括連携協定です。AWS を使う人口は新潟では多く、AWS  ユーザーコミュニティである JAWS-UG の 新潟支部 の活動も活発です。 DERTA を始め、エンジニアコミュニティ作り・ネットワーキング活動が活発化してきており、そういった動きを加速していく狙いもあります。 CTO 人材を育成していくという狙いもありますから、AWS は、初級ではなく中級レベルのトレーニング Developing on AWS を敢えて選びました。このプログラムでは、令和 7 年度までにCTO を 3 人輩出することも目標にしています。」 NINNO ACCADEMIA 開校式の様子 新潟県 産業労働部 創業・イノベーション推進課 鈴木 純一 氏に、本取り組みの背景についてお伺いしました。 「新潟県では、県内の企業のオープンイノベーション、大企業、スタートアップ、行政や大学のオープンイノベーションを加速させることを目指し、各プレイヤーが交わる場所であるイノベーション拠点 NINNO の取組を支援してきました。県としてもエンジニアコミュニティの形成や人材育成に力を入れており、連携協定締結後は、 DERTA と連携して AWSのハンズオンなどを開催 してきました。 今回の NINNO ACCADEMIA は、拠点を運営する 木山産業 、 けんと放送 、 BSNアイネット を始め、地元の民間企業が主導で立ち上げ、AWS にも協力いただけることになり、地域のイノベーションエコシステムが循環する非常に良い流れと考えています。行政としてもこの流れを後押しし、『変革と挑戦、選ばれる新潟の実現』を加速させていきたいです。」 クラスルームトレーニング Developing on AWSとは？ 今回は、数ある AWS の クラスルームトレーニング のうち、デベロッパー向けの中級コースの Developing on AWS を提供しました。2013年より、AWSの 認定トレーニングパートナー として、 AWS Training Partner of the Year – Global Awardを2年連続で受賞 している トレノケート の高山 裕司 氏がインストラクターを務めました。 クラスルームトレーニングコースマップ Developing on AWS コースの概要 このコースは、AWS の認定インストラクターから、AWS のサービスと AWS SDK や AWS CLI などのデベロッパーツールを使用して、安全でスケーラブルなクラウドアプリケーションを開発する方法を学ぶのに役立ちます。コードを使用して AWS を操作する方法について詳しく説明します。また、主要な概念、ベストプラクティス、トラブルシューティングのヒントについても説明します。この 3 日間のクラスルームトレーニングコースでは、プログラムで AWS のサービスを利用して、ウェブソリューションを構築する方法を学びます。 学習目標 AWS ソフトウェア開発キット (AWS SDK)、Command Line Interface (AWS CLI)、および IDE を使用して、シンプルなエンドツーエンドのクラウドアプリケーションを構築する 開発環境をサポートするための AWS Identity and Access Management (IAM) 許可を設定する アプリケーションで複数のプログラミングパターンを使用して AWS のサービスにアクセスする AWS SDK を使用して、Amazon Simple Storage Service (Amazon S3) および Amazon DynamoDB リソースで CRUD (作成、読み取り、更新、削除) 操作を実行する その他 インストラクターを務めた高山 氏は、今回トレーニングを提供した感想として、以下のように述べています。「この度は弊社をトレーニングパートナーにお選びいただき、大変嬉しく思います。オンラインだけではなく、地域のイノベーションを担っていくというモチベーションの高い受講者様と実際にお会いすることで、より濃密なトレーニングをご提供できたと思います。こうした取り組みが、その地域ならではの課題の解決や、イノベーションを進めていくことに繋がると感じられて非常に意義があると感じています。」 Developing on AWS トレーニングの様子 受講者の一人である リンクチャネル株式会社 の鈴木 優紀 氏は、受講の感想についてこのように述べています。 「私はもともと業務で AWS を使う立場でしたが、自力で業務の中で勉強していくことに限界を感じていました。会社として AWS を使っていく方向性だったので、体系的に学ぶ非常によい機会と考え、受講しました。なんといっても、新潟県のお墨付きで AWSのトレーニングが提供されるため、勤務時間内でやることに関して会社にもすぐ納得いただけました。 実際に受講してみて、知らないこと、例えば Amazon CloudWatch などの運用やオブザーバビリティが軽視されがちなことなど、講義の形できっちり教わらないとできないことがあると実感しました。 コースの内容のうち、7-8 割は使ったことがあるサービスでしたが、自己流でやっていたところの裏付けができて非常によかったですし、今回初めて教わった Amazon Dynamo DB  と Amazon API Gateway などは早速業務で活用できる場面がでてきそうです。業務をしながら学んですぐ実装できるのは、事業会社ならではのメリットですね。AWSが新潟県と連携協定を結んでこうして講座が提供され、地場のユーザー企業としては非常に力強く感じます。」 おわりに いかがでしたでしょうか。今回は、新潟県のイノベーション人材育成講座  NINNO ACCADEMIA への Developing on AWS の活用事例についてご紹介しました。 AWS は今後も、様々な地域でイノベーションを担う人材育成をご支援していきます。ご紹介した Developing on AWS 以外にも、多様なレベルのAWS トレーニングをご用意しております。ご関心のある方は、お気軽に こちら よりお問い合わせください。ご連絡をお待ちしております！ このブログは、 アマゾンウェブサービスジャパン合同会社 パブリックセクター シニア事業開発マネージャーである岩瀬 霞が執筆しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 12月に入り、re:Invent 2023も無事終了しました。私自身は仕事の関係でラスベガスに滞在していたのですが、例年にもましてお客様の熱気が凄く圧倒されてしまいそうになりました。たくさんのアップデートも発表されましたので、まだキャッチアップできていないと言う方は まとめWebinarの資料や録画 をご覧ください。 もっと細かく深掘りするスタイルの振り返りセミナーも開催予定です。 業界カット のものと、 ソリューションカット のものがありますので、こちらもぜひよろしくお願いします。 それでは、12 月 4 日週のアップデートを振り返ってみましょう。 2023 年 12 月 4 日週の主要なアップデート 12/4(月) Amazon SageMaker Canvasで包括的なデータ準備機能が利用可能に コーディング不要で機械学習による予測や、基盤モデルをすぐに利用できるAmazon SageMaker Canvasのデータ準備機能が強化されました。50以上のデータソースからデータをインポートし、300種類以上が用意されている組み込み演算子を利用してデータ準備が可能です。専門的な知識なしに作業に取りかかれるので、データ活用に取り組むハードルを引き下げ、より幅広い方にデータ活用にチャレンジいただけます。 Amazon RedshiftでSUPER型のカラムサイズが最大16MBに Amazon Redshiftで半構造化データやドキュメントを格納するためのSUPERデータ型で、最大データサイズが1MBから16MBに拡張されました。1MBを超えるデータを格納する場合も、事前処理なくそのままRedshiftに取り込んで分析処理を実行できます。 12/5(火) AWS Console Mobile App for iOSでAmazon Qがプレビュー可能に 生成系AIベースのアシスタントサービスであるAmazon QがiOS向けのAWS Console Mobile Appでもご利用いただけるようになりました。現時点ではプレビューの扱いです。質問をテキストで入力したり、音声入力で質問すると、AWSに関する疑問に対する回答を得ることが可能です。 Amazon Rekognitionで精度とレイテンシが改善されたFace APIバージョン7をリリース Amazon Rekognitionが提供するFace APIのバージョン7がリリースされ、顔検出・比較・検索の精度がさらに向上し、レイテンシーが短縮されました。精度向上とレイテンシ短縮はユーザエクスペリエンスの向上につながることがメリットです。 AWS DMSが移行ターゲットとしてAmazon RDS for Db2をサポート AWS DMS(Database Migration Service)が移行先ターゲットとして、Amazon RDS for Db2がサポートされました。オンプレミス環境やEC2で独自に構築したDb2環境をマネージドサービスに移行することが容易になります。なお、フルロードとCDC(Change Data Capture)の双方に対応しています。 12/6(水) AWS Lambdaでスケールアップが12倍高速に AWS Lambdaのスケールアップ速度が向上し、アカウント単位で設定されたLambda functionに対する同時実行数の上限にヒットしない範囲で、10秒ごとに1,000同時実行のスピードでスケールアップが可能になりました。変動の大きいトラフィックであり、一定時間以内に応答を返さなければいけない、といったユースケースで嬉しいアップデートです。 Amazon QuickSightのSPICEエンジンが並列データ取り込みに対応し最大4倍高速に Amazon QuickSightのインメモリエンジンであるSPICEのデータ取り込み速度が最大4倍高速になりました。この高速化は並列取り込みに対応したことによるものです。特に大規模なデータセットの取り込みで効果的です。特に設定変更は必要なく、起動時に自動で有効化されます。 Amazon EC2 Instance ConnectがRHEL/CentOS/macOSに対応 EC2インスタンスに安全に接続する方法、Amazon EC2 Instance Connectの対応OSが拡張されました。従来から利用可能だったAmazon Linux, Ubuntuに加えて、RedHat Enterprise Linux(RHEL), CentOS, macOSでご利用いただけるようになりました。Amazon EC2 Instance Connectを利用するとインスタンスへの接続可否をIAMポリシーで制御したり、AWS CloudTrailでアクセスログを取得できるので、管理が容易なところがポイントです。 12/7(木) AWS IoT SiteWiseのデータを可視化するダッシュボードをノーコードで作成可能に オープンソースのIoTダッシュボードアプリケーションを新たに発表しました。このツールはIoT Application Kit上に構築されており、ドラッグアンドドロップの操作でAWS IoT SiteWiseから収集したデータを可視化することが可能です。 GitHubリポジトリはこちら です。 AWS Lambda関数とAmazon RDS, Amazon RDS Proxyへの接続が簡単に AWS Lambdaのコンソールを利用して、Lambda関数をAmazon RDSまたはAmazon RDS Proxyに接続できるようになりました。ガイド付きのワークフローが提供され、それに従う形で既存のデータベースインスタンスやRDS Proxyに接続できます。VPC周辺の設定やAWS Secrets Managerで管理されるシークレット情報を手動で行う必要がなくなり、便利かつ安全に作業を実行できます。 12/8(金) Amazon CloudWatchでアカウントをまたいでMetrics Insightを利用可能に Amazon CloudWatchは複数のアカウントにまたがって可観測性(オブザーバビリティ)を提供する機能がありますが、今回新たにMetrics Insightを利用できるようになりました。CloudWatch Metrics Insightは大量のメトリクスデータの分析に利用できるSQLエンジンです。複数アカウントのメトリクスに対して利用可能になったことにより、これまでよりも広範な分析が可能になるだけでなく、複数の要素を加味してアラーム発報するような仕組みを作れることも嬉しいポイントです。 週刊AWSのアイキャッチ写真を撮影したのが、今年の3月だということに気づきました。新メンバーを迎えた新体制にもなっていますので、そろそろ写真を撮り直さないとなと思っています。近いうちに新しい写真に切り替わる（といいな）と思いますので、ご期待ください。 ソリューションアーキテクト 小林 正人 (twitter – @maccho_j )

本ブログは 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 原文は こちら です。