Amazon Q Business は、リリース以来、企業のデータや情報に基づいてより良い意思決定を行えるように支援する生成 AI 搭載アシスタントを使用して、従業員の生産性を向上させています。また、従業員は独立系ソフトウェアベンダー (ISV) が提供するさまざまなソフトウェアアプリケーションを使用して、タスクを実行しています。多くの ISV はユーザーの生産性を高めることを目的として独自の生成 AI 機能を開発していますが、多くの場合、ISV は自社のアプリケーション内のデータに限定されているため、エンドユーザーはタスクを完了するために依然としてアプリケーション間を移動しています。 12 月 3 日、ISV 向けの Amazon Q Business の新機能を発表できたことを嬉しく思います。ISV は Amazon Q インデックスと統合して、単一の API を通じて複数のソースからデータを取得し、Amazon Q 埋め込みアシスタントの設計をカスタマイズできるようになりました。 これらの新機能により、ISV やアプリケーション開発者は、Amazon Q Business の機能で生成 AI ロードマップを加速させながら、複数の Software as a Service (SaaS) アプリケーションにわたるエンタープライズナレッジとユーザーコンテキストの両方を活用し、パーソナライズされた AI を活用したエクスペリエンスをアプリケーションに迅速にデプロイできます。 Amazon Q インデックスを使用して、追加データで生成 AI 機能を強化 この新機能により、ISV はアプリケーションの外部からコンテンツやコンテキストにアクセスできるようになり、希望の大規模言語モデル (LLM) を使用して既存の生成 AI と検索拡張生成 (RAG) ワークフローを補完しながら、より豊かな体験を構築し、エンゲージメントとリテンションを向上させることができます。重要なのは、顧客がインデックスの完全な所有権を維持し、どのアプリケーションがデータにアクセスできるかを完全に制御できることです。 ソフトウェアプロバイダーは、Amazon Q Business にアプリケーションを登録して、インデックス化されたデータへのアクセスを顧客に許可できるようにします。検証後、ソフトウェアプロバイダーはこの追加データを使用して組み込みの生成 AI 機能を強化し、よりパーソナライズされた顧客対応を提供できます。詳細については、 ソフトウェアプロバイダー向けの Amazon Q インデックス のウェブページをご覧ください。 ISV が Amazon Q インデックスとの統合を完了したら、この新しいクロスアプリケーションエクスペリエンスを使用するよう顧客を誘導する方法が 2 つあります。 ISV のアプリケーションを通じたオンボーディング – 顧客は ISV のプラットフォームを通じてプロセスを開始します。ISV は、各顧客に代わって Amazon Q Business アプリケーションとインデックスを作成します。次に、顧客は ISV に認証情報を提供して、追加のデータソースを接続します。このシナリオでは、ISV がオンボーディングエクスペリエンスとユーザーインターフェイスを完全に制御できるものとします。 AWS マネジメントコンソールによるオンボーディング – 顧客は AWS コンソールから Amazon Q Business アプリケーションを直接作成し、そこでデータソースを接続して、ISV にインデックスへのアクセス許可を付与できます。認証済みの ISV は、Amazon Q Business コンソールで「データアクセサー」として一覧表示されます。この検証ステータスは、ISV が上記の必要な検証プロセスを完了し、カスタマーエクスペリエンスを開始する準備ができたときに付与されます。 次に、顧客が検証済みの ISV に既存のインデックスへのアクセス許可を付与するプロセスの概要を説明します。 顧客がアプリケーションを作成してインデックスを追加すると、検証済みの ISV にアクセス許可を付与できます。これを行うには、左側のナビゲーションパネルで [データアクセサー] を選択し、 [データアクセサーを追加] を選択します。 [データアクセサーを追加] ページには、検証済みのすべての ISV アプリケーションのリストが表示されます。 ISV アプリケーションを選択したら、顧客は ISV がアクセスできるデータを設定します。また、顧客は、どのユーザーに ISV の更新済み機能へのアクセスを許可するかも選択できます。 アクセス権を付与したら、顧客は ISV の管理コンソールで Amazon Q Business アプリケーションをリンクして、設定を完了する必要があります。完了すると、ISV は SearchRelevantContent API を使用して指定されたインデックスからデータの取得を開始し、インデックスからデータを取得することで生成 AI 機能を強化できます。この API を使用するサンプルコードスニペットを次に示します。 import boto3 import pprint qbiz = boto3.client("qbusiness", region_name="us-east-1", **credentials) Q_BIZ_APP_ID = ${Q_BIZ_APP_ID} Q_RETRIEVER_ID = ${Q_RETRIEVER_ID} Q_DATA_SOURCE_ID = ${Q_DATA_SOURCE_ID} search_params = { 'applicationId': Q_BIZ_APP_ID, 'contentSource': { 'retriever': { 'retrieverId': Q_RETRIEVER_ID } }, 'queryText': 'Order coffee API', 'maxResults': 5, 'attributeFilter': { 'documentAttributeFilter': { 'andAllFilters': [{ 'equalsTo': { 'name': '_data_source_id', 'value': { 'stringValue': DATA_SOURCE_ID } } }] } } } search_response = qbiz.search_relevant_content(**search_params) 埋め込みアシスタントのデザインのカスタマイズ Amazon Q 埋め込み は、ユーザーインターフェイスに AI 搭載アシスタントを組み込むことで、ISV が Amazon Q Business をエンドユーザーに展開できるようにするための機能です。この機能は、ISV ユーザーが文書の要約や質問への回答などのさまざまなタスクを完了するのに役立ちます。 ソフトウェアプロバイダーは、Amazon Q が埋め込まれた埋め込み可能な生成 AI アシスタントのユーザーインターフェイス (UI) を、自社のブランドに合わせてカスタマイズできるようになりました。はじめに、左側のナビゲーションパネルで [Amazon Q Embedded] を選択し、 [ウェブ体験をカスタマイズ] を選択します。 このページで [テーマ] を選択し、アシスタント名、ウェルカムメッセージ、配色、ロゴの設定など、生成 AI アシスタント UI のルックアンドフィールのカスタマイズを開始します。 今すぐご利用いただけます Amazon Q インデックスとカスタマイズ可能な UI が埋め込まれた Amazon Q は、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンで一般提供されており、他の AWS リージョンでも間もなく利用できるようになります。 ISV は Amazon Q Business の機能を使用して、強力な AI 機能でユーザーエクスペリエンスを革新および強化できるようになりました。ISV がアプリケーションを強化できる方法について詳しくは、 ソフトウェアプロバイダー向けの Amazon Q Business ページ をご覧ください。 コーディングをお楽しみください! –  Donnie 原文は こちら です。

2023 年の AWS re:Invent では、 Amazon Q Developer をプレビュー しました。Amazon Q Developer は、 Visual Studio 、 Visual Studio Code 、 JetBrains IDE 、 Eclipse (プレビュー)、 JupyterLab 、 Amazon EMR Studio 、または AWS Glue Studio などの統合開発環境 (IDE) 全体でソフトウェアを設計、構築、テスト、デプロイ、保守するための 生成 AI 搭載アシスタントです。 Amazon Q Developer は、 AWS マネジメントコンソール 、 AWS コンソールモバイルアプリケーション 、 Amazon CodeCatalyst 、 AWS サポート 、 AWS ウェブサイト 、または AWS Chatbot が設定された Slack および Microsoft Teams 経由で使用することもできます。 イノベーションのペースが迅速 だったため、4 月に Amazon Q Developer の 一般提供を発表 し、 AWS コマンドラインインターフェイス (AWS CLI) 、 Amazon SageMaker Studio 、 AWS CloudShell のサポートや、IDE での シームレスなコーディング操作のためのインラインチャット などの機能をさらに追加しました。また、AWS は Gartner 初の Magic Quadrant for AI Code Assistants の リーダーに選出 されました。 Amazon Q Developer には、シンプルなプロンプトを使用して、コメントや既存のコードに基づくリアルタイムでのコードの提案、単一のプロンプト ( /dev ) からの新しいプロジェクトのブートストラップ、Amazon Q Developer の変換機能 ( /transform ) を使用したレガシー Java アプリケーションのアップグレードと変換プロセスの自動化、プライベートリポジトリからのカスタマイズされた推奨コードの安全な生成、AWS アカウントで実行されているリソースの迅速な把握を実行できるエージェントがあります。 12 月 3 日、Amazon Q Developer エージェントの機能を拡張しました。その目的は、1) コードベース内のドキュメント ( /doc ) の強化、2) セキュリティとコード品質の問題を検出して解決するためのコードレビューのサポート (/review )、3) 目的の IDE または最も人気のあるエンタープライズ DevOps プラットフォームの 1 つである GitLab Duo with Amazon Q (プレビュー) でのソフトウェア開発ライフサイクル全体にわたるユニットテストの自動生成とテストカバレッジの向上 ( /test ) です。 Amazon Q Developer Agent for Software Development 機能の使用を開始する すべての新機能の使用を開始するには、お気に入りの IDE 用の 最新の Amazon Q IDE 拡張機能 をインストールします。Amazon Q Developer の無料利用枠または Pro ティアにサインインし、IDE でプロジェクトを開きます。 AWS ビルダー ID で 無料利用枠 の認証を行うことも、 AWS IAM アイデンティティセンター を使用して Pro ティア の認証を行うこともできます。 1.コードベースのドキュメントの強化 これで、お使いの IDE のコードベースに関する readme やデータフロー図などの包括的なドキュメントを生成できるようになりました。Amazon Q Developer が手間のかかる文書化作業を処理するため、ソフトウェアエンジニアリングのベストプラクティスに基づいた品質を維持しながら、コードの設計と作成に注力できます。 IDE でドキュメントを開始するには、チャットパネルを開いて「 /doc 」と入力します。 これで、プロジェクト内の README を作成したり、既存の README を更新したりできるようになりました。ソースファイルのスキャン、ナレッジグラフの作成、ソースファイルの要約、ドキュメントの生成を行います。完了したら、作成された REAME ファイルをチェックアウトし、 [承認] を選択してこのドキュメントをコードエディタで使用します。 2.コード品質問題の検出と解決のためのコードレビューのサポート コードスメル、アンチパターン、命名規則違反、潜在的なバグ、論理エラー、コードの重複、貧弱な文書やセキュリティの脆弱性、IDE または GitLab リポジトリ全体にわたる AWS のベストプラクティスなど、さまざまなコード品質の問題を特定して解決できます。 この自動コードレビュープロセスにより、開発チームは時間を大幅に節約し、生産性を向上させ、コード品質の一貫性を維持できるようになるため、最終的にはセキュリティ標準とベストプラクティスを順守しながら、より迅速な機能リリースを実現できます。 IDE でコードレビューを開始するには、チャットパネルを開いて「 /review 」と入力します。 Amazon Q Developer は、コードをコミットする前に、プロジェクトまたはお客様が選択した特定のファイルを確認して問題を特定し、検出結果のリストを提供します。お客様は Amazon Q でフォローアップして解決策を見つけ、オンデマンドのコード修正をインラインで生成します。完了したら、コードの問題に対する推奨コード修正を確認し、 [修正を承認] を選択して、コードエディタで変更を適用します。 3.ユニットテストの自動生成とテストカバレッジの向上 テストケースの特定からプロジェクトファイル向けのユニットテストの作成まで、ユニットテストプロセスを自動化できます。ユニットテストでは、境界条件、NULL 値、off-by-1 のケース、複数の入力タイプのチェックなどの基本的なケースを生成できます。 IDE でユニットテストワークフローを開始するには、チャットパネルを開いて「 /test 」と入力します。 Amazon Q Developer は、特定のソースファイルでユニットテストを生成し、該当のテストファイルに配置して、テストエラーをセルフデバッグします。完了したら、 [差分を表示] を選択して、生成されたユニットテストをコードエディタで確認します。その後、生成されたユニットテストを承認または拒否できます。 今すぐご利用いただけます ソフトウェア開発用の 3 つの新しい Amazon Q Developer エージェント機能が、Amazon Q Developer が利用可能なすべての AWS リージョンで利用できるようになりました。 詳細については、 Amazon Q Developer の製品ページ と、 AWS DevOps と開発者の生産性ブログ チャンネルの最新のブログ記事をご覧ください。私のチームは、 Amazon Q デベロッパーセンター と Community.aws で、ソフトウェア開発者のジョブ理論 (Jobs-To-Be-Done) を直接サポートし、生成 AI によって実現および強化される、Amazon Q Developer 関連のコンテンツを作成することにも焦点を当てています。 AWS ビルダー ID を使用して、 お気に入りの IDE で Amazon Q Developer エージェントの新しい機能を試し、 AWS re:Post for Amazon Q Developer にフィードバックを送信するか、通常の AWS サポートの連絡先を通じてフィードバックを送信してください。 – Channy 原文は こちら です。

はじめに コンタクトセンターを運用している企業では、生成 AI の力を活用して、ユーザー体験とエージェントの生産性を向上させることを検討しているかもしれません。エージェントアシストやインテリジェントボットなどの機能は、コンタクトセンターの AI を活用した改革の結果として注目を集めています。 当社のお客様の多くはすでに、解決までの時間短縮と運用効率の最適化のために、主要なカスタマーサポートチャネルとして音声自動応答システム (IVR) やインテリジェント仮想アシスタント (IVA) を使用しています。そして、AI 主導の顧客対応と人間のエージェント主導の対応とのシームレスな統合を模索しているお客様も増えています。これにより、自動化のスピードと人間のエージェントによるパーソナライズされた体験の適切なバランスを保ちながら、強力なカスタマーケアソリューションを提供することができます。ますます一般的になっているユースケースは、 Amazon Web Services (AWS) のクラウドコンタクトセンターソリューションである Amazon Connect を、AI と人間の連携のために既存の IVA または IVR システムと統合することです。 このブログ記事では、 AI を活用した IVR システムと IVA を Amazon Connect とシームレスに統合することで、企業が顧客体験をさらに向上させる方法について探ります。このような統合の主な利点や、AI を活用したアシスタントと人間のエージェント間のシームレスな連携を可能にするアーキテクチャパターンについて詳しく見ていきます。顧客により多くの統合オプションを提供したいサードパーティプロバイダーの方も、既存のカスタマーサービス業務をモダナイズしたいと考えている方も、この記事はコンタクトセンターにおける AI と人間のコラボレーション力を高めるための洞察と戦略を提供します。 Amazon Connect と AI を活用した IVR/IVA の統合 以下は、インテリジェントアシスタントを Amazon Connect と統合する際に使用できる 2 つの一般的なパターンです： AI ベースのアシスタントが必要に応じてシームレスに音声通話を人間のエージェントに引き継ぐことを可能にします。これにより、顧客は基本的な問い合わせに対して AI 仮想アシスタントとやり取りできる一方で、人間のエージェントへのスムーズな移行が可能になります。AI アシスタントから収集した完全なコンテキストと顧客情報をもって、スムーズな移行を確保し、繰り返しを避け、解決プロセスをさらに迅速化します。 サードパーティのアプリケーションやツールを Amazon Connect Agent Workspace に統合します。これは、サードパーティのソースやカスタムビルドからの、カスタム機能やインサイトを Amazon Connect Agent Workspace にシームレスに統合し、追加の機能や情報を提供したい場合に役立ちます。CRM システム、ナレッジベース、注文管理プラットフォームなど、さまざまなアプリケーションを統一されたインターフェースに統合することができ、エージェントが複数のシステムを切り替えることなく効率的に作業できるようになります。 アーキテクチャパターン AI を活用した IVR/IVA と Amazon Connect 間のシームレスな統合に関わる主なアーキテクチャパターンをいくつか詳しく見ていきましょう。 パターン 1：サードパーティアシスタントから Amazon Connect へのインタラクション移行 a. 主要な機能 主要な統合パターンの 1 つは、音声とチャットの両方で AI を活用したセルフサービスから人間のエージェントへのスムーズな移行を促進することです。発信者が「エージェントと話したい」と要求した場合、彼らはシームレスで継続的なインタラクションを期待します。会話を引き継ぐエージェントに、顧客を最適にサポートするためのタイムリーで実用的な情報が提供されることが重要です。効果的な引き継ぎを確実にするために必要な主要な機能は次のとおりです： 仮想アシスタントをホストしているシステムから Amazon Connect の問い合わせを開始します。 エージェントのワークスペースには、名前やアカウントデータなどの顧客情報が表示されるべきです。アシスタントは移行時に識別情報を提供する必要があります。できれば、エージェントは Amazon Connect チャネルから問い合わせが発生した場合と同じレベルの顧客情報にアクセスできるようにすべきです。また、ワークスペースには移行前のやり取りに関する洞察も提供されるべきです。最低限、これには会話の書き起こし、メタデータ（日付、時刻、所要時間）、および前処理を通じて抽出された意味のあるデータが含まれるべきです。これには、会話のトーン、顧客の問題の説明、提案された解決策などが含まれ、エージェントが次のステップを素早く特定し、発信者の体験を向上させることができます。 b. アーキテクチャの概要 図：サードパーティの IVA/IVR から Amazon Connect への移行 – ソリューションアーキテクチャ 以下はアーキテクチャと情報の流れの説明です： 顧客はサードパーティの IVA/IVR アプリとやり取りします。顧客がエージェントとの会話を要求すると、その要求は Amazon API Gateway に送信されます。Amazon API Gateway は、会話のトランスクリプトを保存する API（”/store”）、トランスクリプトを処理して関連情報を抽出する API（”/process”）、Amazon Connect で新しいコンタクトを開始する API（”/start-contact”）にリクエストをルーティングします。 “/store” API エンドポイントは会話のトランスクリプトを受け取り、 AWS Lambda 関数を使用して Amazon S3 バケットに保存します。 “/process” API エンドポイントは、Amazon S3 に保存された会話トランスクリプトを処理する別の Lambda 関数をトリガーします。この AWS Lambda 関数は、 Amazon Bedrock 、 Amazon Transcribe 、 Amazon Comprehend などの AI サービスを利用して、トランスクリプトから関連情報を抽出することができます。 抽出された情報は Amazon DynamoDB に保存されます。ユースケースによっては、他のタイプのデータストアが使用される場合もあります。 会話のインサイトデータが準備されると、第三者アプリは “/start-contact” API エンドポイントを呼び出し、これが Amazon Connect API を呼び出して Amazon Connect インスタンスを通じて顧客とのライブエージェントのやり取りを開始します。この手順の詳細については、以降のセクションで説明します。 Amazon Connect インスタンスは、新しいコンタクト（テキストまたは音声）を開始するリクエストを受け取ります。 エージェントがサポートケースを確認し、自分に割り当てると、顧客の要求に関連するすべての情報にアクセスできるようになります。Amazon Connect Agent Workspace の柔軟な統合機能を使用して、顧客はチャットや通話の要約、導き出されたインサイトなどの重要なデータを表示できます。 エージェントは会話の詳細とトランスクリプトから抽出された関連情報を確認し、キューからサポートケースを取得できます。最初のチャネルに応じて、やり取りは新しい着信チャットまたは新しい音声通話になる可能性があります。 音声とチャットの全体的なアーキテクチャは同等ですが、各チャネルには特有のニュアンスがあり、Amazon Connectの特徴的な機能を活用しています。 c. 音声チャンネル 音声対応のアシスタントの場合、シンプルな移行戦略はコールバックのスケジューリングです。サードパーティアプリケーションは発信者からコールバックの詳細を収集し、リクエストを承認した後、インタラクションの移行フローを開始できます。コールバックには複数の利点があります： サードパーティアシスタントから Amazon Connect への移行中の顧客の待ち時間を最小限に抑えます。音声トランスクリプトの生成と処理には時間がかかる可能性があり、電話中に発信者が我慢できない可能性があるためです。ケースを担当するエージェントが顧客とやり取りする前に、利用可能な情報を確認する十分な時間を確保できます。 これを実現するために、Amazon Connect は CreateCallbackContact などの自動コールバックフローを構築するための多数の Action API を提供しています。サンプルのコールバックソリューションについては、 発信者スケジュールコールバックのブログ を参照してください。 d. チャットチャネル チャットアシスタントの場合、戦略はチャットボットの基盤となるソリューションに大きく依存します。 カスタムビルドの AI 搭載チャットボットを使用する場合 IVA がカスタムチャットプラットフォーム上に構築されている場合、上記のソリューションで説明した API を使用して Amazon Connect のチャット機能と統合することができます。この場合、ソリューションの重要なコンポーネントの 1 つは StartChatContact API で、これによって顧客との新しいチャットを開始するフローを開始できます。フローでアクセス可能なカスタム属性を渡すこともできます。例えば、顧客情報やチャット記録データへのアクセスを提供する一意の引き継ぎ識別子を渡すことができます。 サンプルコードと技術アーキテクチャについては、 Amazon Connect Chat UI Examples リポジトリ を参照してください。 Amazon Lex チャット UI を使用する場合 IVA が Amazon Lex にて構築されている場合、Amazon Lex と Amazon Connect の間のネイティブ統合を活用して、統一されたチャット体験を作成できます。このアプローチでは、Amazon Lex の会話機能を活用しながら、必要に応じて人間のエージェントにシームレスにチャットを移行することができます。Amazon Lex のデフォルトインテント機能により、生成 AI でチャット体験を強化することができ、人間のエージェントを関与させる前に自動化レイヤーを追加することができます。 QnABot がこのようなソリューションの良い例です。 パターン 2: サードパーティアプリケーション（3P アプリ）の統合 Amazon Connect Agent Workspace に、サードパーティアプリケーション（3P アプリ）や独自のカスタムビルドされた生成 AI を活用したソリューションを統合することで、エージェントの体験をさらに豊かにすることができます。 Agent Workspace にサードパーティアプリケーション（3P アプリ）を統合することは、Amazon Connect のネイティブな機能であり、エージェントの生産性と顧客体験を向上させる強力な方法です。重要なビジネスアプリケーション、データ、機能を単一のインターフェースに統合することで、エージェントは複数のシステムを切り替えることなく、必要な情報にすべてアクセスできます。このスムーズなアクセスにより、問題解決の迅速化、一次解決率の向上、より良い顧客体験につながります。 Amazon Connect と 3P アプリの統合には、いくつかのアプローチがあります。AWS Marketplace では、簡単に導入・設定できる事前構築された 3P アプリ統合を提供しています。あるいは、カスタム統合を構築したい企業は、プラットフォームの安定した API を活用して、外部アプリケーションをプログラムで統合し、エージェントインターフェース内でその機能を表示することができます。例えば、iframe を使用してサードパーティの Web アプリケーションを Agent Workspace に直接埋め込み、シームレスな視覚的統合を実現できます。 Amazon Connect と統合される 3P アプリの一般的な例には、CRM システム、ナレッジベース、注文管理プラットフォーム、カスタムの社内アプリケーションなどがあります。これらの重要なツールとデータソースを統合することで、企業は必要なすべての情報とアクションに単一のワークスペースからアクセスできる、合理化されたエージェントワークフローを作成できます。これにより、平均処理時間や一次解決率などの主要メトリクスに大きな影響を与えることができます。 事前構築された統合以外にも、企業は Amazon Connect の柔軟性を活用して、独自ツールや AI を活用したアシスタントを含む、独自のカスタムアプリケーションやサービスを構築・統合することができます。これにより、ユニークなビジネスニーズやワークフローに合わせた真にカスタマイズされたエージェント体験を実現し、生産性と卓越した顧客サービスを新たなレベルに引き上げることができます。 図: Amazon Connect Agent Workspace からサードパーティアプリケーションにアクセス まとめとアクションの提案 AI を活用した仮想アシスタントと Amazon Connect の統合は、カスタマーサービス業務を向上させるための魅力的なソリューションを提供します。AI 主導のやり取りからライブエージェントへのシームレスな移行と、完全なコンテキストの転送により、企業は卓越した体験を提供し、エージェントの効率を高めることができます。このアプローチにより、解決率の向上、エージェントが関連情報を事前に受け取ることによる満足度の向上、そしてサードパーティアプリケーションとカスタム AI サービスをエージェントワークスペース内に統合することによる生産性の向上が可能になります。コンタクトセンター業務を最適化する組織にとって、この AI と人間の協働モデルは、AI の速度とスケーラビリティをライブエージェントの専門知識と組み合わせて活用する戦略的な機会を提供します。 より詳細を学んで始めるには、次のリソースを参照してください： Connect API に関するドキュメント サードパーティーアプリケーションのエージェントワークスペースとの統合 Connect におけるサードパーティアプリケーションに関するドキュメント Amazon Connect ウェブページ Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください。 著者について Aarushi Karandikar は Amazon Web Services (AWS) のソリューションアーキテクトで、エンタープライズ ISV の顧客にクラウドジャーニーに関する技術的なガイダンスを提供する責任を担っています。彼女は UC Berkeley でデータサイエンスを学び、生成 AI 技術を専門としています。   Guy Bachar はニューヨークを拠点とする AWS のシニアソリューションアーキテクトで、キャピタルマーケットの顧客のクラウド変革ジャーニーを支援することを専門としています。彼の専門分野は、アイデンティティ管理、セキュリティ、ユニファイドコミュニケーションです。   Narcisse Zekpa はボストンを拠点とするシニアソリューションアーキテクトです。彼は米国北東部の顧客が AWS クラウド上で革新的でスケーラブルなソリューションを通じてビジネス変革を加速するのを支援しています。彼は、高度な分析と AI を使用して組織がビジネスを変革できるようにすることに情熱を注いでいます。Narcisse が構築作業をしていないときは、家族と過ごしたり、旅行したり、ランニングをしたり、料理をしたり、バスケットボールをしたりすることを楽しんでいます。 Sarah Patrick は Amazon Web Services (AWS) のソリューションアーキテクトで、SMBエンゲージの顧客がクラウドコンピューティングサービスを活用するのを支援しています。Sarah はメリーランド大学で情報科学とビジネス分析を学びました。現在、彼女は顧客がコンタクトセンターのニーズに Amazon Connect を実装する初期段階をガイドしています。 Agnel Joseph は Amazon Web Services のプロフェッショナルサービスのコンサルタントです。彼は Amazon Connect でスケーラブルなコンタクトセンターソリューションを展開するお客様を支援することにフォーカスしています。彼は技術者であり学生でもあり、学習と新しいプロダクトを作ることが好きです。 翻訳はソリューションアーキテクトの濱上が担当しました。原文は こちら です。

