この記事は “ 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 によるマイクロサービスアーキテクチャを専門としています。彼の使命は、データストレージ、アクセシビリティ、分析、予測機能を含む包括的なエンドツーエンドソリューションを通じて、組織がデータの可能性を最大限に活用できるようにすることです。

11月26日、クラウド導入の促進、生産性の向上、イノベーションの推進を実現する完全マネージド型のナレッジサービスである AWS re:Post Private を開始します。re: Post Private を使用すると、組織はコラボレーションを強化し、クラウドコミュニティ向けに構築されたナレッジリソースにアクセスできるようになります。これには、AWS の厳選された技術コンテンツとトレーニング資料が含まれています。コンテンツは、組織のメンバーと AWS アカウントチームのためのプライベートディスカッションやコラボレーションフォーラムとともに、組織のユースケースに合わせて特別にカスタマイズされています。 その名前が示すように、 AWS re:Post のプライベートバージョンと考えることができます。プライベートコンテンツとアクセスは、組織と AWS アカウントチームに属するユーザーに限定されます。 あらゆる規模や業種の組織が、業務をクラウドに移行するケースが増えています。クラウドの導入を成功させるには、組織は適切なスキルと構造を備えている必要があります。これを実現する最適な方法は、一元化された Cloud Center of Excellence (CCOE) を設立することです。CCOEは組織の一元的なガバナンス機能であり、ビジネスにおける中央IT、ビジネスユニットIT、およびクラウドサービスの利用者を対象としたコンサルティングの役割を果たします。 ガートナーによると 、CCOEにはガバナンス、仲介、コミュニティという 3 つの柱があります。コミュニティの柱は、利害関係者を集めてクラウドコラボレーションを促進するクラウドコミュニティオブプラクティス（COP）を確立します。COPメンバーとの交流を促進し、クラウド関連のトレーニングやスキル開発を促進することで、組織がクラウドの採用に適応できるよう支援します。 AWS re:Post Private は、社内クラウド実践コミュニティの作成、構築、管理を促進します。これにより、検索や再利用が可能な、スケーラブルなカスタムナレッジベースを構築できます。コミュニティメンバーは、プライベートな質問や回答を投稿したり、記事を公開したりできます。従来のフォーラムの利点であるコミュニティでの議論やコラボレーションと、統合された情報体験の利点を兼ね備えています。 AWS re:Post Private は完全マネージド型のサービスです。複雑なナレッジマネジメントやコラボレーションテクノロジーを運用したり、カスタムソリューションを開発したりする必要はありません。 AWS re:Post Private を使用すると、 AWS サポート とのやり取りも容易になります。プライベートの re: Post から直接サポートケースを作成でき、ケースの解決を組織内のすべての人が参照できる再利用可能な知識に変換できます。 RE: Post Private でデータを保存する AWS リージョンと、アクセスできるユーザーを選択します。保管中および転送中のすべてのデータは、業界標準のアルゴリズムを使用して暗号化されます。管理者は、AWS が管理する暗号化キーを使用するか、お客様が管理および操作するキーを使用するかを選択します。 組織のテクニカルアカウントマネージャーは、プライベート re: Post に自動的に追加されます。組織や AWS チームの中から、自分の AWS ソリューションアーキテクトなど、他の人を招待するように選択できます。AWS アカウントを必要とするのは、プライベートの re: Post 管理者のみです。他のすべてのユーザーは、Microsoft Active Directory などの組織の ID プロバイダーからフェデレーションできます。 re: Post Private を作成する方法を見てみましょう AWS re:Post Private の使用を開始するにあたり、管理者として、ブラウザで AWS マネジメントコンソールの re: POST セクション にアクセスします。 [プライベート re: Post を作成] を選択し、組織、チーム、またはプロジェクト用にプライベートの re: Post を作成するために必要な情報を入力します。 データ暗号化 パラメータと、 サポートケース統合のためのサービスアクセス を有効にするかどうかを選択できます。準備ができたら、 [この re: Post を作成] を選択します。 プライベート re: Post が作成されたら、ユーザーやグループにアクセス権を付与できます。ユーザーとグループの情報は、 AWS IAM アイデンティティセンター とアイデンティティプロバイダーから取得されます。招待されたユーザーには、プライベート re: Post に接続してプロフィールを作成するよう招待するメールが届きます。 管理者側の作業はこれでほぼ終わりです。プライベート re: POST が作成されると、組織の他のメンバーと共有できるエンドポイント名を受け取ります。 Re: Post Private の使い方を見てみましょう 組織の一員として、管理者から受け取ったリンクを使って re: Post Private に移動します。組織の通常のIDサービスで認証すると、re: Post Private のランディングページにリダイレクトされます。 トップメニューでは、タブを選択して、 [質問] 、 [コミュニティ記事] 、 [セレクション] 、 [タグ] 、 [トピック] 、 [コミュニティグループ] 、または [マイダッシュボード] のコンテンツを表示できます。これは、同様の構造を採用した公開ナレッジサービス AWS re:Post を既に使用している場合は、馴染みがあるはずです。 ページのさらに下には、人気のあるトピックと組織内のトップ投稿者が表示されます。また、 質問 や コミュニティグループ にもアクセスできます。検索できるコンテンツを、キーワード、タグ、著者などで検索できます。 料金と利用可能性 組織の AWS re:Post Private は、米国西部 (オレゴン) と欧州 (フランクフルト) の AWS リージョンで作成できます。 AWS re:Post Private は、AWS エンタープライズまたはエンタープライズオンランプサポートプラン をお持ちのお客様にご利用いただけます。re:Post Private では、標準機能を 6 か月間試用できる 無料利用枠 を提供しています。無料利用枠のユーザー数に制限はなく、コンテンツストレージは 10 GB に制限されています。無料ストレージの上限に達すると、プランは有料のスタンダード階層に変換されます。 AWS re:Post Private Standard 階層では、使用した分だけお支払いいただきます。1 か月あたりのユーザー数に基づいて課金されます。詳細については、「 re: Post プライベート価格ページ 」をご覧ください。 今すぐ始めて、組織で AWS re:Post Private を有効にしてください。 — seb 原文は こちら です。