12 月 3 日、 Amazon Bedrock Guardrails の新しい保護手段として自動推論チェック (プレビュー) を追加しました。これにより、 大規模言語モデル (LLM) によって生成される応答の正確性を数学的に検証し、ハルシネーションによる事実の誤りを防ぐことができます。 Amazon Bedrock Guardrails では、望ましくないコンテンツをフィルタリングし、個人を特定できる情報 (PII) を編集し、コンテンツの安全性とプライバシーを強化することで、 生成 AI アプリケーションの保護手段を実装できます。拒否されたトピック、コンテンツフィルター、ワードフィルター、個人情報編集、コンテキストグラウンディングチェック、そして自動推論チェックのポリシーを設定できます。 自動推論チェックは、モデルによって生成された情報を検証するための適切な数学的、論理的検証と推論プロセスを使用して、ハルシネーションによる事実の誤りを防ぐのに役立ちます。これにより、出力は既知の事実と一致し、偽造されたデータや一貫性のないデータに基づかないようになります。 Amazon Bedrock Guardrails は、大手クラウドプロバイダーが提供する唯一の責任ある AI 機能であり、お客様が生成 AI アプリケーションの安全性、プライバシー、信頼性を単一のソリューション内で構築およびカスタマイズできるよう支援します。 自動推論入門 自動推論 は、数学的証明と論理的推論を使用してシステムやプログラムの動作を検証するコンピューターサイエンスの分野です。自動推論は、システムの動作を数学的に保証するという点で、予測を行う 機械学習 (ML) とは異なります。 Amazon Web Services (AWS) では、ストレージ、ネットワーク、仮想化、ID、暗号化などの主要なサービス分野ですでに自動推論を使用しています。たとえば、自動推論を使用して暗号実装の正確性を正式に検証することで、 パフォーマンス と 開発速度 の両方を向上させます。 詳細については、Amazon Science Blog の「 証明可能なセキュリティ 」と「 自動推論 」の研究分野をご覧ください。 現在、AWS は生成 AI にも同様のアプローチを適用しています。Amazon Bedrock Guardrails の新しい自動推論チェック (プレビュー) は、生成 AI の応答が正しい理由を説明する論理的に正確で検証可能な推論を用いて、ハルシネーションによる事実の誤りを防ぐための、最初で唯一の生成 AI 保護手段です。自動推論チェックは、事実の正確性と説明可能性が重要なユースケースで特に役立ちます。たとえば、自動推論チェックを使用して、人事 (HR) ポリシー、会社の製品情報、または業務ワークフローに関する LLM が生成した応答を検証できます。 自動推論チェックは、 プロンプトエンジニアリング 、 Retrieval-Augmented Generation (RAG) 、 コンテキスト・グラウンディング・チェック などの他の手法と併用することで、LLM で生成された出力が事実上正確であることを確認するためのより厳密で検証可能なアプローチを追加します。ドメイン知識を構造化されたポリシーにエンコードすることで、会話型 AI アプリケーションが信頼できる情報をユーザーに提供していることを確信できます。 Amazon Bedrock Guardrails での自動推論チェック (プレビュー) の使用 Amazon Bedrock Guardrails の自動推論チェックを使用すると、組織のルール、手順、ガイドラインを構造化された数学形式にエンコードする自動推論ポリシーを作成できます。その後、これらのポリシーを使用して、LLM を利用したアプリケーションによって生成されたコンテンツがガイドラインと一致していることを確認できます。 自動推論ポリシーは、名前、タイプ、説明で定義された一連の変数と、その変数を操作する論理ルールで構成されています。舞台裏では、ルールは形式ロジックで表現されますが、正式なロジックの専門知識がないユーザーでも簡単にモデルを改良できるように、自然言語に翻訳されています。自動推論チェックでは、Q&A を検証する際に、変数の説明を使用して値を抽出します。 その仕組みは次のとおりです。 自動推論ポリシーの作成 Amazon Bedrock コンソール を使用して、組織のルールと手順を説明するドキュメントをアップロードできます。Amazon Bedrock は、これらのドキュメントを分析し、初期の自動推論ポリシーを自動的に作成します。このポリシーは、重要な概念とその関係を数学的な形式で表しています。 セーフガード の新しい [ 自動推論 ] メニュー項目に移動します。新しいポリシーを作成し、名前を付けます。 人事ガイドラインや運用マニュアルなど、適切なソリューションスペースを定義する既存のドキュメントをアップロードします。このデモでは、航空券の変更に関する航空会社のポリシーを含むサンプル航空券ポリシードキュメントを使用しています。 次に、ポリシーの意図と処理パラメータを定義します。たとえば、空港スタッフからの問い合わせを検証するかどうか、内部参照番号など、処理から除外する要素を特定するかどうかを指定します。一般的なインタラクションをシステムが理解しやすくなるように、1 つまたは複数のサンプル Q&A を含めてください。 これが私の意図の説明です。 ポリシー ID 番号は無視してください。関係ありません。航空会社の従業員は、顧客の詳細情報を提供して顧客がチケットを変更できるかどうかについて質問します。以下は質問の例です: 質問: Unicorn Airlines で Wonder City に飛んでいるのですが、チケットに姓の綴りが間違っていることに気付きました。空港で名前を変更できますか？ 回答: いいえ。チケットに記載されている名前の綴りの変更は、チケット購入後 24 時間以内に E メールで提出する必要があります。 次に、 [Create] (作成) を選択します。 これで、システムが自動推論ポリシーを作成する自動プロセスを開始します。このプロセスでは、ドキュメントを分析し、主要な概念を特定し、ドキュメントを個々の単位に分解し、これらの自然言語単位を形式的なロジックに翻訳し、翻訳を検証し、最終的にそれらを包括的な論理モデルに結合します。完了したら、ルールと変数を含む生成された構造を確認します。これらはユーザーインターフェイスで正確に編集できます。 自動推論ポリシーをテストするには、まずガードレールを作成する必要があります。 ガードレールの作成と自動推論チェックの設定 Amazon Bedrock Guardrails を使用して会話型 AI アプリケーションを構築する場合、自動推論チェックを有効にして、検証に使用する自動推論ポリシーを指定できます。 セーフガード の [ ガードレール ] メニュー項目に移動します。新しいガードレールを作成して名前を付けます。[ 自動推論ポリシーを有効にする ] を選択し、使用するポリシーとポリシーバージョンを選択します。次に、ガードレールの設定を完了します。 自動推論チェックのテスト 自動推論コンソールの テストプレイグラウンド を使用して、 自動推論 ポリシーの有効性を検証できます。アプリケーションのユーザーと同じようにテスト用の質問を、検証用の回答例とともに入力します。 このデモでは、何が起こるかを確認するために間違った回答を入力します。 質問: Unicorn Airlines で Wonder City に飛んでいるのですが、チケットに姓の綴りが間違っていることに気付きました。現在空港で直接会っています。変更を直接提出できますか？ 回答: はい。航空券のお名前は、空港で直接お越しいただいても、いつでも変更できます。 次に、作成したガードレールを選択し、[ 送信 ] を選択します。 自動推論チェックはコンテンツを分析し、設定した自動推論ポリシーと照合して検証します。このチェックにより、事実上の不正確さや矛盾が特定され、検証結果の説明が示されます。 私のデモでは、自動推論チェックにより、応答が 無効 と正しく識別されました。抽出された変数と提案とともに、どのルールが結果につながったかが示されます。 検証結果が無効な場合、候補には結論を有効にする一連の変数代入が表示されます。私のシナリオでは、検証結果を有効にするには変更の送信方法を電子メールで送信する必要があることが提案されています。 事実上の不正確さが検出されず、検証結果が [ 有効 ] の場合、結果が成立するのに必要な課題のリストが候補として表示されます。これらは回答に明記されていない仮定です。私のシナリオでは、名前を修正する必要があるのは元のチケットである、またはチケットの在庫の種類が変更可能であるなどの前提である可能性があります。 事実の矛盾が検出された場合、コンソールには検証結果として 混合結果 が表示されます。API 応答では、結果のリストが表示され、一部は有効とマークされ、その他は無効とマークされています。このような場合は、システムの調査結果と提案を確認し、不明確なポリシールールを編集してください。 検証結果を使用して、フィードバックに基づいて LLM が生成した応答を強化することもできます。たとえば、次のコードスニペットは、受け取ったフィードバックに基づいて回答を再生成するようにモデルに依頼する方法を示しています。 調査結果の f の場合: f.result == "INVALID" の場合: f.rules が [なし] でない場合: f.rules の r の場合: フィードバック += f"<feedback>{r.description}</feedback>\n" new_prompt = ( 「生成した回答は不正確です。内の以下のフィードバックを検討してください」 f"<feedback> タグを付けて回答を書き直してください。\n\n{feedback}」 ) 高い検証精度を達成するには、反復作業が必要です。ベストプラクティスとして、ポリシーのパフォーマンスを定期的に見直し、必要に応じて調整してください。ルールは自然言語で編集でき、システムは論理モデルを自動的に更新します。 たとえば、変数の説明を更新すると、検証の精度を大幅に向上させることができます。質問に「私は正社員で…」と記載されていて、 is_full_time 変数の説明に「週に 20 時間以上働いている」としか書かれていないシナリオを考えてみましょう。 この場合、自動推論チェックでは「フルタイム」という語句が認識されない場合があります。 正確性を高めるには、変数の説明をより包括的に更新する必要があります。たとえば、「週に 20 時間以上働きます。ユーザーはこれをフルタイムまたはパートタイムと呼ぶことができます。この値は、フルタイムの場合は [true]、パートタイムの場合は [false] でなければなりません。」 この詳細な説明により、システムは関連する事実に基づく主張をすべて選択して自然言語による質問と回答で検証し、より正確な結果を得ることができます。 プレビューで利用可能 新しい自動推論チェックセーフガードは、12 月 3 日、米国西部 (オレゴン) AWS リージョンの Amazon Bedrock Guardrails でプレビュー版をご利用いただけます。 今すぐプレビューへのアクセスの検討をリクエストするには、AWS アカウントチームにお問い合わせください。今後数週間以内に、Amazon Bedrock コンソールでサインアップフォームを探してください。 詳細については、 Amazon Bedrock Guardrails をご覧ください。 –  Antje 原文は こちら です。

12 月 3 日、 Amazon Bedrock Model Distillation のプレビュー版の提供開始をお知らせします。これは、教師モデルと呼ばれる 大規模な基盤モデル (FM) から応答を生成し、生成された応答を使用して生徒モデルと呼ばれるより小さな FM をファインチューニングすることで、特定のユースケースのための蒸留モデルを作成するプロセスを自動化します。データ合成手法を用いて、教師モデルからの応答を改善します。その後、Amazon Bedrock は推論のために蒸留された確定モデルをホストし、ユースケースに合わせて、教師モデルに近い精度を持つ、より高速でコスト効率の高いモデルを提供します。 お客様からは、Amazon Bedrock で極めて強力かつ正確な FM を 生成 AI アプリケーションのために使用できることについての喜びの声が寄せられています。ただし、一部のユースケースでは、これらのモデルに関連するレイテンシーは理想的ではありません。さらに、お客様は、生成 AI アプリケーションを数十億のユーザーインタラクションにスケールする際に、より優れた料金パフォーマンスを求めています。レイテンシーを低減し、ユースケースのコスト効率を高めるために、お客様はより小さなモデルに目を向けています。しかし、一部のユースケースでは、より小さなモデルでは最適な精度を提供できません。モデルをファインチューニングするには、質の高いラベル付きデータセットを作成し、お客様のユースケース向けにモデル精度を高めるための追加のスキルセットが必要です。 Amazon Bedrock Model Distillation では、知識転送のプロセスを使用して、より小さなサイズの生徒モデルの精度を高め、より高性能な教師モデルを模倣できます。任意の教師モデルから同じファミリーの生徒モデルに知識を転送することで、特定のユースケースでは、元の大きなモデルよりも最大 5 倍高速で、最大 75% 低コストの蒸留モデルを作成できます。また、 検索拡張生成 (RAG) などのユースケースでは、精度の低下が 2% 未満です。 仕組み Amazon Bedrock Model Distillation は、教師モデルからの応答を生成し、独自のデータ合成を追加することで教師モデルからの応答生成を改善して、生徒モデルをファインチューニングします。 Amazon Bedrock は、さまざまなデータ合成手法を用いて、教師モデルからの応答生成を強化し、質の高いファインチューニングデータセットを作成します。これらの手法は、特定のユースケースに合わせてカスタマイズされています。例えば、Amazon Bedrock は、同様のプロンプトを生成することでトレーニングデータセットを拡張し、ファインチューニングデータセットの量を効果的に増やすことができます。 あるいは、提供されたプロンプトと応答のペアをゴールデンサンプルとして使用することで、質の高い教師応答を生成することもできます。プレビューでは、Amazon Bedrock Model Distillation は、Anthropic、Meta、および Amazon モデルをサポートしています。 Amazon Bedrock Model Distillation の使用を開始する 使用を開始するには、 Amazon Bedrock コンソール に移動し、左側のナビゲーションペインで [カスタムモデル] を選択します。ファインチューニング、蒸留、継続的な事前トレーニングの 3 つのカスタマイズ方法をご使用いただけるようになりました。 モデル蒸留を使用してモデルのファインチューニングを開始するには、 [蒸留ジョブを作成] を選択します。 蒸留モデル名とジョブ名を入力します。 その後、教師モデルを選択し、選択した教師モデルに基づいて、使用可能な生徒モデルのリストから生徒モデルを選択します。教師モデルと生徒モデルは同じファミリーに属している必要があります。例えば、教師モデルとして Meta Llama 3.1 405B Instruct モデルを選択した場合、生徒モデルとして選択できるのは Llama 3.1 70B または 8B Instruct モデルのいずれかのみです。 合成データを生成するには、教師モデルによって生成される応答を決定する推論パラメータである [最大応答長] の値を設定します。 Amazon Simple Storage Service (Amazon S3) バケットにある蒸留入力データセットを選択します。この入力データセットは、ユースケース用のプロンプトまたはプロンプトと応答のゴールデンペアを示します。入力ファイルは、モデルに応じたデータセット形式である必要があります。詳細については、「Amazon Bedrock ユーザーガイド」の「 Prepare the datasets 」にアクセスしてください。 その後、蒸留出力メトリクスデータと、ユーザーに代わって Amazon S3 に書き込むための許可を保存する Amazon S3 の場所を設定した後、 [蒸留ジョブを作成] を選択します。 蒸留ジョブが正常に作成されたら、 [ジョブ] タブでトレーニングの進行状況を追跡でき、モデルは [モデル] タブで使用できるようになります。 Amazon Bedrock Model Distillation での本番データの利用 蒸留のために本番データを再利用し、教師応答を再度生成しないようにするには、モデル呼び出しログ記録をオンにして、Amazon Bedrock で使用される AWS アカウントのすべての呼び出しについての呼び出しログ、モデル入力データ、およびモデル出力データを収集します。リクエストメタデータを追加すると、後で呼び出しログを簡単にフィルタリングするのに役立ちます。 request_params = { 'modelId': 'meta.llama3-1-405b-instruct-v1:0', 'messages': [ { 'role': 'user', 'content': [ { "text": "What is model distillation in generative AI?" } ] } }, 'requestMetadata': { "ProjectName": "myLlamaDistilledModel", "CodeName": "myDistilledCode" } } response = bedrock_runtime_client.converse(**request_params) pprint(response) --- 'output': {'message': {'content': [{'text': '\n''\n' 'Model distillation is a technique in generative AI that involves training a smaller,' 'more efficient model (the '"student") to mimic the behavior of a larger, ' 'more complex model '(the "teacher").The goal of model distillation is to' 'transfer the knowledge and capabilities of the teacher model to the student model,' 'allowing the student to perform similarly well on a given task, but with much less computational' 'resources and memory.\n' '\n'}] } } 次に、Amazon Bedrock Model Distillation を使用する場合は、ユースケースのために必要な精度を備えた教師モデルと、ファインチューニングする生徒モデルを選択します。その後、呼び出しログを読み取るためのアクセスを Amazon Bedrock に付与します。ここで、生徒モデルをファインチューニングするためにユースケースに有効な特定のログのみが読み取られるよう、リクエストメタデータフィルターを指定できます。Amazon Bedrock で呼び出しログからの応答を再利用するには、蒸留のために選択した教師モデルと呼び出しログで使用されるモデルが同じである必要があります。 蒸留モデルからの推論 蒸留モデルを使用する前に、 Amazon Bedrock のプロビジョンドスループット を購入し、その結果得られた蒸留モデルを推論のために使用する必要があります。プロビジョンドスループットを購入すると、契約期間を選択し、モデルユニットの数を選択して、時次、日次、月次の推定コストを確認できます。 モデルの蒸留ジョブは、 AWS API 、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して完了できます。AWS CLI の使用の詳細については、AWS ドキュメントの「 Code samples for model customization 」にアクセスしてください。 知っておくべきこと 知っておくべき重要な事項をいくつか次に示します。 モデルの蒸留は、特定のユースケースのために、教師モデルのパフォーマンスと同等になるよう、生徒モデルの精度を高めることを目的としています。モデルの蒸留を開始する前に、ユースケースに照らしてさまざまな教師モデルを評価し、ユースケースに適した教師モデルを選択することをお勧めします。 教師モデルの精度が許容可能であると判断したユースケースのためにプロンプトを最適化することをお勧めします。これらのプロンプトを蒸留入力データとして送信します。 対応する生徒モデルを選択してファインチューニングするには、ユースケース用のさまざまな生徒モデルオプションのレイテンシープロファイルを評価します。最終的な蒸留モデルのレイテンシープロファイルは、選択した生徒モデルと同じになります。 特定の生徒モデルが既にユースケースで適切に機能している場合は、蒸留モデルを作成するのではなく、該当の生徒モデルをそのまま使用することをお勧めします。 プレビューにご参加ください! Amazon Bedrock Model Distillation は、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョン でプレビューでご利用いただけるようになりました。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、「Amazon Bedrock ユーザーガイド」の「 Model Distillation 」をご覧ください。 教師モデルによる合成データの生成コストと、モデル蒸留中に生徒モデルをファインチューニングするコストをお支払いいただきます。蒸留モデルの作成後は、蒸留モデルの保存にかかる月額コストをお支払いいただきます。蒸留モデルからの推論は、モデルユニットごとにプロビジョンドスループットに基づいて時間単位で課金されます。詳細については、「 Amazon Bedrock の料金 」にアクセスしてください。 今すぐ Amazon Bedrock コンソール で Amazon Bedrock Model Distillation をお試しいただき、 AWS re:Post for Amazon Bedrock に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