機械学習を使用して統計的な異常や、異常なパターンを検出することにより、データ品質を向上させるのに役立つ新しい AWS Glue Data Quality 機能のプレビューを開始します。コードを書かなくても、データ品質の問題に関する深いインサイト、データ品質スコア、および異常を継続的に監視するために使用できるルールに関する推奨事項が得られます。 データ品質の重要性 AWS のお客様は、データを抽出して変換するためのデータ統合パイプラインをすでに構築しています。データ品質ルールを設定して、生成されるデータが高品質で、ビジネス上の意思決定を正確に行えるようにします。多くの場合、これらのルールは、ビジネスの現状を反映して、特定の時点で選択され固定された基準に基づいてデータを評価します。しかし、ビジネス環境が変化し、データの特性が変化すると、ルールが常に見直され、更新されるとは限りません。 たとえば、初期段階のビジネスで 1 日の売上高が 1 万ドル以上であることを確認するルールを設定できます。ビジネスが成功し成長するにつれて、ルールは時々チェックして更新する必要がありますが、実際にはそうなることはほとんどありません。その結果、売上が予想外に減少した場合、時代遅れのルールは有効にならず、誰も満足しません。 実行中の異常検出 異常なパターンを検出し、データに関するより深いインサイトを得るために、組織は独自の適応型システムを作成しようとしたり、あるいは特定の技術スキルと専門的なビジネス知識を必要とする高価な商用ソリューションに頼ろうとします。 この広範囲に及ぶ課題に対処するため、Glue Data Quality では現在、機械学習 (ML) を利用しています。 Glue Data Quality に新しく追加されたこの便利な機能は、一度起動すると、新しいデータが届くたびに統計を収集し、機械学習と動的しきい値を使用して過去のパターンから学習し、外れ値や異常なデータパターンを調べます。このプロセスでは観測結果が得られ、傾向も視覚化されるため、異常をすばやく理解できます。 また、オブザベーションの一部として推奨ルールも表示され、それらをデータパイプラインに簡単かつ段階的に追加できます。ルールは、データパイプラインの停止などのアクションを強制できます。以前は、静的ルールしか記述できませんでした。これで、しきい値を自動調整する動的ルールと、繰り返し発生するパターンを把握して偏差を特定する 異常検出 ルールを作成できます。ルールをデータパイプラインの一部として使用すると、データフローが停止して、データエンジニアが確認、修正、再開できるようになります。 異常検出を使用するには、ジョブに データ品質評価 ノードを追加します。 ノードを選択し、 [アナライザーの追加] をクリックして統計と列を選択します。 Glue Data Quality は、データから学習してパターンを認識し、観測値を生成して [データ品質] タブに表示します。 そしてビジュアライゼーション: 観察結果を確認した後、新しいルールを追加します。1 つ目は、行数が過去 10 回の実行の最小値と、過去 20 回の実行の最大値の間にあることを確認する適応しきい値を設定します。もう 1 つは、週末に rowCount が異常に多いなど、異常なパターンを探すものです。 プレビューに参加しましょう この新しい機能は現在、以下の AWS リージョンでプレビューでご利用いただけます。米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) 。詳細については、データ品質異常検出]] をご覧ください。 この機能がリリースされたら、詳細なブログ投稿をお楽しみに！ 詳細はこちら データ品質異常検出 – Jeff ; 原文は こちら です。

11月26日、 Application Load Balancer に X509 証明書を提示する相互認証クライアントのサポートについてお知らせします。この新機能により、クライアント認証をロードバランサーにオフロードして、信頼できるクライアントだけがバックエンドアプリケーションと通信できるようになります。この新機能は、強力な暗号化とゼロデイ脆弱性からの保護を提供するAWSのオープンソース Transport Layer Security (TLS) 実装である S2N に基づいて構築されており、開発者はこれを信頼できます。 相互認証 (mTLS) は、オンラインバンキング、自動車、ゲームデバイスなどの企業間 (B2B) アプリケーションで、デジタル証明書を使用してデバイスを認証するためによく使用されます。企業は通常、データやサービスへのアクセスを許可する前に、プライベート認証局 (CA) とともにクライアントを認証します。 お客様は、自分で作成したソリューションまたはサードパーティのソリューションを使用して相互認証を実装しており、追加の時間と管理オーバーヘッドが必要です。これらの顧客は、エンジニアリングリソースを費やしてバックエンドに機能を組み込んだり、最新のセキュリティパッチに対応するようにコードを更新したり、証明書を作成および更新するためのインフラストラクチャに多額の投資を行ったりしています。 Application Load Balancer での相互認証により、完全に管理されたスケーラブルで費用対効果の高いソリューションが実現し、開発者リソースを他の重要なプロジェクトに集中できるようになります。ALB は失効チェックでクライアントを認証し、クライアント証明書情報をターゲットに渡します。この情報はアプリケーションによる承認に使用できます。 ALB での相互認証の開始方法 ALB で相互認証を有効にするには、 Amazon EC2 コンソールの ALB ウィザード で [ Application Load Balancer の作成] を選択します。 リスナーとルーティングのセクション で [HTTPS] を選択すると、セキュリティポリシー、デフォルトサーバー証明書、相互認証をサポートする新しいクライアント証明書処理オプションなど、その他の設定が表示されます。 相互認証 (mTLS) を有効にすると、クライアント証明書を提示するリクエストをリスナーがどのように処理するかを設定できます。これには、Application Load Balancer が証明書を認証する方法と、バックエンドターゲットに送信される証明書メタデータの量が含まれます。 相互認証には 2 つのオプションがあります。 Passthrough オプションは、クライアントから受信したすべてのクライアント証明書チェーンを、HTTP ヘッダーを使用してバックエンドアプリケーションに送信します。MTLS 対応の Application Load Balancer は、ハンドシェイクでクライアント証明書を取得し、TLS 接続を確立して、HTTPS ヘッダーで取得したものをターゲットアプリケーションに送信します。アプリケーションは、クライアントを認証するためにクライアント証明書チェーンを検証する必要があります。 トラストストアで検証 オプションを使用すると、Application Load Balancer とクライアントは互いの ID を検証し、TLS 接続を確立して両者間の通信を暗号化します。新しいトラストストア機能が導入されました。 AWS Private Certificate Authority またはその他のサードパーティ CA によって生成されたルート証明書や中間証明書を含む CA バンドルを信頼するソースとしてアップロードして、クライアント証明書を検証できます。 既存のトラストストアを選択するか、新しいトラストストアを作成する必要があります。トラストストアには、CA、信頼できる証明書、およびオプションで証明書失効リスト (CRL) が含まれます。ロードバランサーはトラストストアを使用してクライアントとの相互認証を行います。 このオプションを使用して新しいトラストストアを作成するには、Amazon EC2 コンソールの左側のメニューで [トラストストア] を選択し、 [トラストストアの作成] を選択します。 PEM 形式の CA 証明書バンドルを選択し、オプションで Amazon Simple Storage Service (Amazon S3) バケットから CRL を選択できます。CA 証明書バンドルは、トラストストアで使用される CA 証明書 (ルートまたは中間) のグループです。CRL は、侵害されたクライアント証明書を CA が取り消し、その失効した証明書を拒否する必要がある場合に使用できます。CA バンドルを置き換えたり、作成後に CRL をトラストストアに追加したり、トラストストアから削除したりできます。 Create-trust-store などの新しい API で AWS コマンドラインインターフェイス (AWS CLI) を使用して、CA 情報をアップロードしたり、Application Load Balancer リスナーで mutual-authentication-mode を設定したり、ユーザー証明書情報をターゲットに送信したりできます。 $ aws elbv2 create-trust-store --name my-tls-name \ --ca-certificates-bundle-s3-bucket channy-certs \ --ca-certificates-bundle-s3-key Certificates.pem \ --ca-certificates-bundle-s3-object-version &lt;version&gt; &gt;&gt; arn:aws:elasticloadbalancing:root:file1 $ aws elbv2 create-listener --load balancer-arn &lt;value&gt; \ --protocol HTTPS \ --port 443 \ --mutual-authentication Mode=verify, TrustStoreArn=&lt;arn:aws:elasticloadbalancing:root:file1&gt; AWS プライベート CA、サードパーティ CA、自己署名 CA など、独自のプライベート CA を既にお持ちの場合は、その CA バンドルまたは CRL を Application Load Balancer のトラストストアにアップロードして、相互認証を有効にすることができます。 Application Load Balancer で相互認証をテストするには、 以下の手順に従って OpenSSL を使用して自己署名 CA バンドルとクライアント証明書を作成し、それらを Amazon S3 バケットにアップロードして、ELB トラストストアで使用します。 curl に --key および --cert パラメーターを使用すると、リクエストの一部としてクライアント証明書を送信できます。 $ curl--key my_client.key--cert my_client.pem https://api.yourdomain.com クライアントが無効または期限切れの証明書を提示した場合、証明書を提示できなかった場合、トラストチェーンが見つからない場合、トラストチェーン内のリンクのいずれかが期限切れになっている場合、または証明書が失効リストに含まれている場合は、相互認証は失敗する可能性があります。 Application Load Balancer は、クライアントの認証に失敗するたびに接続を閉じ、ロードバランサーに送信されたリクエストに関する詳細情報をキャプチャする 新しい接続ログ を記録します。各ログには、クライアントの IP アドレス、ハンドシェイクの待ち時間、使用された TLS 暗号、クライアント証明書の詳細などの情報が含まれます。これらの接続ログを使用して、リクエストパターンを分析し、問題をトラブルシューティングできます。 詳細については、AWS ドキュメントの「 Application Load Balancer での相互認証 」を参照してください。 今すぐご利用いただけます Application Load Balancer での相互認証は、Application Load Balancer が利用可能なすべての商用 AWS リージョン (中国を除く) で利用できるようになりました。初期費用や契約は必要ありません。お支払いいただくのは使用した分のみです。料金については、「 Elastic Load Balancing の料金 」ページを参照してください。 ぜひお試しいただき、 AWS re:Post for Amazon EC2 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 詳細はこちら。 Application Load Balancer 製品ページ – Channy 原文は こちら です。