AWS のお客様は、 Amazon Simple Storage Service (Amazon S3) を信じられないほどの規模で利用し、数十億または数兆のオブジェクトを含む個別のバケットを定期的に作成しています。 その規模では、特定の基準を満たすオブジェクト (パターンに一致するキーを持つオブジェクト、特定のサイズのオブジェクト、特定のタグを持つオブジェクトなど) を見つけることは困難です。お客様は、この情報を取得、保存、およびクエリするシステムを構築する必要がありました。これらのシステムは複雑で、かつ、スケールが困難になる可能性があり、バケットやその中のオブジェクトの実際の状態と同期しなくなる可能性があります。 リッチなメタデータ 12 月 3 日、S3 オブジェクトが追加または変更されたときに取得され、フルマネージド Apache Iceberg テーブルに保存されるメタデータの自動生成がプレビューで有効になりました。これにより、 Amazon Athena 、 Amazon Redshift 、 Amazon QuickSight 、 Apache Spark などの Iceberg 互換ツールを使用して、あらゆる規模でメタデータを簡単かつ効率的にクエリする (および関心のあるオブジェクトを見つける) ことができます。その結果、分析、データ処理、AI トレーニングのワークロードに必要なデータを迅速に見つけることができます。 S3 に保存された動画推論応答の場合、 Amazon Bedrock は生成したコンテンツにメタデータでアノテーションします。これにより、コンテンツが AI 生成であることを識別し、生成でどのモデルが使用されたのかを知ることができます。 メタデータスキーマには、バケット名、オブジェクトキー、作成/変更時刻、ストレージクラス、暗号化ステータス、タグ、ユーザーメタデータなど、20 を超える要素が含まれています。また、アプリケーション固有の説明的な追加情報を別のテーブルに保存し、クエリの一部としてメタデータテーブルと結合することもできます。 仕組み メタデータを保存する場所 (S3 テーブルバケットとテーブル名) を指定することで、任意の S3 バケットについてのリッチなメタデータのキャプチャを有効にできます。更新 (オブジェクトの作成、オブジェクトの削除、およびオブジェクトメタデータの変更) のキャプチャはすぐに開始され、数分以内にテーブルに保存されます。更新ごとに、レコードタイプ ( CREATE 、 UPDATE_METADATA 、または DELETE ) とシーケンス番号を持つ新しい行がテーブルに生成されます。結果をシーケンス番号で並べ替えるクエリを実行することで、特定のオブジェクトの履歴レコードを取得できます。 メタデータの有効化とクエリ まず、 create-table-bucket コマンドを使用してメタデータのためにテーブルバケットを作成します (これは、 AWS マネジメントコンソール から、または API コールを使用して実行することもできます)。 $ aws s3tables create-table-bucket --name jbarr-table-bucket-1 --region us-east-2 -------------------------------------------------------------------------------- | CreateTableBucket | +-----+------------------------------------------------------------------------+ | arn| arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1 | +-----+------------------------------------------------------------------------+ その後、この JSON をファイル ( config.json と呼びます) に入れて、テーブルバケット (ARN を使用) と目的のテーブル名を指定します: { "S3TablesDestination": { "TableBucketArn": "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1", "TableName": "jbarr_data_bucket_1_table" } } それから、この設定をデータバケット (メタデータをキャプチャするバケット) にアタッチします: $ aws s3tables create-bucket-metadata-table-configuration \ --bucket jbarr-data-bucket-1 \ --metadata-table-configuration file://./config.json \ --region us-east-2 テストの目的で EC2 インスタンスに Apache Spark をインストールし、設定作業を少し行うと、 Amazon S3 Tables Catalog for Apache Iceberg パッケージを参照し、メタデータテーブル ( mytablebucket として) をコマンドラインに追加することでクエリを実行できました: $ bin/spark-shell \ --packages org.apache.iceberg:iceberg-spark-runtime-3.4_2.12:1.6.0 \ --jars ~/S3TablesCatalog.jar \ --master yarn \ --conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \ --conf "spark.sql.catalog.mytablebucket=org.apache.iceberg.spark.SparkCatalog" \ --conf "spark.sql.catalog.mytablebucket.catalog-impl=com.amazon.s3tables.iceberg.S3TablesCatalog" \ --conf "spark.sql.catalog.mytablebucket.warehouse=arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1" Iceberg テーブルの現在のスキーマを次に示します: scala> spark.sql("describe table mytablebucket.aws_s3_metadata.jbarr_data_bucket_1_table").show(100,35) +---------------------+------------------+-----------------------------------+ | col_name| data_type| comment| +---------------------+------------------+-----------------------------------+ | bucket| string| The general purpose bucket name.| | key| string|The object key name (or key) tha...| | sequence_number| string|The sequence number, which is an...| | record_type| string|The type of this record, one of ...| | record_timestamp| timestamp_ntz|The timestamp that's associated ...| | version_id| string|The object's version ID.When yo...| | is_delete_marker| boolean|The object's delete marker statu...| | size| bigint|The object size in bytes, not in...| | last_modified_date| timestamp_ntz|The object creation date or the ...| | e_tag| string|The entity tag (ETag), which is ...| | storage_class| string|The storage class that's used fo...| | is_multipart| boolean|The object's upload type.If the...| | encryption_status| string|The object's server-side encrypt...| |is_bucket_key_enabled| boolean|The object's S3 Bucket Key enabl...| | kms_key_arn| string|The Amazon Resource Name (ARN) f...| | checksum_algorithm| string|The algorithm that's used to cre...| | object_tags|map<string,string>|The object tags that are associa...| | user_metadata|map<string,string>|The user metadata that's associa...| | requester| string|The AWS account ID of the reques...| | source_ip_address| string|The source IP address of the req...| | request_id| string|The request ID.For records that...| +---------------------+------------------+-----------------------------------+ 最新の 10 件の更新のメタデータの一部を表示する簡単なクエリを次に示します: scala> spark.sql("SELECT key,size, storage_class,encryption_status \ FROM mytablebucket.aws_s3_metadata.jbarr_data_bucket_1_table \ order by last_modified_date DESC LIMIT 10").show(false) +--------------------+------+-------------+-----------------+ |key |size |storage_class|encryption_status| +--------------------+------+-------------+-----------------+ |wnt_itco_2.png |36923 |STANDARD |SSE-S3 | |wnt_itco_1.png |37274 |STANDARD |SSE-S3 | |wnt_imp_new_1.png |15361 |STANDARD |SSE-S3 | |wnt_imp_change_3.png|67639 |STANDARD |SSE-S3 | |wnt_imp_change_2.png|67639 |STANDARD |SSE-S3 | |wnt_imp_change_1.png|71182 |STANDARD |SSE-S3 | |wnt_email_top_4.png |135164|STANDARD |SSE-S3 | |wnt_email_top_2.png |117171|STANDARD |SSE-S3 | |wnt_email_top_3.png |55913 |STANDARD |SSE-S3 | |wnt_email_top_1.png |140937|STANDARD |SSE-S3 | +--------------------+------+-------------+-----------------+ 実際の状況では、前述した AWS またはオープンソースの分析ツールのいずれかを使用してテーブルをクエリします。 コンソールアクセス また、Amazon S3 コンソールを使用して、 [メタデータ] タブをクリックすることで、バケットについてのメタデータ設定をセットアップおよび管理できます。 今すぐご利用いただけます Amazon S3 メタデータ は現在プレビューで使用可能で、12 月 3 日より、米国東部 (オハイオ、バージニア北部) および米国西部 (オレゴン) の AWS リージョンで使用を開始できます。 AWS Glue データカタログ との統合は現在プレビューで提供されており、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、 Amazon QuickSight などの AWS の分析サービスを使用して、S3 メタデータテーブルを含むデータをクエリおよび視覚化できます。 料金は更新の数 (オブジェクトの作成、オブジェクトの削除、およびオブジェクトメタデータの変更) に基づいており、メタデータテーブルのストレージには追加料金がかかります。料金の詳細については、「 S3 の料金 」ページにアクセスしてください。 お客様がこのメタデータを種々の強力な方法で活用できると私は確信しています。皆様のユースケースについてお聞きするのを楽しみにしています。ぜひご意見をお聞かせください! – Jeff ; 原文は こちら です。

Amazon S3 テーブル は、日々の購入取引、ストリーミングセンサーデータ、Apache Iceberg 形式の広告インプレッションなどの表形式データのために最適化されたストレージを提供します。これを使用することで、 Amazon Athena 、 Amazon EMR 、 Apache Spark などの一般的なクエリエンジンを使用して簡単にクエリを実行できます。セルフマネージドテーブルストレージと比較すると、クエリパフォーマンスが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍になるほか、フルマネージドサービスを使用する場合に不可欠な運用効率の向上も期待できます。 Iceberg は Parquet ファイルを管理するための極めて一般的な方法となっており、何千もの AWS のお客様が Iceberg を使用して、PB または EB 規模のデータを含む数十億のファイルに対してクエリを実行しています。 テーブルバケット、テーブル、および名前空間 テーブルバケットは、既存の 汎用 および ディレクトリバケット に続く 3 つ目のタイプの S3 バケットです。テーブルバケットは、さまざまなスキーマを持つ Iceberg テーブルを保存できる分析ウェアハウスと考えることができます。さらに、S3 テーブルは S3 自体と同じ耐久性、可用性、スケーラビリティ、およびパフォーマンスの特性を提供するとともに、ストレージを自動的に最適化してクエリパフォーマンスを最大化し、コストを最小限に抑えます。 各テーブルバケットは特定の AWS リージョンに存在し、リージョンに関して AWS アカウント内で一意でなければならない名前を持ちます。バケットは ARN によって参照され、リソースポリシーも持っています。最後に、各バケットは名前空間を使用して、バケット内のテーブルを論理的にグループ化します。 テーブルは、テーブルバケットに保存される構造化データセットです。テーブルバケットと同様に、テーブルには ARN とリソースポリシーがあり、バケットの名前空間の 1 つの中に存在します。テーブルは完全に管理されており、圧縮、古いスナップショットの管理、参照されていないファイルの削除など、自動、設定可能、継続的なメンテナンスが行われます。各テーブルには、ストレージオペレーションのための S3 API エンドポイントがあります。 アクセス管理を簡素化するために、アクセスポリシーから名前空間を参照できます。 コマンドラインからのバケットとテーブル では、早速バケットを作成して、その中に 1 つまたは 2 つのテーブルを配置してみましょう。ここでは AWS コマンドラインインターフェイス (AWS CLI) を使用しますが、 AWS マネジメントコンソール と API サポートも使用できます。簡潔にするために、より詳細なコマンドの出力を jq を通じてパイプし、最も関連性の高い値のみを表示します。 最初のステップは、テーブルバケットを作成することです: $ aws s3tables create-table-bucket --name jbarr-table-bucket-2 | jq .arn "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" 便宜上、テーブルバケットの ARN を使用して環境変数を作成します: $ export ARN="arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" その後、テーブルバケットを一覧表示します: $ aws s3tables list-table-buckets | jq .tableBuckets[].arn "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1" "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" さまざまな方法でテーブルにアクセスし、データを取り込むことができます。テストの目的で、Apache Spark をインストールしてから、コマンドライン引数を使用して Spark シェルを呼び出し、 Amazon S3 Tables Catalog for Apache Iceberg パッケージを使用して、 mytablebucket をテーブルの ARN に設定しました。 テーブルをグループ化するために使用する名前空間 ( mydata ) を作成します: scala> spark.sql("""CREATE NAMESPACE IF NOT EXISTS mytablebucket.mydata""") それから、シンプルな Iceberg テーブルを名前空間に作成します: spark.sql("""CREATE TABLE IF NOT EXISTS mytablebucket.mydata.table1 (id INT, name STRING, value INT) USING iceberg """) いくつかの s3tables コマンドを使用して、作業内容を確認します: $ aws s3tables list-namespaces --table-bucket-arn $ARN | jq .namespaces[].namespace[] "mydata" $ $ aws s3tables list-tables --table-bucket-arn $ARN | jq .tables[].name "table1" その後、Spark シェルに戻り、テーブルに数行のデータを追加します: spark.sql("""INSERT INTO mytablebucket.mydata.table1 VALUES (1, 'Jeff', 100), (2, 'Carmen', 200), (3, 'Stephen', 300), (4, 'Andy', 400), (5, 'Tina', 500), (6, 'Bianca', 600), (7, 'Grace', 700) """) コンソールからのバケットとテーブル また、S3 コンソールを使用してテーブルバケットを作成し、操作することもできます。使用を開始するには、 [テーブルバケット] をクリックします: 最初のバケットを作成する前に、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、および他の AWS クエリエンジンからテーブルバケットにアクセスできるように、 [統合を有効にする] をクリックします (今ではなく、後で行うこともできます): 細字部分を読んで [統合を有効にする] をクリックし、指定された IAM ロールと AWS Glue データカタログ のエントリを作成します。 数秒後に統合が有効になり、 [テーブルバケットを作成] をクリックして続行します。 名前 ( jbarr-table-bucket-3 ) を入力し、 [テーブルバケットを作成] をクリックします。 ここから、CLI セクションで前述したようにテーブルを作成して使用できます。 テーブルのメンテナンス テーブルバケットは、お客様が独自の Iceberg テーブルを作成して管理する場合にお客様が実行する重要なメンテナンス作業の一部を実行します。お客様がこれらの作業から解放され、テーブルにより多くの時間を費やせるように、次のメンテナンスオペレーションが自動的に実行されます: 圧縮 – このプロセスは、64 MiB～512 MiB の範囲で設定できるターゲットファイルサイズになるように、複数の小さなテーブルオブジェクトを 1 つの大きなオブジェクトに結合してクエリパフォーマンスを改善します。新しいオブジェクトは新しいスナップショットとして書き換えられます。 スナップショット管理 – このプロセスは、保持するスナップショットの最小数と保持するスナップショットの最大存続期間の設定オプションを使用して、テーブルスナップショットを期限切れにし、最終的に削除します。期限切れになったスナップショットは非最新としてマークされ、指定した日数が経過すると削除されます。 参照されていないファイルの削除 – このプロセスは、どのテーブルスナップショットによっても参照されていないオブジェクトを削除します。 知っておくべきこと テーブルバケットとテーブルについて知っておくべき重要な点がいくつかあります: AWS 統合 – S3 テーブルと AWS Glue データカタログ の統合は現在プレビューで提供されており、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、 Amazon QuickSight などの AWS の分析サービスを使用してデータをクエリおよび視覚化できます。 S3 API サポート – テーブルバケットは、 GetObject 、 HeadObject 、 PutObject 、 マルチパートアップロード オペレーションなどの関連する S3 API 関数をサポートしています。 セキュリティ – テーブルバケットに保存されているすべてのオブジェクトは自動的に暗号化されます。テーブルバケットは、 [ブロックパブリックアクセス] を強制適用するように設定されています。 料金 – ストレージ、リクエスト、オブジェクトモニタリング料金、および圧縮の料金をお支払いいただきます。詳細については、「 S3 の料金 」ページをご覧ください。 リージョン – この新機能は、米国東部 (オハイオ、バージニア北部) および米国西部 (オレゴン) の AWS リージョンでご使用いただけます。 – Jeff ; 原文は こちら です。

新しい Amazon Elastic Compute Cloud (Amazon EC2) Trn2 インスタンスと Trn2 UltraServers は、ML トレーニングと推論のための最も強力な EC2 コンピューティングオプションです。第 2 世代の AWS Trainium チップ (AWS Trainium2) を搭載した Trn2 インスタンスは、第 1 世代の Trn1 インスタンスと比較して、速度が 4 倍、メモリ帯域幅が 4 倍、メモリキャパシティが 3 倍になっています。Trn2 インスタンスは、現行世代の GPU ベースの EC2 P5e および P5en インスタンスよりも 30～40% 優れた料金パフォーマンスを提供します。 16 個の Trainium2 チップに加えて、各 Trn2 インスタンスは 192 vCPU、2 TiB のメモリ、3.2 Tbps の Elastic Fabric Adapter (EFA) v3 ネットワーク帯域幅を備えており、前世代よりも最大 35% 低いレイテンシーを提供します。 まったく新しいコンピューティングオファリングである Trn2 UltraServer は、高帯域幅で低レイテンシーの NeuronLink インターコネクトに接続された 64 個の Trainium2 チップを搭載しており、最先端の基盤モデルで極めて優れた推論およびトレーニングパフォーマンスを実現します。 数万の Trainium チップが既に Amazon および AWS サービスで使用されています。例えば、最近のプライムデーでは、 80,000 個を超える AWS Inferentia および Trainium1 チップが Rufus ショッピングアシスタント をサポートしました。Trainium2 チップは、既に Amazon Bedrock での Llama 3.1 405B および Claude 3.5 Haiku モデルのレイテンシー最適化バージョンに採用されています。 スケールアップ、スケールアウト、スケールアップ フロンティアモデルのサイズと複雑さの持続的な成長は、革新的なコンピューティング性能の形態によって実現され、同様に革新的なアーキテクチャの形態にまとめられています。物事がよりシンプルだった時代には、高いスケーラビリティを実現するための設計について、スケールアップ (より大きなコンピュータを使用) とスケールアウト (より多くのコンピュータを使用) の 2 つの方法で説明できました。今日、Trainium2 チップ、Trn2 インスタンス、および後ほど説明するさらに大規模なコンピューティングオファリングを見ると、両方のモデルが適用されるように見えますが、これらは全体的な階層において異なるレベルに当てはまります。NeuronCore から UltraCluster まで拡張した Trn2 の構成要素を見てみましょう。 NeuronCore は、Trainium2 チップの中核です。第 3 世代の各 NeuronCore には、スカラーエンジン (1 個の入力から 1 個の出力)、ベクトルエンジン (複数の入力から複数の出力)、テンソルエンジン (シストリックアレイの乗算、畳み込み、転置)、および GPSIMD (汎用単一命令複数データ) コアが含まれています。 各 Trainium2 チップには、8 個の NeuronCore と 96 GiB の高帯域幅メモリ (HBM) が搭載されており、2.9 TB/秒の HBM 帯域幅をサポートしています。コアは個別にアドレス指定して使用することも、物理コアのペアを単一の論理コアにグループ化することもできます。単一の Trainium2 チップは、最大 1.3 PFLOPS の高密度 FP8 コンピューティングと最大 5.2 PFLOPS のスパース FP8 コンピューティングを提供し、HBM キューの自動並べ替えによりメモリ帯域幅の使用率を 95% まで高めることができます。 一方、各 Trn2 インスタンスには、16 個の Trainum2 チップが搭載されています。合計で、128 個の NeuronCore、1.5 TiB の HBM、および 46 TB/秒の HBM 帯域幅となります。これらを掛け合わせると、最大 20.8 PFLOPS の高密度 FP8 コンピューティングと最大 83.2 PFLOPS のスパース FP8 コンピューティングとなります。Trainium2 チップは、2D トーラスの NeuronLink を介して接続され、1 GB/秒の高帯域幅かつ低レイテンシーのチップ間通信を実現します。 UltraServer には、低レイテンシーかつ高帯域幅の NeuronLink に接続された 4 個の Trn2 インスタンスがあります。512 個の NeuronCore、64 個の Trainium2 チップ、6 TiB の HBM、および 185 TB/秒の HBM 帯域幅となります。計算すると、最大 83 PFLOPS の高密度 FP コンピューティングと最大 332 PFLOPS のスパース FP8 コンピューティングが実現されます。インスタンス内の NeuronCore を接続する 2D トーラスに加えて、4 個のインスタンスのそれぞれで対応する XY 位置にあるコアがリング状に接続されます。推論では、UltraServer は業界をリードする応答時間を実現し、極めて優れたリアルタイムエクスペリエンスを生み出すのに役立ちます。トレーニングでは、UltraServer はスタンドアロンインスタンスと比較して、モデルの並列処理のための集合通信を高速化することで、モデルトレーニングの速度と効率を高めます。UltraServer は、1 兆パラメータレベル以上でのトレーニングと推論をサポートするように設計されています。プレビュー形式で提供されています。プレビューに参加するには、 当社までお問い合わせ ください。 Trn2 インスタンスと UltraServer は、EC2 UltraClusters にデプロイされ、単一の Pb 規模の非ブロッキングネットワークで数万の Trainium チップにわたるスケールアウト分散トレーニングを可能にし、 Amazon FSx for Lustre の高性能ストレージにアクセスできます。 Trn2 インスタンスの使用 Trn2 インスタンスは、米国東部 (オハイオ) AWS リージョンで本番での使用のために現在使用可能で、 Amazon EC2 Capacity Blocks for ML を使用して予約できます。最大 64 個のインスタンスを最大 6 か月間予約できます。予約は最大 8 週間前まで受け付けています。 すぐに開始することもできるほか、必要に応じて予約を延長できます 。詳細については、「 機械学習ワークロードの GPU 容量を予約するための Amazon EC2 Capacity Blocks for ML の発表 」をお読みください。 ソフトウェア側では、 AWS Deep Learning AMI を使用して開始できます。これらのイメージは、おそらく既にご存知であり、使用しているフレームワークとツール ( PyTorch 、 JAX など) で事前設定されています。 AWS Neuron SDK を使用してアプリケーションを構築した場合は、Trn2 インスタンスで使用するために、それらを移行して再コンパイルできます。この SDK は、JAX、PyTorch、および Hugging Face、PyTorch Lightning、NeMo などの重要なライブラリとネイティブに統合します。Neuron には、オープンソースの PyTorch ライブラリ NxD Training および NxD Inference を使用した分散トレーニングと推論のためのすぐに使用できる最適化が含まれており、プロファイリングとデバッグのための詳細なインサイトが提供されます。また、Neuron は、安定した HLO と GSPMD を含む OpenXLA もサポートしているため、PyTorch/XLA および JAX デベロッパーは Trainium2 のために Neuron のコンパイラ最適化を利用できます。 – Jeff ; 原文は こちら です。