11月26日より、新しい AWS 無料利用枠 API を使用して、 AWS 無料利用枠 の使用状況を確認できます。API は AWS コマンドラインインターフェイス (AWS CLI) で直接使用することも、 AWS SDK を使用してアプリケーションに統合することもできます。 AWS 無料利用枠プログラムでは、各サービスに指定された上限まで、AWS サービスを無料で試用できます。AWS 無料利用枠には、 次の 3 種類のサービスが含まれます。 常時無料 オファーにより、お客様が AWS ユーザーである限り、指定された制限まで無料でサービスを使用できます。 12 か月間の無料オファー により、お客様はアカウントが有効になった日から 1 年間、指定された上限まで無料でサービスを使用できます。 短期トライアル は、サービスに応じて、特定の期間、または1回限りの制限まで無料で利用できます。 AWS リソースを有効にして、無料利用枠を提供する AWS サービスとやり取りし始めたら、無料利用枠の上限までの進捗状況を追跡して、いつ従量制料金に切り替えるべきかがわかるようにする必要があります。 AWS 無料利用枠の使用状況を追跡する方法はいくつかあります。 AWS Billing and Cost Management コンソールの 請求設定 にある使用状況アラートはデフォルトで有効になっており (アカウントが AWS Organizations 経由で作成された場合を除く)、各サービスの無料利用枠の上限の 85% を超えるとメールが送信されます。 請求とコスト管理コンソールの 予算 セクション で、費用ゼロの予算または月額費用の予算を作成できます。テンプレートを使用すると、数回クリックして通知するメールアドレスを入力するだけで済みます。 Billing and Cost Management コンソールの 無料利用 枠ページ には、サービス、オファーのタイプ、現在の使用量、現在の請求期間における各オファーの予測使用量が表示されます。 新しい GetFreeTierUsage API は、プログラムで使用できる構造化された形式で、無料利用枠ページと同じ情報を提供します。 この新しい API が実際にどのように機能するのかを見てみましょう。 AWS CLI で AWS 無料利用枠の API を使用する 過去数か月間に作成された新しいアカウントにアクセスできました。ここでは、 AWS コマンドラインインターフェイス (AWS CLI) を使用して GetFreeTierUsage API を呼び出しています。 aws freetier get-free-tier-usage レスポンスは、この請求期間中にこのアカウントに適用される各オファーの現在の使用量の説明を含む JSON ドキュメントです。わかりやすくするために、ここではいくつかのオファーのみを示します。 { "freeTierUsages": [ { "service": "Amazon Simple Queue Service", "operation": "", "usageType": "Requests", "region": "global", "actualUsageAmount": 294387.0, "forecastedUsageAmount": 679354.6153846154, "limit": 1000000.0, "unit": "Requests", "description": "1000000.0 Requests are always free per month as part of AWS Free Usage Tier (Global-Requests)", "freeTierType": "Always Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "", "usageType": "EBS:VolumeUsage", "region": "global", "actualUsageAmount": 9.0, "forecastedUsageAmount": 33.0, "limit": 30.0, "unit": "GB-Mo", "description": "30.0 GB-Mo for free for 12 months as part of AWS Free Usage Tier (Global-EBS:VolumeUsage)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances:0002", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 476.0, "forecastedUsageAmount": 851.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 225.0, "forecastedUsageAmount": 485.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" }, { "service": "Amazon Redshift", "operation": "RunComputeNode:0001", "usageType": "Node:dc2.large", "region": "global", "actualUsageAmount": 367.0, "forecastedUsageAmount": 735.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free per month during a short-term trial as part of AWS Free Usage Tier (Global-Node:dc2.large)", "freeTierType": "Free Trial" }, ... ] } FreeTierUsages リストには、最も一般的なオファーがいくつか含まれています。 Amazon Elastic Compute Cloud (Amazon EC2) 向けの 2 つのコンピューティングオファー。 オペレーション RunInstances:0002 のオファーは Windows 向けです。 オペレーション RunInstances のオファーは Linux 向けです。 オペレーション プロパティの値は、 Amazon EC2 コンソール の [インスタンス] または [AMI] ページに表示されるプラットフォームの詳細および使用オペレーションと同じです。詳細については、「 Amazon EC2 ユーザーガイドの AMI 請求情報フィールド 」を参照してください。 Amazon Elastic Block Store (Amazon EBS) 容量向けの 1 つのストレージオファー。これと 2 つの Amazon EC2 コンピューティングオファーの FreeTierType は 12 か月間無料 です。 Amazon Simple Queue Service (Amazon SQS) 向けの 常時無料 オファー。 Amazon Redshift の 無料トライアル (短期) オファー。 これらのオファーのいくつかのプロパティを見てみましょう。 説明 には、オファーの内容がわかりやすく説明されています。 FreeTierType は、 常時無料 、 12 か月無料 、 無料トライアル (短期) のいずれかのオファーの種類を示します。 ユニット は、オファーの使用状況を測定するために使用される単位を表します。たとえば、EC2 インスタンスの場合は Hrs (時間)、EBS ボリュームの場合は GB-MO (1 か月あたりの GB)、Amazon SQS の場合は リクエスト などです。 興味深いのプロパティは、オファーの上限 ( limit )、オファーの実際の使用量 ( actualUsageAmount )、請求期間の終わり (当月) の予測使用量 ( forecastedUsageAmount ) の 3 つです。これらはすべて、オファーで使用される単位に基づいています。たとえば、Windows と Linux のコンピューティングオファーには、それぞれ 1 か月あたり 750 時間という制限があります。ストレージサービスの上限は 1 か月あたり 30 GB です。Amazon SQS の場合、オファーの上限は 1 か月あたり 100 万リクエストです。 制限と無料で提供されるサービスの詳細については、各カードの AWS 無料利用枠 ページと各サービスの料金ページに記載されています。AWS 無料利用枠の API で提供される実際の使用量と予測使用量は、 AWS コストと使用状況レポート と同様に、1 日につき 3 回までと推定されます。 予測される使用量がオファーの上限を超える場合、もし同じ方法でサービスを引き続き使用するのであれば、請求期間の終了前に従量制料金に切り替える予定です。上限に達すると、実際の使用量は GetFreeTierUsage API によって追跡されなくなります。つまり、実際の使用量が上限を超えることはできません。その場合、対応するオファーは API から返されません。 たとえば、AWS CLI の --query オプションを使用して、予測が制限を超えるオファーを探します。 aws freetier get-free-tier-usage --query 'freeTierUsages[?forecastedUsageAmount &gt; limit]' { "freeTierUsages": [ { "service": "Amazon Elastic Compute Cloud", "operation": "", "usageType": "EBS:VolumeUsage", "region": "global", "actualUsageAmount": 9.0, "forecastedUsageAmount": 33.0, "limit": 30.0, "unit": "GB-Mo", "description": "30.0 GB-Mo for free for 12 months as part of AWS Free Usage Tier (Global-EBS:VolumeUsage)", "freeTierType": "12 Months Free" }, { "service": "Amazon Elastic Compute Cloud", "operation": "RunInstances:0002", "usageType": "BoxUsage:freetier.micro", "region": "global", "actualUsageAmount": 476.0, "forecastedUsageAmount": 851.0, "limit": 750.0, "unit": "Hrs", "description": "750.0 Hrs for free for 12 months as part of AWS Free Usage Tier (Global-BoxUsage:freetier.micro)", "freeTierType": "12 Months Free" } ] } この結果によると、無料利用枠の制限内にとどまりたい場合は、EBS ボリュームと Windows での Amazon EC2 コンピューティングの使用方法を確認できます。 たとえば、現在、Windows EC2 インスタンスでは、1 か月で利用可能な 750 時間のうち 476 時間を使用しています。このペースでは、限界を超えて約 851 時間に達すると予測されています。コストが気になる場合は、使用していないときや夜間に Windows インスタンスをオフにすることもできます。 知っておくべきこと 以前は、 無料利用枠の API は公開されておらず、同じデータを確認できる AWS 請求コンソールの無料利用枠ページ で内部的に使用されていました。 GetFreeTierUsage API を公開することで、お客様が AWS を楽しみ、AWS 無料利用枠のオファーをより有効に活用し、何が無料で、制限に近づいたり超えたりしたときに何をすべきかを理解できるようになることを願っています。 この情報を使用して、ビジネスニーズを満たすカスタムレポートを作成できます。たとえば、コンピューティングコストを回避したい場合は、プログラムで EC2 インスタンスを停止または休止状態にしたり、EC2 Auto Scaling グループのサイズを 0 に設定したりできます。任意の AWS SDK を使用してウェブアプリを作成したり、このデータをモニタリングソリューションに統合したりできます。 より一般的には、オファーの使用量が制限に近づいたときに、追加の E メールまたは通知 ( Amazon SES や Amazon SNS を使用するなど) を送信できます。これにより、追加費用をかけずにオファーのメリットを最大限に引き出すことができます。使用予算額を無料利用枠の上限に設定すれば、AWS Budgets でもこれを行うことができます。 オファーがこのアカウントに適用されなくなった場合 (たとえば、前月末に期限が切れたため)、対応するアイテムはリストに含まれません。前回の API 呼び出しの結果を保存すると、オファーのリストを前回の請求サイクルで報告されたオファーと比較して、最近期限切れになったオファーを確認できます。 AWS 無料利用枠の使用状況を追跡する方法について詳しく知るために、 AWS Skill Builder で次の 3 つの 10 分コースを作成しました。AWS の専門家から学び、オンラインでクラウドスキルを身に付けることができるオンライン学習センターです。 AWS 無料利用枠: サービスの概要 AWS 無料利用枠: モニタリングサービスの概要 AWS 無料利用枠: サービス管理の概要 – Danilo 原文は こちら です。

Amazon CloudWatch を使用して、 ハイブリッド、マルチクラウド 、およびオンプレミスのデータソースからのメトリクスを統合し、一貫性のある統一された方法で処理できるようになりました。ソースに関係なく、あらゆるメトリクスでクエリ、視覚化、アラームを行うことができます。この新機能は、統一されたビューを提供するだけでなく、インフラストラクチャの複数の部分や側面にまたがる傾向や問題を特定するのに役立ちます。 この新機能について初めて聞いたとき、「待って、 PutMetricData でもそれはできるけど、何が凄いの?」と思いました。 結果的に、かなり凄いことが分かりました。 PutMetricData はメトリックスを CloudWatch に保存しますが、この便利な新機能ではソースから直接オンデマンドでメトリクスを取得します。 データを保存する代わりに、 Prometheus 用のアマゾンマネージドサービス 、汎用 Prometheus 、 Amazon OpenSearch Service 、 Amazon RDS for MySQL 、 Amazon RDS for PostgreSQL 、 Amazon Simple Storage Service (Amazon S3) に保存されている CSV ファイル、および Microsoft Azure モニター からデータを引き出すコネクタを選択して設定します。各コネクタは、 AWS CloudFormation テンプレートからデプロイされる AWS Lambda 関数です。CloudWatch は必要に応じて適切な Lambda 関数を呼び出し、返されたメトリクスをすぐに使用します。メトリクスはバッファリングされたり保持されたりしません。 コネクタの作成と使用 はじめに、CloudWatch コンソールを開いて [すべてのメトリックス] をクリックし、 [マルチソースクエリ] タブをアクティブにしてから、 [データソースの作成と管理] をクリックします。 そしてこれをもう一度行います。 次に、データソースタイプを選択します。 その後、CloudWatch は、データソースのコネクタを作成して設定するために必要な詳細情報を入力するように求めます。たとえば、 Amazon RDS — MySQL を選択した場合、データソースに名前を付け、RDS データベースインスタンスを選択して、接続情報を指定します。 [データソースの作成] をクリックすると、Lambda 関数、Lambda 権限、IAM ロール、シークレットマネージャーシークレット、ロググループ、および AWS CloudFormation スタックが自分のアカウントに作成されます。 次に、データソースを参照して提供するメトリクスを利用する準備ができたら、メトリックのタイムスタンプと値を返す SQL クエリを入力します。 Lambda 関数の内部 カスタム — 開始 テンプレートのコードは短く、シンプルで、理解しやすいものです。次の 2 つのイベントのハンドラーを実装しています。 DescribeGetMetricData — このハンドラーは、コネクタの名前、他のハンドラーへの引数のデフォルト値、および CloudWatch コンソールのカスタムデータソースクエリビルダーに表示される Markdown 形式のテキスト説明を含む文字列を返します。 GetMetricData — このハンドラーは、ハンドラーの引数として指定された時間範囲について、メトリクス名、タイムスタンプとメトリックス値の 1 次元配列を返します。 このコードを数分間調べれば、独自のデータソースに接続する関数の記述方法がわかるはずです。 知っておくべきこと この強力な新機能に関して留意すべき点がいくつかあります。 リージョン — すべての商用 AWS リージョンでデータコネクタを作成して使用できます。あるリージョンで実行されているコネクタは、他のリージョンや他の AWS アカウントのサービスやエンドポイントに接続してデータを取得できます。 料金 — コネクタには追加料金はかかりません。Lambda 関数の呼び出しと、作成したその他の AWS インフラストラクチャの料金を支払います。 – Jeff ; 原文は こちら です。

クロスリージョンデータレプリケーションを使用して、 Amazon WorkSpaces ユーザーにビジネス継続性を提供できるようになりました。スナップショットは 12 時間ごとに作成され、目的のターゲットリージョンにレプリケートされます。このスナップショットを使用して 12～24 時間の目標復旧時点 (RPO) が得られます。 マルチリージョンレジリエンスのレビュー 同僚のアリエルは、2022年の記事「 Amazon WorkSpaces マルチリージョンレジリエンスによる事業継続性の向上 」で、この機能の初期バージョンを紹介し、この機能を使用してユーザーが利用できるスタンバイ仮想デスクトップをセットアップする方法を示しました。セットアップが完了すると、ユーザーは完全修飾ドメイン名 (FQDN) を含む Amazon WorkSpaces 登録コードを使用してログインします。プライマリリージョンの WorkSpaces が利用できない場合、ユーザーはセカンダリリージョンのスタンバイ WorkSpaces にリダイレクトされます。 スタンバイ WorkSpaces は、インフラストラクチャとストレージの少額の固定月額料金で利用でき、その月の利用時間ごとに低額の定額料金がかかります。この機能とこのビジネスモデルを組み合わせることで、スタンバイデプロイメントを簡単かつ経済的に維持できます。 クロスリージョンデータレプリケーション 本日、一方向のクロスリージョンデータレプリケーションを追加することで、この機能をさらに強化します。プライマリ WorkSpace に保存されているアプリケーション、ドキュメント、その他のリソースは 12 時間ごとにスナップショットされ、セカンダリ WorkSpace をホストするリージョンにコピーされます。冗長性がさらに強化され、データ保護が強化され、システム停止によって失われる生産性を最小限に抑えることができます。これは、ユーザーがベースイメージ上にアプリケーションをインストールして構成している場合に特に役立ちます。これは、セカンダリ WorkSpace で上記の手順を繰り返す必要がないためです。 仕組みは以下のとおりです。 通常の運用 — 通常の運用では、 WorkSpaces フリートのユーザーはプライマリリージョンを使用しています。システム (C:) ドライブとデータ (D:) ドライブの EBS スナップショットは 12 時間ごとに作成されます。マルチリージョンレジリエンスはセカンダリリージョンで実行され、新しいスナップショットを定期的にチェックします。それらが見つかると、セカンダリリージョンへのコピーを開始します。コピーがセカンダリリージョンに到着すると、それらを使用してセカンダリ WorkSpace を更新します。 フェイルオーバー検出 — セットアッププロセスの一環として、「 DNS サービスの設定と DNS ルーティングポリシーの設定 」に従って、DNS ルーティングポリシーとオプションの Amazon Route 53 ヘルスチェックを設定し、クロスリージョンリダイレクトを管理します。 フェイルオーバー — 大規模イベント (LSE) がプライマリリージョンとプライマリ WorkSpace に影響する場合、先ほど説明したフェイルオーバー検出が有効になります。ユーザーが再接続を試みると、セカンダリージョンにリダイレクトされ、最新のスナップショットを使用して WorkSpace が起動し、12～24 時間前のデータやアプリにアクセスして稼働状態に戻ります。 フェイルバック — LSE が終了すると、ユーザーはセカンダリ WorkSpace で作成したデータを手動でバックアップし、そこからログアウトします。その後、再びログインすると、今度はプライマリリージョンと WorkSpace にリダイレクトされ、そこでバックアップを復元して作業を続けることができます。 セットアップを始める WorkSpaces 管理者として、まず必要なプライマリワークスペースを見つけることから始めます。 これを選択し、 [アクション] メニューから [スタンバイワークスペースの作成] を選択します。 セカンダリ WorkSpace に必要なリージョンを選択し、 [次へ] をクリックします。 次に、リージョン内の適切なディレクトリを選択し、もう一度 [次へ] をクリックします。 プライマリ WorkSpace が暗号化されている場合は、セカンダリリージョンに KMS キーの ARN を入力する必要があります (または、 マルチリージョンキー を使用するとさらに便利です)。 [データ複製を有効にする] をオンにして、追加の月額料金を許可していることを確認します。 次のページで選択内容を確認し、 [作成] をクリックして、選択したリージョンでセカンダリ WorkSpace の作成を開始します。 前述のように、 マルチリージョンレジリエンスを設定する必要もあります 。これには、WorkSpaces 登録コードとして使用するドメイン名の設定、Route 53 ヘルスチェックの設定、およびそれらを使用してルーティングポリシーを強化することが含まれます。 知っておくべきこと クロスリージョンデータレプリケーションについて知っておくべき重要な点をいくつか紹介します。 ディレクトリ — この記事 で説明されているように、構成されたセルフマネージド型 Active Directory、 AWS マネージド AD 、または AD コネクタ を使用できます。シンプル AD はサポートされていません。 スナップショット — 特定のデータボリュームの最初の EBS スナップショットがいっぱいで、後続のスナップショットは増分になります。その結果、特定の WorkSpace の最初のレプリケーションは、後続のレプリケーションよりも時間がかかる可能性があります。スナップショットは WorkSpaces 内部のスケジュールで開始され、タイミングを制御することはできません。 暗号化 — プライマリリージョンとセカンダリリージョンで同じ AWS Key Management Service (AWS KMS) キーを使用している限り、この機能は 暗号化された WorkSpace で使用できます。 マルチリージョンキー を使用することもできます。 バンドル — Windows 10 および Windows 11 のバンドルを使用できますが、BYOL を実行することもできます。 アカウント — 各 AWS アカウントには、保留中の EBS スナップショットの数に一定の制限があります。これにより、大量の WorkSpaces でこの機能を使用できなくなる可能性があります。 料金 — 各プライマリ WorkSpace に設定されたストレージ量に基づいて、固定月額料金をお支払いいただきます。詳細については、「 Amazon WorkSpaces の料金表 」ページを参照してください。 – Jeff ; 原文は こちら です。

生成系人工知能 (AI) を活用した 通話要約を Amazon Transcribe Call Analytics のプレビューを発表します。 Amazon Bedrock を搭載したこの機能は、カスタマーサービスへの電話を自動的に要約することで、企業がカスタマーエクスペリエンスを向上させ、エージェントとスーパーバイザーの生産性を向上させるのに役立ちます。Amazon Transcribe Call Analytics は、機械学習 (ML) を活用した分析を提供します。これにより、コンタクトセンターは顧客との会話の感情、傾向、ポリシーコンプライアンスを理解して、顧客体験を向上させ、重要なフィードバックを特定できます。たった 1 回の API コールで、顧客との会話のトランスクリプトや豊かなインサイト、および要約を抽出することができます。 ビジネスとして、各会話に関連するアクションアイテムを含め、重要な会話ポイントの正確な履歴記録を維持したいと考えていることは理解しています。そのためには、エージェントは会話の終了後にメモをまとめ、CRM システムに入力します。このプロセスには時間がかかり、人為的ミスの原因となります。ここで、エージェントが会話中に話し合った重要なアクションアイテムを正しく把握して行動でず、顧客の信頼が低下することを想像してみてください。 仕組みの説明 11月26日より、エージェントとスーパーバイザーが顧客との会話を要約しやすくなるように、Amazon Transcribe Call Analytics はコンタクトセンターとのやり取りの簡潔な要約を生成します。この要約には、顧客が電話をかけた理由、問題への対処方法、特定されたフォローアップアクションなどの主要な要素が含まれます。顧客とのやり取りが完了すると、エージェントは会話を要約する必要がないため、次の顧客のサポートに直接進むことができます。その結果、顧客の待ち時間が短縮され、エージェントの生産性が向上します。さらに、スーパーバイザーは、顧客の問題を調査するときに概要を確認して会話の要点を把握できます。通話の録音全体を聞いたり、トランスクリプトを読んだりする必要はありません。 コンソールで Amazon Transcribe Call Analytics を調べる これがどのように機能するかを視覚的に確認するために、まず該当する AWS リージョン に Amazon Simple Storage Service (Amazon S3) バケット を作成します。次に、オーディオファイルを S3 バケットにアップロードします。 音声を書き起こし、顧客とエージェントが行った会話に関する追加の分析を提供する分析ジョブを作成するには、Amazon Transcribe Call Analytics コンソールにアクセスします。左側のナビゲーションバーで [ポストコール分析] を選択し、 [ジョブの作成] を選択します。 次に、オーディオファイルの言語に基づいて言語設定が維持されるように、ジョブ名を入力します。 Amazon S3 URI パスには、この記事で示した最初のスクリーンショットでアップロードされたオーディオファイルへのリンクを指定します。 [ロール名] で、Amazon S3 バケットにアクセスする [IAM ロールの作成] を選択し、 [次へ] を選択します。 生成系コールサマリーを有効にして、 [ジョブの作成] を選択します。 数分後、ジョブのステータスが [進行中] から [完了] に変わり、正常に完了したことが示されます。 ジョブを選択すると、次の画面にトランスクリプトと新しいタブ [生成系コールサマラリー — プレビュー ] が表示されます。 トランスクリプトをダウンロードして、分析と概要を確認することもできます。 今すぐご利用いただけます Amazon Transcribe Call Analytics の生成系コールサマリーは、11月26日、米国東部 (バージニア北部) と米国西部 (オレゴン) で英語でご利用いただけます。 Amazon Transcribe Call Analytics の生成系コールサマリーでは、従量制料金でお支払いいただき、階層型の料金設定に基づいて毎月請求されます。詳細については、「 Amazon Transcribe の料金設定 」をご参照ください。 詳細はこちら 。 Amazon Transcribe Call Analytics の製品ページ Amazon Transcribe Call Analytics 開発者ガイド – Veliswa 原文は こちら です。