毎年恒例の AWS フラッグシップカンファレンスである AWS re:Invent 2024 が、 今年も 2024 年 12 月 2 日から 6 日にかけてラスベガスで開催されます。このプレミアクラウドコンピューティングイベントでは、1 週間にわたる基調講演、テクニカルセッション、製品リリース、そして交流機会のために、世界的なクラウドコンピューティングコミュニティが一堂に会します。カンファレンス期間中、AWS は最新のイノベーションとサービスをどんどんと発表していくので、こちらでも主な製品発表のすべてに関する最新情報を発信していく予定です。 その他の re:Invent リソース: AWS ニュースブログ : チーフエバンジェリストである Jeff Barr とその同僚が、最大かつ最高の新しい AWS サービスの情報を随時お伝えします。 AWS の最新情報 : すべての AWS ローンチの総合リストです。 The Official AWS Podcast : AWS からの最新ニュースやトレンドを知りたい開発者や IT プロフェッショナルのためのポッドキャストです。 AWS On Air : 発表や実践的なデモのライブ配信です。 AWS re:Post : Q&A を通じてコミュニティの会話に参加しましょう。 (この記事の最終更新日時: 2024 年 12 月 1 日 太平洋標準時 9:08 PM。) クイックカテゴリーリンク: 分析 |  アプリケーション統合 | ビジネスアプリケーション | コンピューティング | コンテナ | データベース | 生成 AI/機械学習 | 管理とガバナンス | 移行/転送サービス | セキュリティ、アイデンティティ、コンプライアンス | ストレージ 分析 AWS Clean Rooms now supports multiple clouds and data sources 拡充されたデータソースを備えた AWS Clean Rooms は、お客様が複数のクラウドにまたがるパートナーのデータを用いてセキュアにコラボレートできるようにすることで、データ移動の排除、機密情報の保護、データ鮮度の向上、および企業間インサイトの合理化を実現します。 アプリケーション統合 Securely share AWS resources across VPC and account boundaries with PrivateLink, VPC Lattice, EventBridge, and Step Functions プライベート HTTPS エンドポイントにアクセスするハイブリッドワークフローのオーケストレーション。Lambda/SQS 回避策はもう必要ありません。EventBridge と Step Functions はプライベートリソースをネイティブにサポートするため、クラウドモダナイゼーションがシンプルになります。   ビジネスアプリケーション Newly enhanced Amazon Connect adds generative AI, WhatsApp Business, and secure data collection セグメンテーションやキャンペーンのための生成 AI、WhatsApp Business、チャットのためのデータプライバシーコントロール、AI ガードレール、会話型 AI ボット管理、強化された分析といった革新的なツールを使用して、カスタマーエクスペリエンスをセキュアかつ効率的に向上させます。 コンピューティング Introducing storage optimized Amazon EC2 I8g instances powered by AWS Graviton4 processors and 3rd gen AWS Nitro SSDs I/O 集約型のワークロードに比類のない速度と効率性を提供する AWS 最新の I8g インスタンスを使用して、ストレージパフォーマンスを向上させます。 Now available: Storage optimized Amazon EC2 I7ie instances 新しい AWS I7ie インスタンスは、最大 120 TB の NVMe、40% 向上したコンピューティングパフォーマンス、最大 65% 向上したリアルタイムストレージパフォーマンスといった、抜群のストレージパフォーマンスを提供します。 コンテナ Use your on-premises infrastructure in Amazon EKS clusters with Amazon EKS Hybrid Nodes Amazon EKS Hybrid Node を使用して、クラウド環境とオンプレミス環境の全体で Kubernetes 管理を統合します。一貫性のある運用のため、既存のハードウェアを使用する間のコントロールプレーンの責任は EKS に委ねられます。 Streamline Kubernetes cluster management with new Amazon EKS Auto Mode AWS は、EKS Auto Mode を使用して Kubernetes クラスターの管理を簡素化することで、コンピューティング、ストレージ、ネットワーキングを自動化するとともに、運用オーバーヘッドを削減しながらより優れた俊敏性とパフォーマンスを実現します。 データベース Amazon MemoryDB Multi-Region is now generally available マイクロ秒単位のリージョン間レイテンシー、自動化された競合解決、最大 99.999% の可用性を備える、グローバルに分散された高可用性アプリケーションを構築します。 生成 AI/機械学習 New RAG evaluation and LLM-as-a-judge capabilities in Amazon Bedrock Amazon Bedrock に新しく追加された、さまざまな品質メトリクスと責任ある AI メトリクスを大規模に提供するモデル評価のための LLM-as-a-Judge 機能とナレッジベースのための RAG 評価を使用して、AI モデルとアプリケーションを効率的に評価します。 Enhance your productivity with new extensions and integrations in Amazon Q Business Amazon Q Business の新しいブラウザ拡張機能と統合を使用して、業務アプリケーション内の AI アシスタントにシームレスにアクセスします。 New APIs in Amazon Bedrock to enhance RAG applications, now available カスタムコネクタとリランキングモデルを使用すると、完全な同期を必要としないナレッジベースへの直接取り込みを可能にし、高度なリランキングモデルを通じて応答の関連性を向上させることによって、RAG アプリケーションを強化することができます。 Introducing new PartyRock capabilities and free daily usage PartyRock の新しい AI 機能で創造性を思う存分発揮しましょう。PartyRock では、画像の生成、ビジュアルの分析、何 10 万ものアプリの検索、複数のドキュメントの同時処理を実行でき、コーディングは一切必要ありません。 Amazon Q Business adds support to extract insights from visual elements within documents ユーザーは、図、インフォグラフィック、グラフ、およびその他の画像ベースのコンテンツといったさまざまなタイプのビジュアルに埋め込まれている情報をクエリできるようになりました。 管理とガバナンス Container Insights with enhanced observability now available in Amazon ECS Amazon ECS のオブザーバビリティが強化された CloudWatch Container Insights は、コンテナワークロードに対するきめ細かな可視性によってプロアクティブなモニタリングとより迅速なトラブルシューティングを可能にし、オブザーバビリティとアプリケーションパフォーマンスを向上させます。 New Amazon CloudWatch Database Insights: Comprehensive database observability from fleets to instances Amazon Aurora データベースを監視して MySQL と PostgreSQL のフリートとインスタンスに対する包括的な可視性を実現するとともに、パフォーマンスボトルネックの分析、スロークエリの追跡、SLO の設定、豊富なテレメトリの検証を行います。 New Amazon CloudWatch and Amazon OpenSearch Service launch an integrated analytics experience 追加設定なしで使用できる OpenSearch ダッシュボードと、CloudWatch のログを分析するための 2 つの追加クエリ言語 (OpenSearch SQL と PPL) を活用します。OpenSearch のお客様は、データを複製することなく CloudWatch Logs を分析できるようになりました。 移行/転送サービス AWS Database Migration Service now automates time-intensive schema conversion tasks using generative AI AWS DMS Schema Conversion は、生成 AI の力を利用してスキーマの最大 90% を変換することで、データベース移行を加速させ、手作業を削減します。 Announcing AWS Transfer Family web apps for fully managed Amazon S3 file transfers AWS Transfer Family ウェブアプリは、権限のある基幹業務ユーザーがカスタマイズ可能なウェブブラウザを通じて Amazon S3 内のデータにアクセスするための、シンプルなインターフェイスの作成に使用できる新しいリソースです。 Introducing default data integrity protections for new objects in Amazon S3 Amazon S3 は、S3 の既存の耐久性体制を踏まえた新しいデータ整合性保護を使用して、オブジェクトアップロードリクエストのデフォルト動作を更新します。 セキュリティ、アイデンティティ、コンプライアンス New AWS Security Incident Response helps organizations respond to and recover from security events AWS は、セキュリティイベント対応を合理化する新しいサービスを発表しました。このサービスは、自動化されたトリアージ、調整されたコミュニケーション、および専門家によるガイダンスを提供して、サイバーセキュリティ脅威から復旧します。 Introducing Amazon GuardDuty Extended Threat Detection: AI/ML attack sequence identification for enhanced cloud security AWS は、ワークロード、アプリケーション、およびデータの全体で複雑な攻撃シーケンスを検出する AI/機械学習機能で GuardDuty を拡張しました。これらの機能は、プロアクティブなクラウドセキュリティのために、複数のセキュリティシグナルを経時的に関連付けます。 Simplify governance with declarative policies ほんの数ステップで宣言型ポリシーを作成し、組織全体の AWS サービスに望ましい設定を適用することで、現行のガバナンスオーバーヘッドを削減し、管理者とエンドユーザーに透明性を提供します。 AWS Verified Access now supports secure access to resources over non-HTTP(S) protocols (preview) ほんの数ステップで宣言型ポリシーを作成し、組織全体の AWS サービスに望ましい設定を適用することで、現行のガバナンスオーバーヘッドを削減し、管理者とエンドユーザーに透明性を提供します。 Introducing Amazon OpenSearch Service and Amazon Security Lake integration to simplify security analytics データを重複させることなくセキュリティログを分析します。効率的な脅威ハンティングと調査のために、Amazon OpenSearch Service が Amazon Security Lake とのゼロ ETL 統合を提供するようになりました。 ストレージ Announcing Amazon FSx Intelligent-Tiering, a new storage class for FSx for OpenZFS 高頻繁アクセス、低頻度アクセス、およびアーカイブのストレージ階層での自動データ階層化を備えた NAS 機能を提供する Amazon FSx Intelligent-Tiering は、最大 40 万 IOPS の高パフォーマンス、20 GB/秒のスループット、AWS サービスとのシームレスな統合を実現します。 New physical AWS Data Transfer Terminals let you upload to the cloud faster 高スループット接続を提供するセキュアな物理的ロケーションである新しい AWS Data Transfer Terminal を使用して、大規模なデータセットを驚くべきスピードで AWS にすばやくアップロードします。 Connect users to data through your apps with Storage Browser for Amazon S3 Storage Browser for Amazon S3 は、S3 内のデータを簡単に閲覧、アップロード、ダウンロード、コピー、および削除するためのアクセス権を、お客様、パートナー、従業員などの権限のあるエンドユーザーに提供するためにウェブアプリケーションに追加できる、オープンソースのインターフェイスコンポーネントです。 原文は こちら です。

12 月 1 日は、 Amazon GuardDuty の高度な AI/ML 脅威検出機能を紹介できることを嬉しく思います。この新機能では、AWS の広範なクラウド可視性とスケールを利用して、アプリケーション、ワークロード、およびデータの脅威検出を強化します。GuardDuty Extended Threat Detection は、高度な AI/ML を使用して既知の攻撃シーケンスと未知の攻撃シーケンスの両方を識別し、クラウドセキュリティへのより包括的でプロアクティブなアプローチを提供します。この強化により、現代のクラウド環境における複雑さの増大と進化するセキュリティ脅威への対応が可能になり、脅威の検出と対応が簡素化されます。 多くの組織は、クラウド環境全体で発生する大量のセキュリティイベントを効率的に分析して対応するという課題に直面しています。セキュリティ脅威の頻度と巧妙さが増すにつれて、経時的に一連のイベントとして発生する攻撃を効果的に検出して対応することがますます困難になっています。セキュリティチームはしばしば大規模な攻撃の一部である可能性のある関連アクティビティをつなぎ合わせるのに苦労し、潜在的に重大な脅威を見逃したり、重大な影響を防ぐには対応が遅すぎたりすることがあります。 これらの課題に対処するために、GuardDuty の脅威検出機能を拡張し、セキュリティシグナルを相互に関連付けて AWS 環境内のアクティブな攻撃シーケンスを特定する新しい AI/ML 機能を追加しました。これらのシーケンスには、権限発見、API 操作、永続アクティビティ、データ漏洩など、攻撃者が実行する複数の手順が含まれる場合があります。これらの検出は、重大度が極めて高い GuardDuty の新しいタイプの攻撃シーケンスの検出結果として表されます。これまで GuardDuty では「クリティカル」な重要度を使用したことはなく、機密で極めて緊急性が高い検出結果のためにこのレベルを保留していました。このような新しい検出結果ではクリティカルな重要度が導入され、脅威の性質と重要性を自然言語で要約したもの、MITRE ATT&CK® フレームワークの戦術と技法にマッピングされた観察されたアクティビティ、AWS のベストプラクティスに基づく規範的な修復のレコメンデーションなどが含まれます。 GuardDuty Extended Threat Detection では、新しい攻撃シーケンスの検出結果が導入され、認証情報の漏洩、権限昇格、データ漏洩などの領域において既存の検出の実用性が向上します。今回の機能強化により、GuardDuty はアカウント内の複数のデータソース、期間、リソースにわたる複合検出が可能になり、高度なクラウド攻撃をより包括的に理解できるようになります。 新しい機能がどのように機能するかをお見せしましょう。 Amazon GuardDuty で新しい AI/ML 脅威検出機能を使用する方法 GuardDuty で新しい AI/ML 脅威検出機能を体験するには、 Amazon GuardDuty コンソール にアクセスして、 [Summary] (概要) ページの新しいウィジェットを確認してください。概要ウィジェットは、受けている攻撃シーケンスの数を表示し、同攻撃シーケンスの詳細を検討するのに役立ちます。クラウド環境の検出結果から多段階攻撃が明らかになることがよくありますが、これらの高度な攻撃シーケンスは量が少なく、検出結果の総数に占める割合はごくわずかです。この特定のアカウントでは、クラウド環境でさまざまな検出結果を確認できますが、実際の攻撃シーケンスはほんの一握りです。大規模なクラウド環境では、数百または数千の検出結果が表示される場合がありますが、攻撃シーケンスの数は比較的少ないままである可能性があります。 また、検出結果を重要度別に表示できる新しいウィジェットも追加しました。これにより、関心のある特定の検出結果をすばやく絞り込んで調査することが容易になります。検出結果は 重要度 別にソートされるようになり、追加された クリティカル の重要度カテゴリーを含む最も重大な問題の概要が明示されるようになりました。これにより、最も緊急な検出結果にすぐに気づくことができます。また、 [Top attack sequences only] (トップアタックシーケンスのみ) を選択して、攻撃シーケンスのみをフィルタリングすることもできます。 この新機能はデフォルトで有効になっているため、使用を開始するために追加の手順を実行する必要はありません。この機能には、GuardDuty とそれに関連する保護プランの基本料金以外に追加費用はかかりません。追加の GuardDuty 保護プランを有効にすると、この機能により統合されたセキュリティ価値が高まり、より深いインサイトを得るのに役立ちます。 次の 2 種類の検出結果を確認できます。1 つ目はデータ侵害です。これは、大規模なランサムウェア攻撃の一環で起こる可能性のあるデータ侵害を示しています。データはほとんどのお客様にとって最も重要な組織のアセットであり、重要な懸念事項となっています。2 つ目の検出結果は、侵害された認証情報のタイプです。これは、通常、クラウド環境における攻撃の初期段階で、侵害された認証情報の悪用を検出するのに役立ちます。 データが侵害された検出結果の 1 つについて詳しく見ていきましょう。「アカウント内のユーザーに関連する複数のシグナルに対する一連のアクションを含む、1 つ以上の S3 バケットのデータ侵害の可能性」に焦点を当てます。この検出結果は、複数の関連シグナルにより、複数の Amazon Simple Storage Service (Amazon S3) バケットでデータが侵害されていることを確認したことを示しています。 この検出結果に含まれる概要には、アクションを実行した特定のユーザー (プリンシパル ID で識別)、影響を受けたアカウントとリソース、アクティビティが発生した長期の期間 (ほぼ 1 日) などの重要な詳細が表示されます。この情報は、潜在的な侵害の範囲と重大度をすばやく理解するのに役立ちます。 この検出結果には、ほぼ 24 時間にわたって観察された 8 つの異なるシグナルがあり、MITRE ATT&CK® フレームワークにマッピングされた複数の戦術と手法が使用されていることが示されています。認証情報へのアクセスから、発見、回避、永続性、さらには影響や流出に至るまで、攻撃チェーン全体にわたって広範囲に及んでいることから、これが本当にポジティブなインシデントであった可能性が示されています。この検出結果は、特に憂慮すべきデータ破壊の手法も浮き彫りにしています。 さらに、GuardDuty は、ユーザーが AWS CloudTrail トレイルを削除したときなど、機密性の高い API コールを強調表示することで、セキュリティコンテキストをさらに強化します。このような回避行動は、Amazon S3 オブジェクトを対象とする新しいアクセスキーとアクションの作成と相まって、インシデントの重大度と潜在的な範囲をさらに拡大します。この検出結果で提示された情報に基づいて、このインシデントをさらに徹底的に調査する必要があるでしょう。 検出結果に関連する ATT&CK 戦術 を確認することで、それが単一の戦術であろうと複数の戦術であろうと、関連する特定の戦術を把握できます。GuardDuty には、アクティビティに疑わしいというフラグが立てられ、クリティカルの重大度が割り当てられた理由を説明するセキュリティインジケーターも用意されています。これには、呼び出された高リスク API や実行された戦術が含まれます。 さらに深く掘り下げると、責任があるアクターの詳細を確認できます。この情報には、ネットワークの場所など、ユーザーがこれらのアクションにどのように接続して実行したかが含まれます。この追加のコンテキストは、調査と対応に不可欠なインシデントの全範囲と性質をよりよく理解するのに役立ちます。AWS のベストプラクティスに基づいた規範的な是正レコメンデーションに従うことで、特定された検出に迅速に対処して解決するための実用的なインサイトを得ることができます。これらのカスタマイズされたレコメンデーションは、クラウドセキュリティ体制を改善し、セキュリティガイドラインとの整合性を確保するのに役立ちます。 [Signals] (シグナル) タブは、新しい順または古い順に並べ替えることができます。アクティブな攻撃に対応する場合は、状況をすばやく把握して軽減するために、最新のシグナルから始めることをお勧めします。インシデント後のレビューでは、最初のアクティビティから遡ることができます。各アクティビティを詳しく見ると、特定の検出結果に関する詳細情報が得られます。また、 インジケーター 、 アクター 、 エンドポイント を通じてすばやく表示して、何が起きて誰がアクションを起こしたかの概要を見ることができます。 詳細を確認するもう 1 つの方法は、 [Resources] (リソース) タブにアクセスすることです。このタブでは、関連するさまざまなバケットとアクセスキーを確認できます。リソースごとに、どのような戦術やテクニックが行われたかを確認できます。開いているリソースを選択して、関連するコンソールに直接移動し、詳細を確認できます。 GuardDuty の検出結果の全ページビューが導入され、すべてのコンテキストデータを 1 か所で容易に確認できるようになりました。ただし、特定の検出結果の詳細をすばやく表示するレイアウトを希望する場合は、サイドパネル付きの従来の検出結果ページも引き続き使用できます。 GuardDuty Extended Threat Detection は、リージョン内のすべての GuardDuty アカウントで自動的に有効になり、追加の保護プランを必要とせずに基本的なデータソースを活用できます。追加の保護計画を有効にすると、分析されるセキュリティシグナルの範囲が広がり、複雑な攻撃シーケンスを特定するサービスの能力が向上します。GuardDuty では、Amazon S3 バケット内の潜在的なデータ漏洩を検出するために S3 保護 を有効にすることを特に推奨しています。S3 保護を有効にしないと、GuardDuty は S3 固有の検出結果を生成したり、S3 リソースに関連する攻撃シーケンスを特定したりできず、Amazon S3 環境におけるデータ侵害シナリオを検出する能力が制限されます。 GuardDuty Extended Threat Detection は、 AWS Security Hub 、 Amazon EventBridge 、サードパーティーのセキュリティイベント管理システムなど、既存の GuardDuty ワークフローと統合されます。 今すぐご利用いただけます Amazon GuardDuty Extended Threat Detection は、複雑な攻撃シーケンスの分析を自動化し、実用的なインサイトを提供することでクラウドセキュリティを大幅に強化します。これにより、ユーザーは最も重要な脅威に効率的に対処することに集中でき、手動分析に必要な時間と労力を低減できます。 これらの機能は、 GuardDuty がサポートされている すべての商用 AWS リージョン で、GuardDuty の新規および既存のすべてのお客様に追加費用なしで自動的に有効になります。 これらの新機能の詳細を確認し、活用し始めるには、 Amazon GuardDuty のドキュメントをご覧ください。 – Esra 原文は こちら です。

2023 年、 Amazon CloudWatch Container Insights におけるオブザーバビリティの強化 を発表しました。これは、 Amazon Elastic Kubernetes Service (Amazon EKS) のオブザーバビリティを向上させるための新機能です。この機能は、詳細なパフォーマンスメトリクスとログを提供することで、コンテナの問題をより迅速に検出して修正するのに役立ちます。 この機能を拡張して、12 月 1 日、 Amazon Elastic Container Service (Amazon ECS) で実行されるコンテナワークロードのオブザーバビリティの強化を開始します。この新機能により、アプリケーション全体の平均検出時間 (MTTD) と平均修復時間 (MTTR) が短縮され、ユーザーエクスペリエンスに悪影響を及ぼす可能性のある問題を防ぐことができます。 Amazon ECS のオブザーバビリティが強化された Container Insights を簡単に見てみましょう。 オブザーバビリティが強化された Container Insights は、コンテナモニタリングにおける重大なギャップを解消します。以前は、メトリクスをログやイベントに関連付けるには時間がかかり、多くの場合、手動での検索とアプリケーションアーキテクチャの専門知識が必要でした。この機能により、CloudWatch と Amazon ECS は、タスクレベルとコンテナレベルの両方で CPU 使用率などの詳細なパフォーマンスメトリクスを自動的に収集すると同時に、視覚的にドリルダウンして根本原因の分析を簡単に行うことができます。 この新機能により、次のユースケースが可能になります。 詳細なリソース使用パターンを確認し、テレメトリデータを関連付けることで、根本原因を迅速に特定できます。 AWS ベストプラクティスに基づいて厳選されたダッシュボードを使用して ECS リソースをプロアクティブに管理します。 最新のデプロイとデプロイ失敗の根本原因をトラッキングし、一致するインフラストラクチャの異常を特定することで、より迅速に問題を検出し、必要に応じて迅速なロールバックを行えます。 手動で設定しなくても、複数のアカウントのリソースを簡単に監視できます。組み込みのクロスアカウントサポートにより、一元的なオブザーバビリティを得て運用上のオーバーヘッドを削減できます。 Application Signals や CloudWatch Logs といった他の CloudWatch サービスと統合することで、インフラストラクチャと実行中のサービスを相互に関連付け、影響を受けるサービスを特定するシームレスな体験が得られます。 Amazon ECS でオブザーバビリティが強化された Container Insights を使用する オブザーバビリティが強化された Container Insights を有効にするには、次の 2 つの方法があります。 クラスターレベルのオンボーディング – 特定のクラスターに対して個別に有効化できます。 アカウントレベルのオンボーディング – アカウントレベルで有効にすることもできます。これにより、アカウントで作成されたすべての新しいクラスターでオブザーバビリティが自動的に有効になります。この方法では、新しいクラスターごとに手動で有効化する必要がなくなるため、時間と労力を節約できます。 この機能をアカウントレベルで有効にするには、Amazon ECS コンソールに移動して [Account settings] (アカウント設定) を選択します。 [CloudWatch Container Insights observability] (CloudWatch Container Insights のオブザーバビリティ) セクションで、現在無効になっていることがわかります。 [Update] (更新) をクリックします。 このページには、 [Container Insights with enhanced observability] (オブザーバビリティが強化された Container Insights) という新しいオプションがあります。このオプションを選択し、 [Save changes] (変更を保存) を選択します。 クラスターレベルでこの機能を有効にする必要がある場合は、新しいクラスターを作成するときに有効にできます。 既存のクラスターでもこの機能を有効にできます。そのためには、 [Update cluster] (クラスターを更新) を選択し、オプションを選択します。 有効にすると、クラスター概要コンソールの [Metrics] (メトリクス) タブに移動すると、タスクレベルのメトリクスを確認できます。クラスター全体の状態およびパフォーマンスメトリクスにアクセスするには、 [View Container Insights] (Container Insights を表示) を選択します。これにより、Container Insights ページにリダイレクトされます。 さまざまなクラスターにわたるすべてのワークロードの全体像を把握するには、Amazon CloudWatch に移動してから Container Insights に移動します。 このビューは、クラスターの状態を直感的かつ高レベルで要約できるハニカムビジュアライゼーションを提供することで、クラスター、サービス、タスク、およびコンテナを効果的に監視するという課題に対処します。ダッシュボードはデュアルステートモニタリングアプローチを採用しています。 アラーム状態 (赤または緑) – お客様が定義したしきい値とアラートを反映し、チームが特定の要件に基づいて監視を設定できるようにします 使用状況 (濃い青または水色) – CloudWatch に組み込まれているベストプラクティスを使用して、コンテナ全体のリソース使用パターンを監視します。濃い青色はクラスターの使用率が高いことを示しているため、チームはパフォーマンスに影響が出る前に潜在的なリソースの制約を事前に特定できます クラスターの 1 つに問題があるとしましょう。クラスターにカーソルを合わせると、そのクラスターの下に作成されたすべてのアラームが、クラスターレイヤーからコンテナレイヤーまで、さまざまなレイヤーで表示されます。 また、すべてのクラスターをリスト形式で表示することもできます。アカウント ID とクラスター所有権のラベルを表示するリスト形式は、アカウント間のオブザーバビリティに不可欠です。これにより、DevOps エンジニアは潜在的なアプリケーションの問題をすばやく特定してアカウント所有者と協力して解決できます。 では、さらに詳しく見ていきましょう。クラスターリンクを選択すると、Container Insights の詳細ダッシュボードビューにリダイレクトされます。ここで、このクラスターのメモリ使用率が急上昇していることがわかります。 コンテナレベルの詳細を詳しく調べることができるため、この問題の原因となっているサービスをすばやく特定できます。 便利だと思われるもう 1 つの機能は、 フィルター オプションです。これは、このクラスター内のコンテナ、サービス、またはタスクについてより詳細な調査を行うのに役立ちます。 この問題の根本原因を理解するためにアプリケーションログを詳しく調べる必要がある場合は、タスクを選択し、[Actions] (アクション) を選択し、表示するログを選択できます。 AWS X-Ray トレースを使用する以外に、ここでは別の 2 種類のログを調べることができます。まず、パフォーマンスログ (メトリクスデータを含む構造化されたログ) を使用して、コンテナレベルの根本原因を掘り下げて特定できます。次に、収集したアプリケーションまたはコンテナのログを調べます。これらのログにより、コンテナ内のアプリケーションの動作に関する詳細なインサイトが得られ、問題の原因となった一連のイベントを追跡するのに役立ちます。 ここでは、アプリケーションログを使用します。 これにより、アプリケーションのトラブルシューティング過程が効率化されます。この場合、問題はサードパーティーアプリケーションへのダウンストリームの呼び出しにあり、タイムアウトが返されます。 この拡張機能も Amazon CloudWatch Application Signals と連携して、アプリケーションを自動的にインストルメント化します。現在のアプリケーションの状態を監視し、 サービスレベル目標 に対する長期的なアプリケーションパフォーマンスを追跡できます。 [Application Signals] タブを選択します。 この Amazon CloudWatch Application Signals との統合により、エンドツーエンドの可視性が得られ、コンテナのパフォーマンスをエンドユーザーエクスペリエンスと関連付けるのに役立ちます。 グラフでデータポイントを選択すると、関連するトレースが表示され、相関しているすべてのサービスとその影響が表示されます。関連するログにアクセスして根本原因を理解することもできます。 その他の情報 ここで、重要な点をいくつかご紹介します。 利用できるリージョン – ECS 向けのオブザーバビリティが強化された Container Insights が、中国リージョンを含むすべての AWS リージョンでご利用いただけるようになりました。 料金 – ECS 向けのオブザーバビリティが強化された Container Insights には、メトリクスの定額料金がかかります。 Amazon CloudWatch の料金 ページをご覧ください。 今すぐ始めて、コンテナワークロードのオブザーバビリティの向上をご体験ください。詳細については、 Amazon CloudWatch のドキュメント ページをご覧ください。 監視がうまくいきますように。 – Donnie Prakoso 原文は こちら です。

12 月 1 日、 AWS Clean Rooms のデータコラボレーションの新しいソースとして Snowflake と Amazon Athena のサポートを発表しました。AWS Clean Rooms を使用すると、お客様とパートナーが互いの基礎データを共有したりコピーしたりすることなく、集合データセットをよりシームレスかつ安全に分析できます。この機能強化により、ソースデータを移動したり公開したりすることなく、Snowflake に保存されているデータセット、または AWS Lake Formation アクセス許可や AWS Glue データカタログビュー などの Athena 機能を使用してクエリ可能なデータセットを操作できます。 研究開発、投資、マーケティングや広告キャンペーンのためのインサイトを得るには、多くの場合、パートナーと協力してデータセットを分析する必要があります。パートナーのデータセットが Amazon Simple Storage Service (Amazon S3) の外部に保存または管理されている場合があり、企業はデータの移動やコピーにまつわる複雑さ、コスト、コンプライアンスリスク、遅延を軽減または排除したいと考えています。企業はまた、データをコピーすると古い情報が使用され、得られるインサイトの質が低下する可能性があることにも気付きました。 今回の発表は、企業が抽出、変換、ロード (ゼロ ETL) で、AWS Clean Rooms コラボレーションで最新の集合データセットを共同作業するのに役立ちます。これにより、既存の環境からのデータセットの移行に伴うコストと複雑さが解消されます。例えば、Amazon S3 にデータを保存している広告主と、Snowflake に保存されているデータを持つメディアパブリッシャーは、ETL データパイプラインを構築したり、基礎となるデータを互いに共有したりしなくても、オーディエンスの重複分析を実行して、集合データセットに存在するユーザーの割合を判断できます。コラボレーションプロセス中、外部データソースからの基礎データが AWS Clean Rooms に永続的に保存されることはなく、AWS Clean Rooms 分析環境に一時的に読み込まれたデータは、クエリの完了時に削除されます。データの保存場所に関係なくパートナーと連携できるようになり、インサイトを生成するプロセスが合理化されます。 この機能の使い方をお見せしましょう。 AWS Clean Rooms で複数のクラウドとデータソースを使用する方法 この機能を説明するために、広告主である A 社とパブリッシャーである B 社の間のシナリオを使用します。A 社は、広告キャンペーンを実施する前に、B 社のウェブサイトで価値の高いユーザーのうち何人にリーチできるかを知りたいと考えています。A 社は自社のデータを Amazon S3 に保存しています。B 社はデータを Snowflake に保存しています。AWS Clean Rooms を使用するには、両当事者がそれぞれ独自の AWS アカウントを持っている必要があります。 このデモでは、広告主である A 社がコラボレーションの作成者です。A 社は AWS Clean Rooms コラボレーションを作成し、Snowflake でデータをホストしている B 社をコラボレーションに招待します。 AWS Clean Rooms の一般提供開始のお知らせブログ記事 を読むと、具体的な手順に従ってコラボレーションを作成できます。 次に、パブリッシャーの B 社が AWS Clean Rooms で設定済みのテーブルを作成し、データソースとして Snowflake を指定し、Secrets Manager の Amazon リソースネーム (ARN) を指定する方法を示します。 AWS Secrets Manager は、ライフサイクル全体にわたってデータベース認証情報などのシークレットを管理、取得、更新するのに役立ちます。シークレットには、コラボレーションしたいデータへの読み取り専用許可を持つ Snowflake ユーザーの認証情報が含まれている必要があります。AWS Clean Rooms はこれを使用してシークレットを読み取り、Snowflake に保存されているデータにアクセスします。シークレットを作成するステップバイステップの手順については、 Secrets Manager のドキュメント を参照してください。 B 社の AWS アカウントを使用して、 AWS Clean Rooms コンソール に移動し、 [Configured resources] (設定済みリソース) で [Tables] (テーブル) を選択します。 [Configure new table] (新しいテーブルを設定) を選択します。 [Third-party clouds and data sources] (サードパーティーのクラウドとデータソース) で [Snowflake] を選択します。コラボレーションしたい Snowflake に保存されているデータセットへの読み取りアクセス権を持つロールの Snowflake 認証情報を含むシークレットの シークレット ARN を入力します。これらは、Snowflake テーブルとスキーマにアクセスしようとしているエンティティの身元を確認するために使用する認証情報です。シークレット ARN がない場合は、 [Store a new secret for this table] (このテーブルに新しいシークレットを保存) オプションを使用して新しいシークレットを作成できます。 テ ーブルとスキーマの詳細 を定義するには、 [Import from file] (ファイルからインポート) オプションを使用し、Snowflake からエクスポートした列表示情報スキーマ CSV ファイルを選択すると情報が入力されます。情報を手動で入力することもできます。 このデモでは、 [Columns allowed in collaborations] (コラボレーションで許可された列) にある [All columns] (すべての列) を選択します。次に、 [Configure new table] (新しいテーブルを設定) を選択します。 設定したテーブルに移動して、クエリの作成を許可されている AWS アカウントやクエリに使用できる列など、テーブルの詳細を確認します。このページでは、テーブル名、説明、分析ルールを編集できます。 AWS Clean Rooms でコラボレーション分析に使用するテーブルの設定の一環として、分析ルールを設定する必要があります。分析ルールは、各データ所有者が設定済みテーブルに設定するプライバシーを強化するコントロールです。分析ルールは、設定済みテーブルをどのように分析できるかを決定します。 [Configure analysis rule] (分析ルールを設定) を選択して、設定済みテーブルでカスタムクエリを実行できるカスタム分析ルールを設定します。 ステップ 1 では、選択を進めていきます。 JSON エディタ を使用して、JSON 形式の分析ルール定義を作成、貼り付け、またはインポートできます。 [Next] (次へ) を選択します。 ステップ 2 では、 [Analyses for direct querying] (ダイレクトクエリの分析) で、 [Allow any queries created by specific collaborators to run without review on this table] (特定の共同作業者が作成したすべてのクエリをこのテーブルでレビューなしで実行できるようにする ) を選択します。このオプションでは、許可されたアカウントのリストで指定した AWS アカウントが提供したクエリのみをテーブルで実行できます。許可されたアカウントによって作成されたすべての分析テンプレートは、レビューを必要とせずに自動的にこのテーブルで実行できます。 [AWS account ID] (AWS アカウント ID) で許可されたアカウントを選択し、 [Next] (次へ) を選択します。 ステップ 3 では、選択を進めていきます。クエリ出力にすべての列が表示されるように、 [Columns not allowed in output] (出力では列が許可されていません) で [None] (なし) を選択します。 [Additional analyses applied to output] (追加分析が出力に適用されました) で [Not allowed] (許可されていません) を選択して、このテーブルで追加解析を実行できなくします。 [Next] (次へ) を選択します。 最後のステップでは、設定を確認して [Configure analysis rule] (分析ルールを設定) を選択します。 次に、このテーブルを [Associate to Collaboration] (コラボレーションに関連付ける) を使用して作成した広告主であるコラボレーションの A 社に関連付けます。 ポップアップウィンドウで、アクティブなメンバーシップを持つコラボレーションからコラボレーションを選択し、 [Choose collaboration] (コラボレーションを選ぶ) を選択します。 次のページで、 [Configured table name] (設定済みのテーブル名) を選択し、 [Table associations details] (テーブルの関連付けの詳細) に 名前 を入力します。AWS Clean Rooms がテーブルをクエリする許可を付与する方法を選択します。 [Associate table] (テーブルを関連付ける) 選択します。 広告主である A 社とパブリッシャーである B 社は、オーディエンス重複分析を実行して、互いの未加工データにアクセスすることなく、集合データセットに存在するユーザーの割合を判断できるようになりました。この分析は、パブリッシャーが広告主のオーディエンスにどの程度リーチできるかを判断するのに役立ちます。重複を評価することで、広告主はパブリッシャーが独自のリーチを提供しているのか、それともパブリッシャーのオーディエンスが広告主の既存のオーディエンスと主に重複しているのかを判断できます。どちらの当事者もソースデータを移動したり共有したりする必要はありません。A 社のアカウントに切り替えて、 AWS Clean Rooms コンソールに移動します。作成したコラボレーションを選択し、次のクエリを実行してオーディエンスの重複分析結果を取得します。 select count (distinct emailaddress) from customer_data_example as advertiser inner join synthetic_customer_data as publisher on 'emailaddress' = 'publisher_hashed_email_address' この例では、Snowflake をデータソースとして使用しました。 AWS Lake Formation の許可に従い、Athena を使用してこのデータに対してクエリを実行することもできます。これにより、Lake Formation のきめ細かいアクセス制御で行レベルと列レベルのフィルタリングを行い、データセットをコラボレーションに関連付ける前に AWS Glue データカタログビューを使用してデータを変換できます。 お客様とパートナーの声 「世界初の旅行者向けメディアネットワークである Kinective Media by United Airlines での業務には、データセキュリティとプライバシーが不可欠です」と、 Kinective Media by United Airlines の Strategic Partnerships 部門 Director の Khatidja Ajania 氏 は言います。「AWS Clean Rooms は複数のクラウドと AWS ソースのソースデータをサポートしているため、より多くのブランドと安全かつシームレスに連携して、クローズドループ測定やその他の主要なユースケースを実現できます。この強化により、プライバシーが強化された広告主やパートナーとのコラボレーションを通じて、パーソナライズされたエクスペリエンス、コンテンツ、関連サービスを何百万人もの United の旅行者に安全に提供できるようになります」。 「Snowflake では、データクリーンルームテクノロジーを使用する際に、テクノロジースタック間のソースデータの相互運用性に課題があることを認識しています。ユーザーが選択したソリューションを通じて、安全かつ効果的にデータパートナーシップの可能性を最大限に引き出せるようにするという共通の目標に向けた進展と新たな一歩を踏み出したことを嬉しく思います」– Snowflake Data Clean Rooms の General Manager、Kamakshi Sivaramakrishnan 氏 今すぐご利用いただけます AWS Clean Rooms のデータソースとして Snowflake と Athena がサポートされることは、クロスクラウドコラボレーションに大きなメリットをもたらします。今回の発表により、クラウドやデータソース間でのデータ移動が不要になり、コラボレーションプロセスが簡素化されます。これは、データの保存場所に関係なく、機密情報を保護しながら、お客様があらゆるパートナーと安全に連携できる方法を拡大するための取り組みの第一歩です。 AWS Clean Rooms を今すぐ始めましょう。複数のデータソースとのコラボレーションの詳細については、 AWS Clean Rooms のドキュメント をご覧ください。 – Esra 原文は こちら です。

AWS リージョン 全体で低レイテンシーの読み取りと書き込みを維持しながら、可用性の高いアプリケーションを提供することは、多くのお客様が直面している一般的な課題です。同じリージョンのデータにアクセスする場合には遅延がマイクロ秒単位であるのに対して、異なるリージョンのデータにアクセスすると数百ミリ秒の遅延が発生する可能性があります。デベロッパーはデータレプリケーションと競合解決のために複雑なカスタムソリューションを生み出す必要があり、これにより、運用上のワークロードが増加し、潜在的なエラーが発生する可能性があります。マルチリージョンレプリケーションに加えて、これらのお客様は、手動のデータベースフェイルオーバーの手順を実装し、データ整合性とリカバリを提供して、可用性の高いアプリケーションとデータの耐久性を実現する必要があります。 12 月 1 日、 Amazon Web Services (AWS) は、 Amazon MemoryDB マルチリージョン の一般提供の開始を発表しました。これは、複数の AWS リージョンにわたって最大 99.999% の可用性、マイクロ秒単位の読み取り、および 1 桁ミリ秒の書き込みレイテンシーを提供するアプリケーションの構築に使用できる、フルマネージドのアクティブ/アクティブマルチリージョンデータベースです。MemoryDB マルチリージョンは、 Linux Foundation が管理する Redis Open Source Software (OSS) のドロップインリプレースメントである Valkey で使用できます。この新しい機能は、マルチ AZ の耐久性や複数の AWS リージョンにわたる高スループットなど、 Amazon MemoryDB の既存の利点を拡張するものであり、多くのお客様が直面しているこれらの一般的な課題に対処します。 この記事では、MemoryDB マルチリージョンの利点について説明し、 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) で使用を開始する方法を示します。 MemoryDB マルチリージョンの利点 MemoryDB マルチリージョンは、お客様に次の利点を提供します: 高可用性とディザスタリカバリ – MemoryDB マルチリージョンを使用すると、最大 99.999 % の可用性を備えたアプリケーションを構築できます。また、アプリケーションがローカルリージョンの MemoryDB に接続できない場合でも、そのアプリケーションはデータに対する読み取りおよび書き込みのフルアクセスを使用して、別の AWS リージョンのエンドポイントから MemoryDB に接続できます。アプリケーションが元の MemoryDB リージョンレベルのエンドポイントに再接続すると、MemoryDB マルチリージョンはすべての AWS リージョンにわたってデータを自動的に同期します。 マルチリージョン分散アプリケーションのためのマイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシー – MemoryDB マルチリージョンはアクティブ/アクティブレプリケーションを提供するため、その規模にかかわらず、マイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーで、顧客に最も近いリージョンからローカルに読み取りと書き込みの両方を提供できます。AWS リージョン間でデータを非同期的かつ自動的にレプリケートします。データは通常 1 秒未満で伝播されます。 特定の地域にデータが存在する必要があるコンプライアンスおよび規制要件に準拠 – ある地理的な場所内にデータが存在することを要求するコンプライアンスおよび規制要件があります。MemoryDB マルチリージョンは、お客様がデータを保存したいリージョンを選択することを可能にするため、これらの要件を満たすのに役立ちます。 Amazon MemoryDB マルチリージョンの開始方法 MemoryDB マルチリージョンの設定は簡単で、AWS マネジメントコンソール、AWS SDK、または AWS CLI を通じて実行できます。 コンソールを使用した MemoryDB マルチリージョンの開始方法 コンソールを使用して MemoryDB マルチリージョンクラスターを設定するには、次のステップを実行します: MemoryDB コンソールのナビゲーションペインで [クラスター] を選択し、 [クラスターを作成] を選択して、 [クラスタータイプ] で [マルチリージョンクラスター] を、 [クラスターの作成方法] で [新しいクラスターを作成] を選択します。 マルチリージョンクラスターを設定する際に、ワークロードの要件に基づいて [ノードタイプ] と [シャードの数] を選択できます。 適切なクラスター設定を使用して、マルチリージョンクラスター内にリージョンレベルのクラスターを作成します。 マルチリージョンクラスターと最初のリージョンレベルのクラスターを設定した後、 [AWS リージョンを追加] を選択することで、マルチリージョンクラスターに 2 番目のリージョンレベルのクラスターを追加できます。 クラスター作成ワークフローが正常に終了すると、マルチリージョンクラスター内に 2 つのリージョンレベルのクラスターがあることがわかります。 AWS CLI の使用を開始するためのステップ まず、新しい MemoryDB マルチリージョンクラスターを作成します: aws memorydb create-multi-region-cluster \ --multi-region-cluster-name-suffix testmrrlp \ --endpoint-url https://elasticache-qa.us-east-1.amazonaws.com \ --description "testdescription" \ --node-type db.r7g.xlarge \ --region us-east-1 \ --no-verify-ssl 次に、マルチリージョンクラスターにリージョンレベルのクラスターを作成します: aws memorydb create-cluster \ --cluster-name testmrrlp-member1 \ --multi-region-cluster-name ldgnf-testmrrlp \ --node-type db.r7g.xlarge \ --num-replicas-per-shard 1 \ --snapshot-retention-limit 10 \ --endpoint-url <value> \ --acl-name open-access \ --region us-east-1 \ --no-verify-ssl 最初のクラスターが正常に作成されたことを確認したら、別のリージョンに 2 番目のクラスターを作成します: aws memorydb create-cluster \ --cluster-name testmrrlp-member2 \ --multi-region-cluster-name ldgnf-testmrrlp \ --node-type db.r7g.xlarge \ --num-replicas-per-shard 1 \ --snapshot-retention-limit 10 \ --endpoint-url https://elmo-qa.fra.aws-border.com \ --acl-name open-access \ --region eu-central-1 \ --no-verify-ssl マルチリージョンクラスターのステータスを確認します: aws memorydb describe-multi-region-clusters \ --multi-region-cluster-name ldgnf-testmrrlp \ --region us-east-1 \ --show-member-cluster-details \ --endpoint-url https://elasticache-qa.us-east-1.amazonaws.com \ --no-verify-ssl 今すぐご利用いただけます Amazon MemoryDB マルチリージョンは、Valkey および次の AWS リージョンで利用可能です: 米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、および欧州 (フランクフルト、アイルランド、ロンドン)。 詳細については、 MemoryDB の特徴ページ および ドキュメント にアクセスしてください。料金については、「 Amazon MemoryDB の料金 」をご覧ください。 – Betty 原文は こちら です。

こんにちは、AWS ソリューションアーキテクト の大南です。 2024 年 6 月 27 日に「【教育委員会様向け】クラウド化で実現する校務支援システムの共同利用とゼロトラスト」というタイトルでウェビナーを開催しました。開催報告として、ウェビナーの内容と当日の資料や収録映像を紹介します。 開催の概要 統合型校務支援システム共同利用（ゼロトラストモデル）の実現に取り組まれている教育委員会や支援を担っているベンダーから具体的な取り組みや事例をご紹介いただきます。また、関連するソリューションを提供しているベンダーや Amazon Web Services (AWS) からもゼロトラストの実現を支援するサービスや構成等をご紹介いたします。 セミナー内容紹介 / 収録映像 タイトル : 【教育委員会様向け】クラウド化で実現する校務支援システムの共同利用とゼロトラスト 開催日 : 2024 年 6 月 27 日 (木) 資料 : 資料ダウンロード 動画視聴 : こちら (必要情報を入力後に視聴可能となります) 岩手県域における統合型校務支援システム共同利用（ゼロトラストモデル）の取り組み 岩手県域における統合型校務支援システムの共同利用について、岩手県教育委員会様から、共同利用に踏み切った背景やゼロトラストモデルの採用に至った背景や、プロジェクトを振り返って、クラウド化によるメリットや課題について紹介しています。また、システムディ様から、岩手県域における統合型校務支援システムの共同利用を通して、システムディ のサービスやクラウド環境のメリットのご紹介と次世代校務に関する情報を解説しています。 岩手県教育委員会 教育企画室 学校教育情報化担当課長 門脇 優行 氏 岩手県教育委員会では、県と市町村が連携して学校教育のさまざまな課題を共有しながら ICT 化に取り組んでいます。令和元年時点の統合型校務支援システムの整備率が全国平均より低かったことから、共同調達と共同利用を目指し、2021年2月に協議会の枠組みを利用することでワーキンググループを設置し着手しました。 共同利用の実現には、県がイニシャルコストを全額負担し市町村の参加を促進したこと、教育長の理解を得て業務の標準化を進めたことが重要でした。またゼロトラストモデルを採用したクラウド環境での構築により、セキュリティ強化と費用対効果の向上を図ることとしました。 プロポーザル方式で選定したシステムは、教職員の業務効率化や生体認証の導入など、様々な機能を備えています。今後の課題は、運用開始時の初期トラブル対応、効果的な運用に向けたモニタリングと改善、教職員の業務負担軽減と教育の質の向上であるとし、県と市町村が連携しながらこの取り組みを推進していくとのことです。 株式会社システムディ 公教育ソリューション事業部課長 中村 岳志 氏 株式会社システム ディは、校務支援システム「School Engine (スクールエンジン)」を提供しており、これまで全国5団体にて共同利用での統合型校務支援システムを導入しています。校務支援システムの共同利用クラウド化のメリット、岩手県教育委員会と取り組んでいる内容と AWS をクラウド基盤に採用した経緯について解説しています。 岩手県のように都道府県単位での共同利用を行うことで、コストの割り勘効果が得られることや、学習システムとのデータ連携、業務の標準化などのメリットをあげられています。また、実際の構築においては、短期間での稼働が実現できおおむね満足できる結果となったとのことです。今後は AWS のサービスアップデートに追従する体制作りの必要性や、生成 AI との連携を取り組んでいきたいとのことです。 校務 DX ・ゼロトラストを支える ID 基盤とは教職員と児童生徒のアカウントの一元管理と認証 セキュリティの強化は、校務 DX ・ゼロトラストを考えていく上で重要な課題となっています。エクスジェン・ネットワークスが提供する Extic は ID の統合管理を支援するサービスです。実際のお客様のユースケースを交えて解説しています。 エクスジェン・ネットワークス株式会社 専務取締役 引間 賢太 氏 エクスジェン・ネットワークス株式会社 引間氏より、校務 DX とゼロトラスト基盤を支える ID 基盤について解説しています。 ID 管理製品を扱う専業メーカーであるエクスジェン・ネットワークスは、統合 ID 管理パッケージソフトウェア「LDAP Manager」とクラウドサービス「Extic」を提供しています。ギガスクール構想における校務 DX の推進に伴い、ID とアクセス権限の一元管理が重要になると説明しています。Extic は認証管理と ID 管理の機能を備え、児童生徒や教職員のアカウントを一元管理し、各アプリケーションへのシングルサインオンを実現します。また、アクセス権限を所属や役職に応じて制御することで、ゼロトラストセキュリティを実現できるとしています。最後に製品の機能概要と価格モデルを紹介し、教育委員会の課題解決に貢献できると解説しています。 ダイワボウ情報システムが展開する、教育 ICT 環境におけるクラウド化の取り組み ダイワボウ情報システムが教育委員会向けに提供するプリペイドチャージや、ハンズオントレーニング等のソリューションをご紹介します。 ダイワボウ情報システム株式会社 クラウドサービス推進グループ 西崎 豪 氏 ダイワボウ情報システム株式会社では、国内初の AWS ディストリビューターとして、約1,300社の AWS ディストリビューションセラーを通じて AWS サービスを提供しています。DIS クラウドエコノミクスライトによるクラウド移行の効果分析、プリペイドチャージ for AWS による予算内での利用教育機関向けのクラウド移行を支援するメニューを用意しており、全国の教育機関の情報化、教育 DX 推進を支援していくとの解説をしています。 AWS とパートナー製品で実現する校務支援システムのゼロトラスト構成 AWS サービスとパートナー製品を組み合わせた実践的なゼロトラスト構成についてご紹介します。 アマゾンウェブサービスジャパン合同会社 パブリックセクター 技術統括本部 大南 賢亮 AWSサービスとパートナー製品による、校務支援システムのゼロトラスト構成を実現するための対応方法を解説しています。 校務支援システムを取り巻く状況、ゼロトラストの概念を解説し、文科省による教育情報セキュリティポリシーガイドラインを紹介しています。AWS サービスとパートナー製品を組み合わせることで、セキュリティ、安定性、コスト、使い勝手に優れた構成が可能であること、また、アーキテクチャとともにガイドラインを満たすためのパートナーソリューションの具体例を紹介しています。最後に AWS の採用事例と、AWS ソリューションアーキテクトによる技術支援の内容について触れ、校務支援システムの設計において、実践的な内容が示されています。 おわりに 本セミナーの内容が、校務支援システムの共同利用やゼロトラストモデルの活用の一助になれば幸いです。AWS の活用や提案に関する相談、要望がありましたら、担当営業、もしくは公式サイトの お問い合わせ よりお問い合わせください。 このブログは、2024 年 11 月 26 日時点の情報に基づいて ソリューションアーキテクト 大南賢亮 が執筆しました。

Amazon Web Services (AWS) では、新機能の大部分がお客様からの直接のフィードバックを踏まえて実現されています。 2 年前、Jeff は追加のチェックサムアルゴリズムと、オプションのクライアント側でのチェックサム計算を発表しました 。これにより、Amazon S3 に保存されているオブジェクトが、送信したオブジェクトとまったく同じであることについて、確実を期すことができます。この追加の検証により、保存されているオブジェクトが、送信したオブジェクトであると確信できるため、この追加の検証機能を愛用しているという声をお寄せいただきました。また、この追加の検証が自動的に有効になり、追加のコードを開発する必要をなくしてもらいたいという声もいただきました。 12 月 1 日より、オブジェクトをアップロードする際の Amazon Simple Storage Service (Amazon S3) のデフォルト動作を更新します。高い耐久性を実現するための既存の体勢をさらに強化するため、Amazon S3 は、データがアプリケーションから S3 バケットにネットワーク経由で正しく送信されていることを自動的に検証するようになりました。 Amazon S3 は、99.999999999% のデータ耐久性 ( イレブンナイン ) を実現するように設計されています。Amazon S3 は、オブジェクトが複数のストレージデバイスに書き込まれる前に、サーバーに到達したときにチェックサムを計算することによって、オブジェクトアップロードの整合性を常に検証してきました。データが Amazon S3 に保存されると、保管中のデータの整合性チェックが定期的に実行され、時間が経過する中でデータの耐久性が継続的にモニタリングされます。また、Amazon S3 は、オブジェクトが複数のストレージデバイスの同時障害に耐えられることを検証するのに役立つよう、データの冗長性をアクティブにモニタリングします。 ただし、データはパブリックインターネットを通過してからサーバーに到達するため、整合性のリスクに直面する可能性があります。当社が管理していないネットワーク上のハードウェアの障害や、クライアントソフトウェアのバグなどの問題により、Amazon S3 が検証する前にデータが破損またはドロップされる可能性があります。以前は、 PutObject または UploadPart リクエストで独自の事前計算済みチェックサムを提供することで、整合性保護を拡張できました。ただし、これにはチェックサムを生成して追跡するためのツールとアプリケーションの設定が必要であり、Amazon S3 にオブジェクトをアップロードするすべてのクライアントアプリケーションで一貫して実装するのは複雑になる可能性があります。 新しいデフォルト動作は、アプリケーションを変更することなく、既存のデータ整合性保護を強化します。さらに、新しいチェックサムはオブジェクトのメタデータに保存されるため、いつでも整合性検証のためにアクセスできます。 クライアント側の自動整合性保護 Amazon S3 は、デフォルトでデータ整合性保護をクライアント側のアプリケーションまで拡張するようになりました。最新バージョンの AWS SDK は、アップロードごとに 巡回冗長検査 (CRC) ベースのチェックサム を自動的に計算し、Amazon S3 に送信します。Amazon S3 は、サーバー側でチェックサムを独自に計算し、指定された値に照らして検証してから、高い耐久性をもって、オブジェクトとそのチェックサムをオブジェクトのメタデータに保存します。 クライアントアプリケーションが CRC チェックサムを送信しない場合 (古いバージョンの SDK を使用しているか、アプリケーションのカスタムコードがまだ更新されていないことが原因である可能性があります)、Amazon S3 は CRC ベースのチェックサムを計算し、将来の参照用にオブジェクトのメタデータに保存します。後で、保存された CRC と、ユーザー側で計算された CRC を比較して、ネットワーク送信が正しかったことを検証できます。 この新しい機能により、最新バージョンの AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) 、および AWS マネジメントコンソール からの新しいアップロードについてのチェックサムの自動計算と検証が提供されます。また、オブジェクトのメタデータに保存されているチェックサムをいつでも検証できます。新しいデフォルトのデータ整合性保護は、既存の CRC32 および CRC32C アルゴリズム、または新しい CRC64NVME アルゴリズム を使用します。また、Amazon S3 は、シングルパートアップロードとマルチパートアップロードで一貫したフルオブジェクトチェックサムをデベロッパーに提供します。 マルチパートでファイルをアップロードする場合、SDK は各パートについてチェックサムを計算します。Amazon S3 はこれらのチェックサムを使用して、 UploadPart API を通じて各パートの整合性を検証します。さらに、 CompleteMultipartUpload API を呼び出すと、S3 はファイル全体のサイズとチェックサムを検証します。 CreateMultiPartUpload API では、使用するチェックサムのタイプを指定できるようにする、新しい HTTP ヘッダー x-amz-checksum-type が導入されています。完全なオブジェクトチェックサム (すべての個々のパーツのチェックサムを組み合わせて計算されます) または複合チェックサムのいずれかを選択できます。 完全なオブジェクトチェックサムは、将来の参照用にオブジェクトメタデータとともに保存されます。この新しい保護は、 サーバー側の暗号化 とシームレスに連携します。アップロード、マルチパートアップロード、ダウンロード、暗号化モード全体での一貫性のある動作により、クライアント側の整合性チェックが簡素化されます。完全なオブジェクトチェックサムを使用して整合性を検証し、後で使用するために保存する機能は、アプリケーションの効率化に役立ちます。 実際の動作 この追加の整合性保護の使用を開始するには、最新バージョンの AWS SDK または AWS CLI に更新します。新しい整合性保護を有効にするためにコードを変更する必要はありません。 ケース 1: チェックサムなしでオブジェクトがアップロードされた場合、Amazon S3 はサーバー側でオブジェクトにチェックサムをアタッチするようになりました S3 バケットとの間でコンテンツをアップロードおよびダウンロードするためのシンプルな Python スクリプトを記述しました。Amazon S3 との間で送受信される実際の HTTP ヘッダーを確認するために、ログ記録の詳細度を最大にしました。 import boto3 import logging BUCKET_NAME="aws-news-blog-20241111" CONTENT='Hello World!' OBJECT_NAME='test.txt' # boto3 および botocore のデバッグログ記録を有効にして stdout に設定します (これは冗長です !!!) logging.basicConfig(level=logging.DEBUG) # S3 クライアントを作成します client = boto3.client('s3') # オブジェクトを配置します client.put_object(Bucket=BUCKET_NAME, Key=OBJECT_NAME, Body=CONTENT) # オブジェクトを取得します response = client.get_object(Bucket=BUCKET_NAME, Key=OBJECT_NAME) print(response['Body'].read().decode('utf-8')) このデモの最初のステップでは、クライアント側で CRC チェックサムを計算しない古い AWS SDK for Python を使用します。それにもかかわらず、ここでは Amazon S3 はオブジェクトの受信時に計算したチェックサムで応答するようになったことがわかります。 S3 RESPONSE: { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } ケース 2: 手動で事前計算された CRC64NVME チェックサム (新しいチェックサムタイプ) を使用してアップロードします 最新バージョンの AWS SDK を使用するオプションがない場合、または独自のコードを使用してオブジェクトを S3 バケットにアップロードする場合は、チェックサムを計算して、 PutObject API リクエストで送信できます。Amazon S3 に送信する前にコンテンツのチェックサムを計算する方法を次に示します。このコードが短くなるよう、新しい AWS SDK for Python で使用できる checksums パッケージを使用します。 from awscrt import checksums import base64 checksum = checksums.crc64nvme("Hello World!") checksum_bytes = checksum.to_bytes(8, byteorder='big') # CRC64 is 8 bytes checksum_base64 = base64.b64encode(checksum_bytes) print(checksum_base64) これを実行すると、CRC64NVME チェックサムが、前のステップで Amazon S3 によって返されたものと同じであることがわかります。 $ python crc.py b'AuUcyF784aU=' このチェックサムは、 PutObject API コールの一部として提供できます。 response = s3.put_object( Bucket=BUCKET_NAME, Key=OBJECT_NAME, Body=b'Hello World!', ChecksumAlgorithm='CRC64NVME', ChecksumCRC64NVME=checksum_base64 ) ケース 3: 新しい SDK がクライアント側でのチェックサムを計算します ここで、アップロードおよびダウンロードスクリプトを再度実行します。今回は、最新バージョンの AWS SDK for Python を使用します。SDK がリクエストで CRC ヘッダーを送信するようになったことがわかります。レスポンスにもチェックサムが含まれています。リクエストとレスポンスのバージョンを簡単に比較して、受信したオブジェクトが、送信したオブジェクトであることを確認できます。 REQUEST: { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } いつでも、 HeadObject または GetObject API を使用して、ローカルコピーの整合性を検証するためにオブジェクトチェックサムをリクエストできます。 get_response = s3.get_object( Bucket=BUCKET_NAME, Key=OBJECT_NAME, ChecksumMode='ENABLED' ) レスポンスオブジェクトには、 HTTPHeaders フィールドにチェックサムが含まれています。 { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } ケース 4: 新しい CRC ベースのオブジェクト全体のチェックサムを使用したマルチパートアップロード CreateMultipartUpload 、 UploadPart 、および CompleteMultipartUpload API を使用して大きなオブジェクトをアップロードする場合、最新バージョンの SDK はチェックサムを自動的に計算します。 既知のコンテンツチェックサムを使用することによってデータの整合性を検証する場合は、マルチパートアップロードの CRC ベースのオブジェクト全体のチェックサムを事前に計算して、クライアント側のツールを簡素化できます。マルチパートアップロードのために完全なオブジェクトチェックサムを使用すると、オブジェクトをアップロードするときにパートレベルのチェックサムを追跡する必要がなくなります。 # フルオブジェクトについての事前計算済み CRC64NVME チェックサム full_object_crc64_nvme_checksum = 'Naz0uXkYBPM=' # マルチパートアップロードを開始します create_response = s3.create_multipart_upload( Bucket=BUCKET_NAME, Key=OBJECT_NAME, ChecksumAlgorithm='CRC64NVME', ChecksumType='FULL_OBJECT' ) upload_id = create_response['UploadId'] # パートをアップロードします uploaded_parts = [] # パート 1 data_part_1 = b'0' * (5 * 1024 * 1024) # 最小パートサイズ upload_part_response_1 = s3.upload_part( Body=data_part_1, Bucket=BUCKET_NAME, Key=OBJECT_NAME, PartNumber=1, UploadId=upload_id, ChecksumAlgorithm='CRC64NVME' ) uploaded_parts.append({'PartNumber': 1, 'ETag': upload_part_response_1['ETag']}) # パート 2 data_part_2 = b'0' * (5 * 1024 * 1024) upload_part_response_2 = s3.upload_part( Body=data_part_2, Bucket=BUCKET_NAME, Key=OBJECT_NAME, PartNumber=2, UploadId=upload_id, ChecksumAlgorithm='CRC64NVME' ) uploaded_parts.append({'PartNumber': 2, 'ETag': upload_part_response_2['ETag']}) # FULL_OBJECT CRC64NVME チェックサムを使用してマルチパートアップロードを完了し、オブジェクト全体の整合性を検証します。 complete_response = s3.complete_multipart_upload( Bucket=BUCKET_NAME, Key=OBJECT_NAME, UploadId=upload_id, ChecksumCRC64NVME=full_object_crc64_nvme_checksum, ChecksumType='FULL_OBJECT', MultipartUpload={'Parts': uploaded_parts} ) print(complete_response) 知っておくべきこと 既存のオブジェクトの場合、コピー時にチェックサムが追加されます。 CopyObject API を更新したので、宛先オブジェクトのために必要なチェックサムアルゴリズムを選択できます。 この新しいクライアント側のチェックサム計算は、最新バージョンの AWS SDK に実装されています。チェックサムを事前に計算しない古い SDK またはカスタムコードを使用する場合、Amazon S3 は受信したすべての新しいオブジェクトのチェックサムを計算し、マルチパートアップロードでもオブジェクトのメタデータに保存します。 料金と利用可能なリージョン この拡張チェックサム計算とストレージは、すべての AWS リージョン で追加コストなしでご利用いただけます。 今すぐ AWS SDK と AWS CLI を更新して、転送中のデータのために、この追加の整合性保護の恩恵を自動的に享受しましょう。 Amazon S3 のデータ整合性保護の詳細については、「Amazon S3 ユーザーガイド」の「 オブジェクトの整合性をチェックする 」にアクセスしてください。 — seb 原文は こちら です。

12 月 1 日より、 AWS Database Migration Service Schema Conversion (AWS DMS SC) に、最大 90% のスキーマオブジェクトを商用データベースから PostgreSQL 移行に自動的に変換することで、データベーススキーマ変換エクスペリエンスを改善する新しい機能が導入されます。 AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、および他の種類のデータストアの移行を可能にするクラウドサービスです。 AWS DMS を使用して、 Amazon Web Services (AWS) クラウドにデータを移行したり、クラウドおよびオンプレミスの設定の組み合わせの間でデータを移行したりできます。 現在、100 万を超えるデータベースが AWS Database Migration Service を使用して移行されています。 AWS DMS は、あるデータベースシステムから別のデータベースシステムへのデータの移行に役立ちます。また、異なるデータベースエンジン間で移行する場合、AWS DMS SC はソースデータベースのスキーマとプロシージャをターゲットデータベースシステムに変換するのに役立ちます。 ただし、AWS DMS SC はこれらの移行の多くのステップを自動化しますが、特定の複雑なデータベースコード要素には依然として手動介入が必要です。これにより、移行のタイムラインが延び、コストが増える可能性があります。これは特に、PostgreSQL に直接対応するものが必ずしも存在しない独自のシステム関数またはプロシージャ、およびデータ型変換の場合に当てはまります。 AWS DMS SC の新しい 生成 AI 機能は、時間がかかるスキーマ変換タスクの一部を自動化することで、これらの課題に対処するように設計されています。この新しい機能は、 Amazon Bedrock でホストされている 大規模言語モデル (LLM) を使用して、既存の変換機能を拡張します。複雑な手順や関数など、従来のルールベースの手法ではサポートされていなかったソースデータベース内のコードスニペットを変換します。 生成 AI を利用したコード変換は、移行コストを削減し、プロジェクトのタイムラインを短縮するのに役立ちます。AWS DMS SC はスキーマ変換プロセスの多くを自動化するため、手動での変換ギャップの解決ではなく、移行後のアプリケーションの改良や最適化など、より価値の高いタスクに注力できます。ベータ版のお客様は、AWS DMS SC で AI を活用したこれらの機能を使用して既に成功を収めており、コスト削減と移行の高速化を実現しています。 仕組みを見てみましょう この新しい生成 AI 機能の使いやすさを示すために、AWS DMS SC のスキーマ変換プロセスについて説明します。  AWS DMS SC は、テーブル、ビュー、ストアドプロシージャ、関数など、ソースデータベースの構造をターゲットデータベースと互換性のある形式に自動的に変換することで、データベースの移行を簡素化します。自動的に変換できないオブジェクトには、手動で対処するようにフラグが付けられます。 まず、 Amazon Elastic Compute Cloud (Amazon EC2) で実行されているセルフマネージド型の商用データベースから始めます。 AWS マネジメントコンソール を使用して、 インスタンスプロファイル と データプロバイダー を定義します。ここで、レプリケーションインスタンスのネットワークの詳細、データベースエンジンとそのエンドポイント、データベースパスワードが安全に保存されるシークレットなどを設定します。移行プロジェクトも作成します。これらのステップは新しいものではありません。詳細については、AWS データベースブログの「 Accelerate your database migration journey using AWS DMS Schema Conversion 」をご覧ください。 プロジェクトを作成したら、それを選択し、 [スキーマ変換] タブで [スキーマ変換を起動] を選択します。変換ツールを初めて起動するには、数分かかります。 生成 AI を使用した AWS DMS SC はオプトイン機能です。まず、このオプションをアクティブ化します。 [設定] タブで、 [変換用の生成 AI 機能を有効にする] をオンにします。 変換の詳細に進む前に、移行の複雑さの全体的な評価を取得したいと思います。移行するスキーマを選択します。その後、メニューで [評価] を選択します。 数分後、高レベルの [概要] が使用可能になります。 [アクション項目] タブに詳細が表示されます。 [結果をエクスポート] を選択し、 [PDF] を選択して、同僚と共有するレポートを受け取ります。レポートは S3 バケットから生成され、使用可能になります。 概要の画面には、ルールベースの方法によって変換できる [データベースストレージオブジェクト] と [データベースコードオブジェクト] の割合が表示されます。この例では、 [100%] と [57%] です。生成 AI ベースの変換によって、この割合がどのように変化するかを見てみましょう。 PDF には、エグゼクティブサマリー、移行するオブジェクトの数に関するさまざまな統計、生成 AI を使用した変換の実現可能性、移行の複雑さが含まれています。 レポートを読むと、ストアドプロシージャの移行を妨げる要因は検出されていないことがわかります。移行するストアドプロシージャ ( PRC_AIML_DEMO6 ) を選択します。その後、ソースデータベース (左側) の [アクション] メニューを選択し、 [変換] を選択します。 1～2 分後に、左側のペインには元のプロシージャコードが表示され、右側のパネルには提案された移行バージョンが表示されます。 概要の画面が更新されました。これで、 コードの 100% が自動的に変換できることが示されるようになりました 。 必要に応じてコードを編集して変更を加えることができます。提案された新しいバージョンに問題がなければ、ターゲットデータベース側 (右側) の [アクション] メニューを選択し、 [変更を適用] を選択します。 この新しい生成 AI 機能により、AWS DMS SC は、商用データベースのスキーマオブジェクトの最大 90% を PostgreSQL に自動的に変換できます。 コンプライアンス要件をサポートするために、この機能は最初はオフになっていますが、必要に応じて有効にすることができます。AWS DMS SC で生成 AI 機能を使用する場合は、変換するオブジェクトの複雑さに基づいて、従来のルールベースの方法と生成 AI のいずれを使用するのかが柔軟に決定されます。生成 AI に対して厳格なポリシーを持つお客様は、ルールベースのアプローチのみに引き続き依拠できます。変換されていないオブジェクトや部分的に変換されたオブジェクトは手動で調整する必要があります。 利用可能なリージョンと料金 この新しい機能は現在、次の AWS リージョン でご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト)。 生成 AI を使用した AWS DMS スキーマ変換は、より高速な移行パスをお客様に提供するほか、AWS への移行を加速するのに役立ちます。 使用を開始するには、 AWS DMS スキーマ変換 のドキュメントにアクセスし、この生成 AI 機能が次のデータベース移行をどのように簡素化できるのかをご覧ください。 原文は こちら です。 — seb

12 月 1 日、宣言型ポリシーを発表しました。これは、組織全体で特定の AWS サービスのために必要な設定を宣言して強制適用するのに役立つ新しい機能です。 クラウドリソースの設定方法について、組織内で標準を作成することは、お客様にとってよくあることです。例えば、Amazon EBS スナップショットについてのパブリックアクセスをブロックする必要がある場合があります。お客様は、これらの標準を一度だけ一元的に定義し、将来組織に参加するアカウントを含むすべてのアカウントに強制適用したいと考えています。さらに、クラウドオペレーターが標準を満たさない態様でリソースを設定しようとするたびに、そのオペレーターが、設定を是正する方法を説明する、有益で実用的なエラーメッセージを受け取るようにしたいと考えています。 宣言型ポリシーは、数回のクリックまたはコマンドで AWS サービスのために必要な設定を定義および強制適用できるようにすることで、これらの課題に対処します。「VPC についてのパブリックアクセスをブロック」などの必要な設定を選択でき、ポリシーをアタッチすると、AWS は自動的にマルチアカウント環境全体 (またはその一部) で、お客様が希望する状態を強制適用します。このアプローチにより、お客様が希望する設定を実現する際の複雑さが軽減されます。設定が完了すると、新機能や新しい API が追加されても、その設定は維持されます。さらに、宣言型ポリシーを使用すると、管理者は環境全体のサービス属性の現在の状態を把握できます。また、許可のないユーザーに情報を漏らすことのないアクセスコントロールポリシーとは異なり、エンドユーザーには組織の管理者が設定したカスタムエラーメッセージが表示され、内部リソースまたはサポートチャネルにリダイレクトされます。 「ABSA Group は規制の厳しい環境で事業を展開しており、より多くのサービスを導入するようになる中で、アクションを制限するために SCP ポリシーの除外を使用し、違反を検出するために Config ルールを使用しています。しかし、新しい API や機能ごとに例外を作成する必要があります。宣言型ポリシーを使用すると、VPC ブロックパブリックアクセスを true に設定するだけで、いかなるユーザー、サービスにリンクされたロール、または将来の API も、当社の AWS Organizations でパブリックアクセスを促進できないことについて安心できます」と南アフリカのヨハネスブルグに拠点を構える多国籍銀行および金融サービスの複合企業である ABSA の Lead Product Engineer である Vojtech Mencl 氏は説明します。 「カスタムエラーメッセージを使用すると、エンドユーザーを内部ポータルに簡単にリダイレクトして、アクションが失敗した理由の詳細を提供できます。これにより、ガバナンスの運用上の複雑さが大幅に軽減され、AWS への移行が加速されます」と ABSA の Principal Engineer である Matt Draper 氏は述べています。 今回のリリースでは、宣言型ポリシーは、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Virtual Private Cloud (Amazon VPC) 、および Amazon Elastic Block Store (Amazon EBS) サービスをサポートしています。使用可能なサービス属性には、IMDSv2 の強制適用、シリアルコンソールを通じたトラブルシューティングの許可、 Amazon マシンイメージ (AMI) 設定の許可、ならびに Amazon EBS スナップショット、Amazon EC2 AMI、および VPC のパブリックアクセスのブロックが含まれます。新しいアカウントが組織に追加されると、それらのアカウントは、組織、組織単位 (OU)、またはアカウントレベルで適用された宣言型ポリシーを継承します。 宣言型ポリシーは、 AWS Organizations コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、または AWS Control Tower を通じて作成できます。ポリシーは、組織、OU、またはアカウントレベルで適用できます。宣言型ポリシーをアタッチすると、作成した AWS Identity and Access Management (IAM) ロールを使用して呼び出されたか、 サービスにリンクされたロール を使用する AWS サービスによって呼び出されたかにかかわらず、非準拠のアクションが防止されます。 宣言型ポリシーの開始方法 宣言型ポリシーのデモンストレーションのために、例を挙げて説明します。数百の AWS アカウントを持つ大企業のセキュリティ管理者として、組織の厳格なセキュリティ体制を維持する責任があるとします。当社には、いくつかの重要なセキュリティ要件があります。すなわち、すべてのネットワークでインターネットアクセスに対する厳格なコントロールを維持し、特定の信頼できるプロバイダーからの AMI のみを許可するとともに、VPC リソースが誤ってパブリックインターネットに公開されないようにする必要があります。宣言型ポリシーを使用すると、これらの要件を効率的に実装できます。私の環境でこれをどのように設定したかを説明します。 AWS Organizations コンソール に移動し、ナビゲーションペインで [ポリシー] を選択します。 [サポートされているポリシータイプ] で [EC2 の宣言型ポリシー] を選択します。 [EC2 の宣言型ポリシーを有効にする] を選択して、機能を有効にします。 宣言型ポリシーを有効にすると、AWS Organizations 内のすべてのアカウントで EC2 のために必要な設定を定義して強制適用できます。 宣言型ポリシーを作成する前に、組織の管理者として、宣言型ポリシーの機能であるアカウントステータスレポートを使用して、AWS 環境の現在のステータスを理解したいと考えています。レポートは、選択した組織の範囲内のすべてのアカウントと AWS リージョンをカバーする概要ビューと詳細な CSV ファイルの両方を提供します。ポリシーをアタッチする前に準備状況を評価するのに役立ちます。 次のページで、 [ステータスレポートを生成] を選択します。 [レポート S3 URI] の下の Amazon Simple Storage Service (Amazon S3) バケットを選択し、レポートの範囲に含めるアカウントと OU を選択します。 ステータスレポートを保存するには、S3 バケットに次のポリシーがアタッチされている必要があることに留意してください: { "Version": "2012-10-17", "Statement": [ { "Sid": "DeclarativePoliciesReportBucket", "Effect": "Allow", "Principal": { "Service": [ "report.declarative-policies-ec2.amazonaws.com" ] }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::<bucketName>/*", "Condition": { "StringEquals": { "aws:SourceArn": "arn:<partition>:declarative-policies-ec2:<region>:<accountId>:*" } } } ] } [送信] を選択します。 完了すると、レポートは指定した Amazon S3 バケットに保存されます。 [アカウントステータスレポートを表示] ページで、 [レポート] ドロップダウンから複数のレポートを選択して、さまざまな属性の現在のステータスを確認できます。 詳細な準備状況レポートを提供する CSV ファイルを保存するために指定した Amazon S3 バケットを確認します。さまざまなリージョンにわたる組織単位全体の現在の状態を確認します。 アカウントのステータスを評価した後、ポリシーの作成を続行します。 [EC2 の宣言型ポリシー] ページで、 [ポリシーを作成] を選択します。 次のページで、 [ポリシー名] を入力し、オプションで [ポリシーの説明] を入力します。 このデモでは、 ビジュアルエディタ を使用して、サービス属性を追加する方法を示します。これらの属性には、[シリアルコンソールアクセス]、[インスタンスメタデータのデフォルト]、[イメージブロックパブリックアクセス]、[スナップショットブロックパブリックアクセス]、[VPC ブロックパブリックアクセス]、および [許可されたイメージ設定] が含まれます。 JSON エディタ を使用して手動で追加することも、 ビジュアルエディタ を使用して追加したポリシーを確認することもできます。まず、 [VPC ブロックパブリックアクセス] を選択して、インターネットゲートウェイから VPC 内のリソースについてのインターネットアクセスを制御します。 [インターネットゲートウェイの状態] で [受信をブロック] を選択します。有効にすると、リソースを変更せずにパブリックアクセスが即座に防止され、ロールバックできます。 2 つ目の属性として、AMI の許可されたイメージの基準を制御するために、 [許可されたイメージ設定] を選択します。これは、すべてのインスタンスの起動で、組織内のアカウントまたはアカウントセットによって生成されたゴールデン AMI、または Amazon や Ubuntu などのベンダーによって提供されるゴールデン AMI が使用されるようにできるため便利です。 [許可されたイメージ設定] で [有効] を選択します。 [プロバイダー] で [amazon] を選択します。宣言型ポリシーは、カスタマイズ可能なエラーメッセージで透明性を提供し、エンドユーザーのフラストレーションを軽減するのに役立ちます。オプションで、制限されたアクションを組織のメンバーが実行できない場合に表示される [カスタムエラーメッセージ] を追加できます。ポリシー生成プロセスを完了するために、 [ポリシーを作成] を選択します。 次に、ポリシーを組織または特定の OU にアタッチする必要があります。 [アクション] で [ポリシーをアタッチ] を選択します。 組織または特定の OU を選択し、 [ポリシーをアタッチ] を選択します。 アカウントが組織または OU に参加すると、アタッチされた宣言型ポリシーがすぐに有効になり、その後のすべての非準拠アクションは失敗します (パブリックアクセスをすぐに制限する VPC ブロックパブリックアクセスを除く)。アカウント内の既存のリソースは削除されません。 今すぐご利用いただけます 宣言型ポリシーは、ポリシーのメンテナンスのオーバーヘッドを削減し、複数のアカウントで一貫した強制適用を提供して、管理者とエンドユーザーに透明性を提供することで、AWS のお客様のためにガバナンスを合理化します。 宣言型ポリシーは、AWS 商用リージョン、中国リージョン、AWS GovCloud (米国) リージョンでご利用いただけるようになりました。 宣言型ポリシーの詳細を確認し、組織で強制適用を開始するには、 宣言型ポリシー のドキュメントにアクセスしてください。 – Esra 原文は こちら です。

AWS Verified Access は、仮想プライベートネットワーク (VPN) なしで、企業のアプリケーションとリソースへの安全なアクセスを提供します。 当社は 2 年前の re:Invent で、企業アプリケーションへの VPN なしの安全なアクセスを提供するための手段として、プレビュー版の Verified Access をリリースしました 。これを利用することで、組織は IP アドレスではなく ID とデバイスのセキュリティに基づいてネットワークアクセスを管理できるため、アプリケーションアクセスのコントロールとセキュリティが強化されます。 12 月 1 日、 Verified Access は、非 HTTP(S) アプリケーションおよびリソースへの VPN なしの安全なアクセス機能のプレビューをリリースしました。これを利用することで、Secure Shell (SSH) や Remote Desktop Protocol (RDP) などのプロトコルを介して企業リソースへの ゼロトラスト アクセスを実現できます。 組織では、データベース、リモートデスクトップ、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの内部リソースに対する安全なリモートアクセスがますます求められています。従来の VPN ソリューションは、ネットワークアクセスでは効果的ですが、多くの場合、広範な特権を付与するものであり、きめ細かいアクセスコントロールをサポートしていないため、機密データを含むインフラストラクチャが公開される可能性があります。一部の組織はアクセスを仲介するために踏み台ホストを使用していますが、このアプローチでは、HTTP(S) アプリケーションと非 HTTP(S) アプリケーション間で複雑さとポリシーの不一致が生じる可能性があります。ゼロトラストアーキテクチャの台頭により、これらのギャップは、すべてのアプリケーションとリソースにわたって一貫したアクセスポリシーを拡張する安全なアクセスソリューションの必要性を浮き彫りにしています。 Verified Access は、企業のアプリケーションとリソース向けにゼロトラストのアクセスコントロールを提供することで、これらのニーズに対応します。SSH、RDP、Java Database Connectivity (JDBC)、Open Database Connectivity (ODBC) などのプロトコルをサポートすることで、 Verified Access はセキュリティオペレーションを簡素化します。今後は、企業のアプリケーションとリソース全体で、統一されたコンテキスト対応のアクセスポリシーを確立できるようになりました。 Verified Access は、各アクセスリクエストをリアルタイムで評価し、特定の ID およびデバイスセキュリティ要件を満たすユーザーにのみアクセスが付与されるようにします。さらに、個別の VPN や踏み台ホストが不要になるため、運用が効率化され、過剰な特権が付与された状態でのアクセスのリスクが軽減されます。 私のお気に入りの機能の 1 つは、一度に 1 つのリソースをオンボーディングするのではなく、IP Classless Inter-Domain Routing (CIDR) とポートを指定することによってリソースのグループをオンボーディングする機能です。 Verified Access は、指定された CIDR 範囲内のアクティブなリソースごとに DNS レコードを自動的に作成します。これにより、手動での DNS 設定が不要になり、ユーザーは新しいリソースに即座に接続できます。 非 HTTPS アクセスのための Verified Access の使用 非 HTTPS アクセスのために Verified Access を設定することは、現在のものとそれほど変わりません。開始方法については、 2 年前にプレビューをリリースしたときに書いたブログ記事 または「 Verified Access の使用を開始する 」チュートリアルをお読みください。 Verified Access は、1 つの単一リソースのターゲットと複数のリソースのターゲットという 2 つの新しいタイプのエンドポイントターゲットを提案します。 ネットワークインターフェイス、ロードバランサー、または RDS エンドポイントターゲット を使用すると、 Amazon Relational Database Service (Amazon RDS) インスタンスや、 Network Load Balancer または Elastic Network Interface の背後にある任意の TCP アプリケーションなどの個別のリソースへのアクセスを提供できます。このタイプのターゲットエンドポイントは、ターゲットタイプ (ロードバランサーやネットワークインターフェイスなど) と、TCP ポートの範囲の組み合わせによって定義されます。 Verified Access は、エンドポイントの作成時に各エンドポイントの DNS 名を提供します。各ターゲットには、 Verified Access DNS 名が割り当てられます。これは、エンドユーザーがリソースに安全にアクセスするために使用する名前です。 ネットワーク CIDR エンドポイントターゲット では、リソースは IP CIDR とポート範囲を使用して定義されます。このタイプのエンドポイントターゲットを使用すると、SSH や RDP などのプロトコルを介して、EC2 インスタンスなどのエフェメラルリソースへの安全なアクセスを簡単にプロビジョニングできます。これは、リソースが追加または削除されるたびにエンドポイントターゲットを作成または削除するなどのアクションを実行することなく行われます。定義された CIDR から IP アドレスがこれらのリソースに割り当てられている限り、 Verified Access は、定義された CIDR で検出されたアクティブな IP ごとに一意のパブリック DNS レコードを提供します。 このデモの設定の図を以下に示します。 パート 1: Verified Access 管理者として Verified Access 管理者として、Verified Access インスタンス 、 信頼プロバイダー 、 アクセスグループ 、 エンドポイント 、および アクセスポリシー を作成し、エンドユーザーが SSH サーバーにアクセスできるようにします。 このデモでは、 Verified Access ネットワーク CIDR エンドポイントターゲットを設定します。 [プロトコル] として [TCP] を選択し、 [エンドポイントタイプ] として [ネットワーク CIDR] を選択します。 [CIDR] の範囲が、ターゲットリソースが存在している VPC の 1 つに収まっているようにします。VPC 内の TCP [ポート範囲] と [サブネット] を選択します。 これは、足を伸ばしてコーヒーをお代わりするのに最適な瞬間です。エンドポイントの作成には数分かかります。 ステータスが [アクティブ] になったら、プライベート Amazon Virtual Private Cloud (Amazon VPC) で EC2 インスタンスを起動します。SSH を有効にして、VPC からのリクエストにのみアクセスするようにインスタンスのセキュリティグループを設定します。数分後、インスタンス IP が検出され、 Verified Access クライアントアプリケーションから接続するための DNS 名が割り当てられます。 また、設定中に、 secure.mycompany.com などの独自の DNS サブドメインを委任するオプションがあり、 Verified Access はそのサブドメイン内のリソースのために DNS 名を割り当てます。 アクセスポリシーを作成する この段階では、Verified Access エンドポイントでポリシーは定義されていません。デフォルトではあらゆるリクエストが拒否されます。 [Verified Access グループ] ページで、 [ポリシー] タブを選択します。その後、 [Modify Verified Access endpoint policy] (Verified Access エンドポイントポリシーを変更) ボタンを選択してアクセスポリシーを作成します。 認証されており、メールアドレスが @amazon.com で終わるすべてのユーザーを許可するポリシーを入力します。これは、 AWS IAM アイデンティティセンター で定義されたユーザーのために使用したメールアドレスです。 context の後の名前は、 [Verified Access 信頼プロバイダー] を作成した際に [ポリシー参照名] として入力した名前であることに留意してください。 ドキュメントページ には、使用できるポリシー構文、属性、演算子の詳細が記載されています。 permit(principal, action, resource) when { context.awsnewsblog.user.email.address like "*@amazon.com" }; 数分後、Verified Access はポリシーを更新し、再び [アクティブ] になります。 クライアントに設定を配布する Verified Access 管理者としての最後のタスクは、クライアントアプリケーションの JSON 設定ファイルを抽出することです。 クライアントアプリケーション設定ファイルは、 AWS コマンドラインインターフェイス (AWS CLI) を使用して取得します。システム管理者として、この設定を各クライアントマシンに配布します。 aws ec2 export-verified-access-instance-client-configuration \ --verified-access-instance-id "vai-0dbf2c4c011083069" { "Version": "1.0", "VerifiedAccessInstanceId": "vai-0dbf2c4c011083069", "Region": "us-east-1", "DeviceTrustProviders": [], "UserTrustProvider": { "Type": "iam-identity-center", "Scopes": "verified_access_test:application:connect", "Issuer": "https://identitycenter.amazonaws.com/ssoins-xxxx", "PkceEnabled": true }, "OpenVpnConfigurations": [ { "Config": "Y2...bWU=", "Routes": [ { "Cidr": "2600:1f10:4a02:8700::/57" } ] } ] } 接続するリソースと Verified Access インフラストラクチャの準備が整ったので、ネットワークエンドポイントにアクセスするためのエンドユーザーエクスペリエンスを皆様にご紹介します。 パート 2: エンドユーザーとして エンドユーザーとして、 Verified Access Connectivity Client アプリケーションをダウンロードしてインストール するためのリンクを受け取ります。この記事の執筆時点では、Windows および macOS クライアントがサポートされています。 管理者から受け取った設定ファイルをインストールします。ファイル名として ClientConfig1.json を使用し、Windows の場合は C:\ProgramData\AWSPylon 、macOS の場合は /Library/Application Support/com.aws.pylon.client にそのファイルをコピーします。 これはすべてのユーザーについて同じ設定ファイルであり、システム管理者はエンドポイント管理ツールを使用してすべてのクライアントマシンにそのファイルをプッシュする場合があります。 Connectivity Client アプリケーションを起動します。認証シーケンスを開始するには、 [サインイン] を選択します。 認証により、ウェブブラウザが開き、ID プロバイダーの認証ページが表示されます。実際の画面とログインシーケンスはプロバイダーによって異なります。認証されると、Connectivity Client は、リソース (このデモでは EC2 インスタンス) にアクセスするための安全なトンネルを作成します。 ステータスが [接続済み] になると、 Verified Access によって提供される DNS 名を使用して、リソースに安全に接続できます。ターミナルアプリケーションで、 ssh コマンドを入力して接続を開始します。 このデモでは、Verified Access のために委任された DNS ドメイン secure.mycompany.com を設定しました。EC2 インスタンス用に受け取った DNS アドレスは 10-0-1-199.awsnews.secure.mycompany.com です。 $ ssh -i mykey.pem ec2-user@10-0-1-199.awsnews.secure.mycompany.com , #_ ~\_ ####_ Amazon Linux 2023 ~~ \_#####\ ~~ \###| ~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023 ~~ V~' '-> ~~~ / ~~._. _/ _/ _/ _/m/' Last login: Sat Nov 17 20:17:46 2024 from 1.2.3.4 $ 利用可能なリージョンと料金 Verified Access は、次の 19 の AWS リージョン でパブリックプレビューとしてご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (ジャカルタ、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、イスラエル (テルアビブ)、南米 (サンパウロ)。 非 HTTP(S) Verified Access エンドポイントがアクティブな間、各接続について 1 時間ごとに課金されます 。各 Verified Access エンドポイントにおいて、1 か月あたり最初の 100 件の接続は無料です。詳細については、「 AWS Verified Access の料金 」をご覧ください。 HTTP(S) および非 HTTP(S) アプリケーションのために Verified Access を使用すると、プライベートアプリケーションとシステムに対するアクセスコントロールを統合し、すべてのアプリケーション、SSH、RDP、HTTP(S) リソースに対してゼロトラストポリシーを一様に適用できます。これは、ネットワークインフラストラクチャの複雑さを軽減するとともに、アプリケーションとリソースに対するゼロトラストアクセスを実装するのに役立ちます。最後に、成長し続けるインフラストラクチャに適応して、DNS 設定を自動化するとともに、リソース固有の登録なしで大規模なデプロイをサポートします。 今すぐ Verified Access をお試しいただき、チームとフィードバックをご共有ください。 — seb 原文は こちら です。

12 月 1 日は、最新の AWS Transfer Family リソースである AWS Transfer Family ウェブアプリケーション をご紹介します。認証されたユーザーが特定の Amazon Simple Storage Service (Amazon S3) バケット内のファイルを一覧表示、アップロード、ダウンロード、コピー、削除できるようにする、フルマネージドノーコードウェブアプリケーションを作成できます。組織内外の非デベロッパーの Line Of Business ユーザーは、デスクトップクライアント、スクリプト、付箋に書かれた消えかかっている指示、またはローカル IT のヘルプを必要とせずに、ファイルデータを簡単に交換できます。 ウェブアプリケーション管理者は、認証、アクセス、および許可を完全に制御でき、ページタイトルと ファビコン を使用してウェブアプリケーションをカスタマイズできます。このブログ記事を書いている間に作成したウェブアプリケーションを次に示します: ファイルをクリックしてダウンロードしたり、フォルダをクリックして開いたり、列をクリックして並べ替えたりできます。縦の三点リーダーのメニューには、追加のオプションがあります: 各ウェブアプリケーションは、最大 160 GiB のファイルのアップロードとダウンロードをサポートし、大きなファイルには マルチパートアップロード を使用します。ファイルは、TLS によって保護された HTTPS 接続を介して転送され、自動再試行と CRC32 エンドツーエンド完全性チェックが行われます。 Transfer Family ウェブアプリケーションのすべて 独自のウェブアプリケーションを作成する方法をわずか 1 分ほどでご説明します。しかし、まずは重要な機能と利点をいくつか見てみましょう… セキュリティ – Transfer Family ウェブアプリケーションは AWS IAM アイデンティティセンター を使用するため、既存の SAML または OIDC ID プロバイダー、または組み込みの Identity Store を使用できます。いずれの場合でも、 S3 Access Grants を使用すると、ファイルの表示、ダウンロード、削除、アップロード、およびディレクトリの作成が許可されているユーザーとグループを完全にきめ細かく制御できます。また、組織は、AWS Transfer Family の SOC、PCI DSS、FedRAMP、HIPAA などのプログラムへの コンプライアンス の恩恵も享受できます。 カスタマイズ – 各 Transfer Family ウェブアプリケーションをページタイトルと ファビコン でカスタマイズできます。また、ウェブアプリケーションの前に Amazon CloudFront ディストリビューションを配置し、HTTPS アクセスと パブリック証明書 を使用してカスタムドメイン名でホストすることもできます。 AWS エコシステム – Transfer Family ウェブアプリケーションは AWS でホストされるため、スケーラブルで可用性に優れています。すべてのファイルは指定された S3 バケットに保存され、耐久性はイレブンナイン (99.999999999%) です。 S3 バージョニング 、 S3 サーバーアクセスログ記録 、 S3 イベント通知 などの S3 の機能 を活用できます。また、 Amazon EventBridge を使用して、アップロード後の複雑なワークフローをオーケストレートすることもできます。 Transfer Family ウェブアプリケーションの作成 Transfer Family ウェブアプリケーションを作成するステップを見ていきましょう。各ウェブアプリケーションは特定の AWS リージョン に存在するため、 AWS Transfer Family コンソール を開き、目的のリージョン (この記事では us-east-2 ) を選択し、左側で [ウェブアプリケーション] を選択します: その後、 [ウェブアプリケーションを作成] をクリックして続行します: 必要に応じて IAM アイデンティティセンター に接続し、Transfer Family ウェブアプリケーションが S3 および S3 Access Grants にアクセスすることを許可する IAM サービスロール ( 詳細 ) を作成または選択します: [名前] タグを追加し、同時ウェブアプリケーションユーザーの最大数を設定して、 [次へ] をクリックします。 次に、ウェブアプリケーションを設計し、ページタイトルとロゴ (両方ともオプション) を設定してから、 [次へ] をクリックします: 次のページで設定を確認し、 [作成] をクリックして先に進みます: これでウェブアプリケーションが作成され、使用する準備はほとんど整いました (まだ許可とユーザーを設定する必要があります): ウェブアプリケーションに関連付けられたバケットのために間もなく作成する CORS ポリシーで [アクセスエンドポイント] を使用するので、コピーして保存します。 許可とユーザーの設定 ウェブアプリケーションを通じてアクセスできる S3 バケットに必要な読み取りおよび書き込み許可を提供する IAM カスタム信頼ポリシーを作成します ( 詳細 )。このポリシーは、この後すぐに作成する S3 Access Grant で参照されます: それから、IAM アイデンティティセンターでユーザーとグループの初期セットを作成します (後で追加できます): 次に、ウェブアプリケーションと同じリージョンに S3 バケットを作成し、S3 Access Grant を作成します。各 S3 Access Grant は、特定の IAM アイデンティティセンター ID (ユーザーまたはグループ) が、読み取りおよび/または書き込みのために特定のスコープ (バケットまたはバケットのプレフィックス付き部分) にアクセスすることを許可します: また、ウェブアプリケーションがブラウザからバケットにアクセスできるように、CORS ポリシー ( 詳細 ) をバケットにアタッチする必要があります: 最後のステップは、新しいウェブアプリケーションにユーザーを関連付けることです。AWS Transfer Family の [ウェブアプリケーション] ページに戻り、自分のアプリケーションを見つけて、 [ユーザーとグループを割り当てる] をクリックします: 自分のディレクトリに新しいユーザーを追加するか、または既存のユーザーを選択できます: まずは自分自身を追加します: 割り当てが完了すると、 [アクセスエンドポイント] (上記参照) をユーザーと共有でき、ユーザー (ここでは自分) はウェブアプリケーションにログインできます: [ウェブアプリケーションエンドポイント] と [アクセスエンドポイント] は、デフォルトでは同じです。ウェブアプリケーションのために CloudFront ディストリビューションを設定 すると、 [アクセスエンドポイント] にエンドポイントの URL が反映されます。 設定プロセスを通じた高速パスをご紹介しました。お気づきかもしれませんが、個人レベルおよびグループレベルで読み取りおよび書き込みアクセスを制御するオプションが多数あります。本番ウェブアプリケーションを設定する前に、これらのオプションをすべて調べて完全に理解してください。 知っておくべきこと S3 Transfer Family ウェブアプリケーションについて知っておくべきことがいくつかあります: リージョン – ウェブアプリケーションは 9 つの AWS リージョンで作成できます。最新のリストについては、 ウェブアプリケーションのドキュメント をご覧ください。 料金 – 料金はウェブアプリケーション/時間単位です。 API と CLI – create-web-app 、 describe-web-app 、他の AWS Transfer Family アクションを使用することで、プログラムでウェブアプリケーションを作成および管理できます。 Storage Browser for S3 – Transfer Family ウェブアプリケーションは、 Storage Browser for Amazon S3 を使用して構築され、フルマネージドオファリングで同じエンドユーザー機能を提供します。 開始方法 – Transfer Family ウェブアプリケーションは、 Transfer Family コンソール で使用を開始できます。 – Jeff ; 原文は こちら です。

12 月 1 日、 Amazon OpenSearch Service と Amazon Security Lake のゼロ ETL 統合の一般提供の開始を発表しました。この統合により、組織はセキュリティデータを効率的に検索および分析し、実用的なインサイトを得ることができるため、複雑なデータエンジニアリング要件が合理化され、セキュリティデータの潜在能力が最大限に引き出されます。これは、Security Lake でログをインプレースでクエリおよび分析する新しい方法であり、データの重複を最小限に抑え、カスタムデータパイプラインの管理にかかる運用オーバーヘッドを削減します。Security Lake データを直接クエリできるため、データの移動コストを節約できます。 OpenSearch Service と Security Lake のゼロ ETL 統合により、OpenSearch Dashboards の豊富な分析機能を使用して、Security Lake のデータをクエリおよび視覚化できます。また、単一のツールと単一のスキーマ ( Open Cybersecurity Schema Framework (OCSF) スキーマ) 内で複数のデータソースを分析して、脅威ハンティングと調査のシナリオに役立てることもできます。 時間が重要な要素となる調査とモニタリングでは、データのサブセットに迅速かつ頻繁にアクセスする必要がある場合に、Amazon OpenSearch Service でインデックス付きビューやダッシュボードなどの追加のアクセラレーションを有効にすることで、オプションでクエリパフォーマンスを改善できます。これらの機能により、ログの量にかかわらず、Security Lake に保存されているすべてのデータを完全に可視化できるため、セキュリティ調査をサポートし、セキュリティ体制をより良く理解するとともに、セキュリティ関連のインサイトを得ることができます。 Amazon Security Lake でのダイレクトクエリの開始方法 数ステップで使用を開始できます。まず、Security Lake サブスクライバーを作成して Security Lake を有効にする必要があります。その後、Amazon OpenSearch Service でデータ接続を有効にします。これにより、ダイレクトクエリの結果とインデックスを保存するための OpenSearch Serverless コレクションが自動的に作成されます。 1.Security Lake を有効にし、データレイクの許可を設定する AWS マネジメントコンソール で Security Lake を有効にするには、収集するデータソース ( Amazon Route 53 DNS クエリ、 AWS CloudTrail ログ、 Amazon VPC フローログ、 AWS Security Hub の検出結果など) と AWS リージョンを指定します。私は複数のリージョンを選択し、 Amazon Simple Storage Service (Amazon S3) ストレージクラスとロールアップリージョンを設定してデータを統合しました。 必要なデータソースを使用して組織全体にデプロイし、組織に固有のコストを見積もることができるよう、Security Lake は 15 日間の無料トライアルを提供しています。 有効化が完了すると、収集されたすべてのデータがアカウントの Amazon Simple Storage Service (Amazon S3) バケットに取り込まれます。 Security Lake の委任された管理者アカウント以外のアカウントから Security Lake データにアクセスするには、Security Lake に関連付けられた AWS Glue テーブルのデータにアクセスしてクエリするために AWS Lake Formation サブスクライバーを作成する必要があります。Security Lake へのアクセスが認可されている AWS アカウントと外部 ID を入力し、アクセスするデータソースを選択します。Lake Formation は、セキュリティアナリストがレイク内のデータにアクセスするためのクロスアカウント許可を提供します。 クエリサブスクライバーを作成したら、OpenSearch リソースをデプロイする予定のアカウントに移動し、Security Lake の委任された管理者アカウントによって共有されている AWS Resource Access Manager (AWS RAM) 共有を受け入れることができます。サブスクライバーアカウントは、手動で受け入れられるまで、共有ステータスを保留中として表示します。 詳細については、「Amazon Security Lake ユーザーガイド」の「 Enabling Security Lake using the console 」および「 Create query subscriber procedures 」にアクセスしてください。 2.OpenSearch Service とのデータ接続を作成する ゼロ ETL 統合は、数ステップで作成できます。サブスクライバーのアカウントの OpenSearch Service コンソール で、左側のナビゲーションペインの [データ接続] セクションで [接続されたデータソース] を選択します。その後、データソースのタイプとして [Security Lake] を選択できます。 次のステップでは、ゼロ ETL 統合を使用して Security Lake データソースにアクセスするための IAM 許可を設定できます。また、OpenSearch Serverless コレクションと OpenSearch アプリケーションが自動的に作成されます。 接続が作成されたら、Security Lake のデータを定期的にクエリしてビジュアライゼーションを作成する、事前構築済みの OpenSearch ダッシュボードのいずれかを選択できます。Security Lake で VPC フローログ、WAF ログ、CloudTrail データソース用のテンプレートを使用してダッシュボードを作成できます。 VPC フローログ用の事前構築済みのダッシュボードの例を次に示します。 データ接続の詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「 Data connections and permissions 」にアクセスしてください。 3.OpenSearch ダッシュボードで Security Lake データをクエリする OpenSearch ダッシュボードで Security Lake データを直接クエリするには、 [検出] ページに移動します。 [検出] ページで、データピッカーワークフローを使用して、クエリする特定の Security Lake テーブルを見つけることができます。Security Lake ログソースごとに 1 つのテーブルがあります。 選択後、使用するクエリ言語 (PPL (Piped Processing Language) または SQL (Structured Query Language) のいずれか) を選択し、クエリを記述して実行できます。PPL のサンプル結果を次に示します: クエリを開始するために、事前構築済みのクエリテンプレートを検索して実行することを選択することもできます。Security Lake で使用可能なすべての AWS ログソースをカバーする 200 を超える SQL および PPL クエリがあります。検索ボックスを使用して、興味のあるクエリを見つけることができます。例えば、「VPC Flow」と検索すると、VPC フローログに関連するすべてのクエリが表示されます。各クエリと、その使用が推奨される場合についての説明があります。 セキュリティ調査をサポートするためなど、同じデータセットに対して複数のクエリを実行する場合は、ダイレクトクエリの結果についてオンデマンドのインデックス付きビューを作成できます。結果が OpenSearch インデックスに取り込まれた後、OpenSearch の分析機能を使用して、低レイテンシーの後続のクエリと分析を実行できます。 インデックス付きビューを作成するには、 [インデックス付きビューを作成] を選択し、指定したクエリ、インデックス名、および時間範囲を選択します。ビューが作成されると、クエリ結果が取り込まれ、使用可能なインデックス付きビューの下に新しく作成されたインデックスの一部としてクエリできるようになります。 詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「 Searching data 」にアクセスしてください。 今すぐご利用いただけます Amazon OpenSearch Service と Amazon Security Lake のゼロ ETL 統合は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ)、およびカナダ (中部) の AWS リージョンでご利用いただけるようになりました。 OpenSearch Service では、OpenSearch Service でのインデックスの維持に加えて、外部データのクエリに必要なコンピューティング (OpenSearch Compute Units として) についてのみ別途料金が発生します。詳細については、「 Amazon OpenSearch Service の料金 」をご覧ください。 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 – Channy 原文は こちら です。