10 月 15 日、 Amazon Aurora PostgreSQL 互換エディション および Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合の一般提供の開始を発表できたことを喜ばしく思います。ゼロ ETL 統合により、トランザクションデータまたは運用データが Amazon Redshift でシームレスに利用できるようになるため、抽出、変換、ロード (ETL) オペレーションを実行する複雑なデータパイプラインを構築して管理する必要がなくなります。ソースデータの Amazon Redshift へのレプリケーションが自動化され、同時にソースデータが更新されるため、Amazon Redshift の分析や機械学習 (ML) 機能で利用して、タイムリーなインサイトを導き出し、時間が重要な要素となる重大なイベントに効果的に対応できます。 これらの新しいゼロ ETL 統合を使用すると、さまざまなデータパイプラインを構築して管理することなく、さまざまなアプリケーションのデータに対して統合分析を実行し、複数のリレーショナルおよび非リレーショナルデータソースから単一のデータウェアハウスにデータを書き込むことができます。この記事では、Amazon Aurora PostgreSQL と Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合の両方を開始する方法について、2 つのステップバイステップのウォークスルーを提供します。 ゼロ ETL 統合を作成するには、ソースを指定し、Amazon Redshift をターゲットとして指定します。統合により、ソースからターゲットデータウェアハウスにデータがレプリケートされ、Amazon Redshift でシームレスに利用できるようになり、パイプラインの状態がモニタリングされます。 これらの新しい統合がどのように機能するかを見てみましょう。この記事では、ゼロ ETL 統合を作成して、異なるソースデータベース (Aurora PostgreSQL と DynamoDB) から同じ Amazon Redshift クラスターにデータをレプリケートする方法を学びます。また、Aurora PostgreSQL ソースデータベースから複数のテーブルまたはデータベースを選択して、同じ Amazon Redshift クラスターにデータをレプリケートする方法も学びます。ゼロ ETL 統合が、複数の ETL パイプラインを構築および管理する運用上の負担なしでどのように柔軟性を提供するのかを見ていきます。 Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合の開始方法 データベースを作成する前に、カスタムクラスターパラメータグループを作成します。これは、Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合では、 Aurora DB クラスターパラメータ に特定の値が必要になるためです。 Amazon RDS コンソール のナビゲーションペインから、 [パラメータグループ] に移動します。 [パラメータグループを作成] を選択します。 [パラメータグループ名] と [説明] で、 custom-pg-aurora-postgres-zero-etl と入力します。 [エンジンタイプ] で [Aurora PostgreSQL] を選択し、 [パラメータグループファミリー] で [aurora-postgresql16] を選択します (ゼロ ETL 統合は PostgreSQL 16.4 以降のバージョンで機能します)。最後に、 [タイプ] で [DB クラスターパラメータグループ] を選択し、 [作成] を選択します。 次に、 [パラメータグループ] ページで新しく作成したクラスターパラメータグループを選択して編集します。 [アクション] を選択し、 [編集] を選択します。次のクラスターパラメータ設定を行います。 rds.logical_replication=1 aurora.enhanced_logical_replication=1 aurora.logical_replication_backup=0 aurora.logical_replication_globaldb=0 [変更を保存] を選択します。 次に、 [Aurora PostgreSQL データベース] を作成します。データベースを作成する際に、必要に応じて構成を設定できます。 [使用可能なバージョン] から [Aurora PostgreSQL (PostgreSQL 16.4 以降と互換性あり)] を選択し、 [追加設定] セクションの [DB クラスターパラメータグループ] で、カスタムクラスターパラメータグループ (今回は [custom-pg-aurora-postgres-zero-etl] ) を選択します。 データベースが使用可能になったら、Aurora PostgreSQL クラスターに接続して、 books という名前のデータベースを作成し、このデータベースのデフォルトスキーマに book_catalog という名前のテーブルを作成して、ゼロ ETL 統合で使用するサンプルデータを挿入します。 ゼロ ETL 統合の使用を開始するために、私は既存の Amazon Redshift データウェアハウスを使用します。Amazon Redshift リソースを作成および管理するには、「 Amazon Redshift 開始方法ガイド 」にアクセスしてください。 Amazon RDS コンソールのナビゲーションペインから [ゼロ ETL 統合] タブに移動し、 [ゼロ ETL 統合を作成] を選択します。 [統合識別子] で postgres-redshift-zero-etl と入力し、 [統合の説明] で Amazon Aurora zero-ETL integration with Amazon Redshift と入力します。 [次へ] を選択します。 次のページで、 [RDS データベースを参照] を選択してソースデータベースを選択します。 [データフィルタリングオプション] で、 database.schema.table パターンを使用します。Aurora PostgreSQL books データベースに、 book_catalog というテーブルを含めます。フィルターに * を含めると、 books データベース内のすべてのスキーマのすべての book_catalog テーブルがレプリケートされます。フィルタータイプとして [含める] を選択し、 [フィルター式] フィールドに books.*.book_catalog と入力します。 [次へ] を選択します。 次のページで、 [Redshift データウェアハウスを参照] を選択し、既存の Amazon Redshift データウェアハウスをターゲットとして選択します。Amazon Aurora がデータウェアハウスにレプリケートできるようにし、大文字と小文字の区別を有効にするには、ターゲットで認可されたプリンシパルと統合ソースを指定する必要があります。Amazon RDS はセットアップ中にこれらのステップを完了できますが、Amazon Redshift で手動で設定することもできます。このデモでは、 [修正する] を選択し、 [次へ] を選択します。 大文字と小文字の区別のパラメータとデータウェアハウスのリソースポリシーを修正したら、次の [タグと暗号化を追加] ページで [次へ] を選択します。設定を確認したら、 [ゼロ ETL 統合を作成] を選択します。 統合が成功したら、統合名を選択して詳細を確認します。 ここで、統合からデータベースを作成してセットアップを完了する必要があります。 Amazon Redshift コンソール に移動し、ナビゲーションペインで [ゼロ ETL 統合] を選択して、作成した Aurora PostgreSQL 統合を選択します。 [統合からデータベースを作成] を選択します。 [ソース名データベース] として books を選択し、 [宛先データベース名] として zeroetl_aurorapg と入力します。 [データベースを作成] を選択します。 データベースが作成されたら、[Aurora PostgreSQL 統合] ページに戻ります。このページで、 [データをクエリ] を選択して Amazon Redshift データウェアハウスに接続し、データがレプリケートされているかどうかを確認します。 zeroetl_aurorapg データベースで選択クエリを実行すると、 book_catalog テーブルのデータが正常に Amazon Redshift にレプリケートされていることがわかります。 冒頭で述べたように、Aurora PostgreSQL ソースデータベースから複数のテーブルまたはデータベースを選択して、同じ Amazon Redshift クラスターにデータをレプリケートできます。同じゼロ ETL 統合に別のデータベースを追加するために必要なのは、 [データフィルタリングオプション] に database.schema.table の形式で別のフィルターを追加し、データベース部分を、レプリケートするデータベース名に置き換えることだけです。このデモでは、同じデータウェアハウスにレプリケートする複数のテーブルを選択します。Aurora PostgreSQL クラスターに publisher という名前の別のテーブルを作成し、サンプルデータを挿入します。 レプリケーションのためにパブリッシャーテーブルを含めるように [データフィルタリングオプション] を編集します。これを実行するために、 postgres-redshift-zero-etl の詳細ページに移動し、 [変更] を選択します。 [フィルター式] フィールドに、カンマを使用して books.*.publisher を付加します。 [続行] を選択します。変更内容を確認し、 [変更を保存] を選択します。統合の詳細ページの [フィルタリングされたデータテーブル] セクションに、レプリケーションのために 2 つのテーブルが含まれていることがわかります。 Amazon Redshift クエリエディタに切り替えてテーブルを更新すると、新しい publisher テーブルとそのレコードがデータウェアハウスにレプリケートされていることがわかります。 Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合が完了したので、DynamoDB の同じデータウェアハウスとのゼロ ETL 統合を作成しましょう。 DynamoDB の Amazon Redshift とのゼロ ETL 統合の開始方法 この部分では、 Book_Catalog という名前の既存の Amazon DynamoDB テーブルを使用して、Amazon DynamoDB ゼロ ETL 統合を作成します。テーブルには 2 つの項目があります。 Amazon Redshift コンソール に移動し、ナビゲーションペインで [ゼロ ETL 統合] を選択します。その後、 [ゼロ ETL 統合を作成] の横にある矢印を選択し、 [DynamoDB 統合を作成] を選択します。 [統合名] で dynamodb-redshift-zero-etl と入力し、 [説明] で Amazon DynamoDB zero-ETL integration with Amazon Redshift と入力します。 [次へ] を選択します。 次のページで、 [DynamoDB テーブルを参照] を選択し、 Book_Catalog テーブルを選択します。統合を作成する前に、認可されたプリンシパルと統合ソースを含むリソースポリシーを指定し、ソーステーブルでポイントインタイムリカバリ (PITR) を有効にする必要があります。Amazon DynamoDB で自動的に実行することも、手動で設定を変更することもできます。統合に必要なリソースポリシーを自動的に適用し、DynamoDB テーブルで PITR を有効にするには、 [修正する] を選択します。 [次へ] を選択します。 その後、既存の Amazon Redshift Serverless データウェアハウスをターゲットとして選択し、 [次へ] を選択します。 [タグと暗号化を追加] ページで、もう一度 [次へ] を選択し、 [確認および作成] ページ で [DynamoDB 統合を作成] を選択します。 ここで、Aurora PostgreSQL ゼロ ETL 統合の場合に実行したのと同じように、統合からデータベースを作成してセットアップを完了する必要があります。Amazon Redshift コンソールで、DynamoDB 統合を選択し、 [統合からデータベースを作成] を選択します。ポップアップ画面で、 [宛先データベース名] として zeroetl_dynamodb と入力し、 [データベースを作成] を選択します。 データベースが作成されたら、Amazon Redshift の [ゼロ ETL 統合] ページに移動し、作成した DynamoDB 統合を選択します。このページで、 [データをクエリ] を選択して Amazon Redshift データウェアハウスに接続し、DynamoDB Book_Catalog テーブルからのデータがレプリケートされているかどうかを確認します。 zeroetl_dynamodb データベースで選択クエリを実行すると、データが Amazon Redshift に正常にレプリケートされていることがわかります。DynamoDB からのデータは [SUPER データ型] 列にレプリケートされており、 PartiQL sql を使用してアクセスできることに留意してください。 DynamoDB Book_Catalog テーブルに別のエントリを挿入します。 Amazon Redshift クエリエディタに切り替えて選択クエリを更新すると、新しいレコードがデータウェアハウスにレプリケートされていることがわかります。 Aurora PostgreSQL および DynamoDB と Amazon Redshift 間のゼロ ETL 統合は、複数のデータベースクラスターからのデータを統合し、データウェアハウスでインサイトを得るのに役立ちます。Amazon Redshift では、複数のテーブルに基づくクロスデータベースクエリとマテリアライズドビューを使用できるため、分析アセットを統合して簡素化し、運用効率を高め、コストを最適化する機会を得ることができます。複雑な ETL パイプラインの設定と管理について心配する必要がなくなりました。 今すぐご利用いただけます Aurora PostgreSQL の Amazon Redshift とのゼロ ETL 統合は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンでご利用いただけるようになりました。 Amazon DynamoDB の Amazon Redshift とのゼロ ETL 統合は、すべての商用、中国、GovCloud の AWS リージョンでご利用いただけるようになりました。 料金に関する情報については、 Amazon Aurora および Amazon DynamoDB の料金ページにアクセスしてください。 この機能の使用を開始するには、「 Amazon Redshift との Aurora ゼロ ETL 統合での作業 」および「 Amazon Redshift ゼロ ETL 統合 」のドキュメントをご覧ください。 – Esra 原文は こちら です。

10 月 7 日週、AWS は ロンドン と パリ で半日の無料会議を開催しました。同僚と私は、デベロッパーが生成 AI ツールを使用して設計、分析、コード作成、デバッグ、デプロイのワークフローをスピードアップする方法を実演しました。イベントは GenAI Lofts で開催されました。これらのロフトは、10 月 25 日 (ロンドン) と 11 月 5 日 (パリ) まで営業しています。イベント、会議、ワークショップ、会合などが盛りだくさんです。参加される場合は、必ずアジェンダ ( ロンドン 、 パリ ) をご確認ください。 有名な AWS ニュースブログの共著者である Veliswa が素晴らしいデモを行いました。彼女は Amazon Q Developer からの提案やレビューのみを使用して、 Duolingo のようなアプリケーション をゼロからライブコーディングしました。 それでは、先週の AWS に関するその他のエキサイティングなニュースを見てみましょう。 10 月 7 日週のリリース 私が注目したいくつかのリリースをご紹介します。 WhatsApp で会話しよう – AWS は、WhatsApp のサポートに AWS End User Messaging を追加しました。これにより、デベロッパーはマルチメディアやインタラクティブなメッセージングオプションを使用して WhatsApp のユーザーにリーチできます。この機能は、既に利用できる SMS やプッシュ通知と統合されています。デベロッパーは AWS マネジメントコンソール を使用してすぐに使い始めることができます。 データレイクテーブルによる Amazon Redshift データ共有 – これにより、さまざまな Amazon Redshift ウェアハウス間で安全で便利な方法でライブデータレイクテーブルを共有できます。 AWS Glue データカタログ のデータレイクテーブルのデータ共有により、データへのライブアクセスが可能になるため、データレイクで更新されるたびに、常に最新かつ一貫性のある情報を確認できます。 ゾーン間 Network Load Balancer 向けのゾーンシフトとゾーンオートシフト – Network Load Balancer (NLB) は、ゾーン間で有効化されるロードバランサーで Amazon Application Recovery Controller のゾーンシフトとゾーンオートシフト機能をサポートするようになりました。ゾーンシフトを使用すると、障害のあるアベイラビリティーゾーンからトラフィックをすばやく移動し、アプリケーションのデプロイ不良やグレー障害などのイベントから回復できます。ゾーンオートシフトは、AWS がアベイラビリティーゾーンへの潜在的な影響を特定したときに、トラフィックを安全かつ自動的にアベイラビリティーゾーンから遠ざけます。 Infrastructure as a Service (IaaS) コードを生成する Console to Code – 今週のローンチで断然お気に入りです。Console to Code を使うと、 AWS マネジメントコンソール でのプロトタイピングから本番デプロイ用のコード構築への移行を簡単、迅速、費用対効果の高い方法で行うことができます。1 回のクリックで、それぞれのコンソールアクションのコードを好みの形式で生成できます。生成されたコードは、タスク用のオートメーションパイプラインの使用を開始し、ブートストラップするのに役立ちます。Console to Code は Amazon Q Developer を利用しています。 AWS CodePipeline の新しい使用開始エクスペリエンス – AWS Data Pipeline では、シンプルで新しい使用開始エクスペリエンスが導入され、新しいパイプラインをすばやく作成できます。CodePipeline コンソールを使用して新しいパイプラインを作成する際、ビルド、オートメーション、デプロイのユースケースにわたるパイプラインテンプレートのリストから選択できるようになりました。パイプラインテンプレートを選択すると、パイプライン定義のアクション設定フィールドに値を入力するように求められます。プロセスが完了すると、完全に設定されたパイプラインがレンダリングされ、実行する準備が整います。 AWS Lambda は Lambda と Amazon S3 間の再帰ループを検出して停止 – Lambda 再帰ループ検出では、 AWS Lambda と Amazon Simple Storage Service (Amazon S3) の間の再帰ループを自動的に検出して停止できるようになりました。デフォルトで有効になっている Lambda 再帰ループ検出は、Lambda と他のサポートされているサービス間の再帰呼び出しを自動的に検出して停止し、暴走するワークロードによる意図しない使用や請求を防ぐ予防ガードレールです。 Amazon MemoryDB for Valkey – Amazon MemoryDB for Redis は、フルマネージド型の Valkey および Redis OSS 互換のデータベースサービスで、マルチ AZ の耐久性、マイクロ秒単位の読み取りと 1 桁のミリ秒単位の書き込みレイテンシー、および高スループットを提供しています。キャッシング、リーダーボード、セッションストアなどのユースケースに最適です。MemoryDB for Valkey により、AWS が提供するセキュリティ、運用上の優位性、信頼性を活用しながら、オープンソーステクノロジーに基づいて構築されたフルマネージド型のエクスペリエンスの恩恵を受けることができます。また、MemoryDB for Valkey は、AWS で人気のあるベクトルデータベースの中で、最も高いリコール率で最速のベクトル検索パフォーマンスを実現します。 Amazon Polly、生成エンジンに 4 つの新しい英語の音声を追加し、3 つのリージョンに拡張 – Polly は、テキストを本物そっくりの音声に変換するマネージドサービスです。これにより、ビジネスニーズに応じて会話をするアプリケーションを作成したり、音声対応製品を構築したりできます。生成エンジンは、最も高度な Amazon Polly テキスト読み上げ (TTS) モデルです。今回のローンチにより、Amazon Polly ポートフォリオにさまざまな新しい合成生成英語ボイスを追加しました。オーストラリア英語の音声 Olivia 一人と、米国英語の音声 Joanna、Danielle、Stephen の 3 人です。これらの音声はより自然な発音と韻律を持っています。このハイティア製品は、教育、出版、マーケティングなど、さまざまな業界やさまざまな目的に使用できます。 AWS のお知らせの詳細なリストについては、AWS の 最新情報 ページをご覧ください。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Cloud Day プラハ – 10 月 23 日にプラハで開催される無料のテクニカルカンファレンスにご参加ください。私も参加して、「基盤モデルをドメインエキスパートに変える技術」についてお話します。今すぐご登録ください。 Innovate の移行、モダナイズ、構築 – クラウドを初めて使用する方も、経験豊富なユーザーも、AWS Innovate で何か新しいことを学習できます。これは無料のオンライン会議です。 北米 (10 月 15 日) または欧州、中東、アフリカ (10 月 24 日) のうち、都合の良い時間とリージョンでご登録ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。10 月 19 日に ヴァドーダラー 、 スペイン 、 グアテマラ で開催される AWS Community Day をお見逃しなく。 AWS re:Invent 2024 – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの登録が開始されました。 ポッドキャストのエピソード を録音する以外に、次の 3 つのセッションのプレゼンテーションを行います。 CMP410 | Accelerate testing cycles of CI/CD pipelines with EC2 Mac instances ( Vishal と共同) DEV301 | The art of transforming foundation models into domain experts ( Gregory と共同) DEV334 | Swift, server-side, serverless これら 3 つのセッションの席は残りわずかとなっています。今すぐご予約ください。 今後開催される AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 10 月 14 日週はここまでです。10 月 21 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本ブログは 2024 年 5 月 30 日に公開されたBlog ” How to issue use-case bound certificates with AWS Private CA ” を翻訳したものです。 このブログでは、 AWS Private Certificate Authority (AWS Private CA) を使用して、特定の用途やユースケースに合わせた幅広い X.509 証明書を発行する方法を紹介します。これらの特定用途向け証明書は、 Key Usage や Extended Key Usage 拡張などの証明書コンポーネント内で、その想定される用途が定義されています。 IssueCertificate API オペレーションを使用して、必要な Key Usage (鍵用途) および Extended Key Usage (拡張鍵用途) の値を指定して、用途を定義する方法を説明します。 背景 AWS Private CA サービスを使用すると、AWS クラウド内に独自の公開鍵インフラストラクチャ (PKI) を構築し、組織内で使用する証明書を発行できます。AWS Private CA が発行する証明書は、 Key Usage 拡張と Extended Key Usage 拡張の両方をサポートしています。これらの拡張機能を特定の値で使用することで、作成時に特定のユースケースに証明書の使用を制限できます。SSL/TLS サーバー認証やコード署名など、証明書を意図されたユースケースに制限することで、アカウンタビリティや最小権限といった具体的なセキュリティ上の利点が得られます。 特定の Key Usage と Extended Key Usage の値で証明書の使用法を定義すると、組織が特定の証明書の目的とそのユースケースを理解するのに役立ちます。監査時に、組織は証明書の Key Usage と Extended Key Usage の値を調べて、証明書の目的と範囲を判断できます。これにより、証明書の使用に関するアカウンタビリティだけでなく、監査人や関係者に対する透明性も確保されます。さらに、これらの拡張機能を特定の値で使用することで、最小特権の原則に従うことができます。使用事例に必要な Key Usage と Extended Key Usage の値のみを定義することで、最小特権を付与できます。例えば、ある証明書が電子メール保護 (S/MIME) にのみ使用される場合、その証明書にはその Extended Key Usage の値のみを割り当てるべきです。 証明書テンプレートとユースケース AWS Private CA では、Key Usage 拡張機能と Extended Key Usage 拡張機能、およびそれらの値は、 IssueCertificate API オペレーションで渡される設定テンプレートを使用して指定されます。AWS が提供する ベーステンプレート は、SSL/TLS サーバー認証やコード署名など、最も一般的な証明書のユースケースに対応しています。しかし、ベーステンプレートで定義されていない証明書のその他のユースケースも存在します。これらのユースケースに対応する証明書を発行するには、 IssueCertificate リクエストでブランク証明書テンプレートを渡し、必要な Key Usage および Extended Key Usage の値を併せて指定することができます。 このようなユースケースには、以下のようなものがあります (ただし、これらに限りません)： SSL/TLS 用の証明書 Extended Key Usage の値が Server Authentication 、 Client Authentication 、またはその両方の証明書を発行します。 電子メール保護 (S/MIME) 用の証明書 Extended Key Usage の値が E-mail Protection の証明書を発行します。 スマートカード認証 (Microsoft スマートカードログイン) 用の証明書 Extended Key Usage の値が Smart Card Logon の証明書を発行します。 文書署名用の証明書 Extended Key Usage の値が Document Signing の証明書を発行します。 コード署名用の証明書 Extended Key Usage の値が Code Signing の証明書を発行します。 Matter 接続規格 に準拠した証明書 Matter 準拠のデバイス認証証明書 Matter 準拠の中間 CA 証明書 Matter 準拠のノード操作証明書 その他の Matter 準拠の証明書 証明書に、 AWS ドキュメント で定義されていないあまり一般的ではない Extended Key Usage の値が必要な場合、オブジェクト識別子 (OID) を渡して Extended Key Usage の値を定義することもできます。OID はドット区切りの文字列識別子で、オブジェクトや属性にマッピングされます。OID は、API での直接渡しを使用して カスタム拡張機能 で定義および渡すことができます。また、CSR (証明書署名要求) の透過的な受け渡しテンプレートを使用して、 CSR で OID を定義する こともできます。具体的なユースケースとしては以下が挙げられます： IPSec または仮想プライベートネットワーク (VPN) 関連の拡張機能を必要とする証明書 以下の Extended Key Usage の値を持つ証明書を発行します： OID: 1.3.6.1.5.5.7.3.5 (IPSEC_END_SYSTEM) OID: 1.3.6.1.5.5.7.3.6 (IPSEC_TUNNEL) OID: 1.3.6.1.5.5.7.3.7 (IPSEC_USER) モバイル運転免許証 (mDL) の ISO/IEC 標準に準拠した証明書 カスタム拡張機能を使用して、mDL DS 用に予約された ISO/IEC 18013-5 OID ： 1.0.18013.5.1.2 を含めます。 ブランク証明書テンプレートがエンドエンティティー証明書だけに限定されないことに注意することが重要です。例えば、 BlankSubordinateCACertificate_PathLen0_APICSRPassthrough テンプレートは、 Basic constraints パラメータを CA:TRUE に設定し、独自の Key Usage および Extended Key Usage 値を持つ下位認証局証明書を発行できるようにします。 ブランク証明書テンプレートの使用 AWS Private CA の 証明書テンプレート を閲覧すると、ベーステンプレートでは独自の Key Usage や Extended Key Usage の拡張機能と値を定義できないことがわかるかもしれません。これらは、最も一般的な証明書タイプの発行を簡素化するために、そのタイプの証明書で使用される拡張機能と値に事前設定されています。例えば、 EndEntityCertificate/V1 を使用する場合、常に Key Usage の値として Critical, digital signature, key encipherment 、Extended Key Usage の値として TLS web server authentication, TLS web client authentication が得られます。以下の表は、このベーステンプレートのすべての値を示しています。 EndEntityCertificate/V1 X509v3 パラメータ 値 Subject alternative name (サブジェクトの別名) [証明書署名要求 (CSR) からのパススルー ] Subject (サブジェクト) [CSR からのパススルー ] Basic constraints (基本制約) CA: FALSE Authority key identifier (認証局鍵識別子) [CA 証明書のサブジェクト鍵識別子 ] Subject key identifier (サブジェクト鍵識別子) [CSR から導出 ] Key Usage (鍵用途) Critical, digital signature, key encipherment Extended Key Usage (拡張鍵用途) TLS web server authentication, TLS web client authentication CRL distribution points (CRL 配布ポイント) [CA 設定からのパススルー ] ブランク証明書テンプレートを見ると、より高い柔軟性があることがわかります。ブランク証明書テンプレートの一例として、 BlankEndEntityCertificate_APICSRPassthrough/V1 を見ると、 EndEntityCertificate/V1 と比較して、事前定義された値が少ないことがわかります。 Extended Key Usage と Key Usage にカスタム値を設定することができます。 BlankEndEntityCertificate_APICSRPassthrough/V1 X509v3 パラメータ 値 Subject alternative name (サブジェクトの別名) [API または CSR からのパススルー ] Subject (サブジェクト) [API または CSR からのパススルー ] Basic constraints (基本制約) CA:FALSE Authority key identifier (認証局キー識別子) [CA 証明書のサブジェクトキー識別子 ] Subject key identifier (サブジェクトキー識別子) [CSR から導出 ] CRL distribution points (CRL 配布ポイント) 注意： CRL 配布ポイントは、CA が CRL 生成が有効に設定されている場合にのみテンプレートに含まれます。 [CA 設定または CSR からのパススルー ] 希望する拡張と値を指定するには、 IssueCertificate API 呼び出しで指定する必要があります。これには 2 つの方法があります： API パススルーテンプレートと CSR パススルーテンプレート です。 API パススルー (通過) – IssueCertificate パラメータの APIPassthrough で定義された拡張とその値が、発行された証明書にそのままコピーされます。 CSR パススルー (通過) – CSR で定義された拡張とその値が、発行された証明書にそのままコピーされます。 これらの値を渡す異なる方法に対応するため、3 種類のブランク証明書テンプレートがあります。CSR ファイルで指定された拡張機能のみを発行する証明書に引き継ぎたい場合は、 BlankEndEntityCertificate_CSRPassthrough/V1 テンプレートを使用できます。同様に、 APIPassthrough パラメータで指定された拡張機能のみを引き継ぎたい場合は、 BlankEndEntityCertificate_APIPassthrough/V1 テンプレートを使用できます。最後に、CSR と APIPassthrough の両方で指定された拡張機能の組み合わせを使用したい場合は、 BlankEndEntityCertificate_APICSRPassthrough/V1 テンプレートを使用できます。テンプレートを選択する際は、以下の点に注意することが重要です： テンプレートの定義は、使用するテンプレートの種類に関係なく、常に CSR で指定された値よりも高い優先順位になります。例えば、テンプレートに digital signature という Key Usage が含まれており、CSR ファイルに key encipherment が含まれている場合、証明書はテンプレート定義の digital signature になります。 API パススルー値は、API パススルーまたは APICSR パススルーテンプレートを使用する場合にのみ適用されます。CSR からの情報は、CSR パススルーまたは APICSR パススルーテンプレートを使用する場合にのみ適用されます。これらの情報源が競合する場合 (CSR と API パススルーで同じ拡張機能や値が指定されている場合)、通常、次のルールが適用されます：各拡張機能の値について、テンプレート定義が最も高い優先順位を持ち、次に API パススルー値、そして CSR パススルー拡張機能の順になります。テンプレートの処理順序について詳しくは、 AWS のドキュメント をご覧ください。 AWS CLI で特定用途向けの証明書を発行する方法 証明書の発行を行うには、適切な AWS Identity and Access Management (IAM) 権限 と、 「アクティブ」ステータスの AWS Private CA が必要です。プライベート CA がアクティブであることを確認するには、AWS Command Line Interface (CLI) から aws acm-pca list-certificate-authorities コマンドを実行します。以下のような出力が表示されます： "Status": "ACTIVE" ステータスを確認した後、プライベート CA の Amazon リソースネーム (ARN) をメモしておきます。 特定のユースケースに限定された証明書を発行するには、AWS Private CA の IssueCertificate API オペレーション を使用する必要があります。 AWS CLI では、 issue-certificate コマンドを使用してこの API を呼び出すことができます。このコマンドには、以下のようないくつかのパラメータを指定する必要があります： ( --certificate-authority-arn ) – プライベート CA の ARN。 ( --csr ) – PEM 形式の CSR。 blob として渡す必要があります (例： fileb:// )。 ( --validity ) – 証明書の「有効期限」(失効日時) ( --signing-algorithm ) – 証明書の署名に使用する署名アルゴリズム。選択する値は、プライベート CA のアルゴリズムファミリー (RSA または ECDSA) と一致する必要があります。例えば、プライベート CA が RSA_2048 を使用している場合、署名アルゴリズムは SHA256WITHRSA のような RSA方式のアルゴリズムである必要があります。 プライベート CA のアルゴリズムファミリーは、そのキーアルゴリズムを参照することで確認できます。 aws acm-pca describe-certificate-authority コマンドで、対応する KeyAlgorithm の値が表示されます。 ( --template-arn ) – ここでブランク証明書テンプレートが定義されます。テンプレートは AWS Private CA テンプレート ARN である必要があります。AWS Private CA テンプレート ARN の完全なリストは、 AWS ドキュメント に記載されています。 ここでは、ブランクのエンドエンティティ証明書テンプレートを使用して、特定のユースケースに対応したエンドエンティティ証明書を発行する方法を実演します。2 種類の異なる証明書を発行します。1 つは電子メール保護用、もう 1 つはスマートカード認証用です。電子メール保護とスマートカード認証の証明書には、ベーステンプレートでは定義されていない特定の Extended Key Usage の値があります。スマートカード認証証明書の発行には CSR パススルーを使用し、電子メール保護証明書の発行には API パススルーを使用します。 使用する証明書テンプレートは次のとおりです： CSR パススルーの場合： BlankEndEntityCertificate_CSRPassthrough/V1 API パススルーの場合： BlankEndEntityCertificate_APIPassthrough/V1 このデモに関する重要な注意点： これらのコマンドはデモ目的のみです。特定のユースケースによっては、メール保護証明書やスマートカード認証証明書は、このデモで示されているものとは異なる拡張が必要になる場合があります。 RSA 2048 秘密鍵を生成します。秘密鍵は適切かつ安全に保護し、保管する必要があります。秘密鍵の暗号化やハードウェアセキュリティモジュール (HSM) での保管などが、保護方法として挙げられます。 ここでは OpenSSL コマンドラインツールを使用します。このツールは Amazon Linux 2023 など多くのオペレーティングシステムにデフォルトでインストールされています。このツールがインストールされていない場合は、必要に応じて組織やオペレーティングシステムのソフトウェア配布システムを使用して入手できます。 API パススルーの使用 ここでは、電子メール保護に特化した証明書を発行する方法を実際に示します。Key Usage と Extended Key Usage の値を指定し、API パススルーを通じて subject alternative name (サブジェクトの別名) も指定します。これらの拡張機能と値が電子メール保護証明書に含まれるようにします。 拡張機能： X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: E-mail Protection X509v3 Subject Alternative Name: email:john_doe@example.com メール保護用の証明書の発行 以下のコマンドを使用して、OpenSSL でキーペアと CSR を作成します。OpenSSL プロンプトで識別名 (Distinguished Name) を入力してください。 openssl req \ -out csr-demo-1.csr \ -new -newkey rsa:2048 \ -nodes -keyout private-key-demo-1.pem EMAIL_PROTECTION Extended Key Usage の値、デジタル署名と鍵暗号化の Key Usage の値、および subject alternative name (サブジェクトの別名) john_doe@example.com を指定してエンドユーザー証明書を発行するには、以下のコマンドを使用します。値がメールアドレスであるため、 Rfc822Name subject alternative name タイプを使用します。 arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 のデータを、お使いのプライベート AWS Private CA の ARN に置き換え、署名アルゴリズムをAWS Private CA で使用しているアルゴリズムに合わせて変更してください。ここでは AWS Private CA が RSA タイプであると仮定し、SHA256WITHRSA を使用しています。 aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --csr fileb://csr-demo-1.csr \ --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1 \ --signing-algorithm "SHA256WITHRSA" \ --validity Value=365,Type="DAYS" \ --api-passthrough "Extensions={ExtendedKeyUsage=[{ExtendedKeyUsageType="EMAIL_PROTECTION"}],KeyUsage={"DigitalSignature"=true,"KeyEncipherment"=true},SubjectAlternativeNames=[{Rfc822Name="john_doe@example.com"}]}" コマンドが成功すると、発行された証明書の ARN が結果として表示されます： { "CertificateArn": "arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789" } このブログの 証明書の取得 セクションに進み、 CertificateArn から証明書と証明書チェーン PEM を取得してください。 CSR パススルーの使用 ここでは、スマートカード認証用の証明書を発行する方法を説明します。 証明書署名要求 (CSR) パススルーを通じて、Key Usage 、Extended Key Usage 、subject alternative name (サブジェクトの別名)の拡張機能と値を指定します。 目標は、これらの値をスマートカード認証証明書に含めることです。 拡張機能: X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Client Authentication, Microsoft Smartcard Login X509v3 Subject Alternative Name: othername: UPN::john_doe@example.com OpenSSL を使用して、これらの特定の拡張フィールドと値をリクエストすることで CSR を生成します。 IssueCertificate を呼び出すと、CSR の内容をそのまま反映するテンプレートがリクエストされた拡張情報を認識し、発行する証明書に反映します。 スマートカード認証用の証明書の発行 以下のコマンドを使用して秘密鍵を作成します。 openssl genpkey \ -algorithm RSA \ -pkeyopt rsa_keygen_bits:2048 \ -out private-key-demo-2.pem openssl_csr.conf というファイルを作成し、識別名 (Distinguished Name) と要求された CSR 拡張を定義します。 以下は OpenSSL 設定ファイルの例です。この設定を openssl_csr.conf ファイルにコピーし、必要に応じて値を調整できます。設定に関する詳細な参考情報は、 OpenSSL ドキュメント で確認できます。 [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = my_req_ext distinguished_name = dn #Specify the Distinguished Name [ dn ] countryName = US stateOrProvinceName = VA localityName = Test City organizationName = Test Organization Inc organizationalUnitName = Test Organization Unit commonName = john_doe #Specify the Extensions [ my_req_ext ] keyUsage = critical, digitalSignature extendedKeyUsage = clientAuth, msSmartcardLogin #UPN OtherName OID: "1.3.6.1.4.1.311.20.2.3". Value is ASN1-encoded UTF8 string subjectAltName = otherName:msUPN;UTF8:john_doe@example.com この例では、設定の [ my_req_ext ] セクションで Key Usage と Extended Key Usage の値を指定できます。 extendedKeyUsage 行では、1.3.6.1.4.1.311.20.2.2 のような Extended Key Usage OID も定義できます。可能な値は OpenSSL ドキュメント で定義されています。 設定ファイルを指定して CSR を作成します。 openssl req -new \ -key private-key-demo-2.pem \ -out csr-demo-2.csr \ -config openssl_csr.conf (オプション) 以下のコマンドを使用して CSR をデコードし、必要な情報が含まれていることを確認できます。 openssl req -in csr-demo-2.csr -noout -text 出力には、以下のように要求された拡張とその値が表示されるはずです。 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Client Authentication, Microsoft Smartcard Login X509v3 Subject Alternative Name: othername: UPN:: <your_user_here> issue-certificate コマンドを使用して証明書を発行します。CSR パススルー テンプレートを使用して、CSR ファイル内の要求された拡張と値が発行された証明書にコピーされるようにします。 arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 のデータを、お使いのAWS Private CA の ARN に置き換え、署名アルゴリズムと有効期間をユースケースに合わせて調整してください。ここでは AWS Private CA が RSA タイプであると仮定して、SHA256WITHRSA を使用しています。 aws acm-pca issue-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --csr fileb://csr-demo-2.csr \ --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 \ --signing-algorithm "SHA256WITHRSA" \ --validity Value=365,Type="DAYS" コマンドが成功すると、発行された証明書の ARN が結果として以下のように表示されます： { "CertificateArn": "arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789" } 証明書の取得 API パススルーまたは CSR パススルーで issue-certificate を使用した後、PEM 形式で証明書の内容を取得できます。 get-certificate コマンドを使用し、証明書を発行したプライベート CA の ARN と、発行された証明書の ARN をそれぞれ指定します。 aws acm-pca get-certificate \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --output text AWS CLI で --query コマンドを使用して、証明書と証明書チェーンを別々のファイルで取得できます。 証明書 aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --output text \ --query Certificate > certfile.pem 証明書チェーン aws acm-pca get-certificate \ --certificate-authority-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111 \ --certificate-arn arn:aws:acm-pca: <region> : <accountID> :certificate-authority/11111111-1111-1111-1111-111111111111/certificate/123465789123456789 \ --output text \ --query CertificateChain > certchain.pem 証明書を取得した後、openssl x509 コマンドを使用してデコードできます。これにより、定義した拡張や値を含む証明書の詳細を確認することができます。 openssl x509 -in certfile.pem -noout -text まとめ AWS Private CA では、証明書の使用方法を定義することで、アカウンタビリティと最小権限の原則というセキュリティ上の利点を実装できます。 Key Usage と Extended Key Usage の値が、証明書の使用方法を定義します。多くの証明書のユースケースでは、基本的な証明書テンプレートでは定義できない Key Usage と Extended Key Usage の組み合わせが必要です。例として、文書署名、スマートカード認証、モバイル運転免許証 (mDL) 証明書などがあります。これらの特定のユースケースに対応する証明書を発行するには、 IssueCertificate API 呼び出しと共にブランク証明書テンプレートを使用できます。ブランク証明書テンプレートに加えて、CSR パススルー機能、API パススルー機能、またはその両方を通じて、 Key Usage と Extended Key Usage の特定の組み合わせを定義する必要があります。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Chris Morris Chris は AWS のクラウドサポートエンジニアです。暗号化やデータ保護を含む、さまざまなセキュリティトピックを専門としています。クラウドにおけるセキュリティ態勢を強化するために、AWS のお客様が AWS セキュリティサービスを効果的に使用できるよう支援することに注力しています。公開鍵基盤と鍵管理は、彼のお気に入りのセキュリティトピックの一部です。 Vishal Jakharia Vishal はアメリカのニュージャージー州を拠点とするクラウドサポートエンジニアです。セキュリティサービスに関する専門知識を持ち、複雑な問題のトラブルシューティングにお客様と協力して取り組むことを好みます。AWS クラウド上での安全でスケーラブルなアーキテクチャの移行と構築をお客様に支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS は “Born from Retail, Built for Retailers” というメッセージを掲げ、Amazon で培われたノウハウをもとに流通小売消費財業界向けソリューションを提供しています。そのなかで、この業界におけるイノベーションのカギとして、「カスタマーエンゲージメント」「デジタルコマース」「インテリジェント・サプライチェーン」「マーチャンダイジング & プランニング」「スマートストア」の 5 つのテーマに取り組んでいます。 AWS を活用してサービスを提供いただいているお客様、そして世界最大級のパートナーネットワークの一員を構成する AWS パートナー各社、計 24 社が集まり、デジタルトランスフォーメーションのストーリーを共有し、「次世代小売」を形作る新しいソリューションを一挙に紹介する展示型イベント、 AWS Retail CPG Expo 2024: カスタマーエンゲージメントからスマートストアまで – 5つの戦略的イノベーションが牽引する次世代小売 を 11 月 12 日に初開催いたします。 開催によせてメッセージ： “皆様の業界課題やチャレンジを踏まえ、更なるデジタル活用での商材の企画、開発、調達から、デジタルマーケティングによる商材の訴求、オンライン／オフラインを統合した購買と高度なサプライチェーンにより、End to End での顧客体験の向上を目ざして、それぞれの領域での AWS パートナー様、ソリューションプロバイダー様のソリューションを一同にご紹介する機会を用意させて頂きました。本 Expo では各ソリューションの概要とユースケース、価値訴求ポイントを理解いただき、デモや QA 対応も兼ねた懇親の場も用意しております。皆様の奮ってのご参加をお待ち申し上げております。” – アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ事業統括本部 流通・小売・消費財営業本部 本部長 黒崎 智昭 イベント概要 AWS はお客様がビルダーとしてそれぞれの課題をテクノロジーで解決するお手伝いをしています。ビルダーとは、必ずしも自らすべてを作る（ビルドする）ことを意味するものではありません。AWS は世界中に広がるパートナーネットワークを擁しており、パートナー各社がお客様の個別の課題にフォーカスする解決策＝ソリューションを展開しています。加えて AWS テクノロジーを活用してサービスを展開するユーザー企業の皆様のソリューションもあります。自社課題の解決に適したソリューションがあれば、それを活用しない手はありません。 一方で、ソリューションはあまりにたくさんあり、自分のほしいソリューションを見つけることは簡単ではありません。 そこで、流通小売消費財業界のエンタープライズビジネスのお客様に向けて、継続的に革新を続けるソリューションプロバイダーによる最先端のソリューションをご紹介する特別な機会を提供するイベントを企画することにいたしました。 ソリューションプロバイダー各社がインタラクティブなセッションで、 カスタマーエンゲージメント デジタルコマース インテリジェント・サプライチェーン マーチャンダイジング & プランニング スマートストア の 5 つの領域で、流通小売消費財業界に固有の課題と機会に応えるサービスや、ベストプラクティスをプレゼンテーションします。 ご来場のお客様が各社と直接交流いただくための懇親会も用意し、会場では各社ブースでデモを展示します。各社のソリューションをより深く理解いただく、そして各社がご来場のお客様の特定のビジネスニーズについて個別にお伺いできる機会を提供します。 2024 年 11 月 12 日 （水）13:30 – 18:30 (13:00 受付開始) 場所： AWS 目黒オフィス 目黒セントラルスクエア 21 階 ※ 事前のお申し込み が必要です。オンラインでの開催はございません。 イベントコンテンツ それではここからは 5 つのテーマごとの登壇企業様をご紹介してまいります。当日は 2 つのトラックで並行してプレゼンテーションを行います。気になるコンテンツとタイムテーブルを事前にチェックの上、ご参加いただくことをお薦めします。 カスタマーエンゲージメント カスタマー 360° によって顧客セグメントの関係性や特徴、顧客生涯価値（LTV）を理解し、CRM、顧客データプラットフォーム（CDP）、有意義な顧客対話を行うためのコンタクトセンターなど、データ主導のインサイトによるカスタマーエンゲージメントの促進に役立つソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： Amplitude, Inc. ソリューション： Amplitude Analytics Braze 株式会社 ソリューション： Braze 富士通株式会社 ソリューション： Personalized Marketing Services 株式会社ギークフィード ソリューション： Sylphina 株式会社ジーニー ソリューション： ジーニーマーケティングクラウド CX 株式会社 primeNumber ソリューション： TROCCO 、 COMETA クアルトリクス合同会社 ソリューション：XM for Customer Experience ティーリアムジャパン株式会社 ソリューション： Tealium Customer Data Hub トレジャーデータ株式会社 ソリューション： CDP Growth Package 株式会社ヴィンクス ソリューション：CRM システム ゼンデスク ソリューション：Zendesk Suite Advanced AI add-on デジタルコマース 生成 AI などを利用した魅力的なサイトや、俊敏なコマース基盤、顧客の望む決済手段の提供といった、デジタルコマースソリューションへの投資は不可欠です。ウェブストアから、ライブコマースや没入体験まで、デジタルコマースのイノベーションを加速し、あらゆるチャネルでカスタマーエクスペリエンスを高めるためのソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： 株式会社コマースニジュウイチ ソリューション： commerce21 Fireworks Japan 株式会社 ソリューション： ライブコマースパッケージ フォーター ソリューション： Forter トラストプラットフォーム ナビプラス株式会社 ソリューション： NaviPlus シリーズ 日本電気株式会社 ソリューション： NeoSarf/DM ECモデル プリズマティクス株式会社 ソリューション： prismatix ストライプジャパン株式会社 ソリューション： Stripe Payments インテリジェント・サプライチェーン サプライチェーンコントロールタワー、倉庫管理システム（WMS）などインテリジェント・サプライチェーンによって、企業内のデータサイロを解消し、高度な AI/ML アルゴリズムを実行して、サプライチェーンを革新および合理化するとともに、変化するあらゆる部分をつなげ、最適化するソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： 株式会社日立製作所 ソリューション： HITLUSTER o9 ソリューションズ・ジャパン株式会社 ソリューション： o9 デジタルブレイン SCSK 株式会社 ソリューション： デジタルサプライチェーンソリューション マーチャンダイジング & プランニング 需要予測の精度を向上させ、在庫水準を予測して適正に保つ、マージンを維持しつつプロモーションの効果を最大化するなど、強化された顧客洞察、需要予測、カテゴリ管理、および店舗実装を通じて、マーチャンダイジングの決定と実行を改善するためのソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： フューチャーアーキテクト株式会社 ソリューション： FutureApparel スマートストア 新たな顧客接点デバイスの可能性を持つ POS、小売業に新たな収益の柱をもたらすことが期待される店舗内デジタルサイネージやリテールメディアの活用といったソリューションをご紹介します。 登壇予定ソリューションプロバイダー（アルファベット順）： Hexa ソリューション：3Dモデル作成・管理ソリューション 日本電気株式会社 ソリューション： NeoSarf/POS ヨメテル株式会社 ソリューション：RFID アンテナ タイムテーブル 2024 年 11 月 12 日 （水）13:30 – 18:30  (13:00 受付開始) 場所：　AWS 目黒オフィス 目黒セントラルスクエア 21 階 13:00 開場 13:30-17:30 各社ソリューションのプレゼンテーション 17:30-18:30 懇親会 & 会場にて各社デモ展示 お申し込みは こちら から。 ※プレゼンテーションの登壇順序はイベントページに掲載しております。 セッションでは、ソリューションプロバイダー全 24 社が次々に登壇し、各 15 分で各社の最もおすすめするソリューションをご紹介していきます。 懇親会ではお食事をお楽しみいただきつつ、各社のデモブースにてご興味のあるソリューションをじっくりとデモでご覧いただき、個別にお話をしていただく時間がございます。また会場では、お客様とソリューションプロバイダーの皆様、あるいはお客様同士でも、様々なネットワーキングをお楽しみいただけるような企画もご用意しています。 この特別な機会をお見逃しなく。皆様のご参加を楽しみにお待ちしております！

こんにちは、カスタマーソリューションマネージャーの服部です。「 クラウドジャーニーの歩み方（前編） 」でクラウドジャーニーの Assess （評価）フェーズ、 Mobilize （移行準備）フェーズについてお話させていただきましたので、今回のブログでは Migration （移行）フェーズと Modernization （モダナイゼーション）フェーズにおける課題や取り組むべき活動についてご紹介していきます。 Migration（移行）フェーズ オンプレまたは他クラウドから 7R を基に移行方法を選択してAWSクラウドに移行を行うフェーズになります。 7R とはシステムを移行する際の具体的な手法のことで、 AWS では「 Relocate 」「 Rehost 」「 Replatform 」「 Repurchase 」「 Refactor 」「 Retire 」「 Retain 」の頭文字を取った「 7R 」を移行戦略として提唱しています。このフェーズで本番稼働しているアプリケーションをクラウド環境へ移行することになりますが、このフェーズでの課題と解決策については Tech 領域、 NonTech 領域それぞれこちら（ Tech課題 ／ NonTech課題 ）に詳しく記載していますのでご覧下さい。 このフェーズで行う実際の移行作業は大きく以下の３つの手順を踏んで進めていきます。 移行計画策定（具体的な移行手順） リハーサル実施 部分移行、全面移行 それぞれの手順ついて詳しく見ていきましょう。 移行計画策定 Assess フェーズ、 Mobilize フェーズで移行の前準備は整っているため、実際に移行を行うプロジェクトを立ち上げます。プロジェクトを遂行していくために「移行の体制」、「移行スケジュール」、「移行対象システム」、「移行方法( 7R )」、「コンティンジェンシープラン」、「意思決定フロー」を策定します。特に移行時に障害が発生した際にどこまでロールバックを行うのか、誰が対応を判断するかなどコンテンジェンシープランを立てておくことが重要です。計画が策定できたら移行作業を行うメンバーを招集して、移行が完了するまで定例会議を開催してメンバー間でコミュニケーションを密に取ることをお勧めします。 リハーサル実施 実際に本番移行を手順の確認をするために事前リハーサルを行います。本番移行で失敗しないために本番と同じ体制で同じ手順で実施することが重要です。ここで手順の確認だけでなく移行作業に掛かる時間を確認することで具体的な移行スケジュールを精緻に立てることができ、実際の移行でシステムを停止させる時間も確認できます。 AWS では、このリハーサルを支援することもできますので、移行の手順など本番移行に際してお悩みのお客さまは是非ご相談ください。 部分移行、全面移行 まずは影響の少ないシステムから部分移行を行うことで、ビジネスインパクトを最小限に抑えた形で移行を始められます。部分移行で手順とシステムへの影響度を確認後、対象システムを広げてリハーサルと部分移行を繰り返していき、移行計画で策定した対象システムの全面移行を完遂させていきます。 これらの手順を遂行するためには移行経験のあるメンバーのサポートが必要になりますが、 CCoE がすでに組成されている場合は CCoE メンバーの支援、組成されていない場合は AWS移行パートナー の協力を得ることで移行をスムーズに進めることができます。 Modernization（モダナイゼーション）フェーズ モダナイゼーションには 1step モダナイゼーションと 2step モダナイゼーションの主な２つのパスがあります。前者は、マイグレーションのタイミングでモダナイズも合わせて行う移行方法で、オンプレから一気にクラウドのメリットを十分に享受できる環境に移行する形です。新規にモダンな環境をクラウド上に構築する場合もこの1step モダナイゼーションの移行方法になります。クラウドスキルや移行経験がある状態でクラウドの価値を最大限活用されたいお客様はこちらを選択することをお勧めします。この移行方法の場合でも前述のマイグレーションフェーズでの実施内容は省略せずに行います。一方、後者は一度リホストを行った後にモダナイズを行う移行方法になりますので、短期間にオンプレサーバを移行されたいお客様はこちらを選択することでリスクを軽減した状態で迅速に移行ができます。クラウドスキルや移行経験がない場合でも、経営判断によって計画的に移行する場合は前者を選択することも可能です。 モダナイゼーションという言葉は、認識違いから本来の目的を見失っている状態で使われている場面が多く見受けられます。モダナイゼーションとは個別技術要素のことではなく、企業や組織が社会の変化にあわせて素早く価値を提供し続けるために組織やシステムを常に新しくしていくことを表しており、人・組織、プロセス、テクノロジーの3つの軸を組み合わせて推進する必要があります。３つの軸を組み合わせて推進するとは、開発を効率的に回すことを目的として組織体制を改善してチームに裁量を渡して自律を促すこと（人・組織）、 IT アーキテクチャだけを変更するのではなく一連の開発作業におけるボトルネックを改善する（プロセス）、最新技術を闇雲に適用しようとせずに課題を解決するための合理的な変更をすること（テクノロジー）、これらを組み合わせて現状の課題を解決していくことを示しています。 どれか1つを刷新するのではなく、組み合わせてモダナイゼーションを推進していくことをイメージしていただくことで本来の目的を見失うリスクを防ぐことができます。他には認識の違いからあれもこれもすべて刷新しようとする状況も発生しがちです。モダナイゼーションを推進するためには、どの様なビジネス効果を実現するかに応じて最適な手段を選択していくことも気を付けるポイントです。 このフェーズはワークロードのコスト最適化やコンテナ、サーバレス、 CI/CD などを適用してモダナイゼーションを行い、クラウド活用によるビジネス効果を最大化させるフェーズです。既存システムが大規模のためモダナイゼーション対象システムの選定をどのように進めていけば良いのか分からない今あるシステムを変えていくとしたらどのような技術が適切なのか分からないなど、初めてクラウド移行を行う際と同様にスキル、経験不足に起因した課題が多く発生します。 対象システムの選定の課題に対しては、 AWS ではお客さまの業務システムを様々な観点から評価・分析し、モダナイゼーションのポイントや To-Be アーキテクチャ案を提示させていただくことができます。 To-Be アーキテクチャを確認することで、対象システムのモダナイゼーション計画が立てやすくなります。 また、スキル、経験不足の課題に対しては、各種学習やハンズオンなどを実施して補うことは良いアプローチですが、最も重要なのはまずは小さく始めてみることです。 PoC や比較的影響が少ないプロジェクトを選定してパイロット移行を複数回行うことによって実体験からモダナイズのスキルや経験を積むことをお勧めします。プロジェクトメンバーの役割を問わず、実際に手を動かして初めて分かることが多いため、実際にモダナイズ経験をすることで移行計画を段階的に立案することができるようになりますし、その後の移行を加速させる効果が得られます。 まとめ ここまでで各フェーズの課題と取り組むべき活動を説明してきましたが、 AWS ではお客様に共通した課題に対して支援するプログラムを各種用意しています。この後の記事ではお客様課題と AWS が提供しているプログラムを結び付けた形で詳しくお話させていただきます。お楽しみに！ 著者プロフィール アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 服部 昌克 アマゾン ウェブ サービス ジャパン 合同会社 カスタマーソリューションマネージメント統括本部 カスタマーソリューションマネージャー 桑原 直哉 参考リンク クラウドジャーニーの歩み方 (前編) 移行戦略（７R）の概要 MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (前編) MRA (移行準備状況評価) から見えるクラウド移行におけるよくある課題とその対策 (後編) AWS 移行コンピテンシーとモナダイゼーションコンピテンシーのパートナー

10 月 1 日から NICE DCV の名前が新しくなります。さようなら NICE DCV、ようこそ Amazon DCV。2024.0 リリース、および機能強化とバグ修正に伴い、NICE DCV は 10 月 1 日 Amazon DCV としてリブランドされました。 この新しい名前は、 Amazon AppStream 2.0 や Amazon WorkSpaces などの AWS マネージドサービスで活用される DCV プロトコルの一貫的な参照にも使用されることになります。 Amazon DCV とは Amazon DCV は高性能リモートディスプレイプロトコルであり、リモートデスクトップやアプリケーションストリーミングを、さまざまなネットワーク条件下で任意のクラウドまたはデータセンターから任意のデバイスにセキュアな方法で配信することができます。 Amazon Elastic Compute Cloud (Amazon EC2) で Amazon DCV を使用することにより、グラフィック集約型のアプリケーションを EC2 インスタンスでリモート実行できます。その後、結果をよりシンプルなクライアントマシンにストリーミングできるため、高価な専用ワークステーションが不要になります。 サーバー側では、Amazon DCV が Linux オペレーティングシステムの主要フレーバーと Windows オペレーティングシステムの両方をサポートすることで、組織のニーズに合わせて選択する柔軟性を提供します。デスクトップとアプリケーションストリーミングを受信するクライアント側は、Windows、Linux、macOS、またはウェブブラウザ用のネイティブ DCV クライアントにすることができます。DCV リモートサーバーと DCV クライアントは、データではなく暗号化されたピクセルのみを転送するため、DCV サーバーから機密データがダウンロードされることはありません。EC2 インスタンスを用いた Amazon Web Services (AWS) での Amazon DCV の使用を選択すると、 33 の地理的リージョンにまたがる 108 の AWS アベイラビリティーゾーンと 31 のローカルゾーン を活用できるので、リモートストリーミングサービスを世界的にスケールすることが可能になります。 8 年前に Amazon が NICE を買収 して以来、私たちはさまざまなお客様が DCV を導入するのを目の当たりにしてきました。DCV の用途は、ビジネスアプリケーションを視覚化する汎用ユーザーから業界固有の専門家まで、多岐にわたることが実証されています。例えば、アーティストは DCV を使用して、デジタルコンテンツの作成やレンダリングタスクのために強力なクラウドワークステーションにアクセスしています。ヘルスケア部門では、医療画像専門家が患者データのリモートでの視覚化と分析のために DCV を使用しています。地球科学者は DCV を使用して油層シミュレーションの結果を分析し、製造業界のエンジニアは DCV を使用して数値流体力学実験を視覚化しています。教育業界や IT サポート業界は、複数のユーザーが単一のデスクトップを共有できる DCV でのコラボレーションセッションからメリットを得ています。 注目に値するお客様には、 Quantic Dream が含まれます。受賞ゲーム開発スタジオである Quantic Dream は、そのアーティストや開発者のための低レイテンシーで高解像度のストリーミングサービスの構築に DCV を役立てています。エンタープライズリソースプランニング (ERP) サービスプロバイダーである Tally Solutions は、何千ものお客様に ERP ソフトウェアをセキュアな方法でストリーミングするために DCV を導入しました。 Volkswagen は、DCV を使用して 1,000 人を超える自動車エンジニアが CAE (Computer Aided Engineering) にリモートでアクセスできるようにしています。サービスが十分に行き届いていないコミュニティにブロードバンド接続を提供するイニシアチブである Amazon Kuiper は、複雑なチップを設計するために DCV を使用しました。 AWS 内では、お客様にマネージドソリューションを提供するために、複数のサービスが DCV を取り入れています。例えば、 AppStream 2.0 では、セキュアかつスケーラブルで信頼性に優れたアプリケーションストリーミングを提供するために DCV が使用されています。また、2020 年からは、DCV 上に構築され、高パフォーマンスのために最適化された Amazon WorkSpaces Streaming Protocol (WSP) が、Amazon WorkSpaces のお客様に提供されています。今日は、WSP という名前も廃止され、DCV に置き換えられます。今後は、Amazon WorkSpaces におけるプロトコルの主要選択肢として DCV が提供されます。 バージョン 2024.0 の新機能 Amazon DCV 2024.0 には、パフォーマンス、セキュリティ、使いやすさを向上させるためのいくつかの修正と機能強化が導入されています。2024.0 リリースでは最新の Ubuntu 24.04 LTS がサポートされるようになり、最新のセキュリティ更新と、システムメンテナンスを簡素化するための長期的な延長サポートを提供します。Ubuntu 24.04 上の DCV クライアントは Wayland をサポートするように構築されているため、グラフィカルレンダリングの効率性が向上し、アプリケーション分離が強化されます。さらに、DCV 2024.0 では QUIC UDP プロトコルがデフォルトで有効化されるようになったため、クライアントは最適化されたストリーミング体験からメリットを得ることができます。このリリースには、リモートユーザーが接続しているときに Linux のホスト画面をブランクにして、ローカルアクセスやリモートセッションとのやり取りを防ぐ機能も導入されています。 使用開始方法 DCV を試してみる最も簡単な方法は、 WorkSpaces コンソール から WorkSpaces インスタンスをスピンアップして、DCV を活用するバンドルのいずれかを選択、または AppStream セッションを作成することです。今回のデモでは、EC2 インスタンスに DCV サーバーをインストールする方法を紹介したいと思います。 Amazon EC2 上で実行されている 2 つのサーバーに DCV サーバーをインストールしました。これらのサーバーの一方は Windows Server 2022 、もう一方は Ubuntu 24.04 を実行しています。また、macOS ノートパソコンにもクライアントをインストールしました。 クライアントパッケージとサーバーパッケージは、Amazon のウェブサイトでダウンロードできます 。どちらのサーバーでも、 セキュリティグループ が UDP または TCP ポート 8443 ( DCV が使用するデフォルトポート ) でのインバウンド接続を許可していることを確認してください。 Windows でのインストールは簡単で、 msi ファイルを起動し、各ステップで Next を選択するだけです。インストールは、この文を書き終えるよりも短い時間で完了しました。 Linux でのインストールにはもう少し注意が必要です。EC2 サーバーの  Amazon マシンイメージ (AMI) には、デスクトップコンポーネントやグラフィックコンポーネントが含まれていません。前提条件として、 X Window System と ウィンドウマネージャ をインストールするとともに、ユーザーがサーバーに接続してグラフィカルユーザーインターフェイスセッションを開始できるように X を設定する必要がありました。幸い、 これらのステップはすべて詳しく説明されています 。以下は、私が使用したコマンドの要約です。 # install desktop packages $ sudo apt install ubuntu-desktop # install a desktop manager $ sudo apt install gdm3 # reboot $ sudo reboot 再起動後、DCV サーバーパッケージをインストールしました。 # Install the server $ sudo apt install ./nice-dcv-server_2024.0.17794-1_amd64.ubuntu2404.deb $ sudo apt install ./nice-xdcv_2024.0.625-1_amd64.ubuntu2404.deb # (optional) install the DCV web viewer to allow clients to connect from a web browser $ sudo apt install ./nice-dcv-web-viewer_2024.0.17794-1_amd64.ubuntu2404.deb サーバーには GPU がなかったため、 これらのステップに従って X11 Dummy ドライバーをイントールし、このドライバーを使用するように X11 を設定しました 。 次に、サービスを起動しました。 $ sudo systemctl enable dcvserver.service $ sudo systemctl start dcvserver.service $ sudo systemctl status dcvserver.service オペレーティングシステムレベルでユーザーを作成 して、パスワードとホームディレクトリを割り当てました。その後、サーバーからの接続を試みる前に、サーバー上のセットアップを確認しました。 $ sudo dcv list-sessions There are no sessions available. $ sudo dcv create-session console --type virtual --owner seb $ sudo dcv list-sessions Session: 'console' (owner:seb type:virtual) サーバー設定の準備が完了した時点で、ノートパソコンの DCV クライアントを起動しました。セッションは、サーバーの IP アドレス、およびユーザーのユーザー名とパスワードを入力するだけで開始できました。 ノートパソコンで新しい DCV クライアントウィンドウを開き、もう一方の EC2 サーバーに接続しました。数秒後、クラウドで実行されている Windows と Ubuntu マシンをリモートで操作できるようになりました。 この例では単一の EC2 インスタンスでの Amazon DCV のインストールに着目しましたが、独自のサービスインフラストラクチャを構築するときは、 Amazon DCV Session Manager 、 Amazon DCV Access Console 、および Amazon DCV Connection Gateway など、DCV サービスの一部である他のコンポーネントを検討することをお勧めします。 料金と利用可能なリージョン Amazon DCV を AWS で使用するときに料金は発生しません。EC2 インスタンス、Amazon Workspace デスクトップ、Amazon AppStream 2.0 といった AWS のリソースやサービスの使用に対する料金のみをお支払いいただきます。オンプレミスサーバーで DCV を使用する予定の場合は、 こちらのウェブサイトにあるライセンス再販業者のリスト をご覧ください。 今すぐ DCV で独自のサーバーの構築を始めましょう 。 — seb 原文は こちら です。

10 月 10 日、AWS コンソールアクションを再利用可能なコードに簡単に変換できる AWS Console-to-Code の一般提供開始 (GA) についてお知らせします。AWS Console-to-Code を使用すると、コンソールでの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの起動などのアクションとワークフローを記録することや、コンソールアクションの AWS コマンドラインインターフェイス (AWS CLI) コマンドをレビューすることができます。必要なのは数回のクリック操作だけです。 Amazon Q が AWS CloudFormation テンプレート (YAML または JSON) や AWS Cloud Development Kit (AWS CDK) (TypeScript、Python、または Java) を始めとする任意の Infrastructure-as-Code (IaC) 形式を使用してコードが生成します。これをインフラストラクチャ自動化の開始ポイントとして使用し、パイプラインなどに含まれる本番ワークロード向けにさらにカスタマイズすることができます。 昨年のプレビューの発表 以来、AWS Console-to-Code はお客様から好評を博しています。お客様からのフィードバックを基に逆算して作業を続けた結果、この GA バージョンでは機能がさらに改善されました。 GA の新機能 より多くのサービスのサポート – プレビュー中、サポートされていたサービスは Amazon EC2 だけでした。GA では、AWS Console-to-Code のサポートが拡張され、 Amazon Relational Database Service (RDS) と Amazon Virtual Private Cloud (Amazon VPC) が含まれるようになりました。 簡素化されたエクスペリエンス – 新しいユーザーエクスペリエンスでプロトタイピング、記録、コード生成のワークフローを簡単に管理できます。 コードのプレビュー – EC2 インスタンスと Auto Scaling グループの起動ウィザードが更新され、お客様は実際に作成しなくてもこれらのリソースのコードを生成できるようになりました。 高度なコード生成 – AWS CDK と CloudFormation のコード生成が Amazon Q の機械学習モデルによって強化されています。 AWS Console-to-Code の開始方法 Amazon EC2 インスタンスを起動するシンプルなシナリオから始めましょう。 Amazon EC2 コンソール にアクセスします。右側にある AWS Console-to-Code ウィジェットを見つけ、 [記録を開始] を選択して記録を開始します。 次に、Amazon EC2 コンソールのインスタンス起動ウィザードを使用して Amazon EC2 インスタンスを起動 します。インスタンスが起動したら、 [停止] を選択して記録を完了します。 [記録されたアクション] テーブルで、記録されたアクションをレビューします。 [タイプ] ドロップダウンリストを使用して、書き込みアクション ( [書き込み] ) でフィルターします。 RunInstances アクションを選択します。 [CLI をコピー] を選択して、対応する AWS CLI コマンドをコピーします。 AWS Console-to-Code から取得した CLI コマンドを以下に示します。 aws ec2 run-instances \ --image-id "ami-066784287e358dad1" \ --instance-type "t2.micro" \ --network-interfaces '{"AssociatePublicIpAddress":true,"DeviceIndex":0,"Groups":["sg-1z1c11zzz1c11zzz1"]}' \ --credit-specification '{"CpuCredits":"standard"}' \ --tag-specifications '{"ResourceType":"instance","Tags":[{"Key":"Name","Value":"c2c-demo"}]}' \ --metadata-options '{"HttpEndpoint":"enabled","HttpPutResponseHopLimit":2,"HttpTokens":"required"}' \ --private-dns-name-options '{"HostnameType":"ip-name","EnableResourceNameDnsARecord":true,"EnableResourceNameDnsAAAARecord":false}' \ --count "1" このコマンドは簡単に変更できます。この例では、タイプ t3.micro ( --instance-type ) の 2 つのインスタンス ( --count 2 ) を起動するよう更新しました。これは簡素化された例ですが、同じ手法を他のワークフローに適用できます。 AWS CloudShell を使用してコマンドを実行すると、予期したとおりに動作し、2 つの t3.micro EC2 インスタンスが起動しました。 シングルクリックの CLI コード生成エクスペリエンスは、アクションが実行されたとき (EC2 インスタンスの起動中) に使用された API コマンドに基づきます。コンソールでアクションを完了すると、コンパニオン画面に記録されたアクションが表示されます。また、開始および停止の機能を備えたインタラクティブな UI では、プロトタイピングのアクションのスコープを明確にすることが容易になります。 AWS CDK を使用した IaC 生成 AWS CDK は、クラウドインフラストラクチャをコードで定義し、AWS CloudFormation を通してプロビジョニングするためのオープンソースフレームワークです。AWS Console-to-Code を使用すると、インフラストラクチャワークフロー用の AWS CDK コード (現在は Java、Python、TypeScript) を生成できます。 EC2 起動インスタンスのユースケースを続けましょう。まだ行っていない場合は、 Amazon EC2 コンソール の右側にある AWS Console-to-Code ウィジェットを見つけ、 [記録を開始] を選択して EC2 インスタンスを起動 します。インスタンスが起動したら、 [停止] を選択して記録を完了し、 [記録されたアクション] テーブルから RunInstances アクションを選択します。 AWS CDK Python コードを生成するには、ドロップダウンリストから [CDK Python を生成] ボタンを選択します。 このコードを開始ポイントとして使用して特定のユースケース用にカスタマイズし、本番環境で使用することができます。 ここでは、既に AWS CDK がインストールされていたので、新しい Python CDK プロジェクトを作成しました。 mkdir c2c_cdk_demo cd c2c_cdk_demo cdk init app --language python 次に、生成されたコードを Python CDK プロジェクトにプラグインしました。この例では、コードが正しいことを確認するために、コードを AWS CDK Stack にリファクタリングし、EC2 インスタンスタイプを変更して、その他の小さな変更を行いました。 cdk deploy を使用して正常にデプロイすることができました。 EC2 インスタンスを起動するコンソールアクションから AWS CDK まで、同じ結果を再現することができました。 from aws_cdk import ( Stack, aws_ec2 as ec2, ) from constructs import Construct class MyProjectStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: super().__init__(scope, construct_id, **kwargs) existing_vpc = ec2.Vpc.from_lookup(self, "ExistingVPC", is_default=True ) instance = ec2.Instance(self, "Instance", instance_type=ec2.InstanceType("t3.micro"), machine_image=ec2.AmazonLinuxImage(), vpc=existing_vpc, vpc_subnets=ec2.SubnetSelection( subnet_type=ec2.SubnetType.PUBLIC ) ) CloudFormation テンプレートを YAML 形式または JSON 形式で生成することもできます。 プレビューコード AWS Console-to-Code には、Amazon EC2 の [プレビューコード] と Amazon EC2 Auto Scaling グループの起動エクスペリエンスから直接アクセスすることもできます。これは、インフラストラクチャコードを取得するために実際にリソースを作成する必要がないことを意味します。 これを試すには、 起動テンプレートを使用して Auto Scaling グループを作成 する手順に従います。ただし、 Auto Scaling グループを作成 する代わりに、 [プレビューコード] をクリックします。インフラストラクチャコードを生成するオプションまたは AWS CLI コマンドをコピーするオプションが表示されます。 知っておくべきこと AWS Console-to-Code を使用する際に考慮すべき点がいくつかあります。 AWS Console-to-Code を使用すれば、誰でもインフラストラクチャワークフロー用の AWS CLI コマンドを生成できます。AWS CDK および CloudFormation 形式のコード生成機能には、1 か月あたり 25 生成の無料クォータがあります。それ以上を使用するには、 Amazon Q Developer サブスクリプション が必要になります。 デプロイする前に、生成された IaC コードコードをテストして検証することをお勧めします。 GA では、AWS Console-to-Code は Amazon EC2、Amazon VPC、Amazon RDS コンソールのアクションのみを記録します。 AWS Console-to-Code の [記録されたアクション] テーブルには、特定のブラウザタブ内の現在のセッション中に実行されたアクションのみが表示されます。以前のセッションや他のタブのアクションは保持されません。ブラウザタブを更新すると、記録されたすべてのアクションが失われることに注意してください。 今すぐご利用いただけます AWS Console-to-Code はすべての商用リージョンでご利用いただけます。詳細については、 Amazon EC2 のドキュメンテーション を参照してください。 Amazon EC2 コンソール でお試しいただいた後、 AWS re:Post for Amazon EC2 または通常の AWS サポート窓口までフィードバックをお寄せください。 原文は こちら です。

本ブログは 株式会社メタバーズ様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの文珠です。 VR や AR といった技術がエンジニア以外の人々にも広く浸透してきた昨今ですが、みなさんは既にメタバース空間を体験されましたか？この分野では日々技術の進化を積極的に取り入れており、様々な企業がその技術を製品の宣伝やアクティビティに活用し、新たな価値を提供しております。 この分野で最近注目されているのは ”生成 AI の技術を VR / AR とどのように組み合わせるか” という観点で、チャットボットやコンテンツ生成など多方面で検討が行われています。その一方で日進月歩で進化している生成 AI の技術に対して、最新の機能に追従していくことは大変だというお客様も多いです。 本記事では株式会社メタバーズ様が VR / AR のサービスに生成 AI の技術を活用された事例を紹介します。メタバーズ様は「メタバース空間構築支援サービス」を提供しております。今回 AWS の生成 AI サービスである Amazon Bedrock をメタバース空間上の AI ボットサービスに組み込むことで、「 対応可能な生成 AI のモデル数の増加 」と「 最新モデルへの追随 」を開発工数をかけずに行えるようになりました。 メタバーズ様の状況と経緯 株式会社メタバーズ 様は、メタバース空間構築支援サービス「 メタバース® CYZY SPACE 」を提供しており、本サービスではスマートフォンや PC のウェブブラウザで利用可能なメタバース空間の構築が可能です。 本サービスで作成されたメタバース空間では、数十人から 1,000 人まで同じ空間に集まることができます。こちらの空間は、学校空間、公共施設、常設ショールーム、バーチャル展示場といった様々な用途に展開ができ、幅広い業種のお客様にご利用いただいております。 (メタバース® CYZY SPACE) 本サービスを運用するためには、各メタバース空間の中でエンドユーザーの対応をする人手が必要でしたが、メタバース空間ごとに 24 時間 365 日で実際の人間を割り当てることは費用的に難しいことでした。この課題は本サービスだけのものではなく、メタバース空間を提供するサービスの共通課題とされています。そこで、メタバーズ様は本課題を解決するために、生成 AI サービスとの連携を検証し、新規サービスを開発されました。それが AI チャットボット・アバターボット作成サービス「 メタバース® Botbird for Business 」です。 こちらのサービスを「 メタバース® CYZY SPACE 」のメタバース空間と連携させることで、AI ボットによるメタバース空間の顧客対応を実現し、人材不足解決を支援しています。 (メタバース® Botbird for Business) 本サービスを利用するお客様が増えていく中で、様々なユースケースにあわせて生成 AI モデルのバリエーションを増やすことが、お客様の満足度向上に繋がることがわかりました。しかし、 様々な種類の生成 AI モデルに対応する には、開発チームの多くの工数が必要でした。そこで、生成 AI 技術の実装箇所に Amazon Bedrock を導入することで、対応可能な生成 AI のモデル数を増加させつつ、その更新の作業もスムーズに対応できるようにしました。 ソリューション／構成内容 3D 空間サービス「 メタバース® CYZY SPACE 」の各ルームには、必要に応じて AI コンシェルジュを投入することができます。各 AI コンシェルジュはバックエンドでチャットサービスの「 メタバース® Botbird for Business 」と通信し、生成 AI によるテキストの返信を行います。 Amazon Bedrock は主に、「テキストチャット用の言語モデル」、「検索拡張生成 (RAG) 用のテキスト埋め込みモデル」の 2 つの機能で利用されています。( RAG 、埋め込みモデル、ベクトルデータベース等について、さらに学びたい方は こちらの記事 をご覧ください。 ) Amazon Bedrock を利用する際には Converse API を用いて、複数の言語モデルをシームレスに切り替えられる実装をしています。また、チャットサービス内部に組み込まれた RAG 機能では、利用者・用途ごとにベクトルデータベースを作成する必要があり、その並列化のために AWS Lambda を活用しています。実は、テキスト埋め込みモデルを利用したベクトル検索が簡単に使えるようになる以前は、類似検索のための機械学習モデルを独自に作成していました。しかし、これには高いマシンスペックのコンピュートリソースが必要であったため、AWS Fargate のスポットインスタンスをいくつも呼び出す必要がありました。今回、Amazon Bedrock 経由でテキスト埋め込みモデル ( Titan Text Embedding や Cohere Embed など ) が利用できるようになったことにより、 AWS Fargate の代わりにAWS Lambda を用いた軽量な処理に置き換えることができました。 全体として心がけているのは、マネージドサービスおよびサーバーレスサービスをできるだけ活用し、運用コストを下げるということです。少人数チームで運用しているため、自動復旧性能と可用性の高さに助けられている部分は大きいと感じています。 (出展: 株式会社メタバーズ) 導入効果 Amazon Bedrock を導入することで、下記の3つの効果を得ることができました。 利用可能な モデルラインナップが倍以上に増え 、お客様は利用用途に合わせて柔軟にモデルを切り替えることが可能に 生成 AI モデルの切り替えを少ない工数で行えるようになり、新規モデル導入時の 開発工数を約 3 日から数時間に削減 類似検索のための機械学習モデルを独自に作成する必要がなくなり、その部分の 開発コストを 90% 削減 上記の結果、メタバース空間上の AI ボットで用いる生成 AI モデルを、幅広い選択肢の中からお客様のユースケースに合わせて選択することが可能になり、お客様の満足度の向上に繋がっています。今後も新しい生成 AI モデルが登場した際には、すぐにラインナップを増やせるというのも嬉しい点ですね。 まとめ 今回はメタバース空間上の AI ボットサービスで、 AWS の生成 AI サービスである Amazon Bedrock を活用する事例を紹介させていただきました。Amazon Bedrock を用いることで「 対応可能な生成 AI のモデル数の増加 」と「 最新モデルへの追随 」を開発工数をかけずに行えるようになりました。これが幅広い業種のお客様の満足度を向上させる結果に繋がっているとのことです。本番環境で利用している生成 AI の最新化や豊富な生成 AI モデルへの対応にご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社メタバーズ : 代表取締役 CEO 兼社長 島谷 直芳 様 （右上）、桂 卓生 様 （右下） Amazon Web Services Japan : アカウントマネージャー 尾形 龍太郎 (左上)、ソリューションアーキテクト 文珠 啓介 (左下) ソリューションアーキテクト 文珠 啓介

2024年6月20日、21日の二日間に開催された AWS Summit Japan では、 AWS Village と称する AWS のサービスやインダストリーソリューションを扱う 90 以上の AWS 展示と、50 以上のお客様事例展示が一堂に会した展示エリアが設けられました。 今年は鉄道関連の事例とソリューション展示が行われ、お客様事例として東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用事例と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューションの紹介を行いました。 本投稿では前編後編の2部構成としており、このブログでは後編として、 AWS ブースで展示した内容を紹介します。前編の JR 東海様、 CKK 様から展示いただいた模様については こちら をご参照ください。 AWS ブース AWS のブースでは「クラウドで進化する鉄道機械保守」のテーマで、鉄道機械設備のリモートメンテナンスのソリューション展示を行いました。本ソリューションは以下の2つのポイントをに分けてご紹介していきます。 ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理 ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成 本ソリューションが機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。 ポイント1： AWS IoT SiteWise を使用した鉄道設備の大規模データ管理 鉄道保全の現場では、転轍機や融雪装置などの従来の鉄道機械に加えて、ホームドアやエレベーターなど様々な機械設備があります。それらの設備は路線全体に点在しており、地理的にも広大な範囲に及びます。また、日本においては生産年齢人口が減少傾向にあり、保全業務の担い手確保が難しくなってくることが予想されます。これらを背景として、鉄道保全業務の効率化・高度化の必然性は高まってきております。効率化・高度化の一つの方向性として膨大な鉄道設備データを収集しリモートで集中管理することが有効です。 AWS IoT SiteWise を利用して路線全体に広域に配置されている鉄道設備群の大規模なデータを効率的に管理・モニタリングする方法についてご紹介いたします。 AWSの構成 今回の展示では全線で9駅を対象とした設備監視システムを構築しました。58の駅構造物に分解されて、それぞれに延べ223の機会設備が配置されていることを想定しております。 AWS IoT SiteWise で各機械設備のデータを取得し、取得したデータを Grafana で可視化しております。223もの機械設備の様々なセンサーデータをどのように管理すると効率的で高度な監視を実現出来るでしょうか。データモデルに着目して述べていきたいと思います。 駅設備データ構造のモデル化 駅の構造に着目すると、駅構内にホームやコンコースがあり、ホームやコンコースには空調機やエレベータなどの設備が配置されており、各設備に温度や回転数を計測するセンサーが付随しています。設備のモニタリングを行うためには、これらのセンサーデータを収集する必要があります。この時考慮すべき事項として、同種の設備が無数にあるため、各駅を起点とした階層構造と対応付けて設備データを管理する必要があります。このように各駅を起点とした階層構造をデータモデルとして管理する仕組みが必要なのです。 AWS IoT SiteWise の アセットモデル作成機能 を利用して大量の設備を効率的に管理することができます。 アセットモデルの作成 AWS IoT Sitewise を利用して次のような流れでアセットモデルを作成しました。詳細な手順は「 産業アセットのモデル化 」を参照ください。 アセットモデルを作成 駅、駅構造物、各機械設備の3階層で計10個のアセットモデルを作成しました。 データプロパティを定義 それぞれのモデル毎のデータプロパティを定義します。今回、空調機の例のように静的なデータ（属性）や設備から取得するデータ（測定）に加えて、変換・メトリクスのプロパティタイプを利用して、監視のために必要な測定値の評価や計算を行ってます。これらのプロパティを利用することでより高度な設備監視が可能となります。 アセットの作成 アセットモデルから各機械設備等のアセットを作成します。この時にアセット間の親子関係を関連付けることができます。親アセットは間r年するアセットのデータにアクセスし集計することができます。今回、各駅をルートとして駅構造物、各機械設備を子アセットとして関連付けております。例えば、美濃大垣駅-改札外コンコース-空調機01,02といったアセットが親子関係になっております。 このように実際の駅の構成を抽象化し、アセットモデルとして定義することで、効率的に設備データを管理することができます。また、監視の要件に合わせて、取得したデータを評価・計算することにより難しい作り込みを必要とせずに簡単に高度な監視も実現することができます。 ポイント2： Amazon Bedrock を使って過去の対応記録から推奨エラー対応方法を生成 AWS IoT SiteWise を使うことの利点の一つとしてリアルタイムアラート機能があります。機器から送られてくるデータに対してあらかじめモデルで定義された閾値を越えた場合に、アラートが発砲するという機能で、この AWS IoT SiteWise アラーム機能は AWS IoT Events と連動することによって提供されています。この機能の活用によりほぼリアルタイムで機器の異常を検知し異常状態に気づくことができます。しかし実際に現場で異常が発生した際は、実は検知したあとの作業の方が労力がかかるケースがほとんどです。そこで今回の展示では、異常を検知したあとの作業に対し少しでもお手伝いできることはないかというところからアイディアを想起させて実装してみました。 実装内容（やったこと） 機器に異常が発生した場合、行う作業の一つとして過去の対応履歴や対策/対応マニュアルなどを探して確認することがあると思います。そういった業務に対し少しでも省力化につながる仕組みとして、過去の蓄積文書を元にした推奨対応策の作成を生成 AI の活用により自動生成し、異常検知の通知メールの中に AI 推奨対応策として入れ込んでメール送信を行うという仕組みを実装してみました。生成 AI のユースケースの一つである RAG ( Retrieval-Augmented Generation ) と呼ばれる検索拡張生成の仕組みをチャットから使うのではなく、エラー情報をインプットとして活用するという試みをしました。 AWSの構成と動作の詳細 構成は図のようになっており、異常が発生した場合の処理の流れは次のようになります。 センサーデータがリアルタイムで AWS IoT SiteWise に格納されます。 格納されたデータに対し設定された閾値で評価され違反しているかを判定します。今回の展示では場合は、エラーコードを検出する文字列判定、設定温度と外気温 (15分平均の温度) の温度差が5度以上かどうかの数値判定、といったものを例として仕込みました。 上記の閾値に違反し異常を検出すると AWS IoT Events によって AWS Lambda に転送されます。 AWS Lambda によってエラーコードから大枠の事象を特定しプロンプト文を作成します。 そして Amazon SQS を経由し RAG が実装された AWS Lambda に転送します。 Amazon SQS から渡されたエラー情報を元に AWS Lambda で RAG を実行します。RAG とは関連情報の検索を行い抜粋された文章を元に生成 AI が文章を作成する仕組みです。ここでは例えば、エラーコードから空調機の冷媒液の漏洩が発生という情報が Amazon SQS から渡され、「空調機の冷媒液漏洩発生時の対処方法」という文言で関連文章内を検索します。そして検索に引っかかった文章を元に LLM (Large Language Model) に「空調機の冷媒液漏洩発生時の対処方法を教えてください」と問いかけることで AI 推奨の対処方法を生成します。ちなみに今回の展示の RAG で使った LLM は Amazon Bedrock の Claude 3 Haiku で、ドキュメント検索のインデックス DB には Amazon Kendra を使いデータソースは Amazon S3 になります。 Amazon S3 に格納されているドキュメントは国土交通省、 JR 総研、日本学術振興会などが公開している PDF 文章です。 Claude 3 Haiku を選んだ背景としては、リアルタイムの異常時対応という想定のため、日本語の精度が高い Claude 3 の中でも一番レスポンスが早いということで選択しました。 最後にメールを作成します。 Amazon Bedrock の Claude 3 Haiku で出力された文章に加えて、 Amazon Kendra から出力された Amazon S3 に格納されたドキュメントを参照できるように一定時間だけ有効な署名付きURLを発行し、参考ドキュメントとしてメールに記載しています。このメールを Amazon SNS で配信します。 展示でのデモ 当日の展示では、意図的に故障データを流せる RaspberryPI (「彦原-新幹線コンコース-空調機 01 」を模擬) を用意し、そこでスクリプトを実行すると異常データが飛ぶという仕掛けを用意しました。実際に実行すると、 Grafana ダッシュボードはほぼリアルタイムで反映され異常となります。 ダッシュボード上が異常となると同時に裏側では AWS IoT Events が動き RAG が実行されております。数十秒で RAG とメール送信の処理が完了し、アラート通知と過去の対応記録から類推された AI 推奨のエラー対応方法が記載されたメールを受信します。下図は実際にその時に受信したメール画面になります。 もし発生した異常への対応方法が記載された適切なドキュメントが見当たらなければ、情報がないことを明示したメールが届きます。下図は実際に受信したメール画面になります。 このように生成 AI の課題の一つであるハルシネーション (生成 AI がユーザーの質問に対して、事実とは異なる情報を利用して回答を生成すること) を抑えることが RAG によって可能になります。 今回私たちの方には適切なドキュメント等を持っていなかったため、公開されている情報から引っ張ってきましたが、適切な自社のマニュアルや対応履歴のドキュメントがあるとより正確で役立つ情報が配信できるソリューションになると考えられます。 以上、 AWS Village の鉄道関連展示における AWS ブースで展示した内容について紹介させていただきました。 本投稿では2024年6月20日、21日の二日間に開催された AWS Summit Japan にて展示された、 東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用(前編) と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューション(後編)の2つの展示内容について2部構成で紹介させていただきました。本投稿が機械設備保守業務の効率化や高度化に取り組まれている皆様のご参考になれば幸いです。 著者 技術統括本部 ソリューションアーキテクト 岩永 昌寛 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネージャー 西部 信博 技術統括本部 ソリューションアーキテクト 宮﨑 知洋

2024年6月20日、21日の二日間に開催された AWS Summit Japan では、 AWS Village と称する AWS のサービスやインダストリーソリューションを扱う 90 以上のAWS 展示と、50 以上のお客様事例展示が一堂に会した展示エリアが設けられました。 今年は鉄道関連の事例とソリューション展示が行われ、お客様事例として東海旅客鉄道株式会社（以下、 JR 東海）様と東海交通機械株式会社（以下 CKK ）様から鉄道機械設備の保全における活用事例と、 AWS から AWS IoT SiteWise および Amazon Bedrock を使った鉄道機械設備のモニタリングソリューションの紹介を行いました。 本投稿では前編後編の2部構成としており、このブログでは前編として、 JR 東海様、 CKK 様から展示いただいた模様を報告します。後編の AWS ブースで展示した内容については こちら をご参照ください。 東海旅客鉄道株式会社様/東海交通機械株式会社様 「鉄道機械」と聞いて皆様はどのような事を想像するでしょうか？ JR 東海様、CKK 様では、皆様が通勤で目にする駅の改札機やホームドアなどはもちろん、雪が舞い上がらないようにするためのスプリンクラーや、車両基地で車両を洗浄する装置など、普段目にすることが少ない機械も含めると、約21,000台の機械設備をメンテナンスされています。 また、それら鉄道機械が約2,000kmにおよぶ鉄道路線に配置されています。 労働力人口が減少していく中、広範囲に配置された多種・多量な機械を効率的にメンテナンスしていくため、 JR 東海様、 CKK 様ではデータを活用した状態監視保全と予防保全に取り組まれており、 AWS Village では「データ収集」と「データ分析」の観点で4つの活用事例が紹介されていました。また、各事例とも情報システム部などのシステム部門ではなく、日々機械メンテナンスに携わっている機械エンジニアの方がこれらのソリューションを実現されたことに、当日 AWS Village を訪れた多くの方が驚かれていたのも印象的でした。 1. 故障調査ロガー 古い設備でも IoT デバイスを活用した遠隔監視を可能にするために CKK 様が開発されたのが「故障調査ロガー」のソリューションです。 故障調査ロガーの開発コンセプトは「1. 既存設備の改良工事が不要」「2. 可搬式で様々なシチュエーションで利用可能」「3. 必要に応じてセンサーの増設が可能」「4. 遠隔地のデータを事務所で確認可能」の4点があり、これらの利点により企業は古い設備の IoT 化を実現できるようになり、対象設備の状態をリアルタイムで監視し、潜在的な問題を早期に発見することができます。これは保守作業の効率化とダウンタイムの削減につながり、結果として運用コストの削減と生産性の向上が期待できます。 故障調査ロガーは CKK 様で普段実際に鉄道機械設備メンテナンスを実施している機械エンジニアの方が、業務の合間を使って AWS IoT Core 、 AWS IoT Greengrass 、 Amazon QuickSight などのサービスを組み合わせて約3ヶ月弱で構築されました。 各種センサー（電流、温度、湿度など）から収集されたデータは、クラウド上で処理され、 Amazon QuickSight を通じて分かりやすく可視化され、機械保守員の判断を支援することができるようになっています。 2. 改札故障予測 AI データに基づく故障時期の予測によって点検回数を削減するため取り組まれたのが CKK 様の故障予測 AI システムです。 CKK 様では、稼働保守データや作業実績データなどの大量の情報を効果的に管理・活用できる環境を整え、このデータを基に機械学習プラットフォーム Amazon SageMaker を用いて、自社開発の状態監視( CBM )モデルを構築されました。この CBM モデルは教師あり学習にて開発されており、 AUC = 0.79 という高精度の予測モデルとなっています。 これらの取り組みの結果、保守コストの15.6%削減、故障対応回数を40%削減という結果が得られています。 さらに、故障の予兆を事前に検知することで、深刻な故障を未然に防ぐことも期待されています。 3. データ分析運用 ( MLOps ) 2.改札故障予測 AI で紹介したような AI モデルを他の鉄道機械に広く適用していく際、多種・多量な機器に対するモデルの開発・運用をどのように効率的に実施していけるかが課題となりました。 JR 東海様はこの課題に対し、 Amazon SageMaker 、 AWS CodeCommit 、 AWS CodePipeline 、 Amazon EventBridge などの AWS のサービスを活用した高度な MLOps 環境を構築されることで解決を図られています。この MLOps 環境によりモデルの学習から推論、管理までの一連のプロセスを自動化しました。 この MLOps の具体的適用例として、東海道新幹線の東京駅ホームドアの異常検知モデルが紹介されていました。 ホームドアを動かすモーターのトルク値を用いた教師なし機械学習モデルにおいて、時間経過や環境変化によるデータドリフトの課題に対応するため、出力データを監視し、自動で再学習を行うアルゴリズムをパイプライン上に実装しています。再学習アルゴリズムにより、正常時の異常度（移動平均）を一定に保つことが可能となりました。具体的には、再学習なしの場合と比較して、3.5年間の正常期間における誤検知回数が約1/7に減少しました。これにより、モデルの検知精度を継続的に維持し、安定した異常検知を実現されています。 4. MELS (機械保全管理システム) Cloud 保全計画管理、保全実績入力など機械設備保守の実業務を支えているのが、 MELS と名付けられた CKK 様の機械保全管理システムです。 このシステムは元々オンプレミスで稼働していましたが、システムの運用保守・セキュリティ対策の負荷が課題となっていました。これらの課題を解決するためと、既に実現していた改札故障 AI との連携を用意するため、 MELS の AWS クラウド移行を行われました。 AWS への移行後もシステムを自らで維持、発展させていくことをできるようにするため、システム移行チームは普段 MELS を使用して業務を行っている機械設備エンジニアの方で構成されました。 AWS への移行決定時はクラウド知識が全くない状態でしたが、 AWS トレーニングと AWS プロフェッショナルサービスの活用により、約1年で AWS クラウドへの移行を実現され、現在も機械設備エンジニアの方によってシステムの保守が行われているほか、機械学習モデルの取り組み、適用業務範囲の拡大も実施されているとのことです。 以上、 AWS Village の鉄道関連展示における JR 東海様と CKK 様の取り組みを紹介しました。 後編のブログでは AWS より展示した、 AWS IoT SiteWise と Amazon Bedrock を利用した鉄道機械設備モニタリングソリューション展示 について紹介します。合わせてご覧ください。 著者 技術統括本部 ソリューションアーキテクト 岩永 昌寛 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネージャー 西部 信博 技術統括本部 ソリューションアーキテクト 宮﨑 知洋

Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレスの時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析できます。 様々な業界のお客様 が Amazon Timestream を採用して、重要なビジネスアプリケーションを監視し、モノのインターネット (IoT) を含むアプリケーション、ウェブサイト、デバイスにわたる数百万のリアルタイムイベントを分析し、リアルタイムの洞察を導き出しています。 Timestream は、基盤となるインフラストラクチャの管理が不要で、ワークロードの要求に合わせて自動的に拡張するため、お客様はアプリケーション開発に集中する事が出来ます。 Amazon Timestream for LiveAnalytics は、お客様からのフィードバックに応える形で、時系列データをクエリ時にコスト効率が高く、金額が予測可能となるように設計された新しい価格モデルを導入しました。以前のクエリの価格モデルは、スキャンされるデータ量に基づいて課金され、クエリ毎に最低 10 MB でしたが、クエリが数 KB 程度の比較的小さい時系列データをスキャンすることが多いユースケースでは、高額となる場合がありました。さらに、クエリへの課金に上限を設定することも困難でした。これらの懸念に対処するために、クエリによってスキャンされたデータ量ではなく、使用されたコンピューティングリソースに基づいて料金を請求する 新しい料金モデル を導入しました。 Timestream Computing Unit (TCUs) に基づくこの新しい価格モデルにより、実際に使用されるリソースに応じてコストが調整され、クエリに使用するコンピューティングリソースの最大数を設定できるため、予算の順守が容易になります。 本投稿では、TCU の概要、TCU を使用したコスト管理、および最適なコストパフォーマンスを実現するためのワークロードに必要な TCU を見積もる方法について説明します。 Timestream Compute Units (TCU) TCU は、Timestream for LiveAnalytics のクエリに割り当てられるコンピューティングの容量です。各 TCU は 4 つの vCPU と 16 GB のメモリで構成されます。時系列データをクエリすると、Timestream サービスは主にクエリ (リアルタイムクエリと分析クエリ) の複雑さと、処理されるデータ量に基づき、必要な TCU の数を決定します。各コンピューティングユニットは同時に複数のクエリを実行するため、使用中の TCU で全クエリを処理できるかどうか、または追加のコンピューティングユニットが必要かどうかを評価し、必要に応じて、コンピューティングユニットを拡張します。TCU の数とその使用期間によって関連コストが決まり、クエリワークロードの管理が透過的かつコスト効率よく行われます。 コスト管理 TCU の利点の 1 つは、クエリコストを制御し、より効率的に管理できることです。 MaxQueryTCU は、AWS リージョン毎、アカウント毎に 設定 できますが、この設定をすることで、Timestream はクエリワークロードに対してMaxQueryTCU までスケールされるように制限することができます。 TCU の最大制限を設定することで、ワークロードのコスト上限を設定できるため、予算内に収める事が容易になります。 コンピューティングユニットの最大数は 4 の倍数に設定できます。料金は、使用したコンピューティングリソースに対してのみ発生します。つまり、最大 TCU を 128 に設定しても、一貫して 8 TCU のみを使用する場合は、 8 つの TCU を使用した課金のみが発生します。従量課金制の料金設定と使用制限の構成により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。Timestream を初めて利用する場合、各 AWS アカウントのデフォルトの MaxQueryTCU 制限は 200 になります。 MaxQueryTCU の設定は UpdateAccountSettings API を使用するか、 AWS マネジメントコンソール から行います。また、TCU を事前に見積もる方法については、本投稿の後半で詳しく説明します。 Timestream コンソールの 管理者ダッシュボード で、 管理者設定を設定 を選択します。 最大クエリ TCU に希望の値を設定し、 設定を保存 します。 現在、使用中のアカウントがクエリによってスキャンされたデータ量に対して請求が行われており、TCU にオプトインするか選択できる場合は、追加のポップアップが表示されます。 尚、最大クエリ TCU を削減する際、使用状況によっては有効になるまでに最大 24 時間かかる場合があります。また、クエリが実際に消費した TCU に対してのみ料金が請求される為、最大クエリ TCU 制限を高くしても、それらの TCU がワークロードで使用されない限り、コストには影響しません。 TCU による請求 TCU を使用すると、最低 30 秒間、使用したコンピューティングリソースに対して 1 秒毎に料金が請求されます。これらのコンピューティングユニットの使用単位は TCU 時間です。アプリケーションが Timestream にクエリを送信すると、Timestream サービスは使用中のコンピューティングユニットでリクエストを処理できるかどうかを確認します。処理出来ない場合、サービスはスケールアップして、クエリを処理するために追加のコンピューティングユニットを割り当てます。クエリの実行後、サービスは追加のクエリを最大 10 秒間待機します。この期間内に追加のクエリがない場合は、使用中のコンピューティングユニットの数をスケールダウンして、リソースを最適化し、コストを最小限に抑えます。 実際の例を使って説明しましょう。まず、アプリケーションに 1 分のうち 40 秒の間、レイテンシが 1 秒未満のクエリを含むクエリパターンがあると仮定します。アプリケーションは、1 分の開始時刻 t1 秒から t40 秒にクエリを Timestream に送信します。 コンピューティングユニットには、最低 30 秒ごとに料金が請求されます。Timestream サービスは、最小時間(30 秒)が経過し、最大 10 秒間クエリがない場合に、コンピューティング ユニットをスケールダウンします。サービスが t1 でクエリ用に 4 つの TCU を割り当て、後続のすべてのクエリが同じ 4 つの TCU で処理されると想定します。 4 つの TCU 使用量のうち 50 秒 (=0.0138889 TCU 時間)、即ち、4 * 0.01388 TCU 時間 = 0.05552 TCU 時間に対して請求されます。このパターンが 1 日 8 時間、毎分 (t1 ～ t60) 繰り返されると仮定すると、消費される合計 TCU 時間は、1 日あたり 0.05552 TCU 時間 * 60 分 * 8 時間 = 26.6496 TCU 時間となります。 TCU 時間を取得したら、目的のリージョンごとのクエリ料金を確認する事で料金を計算できます。 請求をより深く理解するために、さらにいくつかの例を見てみましょう。 ワークロードが 3 時間で 20 個の TCU を使用する場合、 60 TCU 時間 (20 TCU x 3 時間) に対して請求されます。 ワークロードが 30 分間に 12 TCU を使用し、次の 30 分間に 20 TCU を使用します。この場合、16 TCU 時間に対して請求されます (12 TCU x 0.5 時間 + 20 TCU x 0.5 時間)。 TCU の推定 Timestream for LiveAnalytics は、容量とパフォーマンスを調整するために自動的にスケーリングされるため、基盤となるインフラストラクチャの管理や容量のプロビジョニングは必要ありません。データの取り込み、ストレージ、クエリを独立して拡張できる 完全に分離されたアーキテクチャ を特徴としており、アプリケーションのニーズに合わせて事実上無限の拡張性を提供できます。 必要なコンピューティングユニットの数は、クエリの同時実行性、データモデル、クエリによってスキャンされるデータ量などのワークロードの特性によって決まります。処理可能なクエリの数を見積もるために、Timestream for LiveAnalytics でデータが収集および分析され、Grafana を通じて視覚化されるインフラストラクチャ監視のユースケースをシミュレートしました。現実世界のシナリオと同様に、複数のユーザーがメトリクスを監視する 2 つの一般的な可観測性クエリパターンをシミュレートし、ユーザーを 1 から 21 に増やしました。次に、MaxQueryTCU 設定 (4 および 8) を変更して、ユーザーの増加に応じて処理されるクエリの量とそれに対応する待ち時間を監視しました。 ホストの最新のメモリ使用率 ( lastpoint-query.ipynb ) を取得するパターン、及び、過去 10 分間の CPU 使用率をビニングする ( single-groupby-orderby.ipynb ) クエリパターンについて、4 および 8 TCU でクエリボリュームとレイテンシーメトリクスを測定しました。 これらのワークロードでは、サービスにクエリを発行する 1 人のユーザーから開始し、同時ユーザーの数を 21 人までスケールします。テストは、ユーザー構成毎に 1 分間実行され、対応するレイテンシー (p50、p90、p99)、 1 分あたりのクエリ数、およびスロットリング数 (もしあれば) が観察されます。詳細については、 README.md を参照してください。 最初のシミュレーションでは、MaxQueryTCU を 4 に設定し、 次のクエリ を実行します。これにより、特定のホストの最新のメモリ使用率が取得されます。 select memory from "devops"."sample_devops" where time > ago(10m) and hostname='host1' order by time desc limit 1 次のグラフは、レイテンシーのパーセンタイル (秒)、1 分あたりのクエリ数、およびスロットリング数とユーザー数の関係を示しています。 最初は 1 人のユーザーから始めて、時系列データにアクセスするユーザーの数を増やし続けます。わずか 4 つの TCU で、Timestream サービスは 1 分あたり 4,560 件のクエリ、つまり 1 秒あたり約 76 クエリ (QPS) を処理し、p99 レイテンシーは 160 ミリ秒未満でした。 Grafana ユーザーの数が増えると、レイテンシーが増加し、それによって 1 分あたりのクエリ数が減少しますが、スロットリングは最小限に抑えられました。これは、 デフォルトの SDK の最大再試行数が 3 (ベストプラクティス) に設定されており、SDK はスロットリングが発生する前にクエリをリトライするためです。クエリのレイテンシには再試行時間が含まれるため、同時ユーザー数が 7 名 (76 QPS) を超えると、主に複数のリトライが原因で p99 レイテンシーが増加していることがわかります。ユースケースで 1 秒未満のクエリ遅延が許容できる場合は、4 つの TCU で最大 9 人の同時ユーザーと 1 分あたり 4,853 件のクエリをサポート出来る事が分かりました。 次に、MaxQueryTCU を 8 に増やしてテストを再実行します。Timestream サービスはオンデマンドでコンピューティング ユニットを割り当てるため、サービスは 4 TCU から開始され、ワークロードが増加するにつれて追加の 4 TCU を割り当てます。次のグラフは、8 TCU のメトリクスを示しています。 8 TCU の場合、200 ミリ秒未満の p99 レイテンシーで 9,556 件のクエリ (約 159 QPS) を処理可能でした。Grafana ユーザーの数が増えると、レイテンシーが増加し (330 ミリ秒未満)、そのため 1 分あたりのクエリ数がわずかに減少しますが、スロットリングは発生しませんでした。つまり、500 ミリ秒未満のクエリ遅延がユースケースで許容できる場合は、 8 つの TCU で最大 15 人の同時ユーザーと 1 分あたり 9,556 のクエリをサポート出来る事が分かりました。 MaxQueryTCU は最大 1,000 まで増やすことができるため、ユーザーベースの拡大に合わせて拡張できます。許容できるコストに応じて、MaxQueryTCU を増やし続けることも、遅延がユースケースとして許容できる場合には、既存の TCU を使用して追加のユーザーにもサービスを提供することもできます。 次に、以下の クエリ 2 でシミュレーションを繰り返します。これは、ビン分割、グループ化、並べ替えを実行しますが、クエリ 1 と比べるとリソースを大量に消費するクエリです。 select bin(time, 1m) AS binned_time, max(cpu_utilization) as max_cpu_utilization from "devops"."sample_devops" where time > ago(10m) and hostname='host2' group by bin(time, 1m) order by binned_time asc 次のグラフは、クエリ 2 に対応するメトリクスを示しています。 前のテストと同様に、1 人のユーザーから始めて、データにアクセスするユーザーの数を増やしていきます。4 つの TCU で、180 ミリ秒の p99 レイテンシーで 6 人の同時ユーザーに対して 3,310 件のクエリ(約 55 QPS)を処理出来ました。 Grafana ユーザーの数が増加すると、主に再試行によるオーバーヘッドが原因で 1 分あたりのクエリが減少し、レイテンシーも増加します。 次のグラフは、8 つの TCU の際のメトリクスを示しています。 8 つの TCU を使用すると、500 ミリ秒未満の p99 レイテンシーで 15 人の同時ユーザーに対して 6,051 (約 100 QPS) 件のクエリをサポートできます。 必要なパフォーマンスに必要な TCU を使用できますが、少ない TCU から始めて、希望のパフォーマンス基準を満たすか、価格とパフォーマンスの適切なバランスが見つかるまで、アカウント内の MaxQueryTCU を増やすアプローチがあります。 尚、Timestream のスケジュールクエリ機能は、集計およびロールアップ操作をサポートするように設計されており、パフォーマンスを向上させるために派生テーブル (データがすでに集計されており、データ量が削減されている) からダッシュボードや視覚化用のデータを生成するのに最適です。詳細については、「 Improve query performance and reduce cost using scheduled queries in Amazon Timestream 」を参照してください。 シミュレーションで実証されたように、4 つの TCU は 76 QPS (月間 1 億 9,900 万クエリに相当) および 55 QPS (月間 1 億 4,300 万クエリに相当) のクエリ量をサポート可能でしたが、クエリの複雑さに依存する為、シミュレーションで示されているよりも多くなる可能性があります。また、TCU はクエリ数ではなくコンピューティング使用時間に基づいて課金されるため、76 QPS と 55 QPS の費用は変わりません。クエリの同時実行の利点を最大限に高めるには、 データモデル、クエリ、ワークロードを最適化 してコンピューティングリソースを効果的に利用することが不可欠です。これにより、コストが削減され、クエリのスループットが向上し、リソースの使用率が向上します。 AWS Pricing Calculator を使用したコストの見積もり AWS Pricing Calculator を使用して、Timestream for LiveAnalytics の月額コストを見積もることができます。このセクションでは、リアルタイムクエリと分析クエリとみなされるものについての一般的なガイダンスを提供します。 リアルタイムクエリ – 小さなウィンドウ (5 分や 15 分などの数分) 内で メジャー を分析するクエリ、または通常は数百のレコードをスキャンするクエリ。 分析クエリ – 大きな時間範囲 (12 時間、日、月等) にわたってメジャーを分析するクエリ。複雑な結合やサブクエリが含まれる場合があり、通常は数千のレコードをスキャンします。これらのクエリでは、パフォーマンスを向上させるためにデータの集約とセグメント化に高いコンピューティング (CPU/メモリ) が必要です。 これは一般的なガイダンスです。小さなウィンドウ内で補間、導出、またはその他の複雑な関数を要求するような、リアルタイムクエリとして認められない可能性のあるコストのかかるクエリが存在する可能性があります。 わかりやすくするために、料金計算では、1 秒あたり 7 つの同時クエリが 4 つの TCU で 1 秒のレイテンシーで処理されると想定しています。我々の実験では、160 ミリ秒未満の p99 レイテンシーで 72 QPS を達成しました。料金計算ツールは、指定された時間単位 (秒、分、時間、日、月あたり) にわたって均等に分散されるクエリの数を分割します。場合によっては、クエリが 30 秒を超えて実行されない場合 (アイドル期間を含む)、その 1 分全体に対して料金が請求されるわけではありませんが、この Calculator では考慮されないため、実際の合計額はさらに小さくなる可能性があります。クエリのワークロードをよりよく理解している場合は、本投稿の前半で共有した例に基づいて、さらに正確なコストを計算できます。 TCU の監視 TCU の使用状況を効果的に監視するために、Timestream for Live Analytics は Amazon CloudWatch メトリクス QueryTCU を提供します。このメトリクスは、1 分間に使用されるコンピューティングユニットの数を測定し、1 分ごとに更新されます。このメトリクスを使用すると、1 分間に使用された最大および最小の TCU を追跡でき、コンピューティングの使用状況を把握できます。さらに、このメトリクスにアラームを設定して、コンピューティング使用量が特定の閾値を超えたときにリアルタイム通知を受け取ることができ、使用量を最適化し、クエリコストを削減できます。 次のグラフは、過去 3 時間に使用された QueryTCU の最大値を示しています。 最大 TCU は価格の計算には直接役立ちませんが、最大/最小 TCU がどの程度になるかに関して洞察を与える事が出来ます。正確な TCU 時間は、AWS Cost Management コンソールを開いて Cost Explorer を開始 し、Timestream for LiveAnalytics でフィルターする事で確認できます。 2024 年 4 月 29 日以降に初めて Timestream for LiveAnalytics を使用する全ての AWS アカウントは、クエリ料金設定にデフォルトで TCU を使用するようになります。 2024 年 4 月 29 日より前にサービスを利用していた場合は、「コスト管理」セクションで説明されているように、 API を通じて TCU へのオプトインを行うか、AWS Timestream コンソールで変更出来ます。 TCU ベースの価格設定に移行すると、コスト管理が改善され、クエリごとに計測される最小バイト数が無くなります。 TCU ベースの価格設定モデルへのオプトインはオプションであり、元に戻すことのできない変更です。つまり、クエリ価格設定に TCU を使用するように AWS アカウントを移行した場合、クエリ価格設定にスキャンされたバイト数を使用するように戻す事はできません。 結論 この投稿では、TCU、請求、コスト見積もりについて説明し、4 および 8 TCU 構成でのクエリワークロードのシミュレーションを実証しました。リソースを効果的に利用すれば、コストを増加させることなくワークロードを拡張できます。従量制の料金体系と TCU 使用量の最大値の設定により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。詳細については、次のリソースを参照してください。 Timestream Compute Unit (TCU) Data Modeling Best Practices to Unlock the Value of your Time-series Data Amazon Timestream pricing 今すぐ Timestream for LiveAnalytics の利用頂き、多くのメリットを享受することをお勧めします。さらに詳しく知りたい場合は、通常の AWS サポート連絡先に問い合わせるか、 Amazon Timestream の AWS re:Post に質問を投稿してください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本ブログは 2024 年 10 月 10 日に公開されたBlog ” Strengthening security in the era of generative AI: Must-attend sessions at re:Invent 2024 ” を翻訳したものです。 生成 AI は日々新たな、革新的な方法で産業を変革しています。 Amazon Web Services (AWS) では、セキュリティを最優先事項としており、イノベーションを目指す組織にとって重要な要素と考えています。AWS re:Invent 2024 に向けて準備する際は、セキュリティがどのように組織の生成 AI ソリューションを迅速かつ安全に革新するのに役立つかを学ぶため、これらの重要なセッションをスケジュールに組み込むことをお勧めします。業界をリードする専門家が、データを保護するため、あるいは、ガバナンス、リスク、コンプライアンスに対処するために、生成 AI ワークロードをどのように保護できるかについて深い洞察を共有します。 このブログでは、セキュリティリーダーや担当者、技術的な意思決定者、人工知能と機械学習 (AI/ML) の開発者向けに、必見のセッションやお気に入りのアクティビティをいくつかハイライトしました。この楽しさを共有するには、 こちらから登録 してください。ラスベガスでお待ちしています！ 基調講演とイノベーショントーク AWS re:Invent 2024 の 基調講演 と イノベーショントーク は、AWS のシニアリーダーから直接、革新的な洞察を得る機会となります。これらのセッションでは、生成 AI、クラウドセキュリティ、そしてアプリケーション開発と AWS クラウドの未来に新たな方向性を示す革新的なアーキテクチャにおける最新のブレークスルーを深く掘り下げます。 KEY002 – CEO Keynote with Matt Garman (Matt Garman による CEO 基調講演) 。基幹サービスの刷新から新しい体験の創造まで、AWS がクラウド全体でどのようにイノベーションを起こし、お客様とパートナーが安全で豊かな未来を構築できるようにしているかをご覧ください。 SEC203-INT – Security insights and innovation from AWS with Chris Betz (Chris Betz による AWS のセキュリティに関する洞察とイノベーション) 。 AWS の CISO である Chris Betz が、セキュリティを統合・自動化し、チームが重要な取り組みに集中できるようにする変革的な戦略を明らかにする中で、革新的なセキュリティ技術と生成 AI が、組織のセキュアなイノベーションの加速をどのように支援するかをご覧ください。 ARC203-INT – Architectural methods & breakthroughs in innovative apps in the cloud with Shaown Nandi and Ben Cabanas (Shaown Nandi と Ben Cabanas によるクラウドにおける革新的なアプリケーションのアーキテクチャの方法論とブレイクスルー) 。 このトークでは、生成 AI と最先端のアーキテクチャの進歩がアプリケーション設計をどのように変革し、AWS のお客様がシステムを近代化し、堅牢なデータ戦略を開発し、変化し続けるクラウド環境を安全に活用できるようにしているかを紹介します。 イノベーショントーク の全リストをご覧ください。今年、現地に参加できない方も、基調講演とすべてのイノベーショントークはライブストリーミングされます。 セッション 生成 AI のセキュリティに関する専門知識を深めるために設計された、さまざまな学習機会をご覧ください。今年のセッションでは、AI ワークロードとそれを支えるデータを保護するための、実際の環境で有効な具体的な対策をお客様に提供することに重点を置いています。講義形式のブレイクアウトセッション、インタラクティブなチョークトーク、ハンズオンワークショップ、ライブコーディングやコードサンプルを使ったインタラクティブなディスカッションなど、あなたのニーズに合わせたセッションがあります。以下のオプションをご覧いただき、 参加を申し込んで 、この急速に発展する分野での理解と実践的なスキルを向上させてください。 セッションレベル (100 – 400) とセッションタイプの詳細や説明については、 re:Invent のウェブサイト でご確認いただけます。 ブレイクアウトセッション ブレイクアウトセッションは、AWS のエキスパート、お客様、パートナーが提供する 1 時間の講義形式のセッションです。重要なトピックに関する知識を深め、実用的な洞察を得て、業界のリーダーとネットワークを築くのに最適です。 SEC214 – Elevating client experiences with secure AI: Rocket Mortgage’s approach (安全な AI によるクライアント体験の向上： Rocket Mortgage のアプローチ) 。 Rocket Mortgage が AWS の生成 AI サービスを実装して、セキュリティの課題に対処しながら顧客体験を向上させた方法をご覧ください。 セッションの登録 SEC315 – Bring your workforce identities to AWS for generative AI and analytics (生成 AI と分析のために従業員のアイデンティティを AWS に持ち込む) 。 このセッションでは、従業員のアイデンティティプロバイダーを統合して、生成 AI アプリケーションやツールへのアクセスを容易にする力を実演します。AWS と NVIDIA が、アイデンティティを意識したエンドツーエンドの体験をデモンストレーションします。 セッションの登録 SEC323 – The AWS approach to secure generative AI (生成 AI をセキュアにする AWS のアプローチ) 。 AWS がインフラストラクチャ、モデル、アプリケーションの各層で生成 AI をどのように保護し、組み込みのセキュリティ機能でお客様にデータの制御を提供しているかを学びます。 セッションの登録 SEC403 – Generative AI for security in the real world (現実世界におけるセキュリティのための生成 AI) 。 セキュリティチームのための実用的な生成 AI アプリケーションを探索し、インシデント対応、レッドチーム/ブルーチームの強化、セキュリティオペレーションセンター (SOC) のユースケースを含め、セキュリティ運用を強化します。 セッションの登録 チョークトーク チョークトーク（ Chalk talk ）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。このフォーマットは、特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問に答えてもらえるのに理想的です。 SEC303 – Protecting data within your generative AI architectures (生成 AI アーキテクチャ内のデータ保護) 。 機密データを用いた大規模言語モデル (LLM) のトレーニングにおけるリスクを軽減します。サニタイゼーション、匿名化、差分プライバシーなどの技術を探ります。 このトークに登録する SEC327 – Building secure network designs for gen AI applications (生成 AI アプリケーションのためのセキュアなネットワーク設計の構築) 。 AWS 上でのイノベーションを加速し、より安全に変革的な生成 AI アプリケーションを実現するため、クラウドネットワーク設計を最適化します。実証済みのベストプラクティス、先制的な制御、および回復力のある多層防御アーキテクチャを構築するためのリファレンスアーキテクチャを共有します。 このトークに登録する SEC335 – Harness generative AI for business growth amidst the regulatory landscape (規制環境の中で生成 AI を活用してビジネス成長を促進) 。 AWS AI/ML ソリューションがどのように責任あるプラクティスに沿いながらビジネス成長を促進できるかを探ります。欧州連合の一般データ保護規則 (GDPR) から業界固有の規制まで、進化する規制環境をナビゲートするための戦略について、お客様事例から学びます。 このトークに登録する SEC336 – Security and compliance considerations using Amazon Q Business (Amazon Q Business 使用時のセキュリティとコンプライアンスの考慮事項) 。 Amazon Q Business アプリケーションを安全に保つためのベストプラクティスを探ります。アクセス制御、データ保護、コンプライアンスの考慮事項に焦点を当て、AI アシスタントを安全かつコンプライアンスに準拠した状態に保つ方法を学びます。 このトークに登録する SEC338 – Safeguard your generative AI apps from prompt injections. (プロンプトインジェクションから生成 AI アプリを保護) 。 入力検証、セキュアなプロンプトエンジニアリング、コンテンツモデレーションを理解することで、生成 AI アプリケーションをプロンプトインジェクション攻撃 (AI システムを操作して意図しない出力を生成させる攻撃) から保護する方法を学びます。 このトークに登録する PEX308 – Securing generative AI on AWS (AWS 上の生成 AI のセキュリティ確保) 。 パートナーの視点から生成 AI のセキュリティ考慮事項を探ります。パートナーがどのようにデータセキュリティを強化できるか、またお客様の生成 AI ワークロードにパートナーがもたらす付加価値について学びます。 このトークに登録する AIM344 – Understanding the deep security controls within Amazon Q Business (Amazon Q Business 内の深層セキュリティ制御の理解) 。 Amazon Q 内のセキュリティ関連の機能と制御について学び、ビジネスデータを安全に自信を持って使用できるようにします。 このトークに登録する AIM407 – Understand the deep security controls within Amazon Bedrock (Amazon Bedrock 内の深層セキュリティ制御の理解) 。 Amazon Bedrock のセキュリティの詳細に深く踏み込みます。ガードレール、エージェント、ナレッジベースなどの複雑な機能のアーキテクチャ、データフロー、ライフサイクル管理を解説し、データのプライバシーと制御を妥協することなくこの生成 AI サービスを使用できるようにします。 このトークに登録する DEV323 – OWASP Top 10 for LLMs (LLM のための OWASP トップ 10) 。 大規模言語モデル (LLM) に対する OWASP トップ 10 リスクの実際の脆弱性と実証済みの緩和戦略を、インタラクティブなデモと実践的な演習を通じて探ることで、生成 AI アプリケーションのセキュリティ確保スキルを強化します。 このトークに登録する コードトーク コードトークは、人気のあるチョークトーク形式に似ていますが、ホワイトボードでの説明ではなく、ライブコーディングやコードサンプルに焦点を当てています。これらのセッションでは、ソリューションの構築に使用される実際のコードを詳しく見ていき、参加者がアプローチの「理由」を理解し、エラーも含めた開発プロセスを観察できます。参加者は質問をしたり、実際に手を動かしながら学んだりすることが推奨され、より深い実践的な学習体験を得ることができます。 SEC401 – Inspect and secure your application with generative AI (生成 AI を活用したアプリケーションの検査とセキュリティの確保) 。 生成 AI の力を活用してアプリケーションのセキュリティを強化します。AI 駆動型ツールが脆弱性を迅速に検出し、修復戦略を推奨する方法を紹介しながら、より安全なソフトウェアを容易に構築する方法を解説します。 このセッションに登録 SEC405 – Consolidated data protection insights with generative AI (生成 AI を用いたデータ保護の包括的な洞察) 。 Amazon Q in QuickSight を使用して、アカウント全体の AWS KMS キーを迅速かつ実用的な洞察で保護する方法を学びます。 このセッションに登録 ビルダーズセッション AWS のエキスパートが主導する少人数のグループに参加し、AWS 上での構築方法についてインタラクティブに学習します。各ビルダーズセッションは、これから構築するものについての簡単な説明やデモンストレーションから始まり、その後はみなさんの番です！エキスパートがこの一連のハンズオン体験をガイドします。 注意： これらのセッションに参加するには、必ずご自身のラップトップを持参してください。 DOP302 – Creating secure code with Amazon Q Developer (Amazon Q Developer を使用したセキュアなコードの作成) 。 Amazon Q Developer の AI を活用した機能を使用して、よりセキュアで最適化されたコードを書き、脆弱性を検出し、即座に修正を実装する実践的な経験を積むことで、開発ワークフローを変革し、コーディング能力を飛躍的に向上させます。 このセッションに登録する SMB302 – Empower your business with defense-in-depth architecture (多層防御アーキテクチャによるビジネスの強化) 。 実用的でコスト効率の高い多層防御戦略、階層化されたセキュリティアーキテクチャ、AI 特有の保護策を探求することで、中小企業が生成 AI を使ってより安全にイノベーションを起こせるようにし、AWS クラウド上でレジリエントで信頼性の高い AI を活用したソリューションを構築します。 このセッションに登録する ワークショップ ワークショップは 2 時間のインタラクティブなセッションで、チームで協力するか個人で取り組み、AWS サービスを使用して現実世界の課題を解決します。これはハンズオン学習に最適です。各ワークショップは短い講義から始まり、その後、問題に取り組むための時間が確保されています。 注意： AWS エキスパートと一緒に構築作業を行うため、ノートパソコンの持参をお忘れなく。 SEC305 – Generative AI-based code remediations and patch management at scale (生成 AI を活用したスケーラブルなコード修復とパッチ管理) 。 AWS Lambda 、コンテナ、 Amazon Elastic Compute Cloud (Amazon EC2) 全体で、生成 AI を使用して脆弱性の検出と修復を自動化する方法を実践的に体験します。これにより、チームはアプリケーションを積極的に保護することができます。 このワークショップに登録する SEC306 – Securing your generative AI applications on AWS (AWS 上の生成 AI アプリケーションのセキュリティ確保) 。 AWS のサービスと機能を使用して、生成 AI アプリケーションのセキュリティを確保する実践的な経験を得ることができます。脆弱性のあるサンプル AI アプリをデプロイし、その後、問題を保護、検出、対応するための階層的なセキュリティ制御を実装します。これらのベストプラクティスを活用して、帰国後に自身の AI アプリケーションのセキュリティを確保できます。 このワークショップに登録する SEC309 – AWS IAM Identity Center: Secure access to generative AI applications (AWS IAM Identity Center: 生成 AI アプリケーションへの安全なアクセス) 。 アイデンティティを認識するチャットエクスペリエンスの構築方法、サンプルデータセットでのトレーニング方法、そして Amazon Q Business と AWS IAM Identity Center 間のネイティブ統合を使用して外部ワークフォース ID プロバイダーに接続する方法を学びます。 このワークショップに登録する SEC310 – Persona-based access to enterprise data for generative AI applications (生成 AI アプリケーションのための企業データへのペルソナに基づいたアクセス) 。 このインタラクティブなワークショップでは、検索拡張生成 (RAG)、メタデータフィルタリング、 Amazon Cognito を使用して、生成 AI アプリケーションでのドキュメントアクセスを保護する方法を学びます。 このワークショップに登録する Expo の概要 生成 AI のセキュリティや、その他さまざまなセキュリティトピックについて AWS のセキュリティエキスパートと直接話したいですか？その場合は、展示会場のセキュリティアクティベーションエリアで AWS の主要なセキュリティエキスパートと 1 対 1 で会話できます。この機会をお見逃しなく。組織のセキュリティ態勢を強化するお手伝いをします。 以下のような主要なセキュリティ領域について詳しく説明します： 検出と対応: 大規模なワークロードを保護するために、セキュリティリスクの検出と対応のテクニックを探ります。 ネットワークとインフラストラクチャのセキュリティ: AWS サービスを使用して、安全なグローバルネットワークを構築および管理する方法を学びます。 アプリケーションセキュリティ: セキュアなソフトウェアを提供し、アプリケーションセキュリティの課題に対処するための戦略を探ります。 アイデンティティとアクセス管理: 最新のクラウドネイティブなアイデンティティソリューションを採用し、最小権限のアクセス制御を適用します。 デジタル主権とデータ保護: データの制御を維持し、AWS クラウドでデータをセキュアに保護し管理する方法を選択できます。 楽しい時間はまだ続きます！ 革新的な洞察と深い学習に満ちた刺激的な 1 週間の後、世界的に有名な re:Play パーティー にご参加ください。これは re:Invent のフィナーレを飾るパーティーです！ヘッドライナーアーティストによるライブエンターテイメント、絶品の料理、たっぷりの飲み物に囲まれながら、リラックスし、交流を深め、無限の可能性に満ちた未来に乾杯しましょう。 今すぐ登録 re:Invent 2024 は素晴らしいイベントになることは間違いありません。みなさまにお会いできることを楽しみにしています！ 今すぐ登録 して、席を確保してください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Anna Montalat Anna は、AWS 生成 AI セキュリティのシニアプロダクトマーケティングマネージャーで、お客様が Amazon Bedrock、Amazon SageMaker、Amazon Q、その他の AI/ML ソリューションを安全にデプロイできるよう支援しています。新興技術を市場に投入することに情熱を注ぎ、サービスチームやエンタープライズのお客様と緊密に連携しています。仕事以外では、冬はスキー、夏はセーリングを楽しんでいます。 Matt Saner AWS のシニアマネージャーとして、Matt は世界で最も複雑な組織が重要なセキュリティ課題に取り組むのを支援するセキュリティスペシャリストのチームを率いています。Matt とそのチームはセキュリティ組織を戦略的なビジネスイネーブラーに変革するよう取り組んでいます。AWS に入社する前は、金融サービス業界で約 20 年間のキャリアを積みました。仕事以外では、パイロットとして一般航空機を操縦することに喜びを見出しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました

本ブログは 2024 年 1 月 17 日に公開されたBlog ” Building a security-first mindset: three key themes from AWS re:Invent 2023 ” を翻訳したものです。 AWS re:Invent 2023 が 2023 年 11 月 27 日から 12 月 1 日までネバダ州ラスベガスで開催され、世界中から 52,000 人が参加しました。 12 回目となる今回のカンファレンスでは、5 つの基調講演、17 のイノベーショントーク、そして 2,250 を超えるセッションとハンズオンラボを開催して、参加者には実践的な学習とネットワーキングの機会をご提供しました。 Amazon CSO Stephen Schmidt 何十もの新サービスと新機能の発表、そして AWS の幹部、お客様、 パートナー が共有する数え切れないほどのベストプラクティスにより、会場は熱気に包まれていました。私たちは現地ですべての革新的な取り組みと知見を体験しましたが、その要点をまとめるのは容易ではありません。このブログでは、注目を集めた 3 つの重要なセキュリティテーマに焦点を当てて説明します。 セキュリティ文化 サイバーセキュリティについて考えるとき、ビジネスを保護するための技術的なセキュリティ対策に注目するのは自然なことです。しかし、組織は技術ではなく人々で構成されています。自らを守る最良の方法は、効果的なリスク軽減、インシデントの検出と対応、そして継続的なコラボレーションを支える、積極的でレジリエントなサイバーセキュリティ文化を育むことです。 Sustainable security culture: Empower builders for success (持続可能なセキュリティ文化：ビルダー成功の促進) において、AWS Global Services Security Vice President の Hart Rossman 氏と AWS Global Services Security Organizational Excellence Leader の Sarah Currey 氏が、持続可能なセキュリティ文化を構築するための実践的な戦略を提示しました。 Rossman 氏は、セキュリティの課題について AWS と話し合う多くのお客様が、セキュリティをプロジェクト、プログラム、またはサイドプロジェクトとして管理しようとしていると指摘しました。セキュリティ態勢を強化するには、ビジネスにセキュリティを組み込む必要があると彼は述べました。 「セキュリティをプロジェクトやプログラムのように運用していては効果的になり得ないということを、早い段階で理解する必要があります。セキュリティは、経営上の必須事項、つまりビジネスの中核機能として運営しなければなりません。そうすることで、真の効果を発揮できるのです。」— Hart Rossman 、 AWS Global Services Security Vice President 3 つの役立つベストプラクティスを紹介しましょう。 継続的に粘り強く取り組む。 セキュリティの課題を提起してくれた従業員に対して、定期的かつ明確に感謝の意を表しましょう。繰り返しのように感じるかもしれませんが、セキュリティイベントやエスカレーションを学習の機会として扱うことで、ポジティブな文化を醸成できます。こうしたポジティブな文化を築くことで、プラクティスを組織全体に広めていくことができるようになります。共感的なリーダーシップアプローチは、従業員がセキュリティを全員の責任として捉え、経験を共有し、協力者として感じることを促します。 経営陣に報告する。 定期的にビジネスに焦点を当てた会議で経営陣と関わりを持ちましょう。セキュリティ文化が顧客に与える影響に関連する業務指標を明確に提供し、データとビジネス成果を明確に結びつけ、質問する機会を設けることで、経営陣の支持を得ることができます。そして、持続可能で積極的なセキュリティ態勢を確立する取り組みを前進させることができます。 考え方の枠組みを持つ。 良好なセキュリティ文化を創造するための考え方の枠組みを持ちましょう。Rossman 氏は、AWS で観察したセキュリティ文化の 3 つの要素を強調する図(図1) を提示しました：学習者、管理者(スチュワード)、そして構築者(ビルダー)です。セキュリティ文化の良き管理者になりたいのであれば、常に学び、実験し、ベストプラクティスを伝える学習者であるべきです。管理者としての役割が成長するにつれて、セキュリティ文化の構築者となり、文化を新しい方向に進展させることができます。 図1: セキュリティ文化を構築するための考え方の枠組み例 包括性、共感、心理的安全性の原則に対する配慮と取り組みは、チームメンバーが自信を持って発言し、リスクを取り、アイデアや懸念を表現するのに役立ちます。これにより、課題提起を奨励する文化が促進され、従業員が燃え尽きてしまうことを減らし、チームが組織全体のセキュリティ向上に貢献できるようにします。 Shipping securely: How strong security can be your strategic advantage (安全なデリバリー：強力なセキュリティが戦略的優位性となる方法) において、AWS Enterprise Strategy Director の Clarke Rodgers 氏は、セキュリティを最優先するマインドセットを醸成する上でのセキュリティ文化の重要性を改めて強調しました。 Rodgers 氏は、800 社以上のお客様との会議に基づいて、発展段階の 3 つの柱(図2) —認識段階(aware)、追加段階(bolted-on)、統合段階(embedded)—を強調しました。組織が受動的なセキュリティ態勢から能動的なセキュリティ重視のアプローチへと成熟するにつれて、セキュリティ文化が真のビジネスの推進力になると彼は指摘しました。 「組織が強力なセキュリティ文化を持ち、全員がセキュリティを自分の責任と考えるとき、より迅速に行動し、より迅速かつ安全な製品やサービスのリリースを実現できます。」— Clarke Rodgers 、 Director of Enterprise Strategy at AWS 図2: セキュリティを最優先した開発 人間中心の AI CISO やセキュリティ関係者は、効果的なサイバーセキュリティを確立し、従業員の負担を軽減するために、ますます人間中心の視点へと転換しています。 Gartner によると、2027 年までに、大企業の CISO の 50% が、サイバーセキュリティ施策による煩わしさを最小限に抑え、セキュリティ対策の導入を最大化するために、人間中心のセキュリティ設計手法を採用するようになるとされています。 Amazon の CSO である Stephen Schmidt 氏が Move fast, stay secure: Strategies for the future of security (迅速に行動し、安全を確保する: セキュリティの未来に向けた戦略) で述べているように、技術を最優先することは根本的に間違っています。セキュリティは、脅威アクターにとっても、防御側にとっても、人的な課題です。絶え間なく変化する環境に対応し、私たちが支援するお客様のビジネスを安全にサポートするには、ソフトウェアでは解決できない常に変化する課題に焦点を当てる必要があります。 そのような重点を置き続けるには、セキュリティチームと開発チームに、業務の一部を自動化し効率的に拡張するために必要なツールを提供することが求められます。 「人間は最も限りがあり、最も価値のあるリソースです。人間はセキュリティのあらゆる層に影響を与えます。人間が最大限効果的に活動できるよう、私たちがツールとプロセスを提供することが重要です。」— Stephen Schmidt 、 Amazon CSO 組織は、セキュリティのあらゆる層に適用するために人工知能(AI) を使用できますが、AI は熟練したエンジニアの役割を置き換えるものではありません。他のツールと連携して使用し、適切な人間によるレビューを行うことで、セキュリティコントロールをより効果的にすることができます。 Schmidt 氏は、ソフトウェア開発プロセスを加速させるための Amazon 社内での AI の活用や、新たに生成 AI を活用し、人間のスキルを補完する Amazon Inspector 、 Amazon Detective 、 AWS Config 、 Amazon CodeWhisperer の機能を強調しました。これらは、より広範な知識を活用し、人々のセキュリティに関する意思決定を支援します。高度なツールと熟練したエンジニアを組み合わせるこのアプローチは非常に効果的です。なぜなら、AI 単独では難しい、効果的なセキュリティに必要な繊細な判断を人間が行える立場に置くからです。 How security teams can strengthen security using generative AI (セキュリティチームが生成 AI を活用してセキュリティを強化する方法) では、AWS のシニア セキュリティスペシャリスト ソリューションアーキテクトである Anna McAbee 氏と Marshall Jones 氏、そしてプリンシパルコンサルタントの Fritz Kunstler 氏が、内部のナレッジベースと信頼できる公開ソースに基づいて一般的なセキュリティの質問やユースケースに対応できる仮想セキュリティアシスタント (チャットボット) を紹介しています。 図3: 生成 AI を活用したチャットボットのアーキテクチャ 図3 に示されている生成 AI を活用したソリューション（ Amazon Kendra 、 Amazon Security Lake 、 Amazon Bedrock を使用した検索拡張生成 (RAG) を含む）は、定型的なタスクの自動化、セキュリティに関する意思決定の迅速化、新たなセキュリティ課題への注力を増やすことに役立ちます。 このコードは GitHub から入手できます 。すぐに使えるコードのため、お客様の AWS アカウントでさまざまな大規模言語モデルとマルチモーダル言語モデル、設定、プロンプトを使って試してみることができます。 セキュアなコラボレーション コラボレーションはサイバーセキュリティの成功に不可欠ですが、進化する脅威、柔軟な勤務形態、そして拡大するデータ保護とプライバシーの錯綜する規制により、 安全で規制に準拠したメッセージング の維持が課題となっています。 推定で 30.9 億人のスマートフォンユーザーがコミュニケーションのためにメッセージングアプリを利用しており、この数字は 2025 年には 35.1 億人 に増加すると予測されています。 一般利用者向けメッセージングアプリをビジネス関連のコミュニケーションに使用することは、組織にとってデータが適切に保護され保持されているかを確認することが難しくなります。これは、特に特別な記録保持要件がある業界において、リスクの増大につながる可能性があります。 How the U.S. Army uses AWS Wickr to deliver lifesaving telemedicine (米国陸軍が AWS Wickr を使用して救命遠隔医療を提供する方法) において、米国陸軍遠隔医療先端技術研究センター (TATRC) のシニアディレクター Matt Quinn 氏、Deloitte のシニアマネージャー Laura Baker 氏、AWS Wickr のプロダクト責任者 Arvind Muthukrishnan 氏が講演を行いました。彼らは、TATRC の National Emergency Tele-Critical Care Network (NETCCN) が、 AWS Wickr および AWS Private 5G とどのように統合されたかを説明しました。AWS Wickr は HIPAA 対応の安全なメッセージングおよびコラボレーションサービスであり、AWS Private 5G はプライベートセルラーネットワークの展開とスケーリングのためのマネージドサービスです。 セッション中、Quinn 氏、Baker 氏、Muthukrishnan 氏は、TATRC が厳しい環境下でリアルタイムの患者ケアを行うために、現場と遠隔地の医療チーム間の安全な連携を可能にする、リソースの少ない環境でも利用可能な、クラウドベースの遠隔医療ソリューションをどのように実現したかを説明しました。Wickr を使用することで、現場の医療従事者は、医療専門家とのエンドツーエンドで暗号化されたビデオ通話、メッセージング、ファイル共有を通じて、自身の訓練レベルを超える怪我の治療を行うことができました(図4)。また、組織の要件に従って通信記録を安全に保持することができました。 「Wickr を軍事緊急遠隔重症治療プラットフォーム (METTC-P) に組み込むことで、エンドツーエンドの暗号化通信によるセキュリティとプライバシーを提供するだけでなく、戦闘救護員やその他の最前線の医療従事者が世界中の医療専門家から即座に助言を得る能力を与えます。これらの機能は、長期化する治療と、多領域作戦 (MDO) 戦場における多数の負傷者の治療という同時に直面する課題に対処するために必要となるでしょう。」— Matt Quinn 、 TATRC Senior Director 図4: AWS Wickr を使用した遠隔医療ワークフロー 別のチョーク・トークセッション Bolstering Incident Response with AWS Wickr and Amazon EventBridge (AWS Wickr と Amazon EventBridge を活用したインシデント対応の強化) では、AWS Wickr のシニアソリューションアーキテクトである Wes Wood 氏と Charles Chowdhury-Hanscombe 氏が、Wickr を Amazon EventBridge および Amazon GuardDuty と統合する方法をデモンストレーションしました。この統合により、AWS リソースを Wickr ボットに接続する統合ワークフロー(図5) が実現し、インシデント対応能力を強化することができます。このアプローチを使用することで、ネットワークが侵害されている可能性がある場合でも、セキュアな通信チャネルを通じて適切な関係者に重大な検出結果を迅速に警告することが可能になります。 図5: インシデントレスポンスのコミュニケーションのための AWS Wickr 統合 セキュリティは私たちの最優先事項 AWS re:Invent 2023 では、 ゼロトラスト によるアダプティブアクセスコントロール、 AWS サイバー保険パートナー 、Amazon の CTO である ワーナー・ヴォゲルス博士 の人気のキーノート、そして Expo フロアで紹介されたセキュリティパートナーシップなど、さまざまなトピックについてさらに多くのハイライトがありました。多岐にわたる内容でしたが、1 つ明確なことがあります。それは、AWS が技術面とビジネス面の両方の成果を実質的に改善できるよう、セキュリティ最優先のマインドセットの醸成を支援するために懸命に取り組んでいるということです。 オンデマンドのカンファレンスセッションを視聴するには、 YouTube の AWS re:Invent 2023 セキュリティ、アイデンティティ、コンプライアンスのプレイリスト をご覧ください。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 Clarke Rodgers Clarke は AWS のエンタープライズセキュリティ担当ディレクターです。セキュリティ業界で 25 年以上の経験を持ち、エンタープライズのセキュリティ、リスク、コンプライアンスに焦点を当てた幹部と協力して、セキュリティ態勢を強化し、クラウドのセキュリティ機能を理解するための支援を行っています。AWS に入社する前は、多国籍保険会社の北米事業の CISO を務めていました。 Anne Grahn Anne は、シカゴを拠点とする AWS のシニアワールドワイドセキュリティ GTM スペシャリストです。セキュリティ業界で 13 年以上の経験を持ち、サイバーセキュリティリスクを効果的に伝えることに焦点を当てています。公認情報システムセキュリティ専門家（ CISSP ）の資格を保持しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

スポーツ業界が大きな変革期を迎える中、クラウドテクノロジーがイノベーションの原動力となっています。2024 年 9 月 5 日に開催したウェビナーでは、スポーツビジネスの変革を加速する AWS の取り組みと、先進的な活用事例をご紹介しました。 セミナーのアジェンダ: スポーツ業界のイノベーション – アマゾン ウェブ サービス ジャパン合同会社 山口 新時代の競輪レース映像と、AWS クラウドを活用した全国展開 – 株式会社 WinTicket 内田様 スポーツコンテンツホルダーが進めるクラウド活用～映像とデータ領域のシステム内製化～ – パシフィックリーグマーケティング株式会社  渡邉様 スポーツ業界のイノベーション アマゾン ウェブ サービス ジャパン合同会社 インダストリースペシャリスト 山口 [ 資料 ] AI やスポーツデータレイク、IoT などの先端技術を導入し、スポーツ現場に多様な変革をもたらすためにクラウドの活用が進んでいます。選手分析の高度化、スマートスタジアムの実現、ファンエンゲージメントの向上など、スポーツの体験そのものを革新するソリューションが続々と生まれています。こうした業界変革の中で、AWS の取り組みと世界のお客様事例を紹介しました。 新時代の競輪レース映像と、AWSクラウドを活用した全国展開 株式会社 WinTicket スポーツ映像テック事業部 事業責任者　内田 厚太郎 様 [ 資料 ] WINTICKET が提供する、リアルと CG が融合した独自の競輪ライブ映像「WINLIVE」。競輪は全国 43 ヶ所の競輪場で毎日 100 レース前後おこなわれており、そのすべてで WINLIVE を実施するには AWS のクラウド活用が不可欠です。選手トラッキングのための画像認識、データ計算、CG 描画、映像配信、すべてのシステムを AWS クラウドへ移行する取り組み（鋭意進行中）についてご紹介いただきました。 スポーツコンテンツホルダーが進めるクラウド活用～映像とデータ領域のシステム内製化～ パシフィックリーグマーケティング株式会社 メディア事業本部 IT統括部部長 兼 開発グループマネージャー　渡邉 公悠 様 [ 資料 ] スポーツ業界の”コンテンツホルダー”側は IT リソース不足の課題がある中、パシフィックリーグマーケティング (PLM) ではクラウドサービスを使って映像配信基盤やデータ分析システムを構築、データの活用やコスト削減を実現し、技術的なナレッジも社内に蓄積される体制構築を進めています。また、内製化によってコンテンツのニーズへ素早く対応し、今後のビジネスの拡大を目指しています。今回は、パ・リーグTV、パ・リーグ.com 開発の背景にある AWS を中心としたクラウドサービスの活用事例を紹介しただきました。 おわりに 本ブログでは、2024 年 9 月 5 日に開催されたメディアセミナーについて紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 —- 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは AWS 山口が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 2024 年 10 月 17 日 (木) に「 生成 AI と AWS Ad/Marketing Tech Services で実現する広告・マーケティングイノベーション 」というイベントをオンラインで開催します。クッキーレス時代における広告やマーケティングの最新技術とビジネスの動向、AWS のお客様事例をお届けします。広告やマーケティングに携わる方はぜひご参加ください。 コンテンツ回りでは「 2024 年 9 月の AWS Black Belt オンラインセミナー資料及び動画 」が公開されています。「Amazon Bedrock Agents 自律型 AI の実現に向けて: 検討編」、「Amazon Bedrock Knowledge Bases」、「Amazon Bedrock モデル推論 a. 準備編, b.実践編」と Bedrock のコンテンツが盛りだくさんです。資料でも動画でもご都合良い方でご覧ください。 これまで何度か紹介していた「 AWSジャパン生成AI実用化推進プログラム 」は、受付期限が 2024 年 11 月 22 日 に延長されました。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 7 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 大阪ガス株式会社様、生成 AI を使った高精度のカーボンクレジット評価システムを構築 こちらのブログは 前半 と 後半 の連載となっています。大阪ガス様は、2050 年までにカーボンニュートラルを実現することを目標としており、その一環としてカーボンクレジットの活用推進を行っています。カーボンクレジットとは、企業の温室効果ガス排出削減量をクレジットとして発行し取引可能にする仕組みです。カーボンクレジットを利用する際は、企業の取り組みの品質を評価することが非常に重要です。そこで、大阪ガス様ではカーボンクレジットの計画書を生成 AI で解析し、品質評価を行う仕組みを AWS 上に開発しました。計画書に対し、Claude 3.5 Sonnet などのモデルを使って重要な評価基準に基づいたリスク評価を行うことができます。格付会社による評価結果との一致率を測る検証の結果、Claude 3.5 Sonnet では、正解率 97.5%、再現率 96.4%、適合率 99.1% と高い精度の結果を得ることができました。今後は、本システムを気候変動対策のための共通プラットフォームとすることを目指し、精度と信頼性向上に取り組んでいくとのことです。 AWS生成AI国内事例ブログ: ANA X様、生成 AI によるお客様の声 (VoC) 分析により、分類作業や分析時間を60％削減 ANA X様は、商品の改善策の検討のために、コンタクトセンターの通話内容の分析を行っています。分析では、「えーっと」などの意味のない言葉が上位ワードとして捉えられてしまう、言葉の意味を踏まえた問い合わせの分類が難しい、といった課題があり、分類作業を含めた分析作業に1週間程度の時間を要していました。そこで、Amazon Bedrock を使ったお客様の声 (VoC) 分析を行いました。Bedrock の利用により、文脈に沿った問い合わせ理由の自動分類や、これまで見過ごされていた詳細な問い合わせ理由の可視化が実現でき、分類作業、詳細分析時間が 60％ 削減されました。、プロンプトエンジニアリングの設計には、 生成 AI 練習帳 の活用や異なる部門のメンバーを巻き込んだ社内プロンプトワークショップの開催を行なった点も参考になります。 ブログ記事「経済産業省 GENIAC 基盤モデル開発支援事業 (第2期) における採択事業者への支援を開始」を公開 2024年10月10日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が協力して実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の第2期 (2024年7月公募) における採択事業者のキックオフが行われ、本事業の採択事業者が発表されました。AWS は、計算リソース提供事業者として、技術支援や事業化支援等を行います。ブログではAWSを利用する採択事業者とコメントを掲載しています。 ブログ記事「流通・小売・消費財企業のイノベーションを生成 AI で促進する」を公開 AWS は生成 AI を活用した流通・小売・消費財企業の変革を支援しています。本ブログでは、 こちらのe-book  に記載されている生成AI のユースケース、導入のステップ、関連する技術のハイライトを解説しています。 ブログ記事「Amazon Bedrock で利用可能になった Meta からの Llama 3.2 モデルの紹介: 新世代のマルチモーダルビジョンモデルと軽量モデル」を公開 先々週の週刊生成AI with AWS にて、Amazon Bedrock で Meta 社の Llama 3.2 が利用できるようになったとお知らせしました。このブログ記事では、その話題をさらに深掘りする記事の和訳バージョンです。4つのモデル (90B、11B、3B、1B) それぞれの特徴や使用方法を解説しています。 ブログ記事「AI21 Labs の Jamba 1.5 ファミリーのモデルが Amazon Bedrock で利用可能に」を公開 こちらも 先々週の週刊生成AI with AWS でお知らせした AI21 Labs の Jamba 1.5 ファミリーモデルの解説を行う和訳記事です。Jamba 1.5 Mini と Jamba 1.5 Large の特徴について解説しています。 ブログ記事「生成 AI ワークロードのインシデント対応方法論」を公開 生成AI ワークロードにおけるインシデント対応は、 AWS セキュリティインシデント対応ガイド に記載されているガイダンスに加えて生成AI ならではの要素も考慮する必要があります。本ブログでは、インシデント発生前の準備、対応方法、インシデント例を紹介しています。 ブログ記事「Amazon Connect で簡単に実現する、生成 AI を活かしたより良いカスタマーエクスペリエンス」を公開 このブログは、カスタマーエスクペリエンス (CX) 向け生成 AI ブログシリーズの パート1 、 パート2 に続くパート 3 の記事です。今回の記事では、エージェントの効率性の向上、分析と品質のモニタリングといったカスタマーサービスのユースケースに対して、生成 AI を迅速かつ簡単に有効化する方法を紹介しています。 サービスアップデート コンソールからコードを生成する Console to Code の一般提供を開始 AWS マネジメントコンソールから本番デプロイメント用のコード作成を行う Console to Code の一般提供を開始しました。Console to Code を使用すると、コンソールで実行したアクションを、CLI、CloudFormation、CDK 形式から選択したコードに簡単に変換できます。コード変換には Amazon Q Developer が活用されています。現在は、EC2・VPC・RDS に対応しています。 Amazon Q in Connect のプロンプトカスタマイズ機能が利用可能に コンタクトセンターのエージェント向け生成AI搭載アシスタントである Amazon Q in Connect にて、LLMプロンプトを事前設定する機能を提供開始しました。スーパーバイザーはプロンプトをカスタマイズすることで、応答に特定のフレーズを組み込んだり、ビジネスガイドラインに従った応答をしたりすることが可能になりました。利用可能なリージョン情報は こちら をご覧ください。 Amazon Q in Connect にてパーソナライズされたガイダンス機能を追加 Amazon Q in Connect にて、CRM システム内の顧客データを使用して、パーソナライズされたガイダンスをエージェントに推奨する機能が追加されました。リアルタイムの音声から顧客の意図を検出するのに加えて、顧客データを理解した上で、エージェントがどのようなアクションを取るべきかを推奨します。顧客にパーソナライズされた対応によって、顧客満足度向上に繋げることができます。 プレビュー：Amazon Q Business が Smartsheet との統合をサポート Amazon Q Business が、エンタープライズ向け業務管理プラットフォームである Smartsheet との統合をサポートするようになりました。Smartsheet のデータを Amazon Q Business に同期することで、Smartsheet のプロジェクトやタスクに関する情報をAmazon Q Business に問い合わせることができます。本機能は、Amazon Q Business が利用可能なすべての AWS リージョンで利用できます。 Amazon Polly向けの4つの新しい音声合成を追加 Amazon Polly は、テキストを音声に変換するサービスです。今回、アメリカ英語とオーストラリア英語に対応した4つの新たな音声合成の一般提供を開始しました。より自然な発音やイントネーションを備えており、教育、出版、マーケティングなど、様々な産業や目的で使用が可能です。 Amazon Bedrock モデル評価機能が、カスタムモデルの評価に対応 Amazon Bedrock のモデル評価機能は、精度、堅牢性、有害性などの指標に対して基盤モデルを評価、比較することができる機能です。今回、ファインチューニングや継続事前学習による独自のカスタムモデルを評価できるようになりました。これにより、お客様はベースモデルの選択、カスタマイズ、評価、本番環境への移行という一連のサイクルを迅速に回すことができるようになりました。 対応リージョン についてはこちらをご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成AI と毎日戯れており、特にコード生成に注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 みなさんは「週刊AWS キャッチアップ」をご存じでしょうか？過去に一度紹介したことがあるのですが、この週刊AWSと週刊生成AI with AWSの内容を振り返るオンラインの勉強会です。実施回数は現時点で50回を超えていますから、1年以上も継続されていることになりますね。過去の内容はYoutubeでアーカイブされているのを見ることが出来ますし、参加されたい方はぜひ以下JAWS-UGのリンクから、次回スケジュールを確認してください。（木曜もしくは金曜の21時に実施されていますので、現時点では予告が出ていないかもしれません）。 – 週刊AWSキャッチアップ(Youtube再生リスト) – JAWS-UG それでは、先週の主なアップデートについて振り返っていきましょう。 2024年10月7日週の主要なアップデート 10/7(月) （この日は週刊AWSでとりあげるアップデートがありませんでした） 10/8(火) Amazon VPC Lattice is now available in 3 additional Regions – AWS Amazon VPC Lattice の利用可能リージョンが追加され、大阪リージョンでも利用可能になりました。Amazon VPC Lattice は、サービス間通信の接続、セキュリティ保護、モニタリングをシンプルに実現するアプリケーションネットワーキングサービスです。 Mountpoint for Amazon S3 CSI driver introduces new access controls for individual Kubernetes pods – AWS Mountpoint for Amazon S3 Container Storage Interface (CSI) ドライバーで、個々の Kubernetes Pod に個別の AWS ID およびIAM Roleの設定が可能になりました（以前は、Kubernetes クラスター内のすべてのポッド共通する１つのIAM Roleを設定する方式でした）。これにより、より細かい粒度で権限が設定可能になります。 Amazon OpenSearch Serverless introduces a suite of new features and enhancements – AWS Amazon OpenSearch Serverless に複数の新機能と拡張機能が追加されました。これには、ネストされたデータのより効率的な保存と検索を可能にするフラットオブジェクトデータ型、拡張された地理空間機能、多項集計(multi-term aggregation)等が含まれます。また、インデックス作成のレイテンシーの削減、昇順/降順の検索ソートの高速化等、全体的なパフォーマンスも向上しています。 Amazon Connect launches prompt customizations for Amazon Q in Connect – AWS Amazon Q in Connect はクラウドコンタクトセンターのAmazon Qに生成AIのアシスタント機能を追加するものです。今回の改善で、コンタクトセンターのスーパーバイザーが会社のブランドやビジネスガイドラインに合わせて、LLMプロンプトを事前設定できるようになりました。例えば特定の企業フレーズを取り入れたり、特定状況において固定応答を指定したりできます。 Extension of EOL Dates for Amazon Corretto 8 and 11 – AWS AWSが提供する、無料で利用可能な OpenJDK ディストリビューションのAmazon Corretto でサポート終了日(EOL)の延長が発表されました。Amazon Corretto 8 は、以前は2026年4月までだったものが、2030年12月に、Amazon Corretto 11は、以前は2027年9月だったものが、2032年の1月まで延長されており、安定したOpenJDKをより長く使っていただけるようになりました。 Announcing Amazon ElastiCache for Valkey – AWS Amazon ElastiCache で、OSSのインメモリデータベース Valkey が選択可能になりました。プロビジョン型、サーバーレスの両方から選択可能で、サーバーレスの方は他の提供エンジンと比較して33%低い料金が設定されています。 詳細はこちらのブログをご覧ください 。 Announcing Amazon MemoryDB for Valkey – AWS Amazon MemoryDB でも同様に Valkey が選択可能になりました。料金面では、書きこみが10TB/月未満は無料で利用でき、それを超えても$0.04/GBである等、既存エンジンより安価に提供されています。 詳細はこちらのブログをご覧ください 。 10/9(水) Amazon Bedrock Model Evaluation now supports evaluating custom models – AWS Amazon Bedrock のモデル評価（Model Evaluation）で、カスタムモデルも評価可能になりました。これにより、基礎となるモデルを選択し、カスタマイズして評価し、必要に応じて再度カスタマイズする、という評価のサイクルをより容易に実現可能になります。 AWS Lambda now detects and stops recursive loops between Lambda and Amazon S3 – AWS Lambda recursive loop detection (再帰ループ検出)で新たに、S3とLambda間のループを検出可能になりました。Lambda関数はS3のイベントを元に起動するよう設定できるため、Lambda関数の中で同じS3バケットにデータを置くと、再帰ループ（無限ループ）が発生してしまう可能性がありますが、これを検出して停止する等の設定が可能になりました。意図的に再帰ループさせたい場合はこの機能をオフにすることも可能です。詳細は こちらのドキュメントをご覧ください 。 10/10(木) Announcing general availability of Console to Code to generate code – AWS 管理コンソールで Console to Code 機能が利用可能になりました。名前の通り、コンソールの操作を記録して、CDKやCloudFormation等のコードに変換してくれる機能です。現時点では、Amazon EC2、Amazon VPC、Amazon RDSに対応しています。 詳細はこちらのドキュメントをご覧ください 。 10/11(金) Amazon Redshift announces generally availability for data sharing with data lake tables – AWS Amazon Redshift で data sharing with data lake tables 機能が一般提供開始（GA）になりました。これはS3上のデータを一種の外部表としてアクセスする機能を、LakeFormation経由で他Redshiftクラスターに共有可能にするものです。これにより、Redshiftクラスターそれぞれで個別にデータレイク(S3)上へのアクセス設定を行う必要がなくなります。 Cross-zone enabled Network Load Balancer now supports zonal shift and zonal autoshift – AWS AWS Network Load Balancer (NLB) で、Amazon Application Recovery Controller の zonal shift と zonal autoshift のサポートが強化されました。zonal shiftは、AZ内でのみルーティングすることで、他AZへの通信を行わないように制御する仕組みで、autoshiftと組み合わせることで、AZで大きな障害が発生した際、そのAZへルーティングをしないようにすることで、耐障害性を向上させることが可能になる機能です。今回の改善で、NLBでクロスゾーンの負荷分散を実行している環境においても、zonal shiftが利用可能になりました。詳細は こちらのブログを参照してください 。 Amazon CloudFront launches support for JA4 fingerprinting – AWS Amazon CloudFront で、Cloudfront-viewer-ja4-fingerprint ヘッダーに JA4 finger print のデータが渡されるようになりました。このJA4 fingerprintをサーバー上のカスタムロジックや、CloudFront Functions、Lambda @Edge を使用して検査、対応することが可能です。例えばマルウェアやBOTからのアクセスを検出するために利用可能です。 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

このブログは 2024 年 9 月 17 日に Kanishk Mahajan (Principal, Solutions Architect) と、NetApp の Michael Shaul 氏と Sasha Korman 氏によって共同執筆された内容を日本語化したものです。原文は こちら を参照してください。 生成 AI アプリケーションは、一般的に Retrieval Augmented Generation (RAG) と呼ばれる手法を使用して構築されます。RAG を使用することで、基礎モデル (FM) はトレーニングで使用されていない追加データへアクセスすることができます。このデータは、生成 AI プロンプトを強化するために使用され、FM を継続的に再トレーニングすることなく、よりコンテキスト固有で正確な応答を提供し、透明性を向上させ、ハルシネーションを最小限に抑えます。 このブログでは、 Amazon Bedrock と Amazon FSx for NetApp ONTAP を使用して、企業固有の非構造化ユーザーファイルデータを簡単、高速、かつ安全な方法で Amazon Bedrock に取り込み、AWS 上の生成 AI アプリケーションに RAG エクスペリエンスを提供するソリューションを紹介します。 今回のソリューションでは、FSx for ONTAP ファイルシステムを非構造化データのソースとして使用し、ユーザーの既存のファイルとフォルダー、および関連するメタデータを Amazon OpenSearch Serverless ベクトルデータベース に継続的に格納します。これにより、OpenSearch Serverless から取得した企業固有のデータを用いて生成 AI のプロンプトを強化し、Amazon Bedrock を活用した RAG シナリオを実現します。 RAG を使用して Q&A チャットボットなどの生成 AI アプリケーションを開発する場合、お客様はデータのセキュリティを維持し、エンドユーザーが許可されていないデータソースから情報を照会できないようにすることも懸念しています。今回のソリューションでは、FSx for ONTAP を使用して、ユーザーが現在のデータセキュリティとアクセスメカニズムを拡張し、Amazon Bedrock からのモデル応答に適用できるようにしています。FSx for ONTAP を関連メタデータのソースとして使用し、具体的には、ファイルとフォルダーに添付されたユーザーのセキュリティアクセスコントロールリスト (ACL) 構成を使用して、そのメタデータを OpenSearch Serverless に格納します。アクセス制御操作とファイルシステム上の新規データと変更されたデータを RAG アプリケーションに通知するファイルイベントを組み合わせることで、 FSx for ONTAP によって Amazon Bedrock が 生成 AI アプリケーションに接続する特定のユーザーに対して、承認されたファイルのみを使用できるようにする方法を示しています。 AWS のサーバーレスなサービスでは、自動スケーリング、高可用性、従量課金モデルが提供されるため、開発者は生成 AI アプリケーションの構築に集中しやすくなります。 AWS Lambda を使用したイベント駆動型コンピューティングは、ドキュメントの埋め込みや柔軟な大規模言語モデル (LLM) オーケストレーションなどのコンピューティング集約型のオンデマンドタスクに適しています。また、 Amazon API Gateway は、フロントエンドとの連携や LLM のイベント駆動型呼び出しを可能にする API インターフェイスを提供します。今回のソリューションでは、API Gateway と Lambda を使用して、Amazon Bedrock と FSx for ONTAP 上にスケーラブルで自動化された API 駆動型サーバーレスアプリケーションレイヤーを構築する方法も示しています。 ソリューションの概要 このソリューションは、 AWS Managed Microsoft AD のドメインに参加した ストレージ仮想マシン (SVM) を持つ、 FSx for ONTAP マルチ AZ 構成 のファイルシステムを使用します。OpenSearch Serverless ベクトル検索コレクションは、スケーラブルで高性能な類似検索機能を提供します。 Amazon Elastic Compute Cloud (Amazon EC2) Windows サーバーを FSx for ONTAP ボリュームの SMB/CIFS クライアントとして使用し、ボリューム内の SMB 共有に対してデータ共有と ACL を設定します。このデータと ACL を使用して、Amazon Bedrock を使用した RAG シナリオにおける埋め込みへのアクセス許可をテストします。 今回のソリューションにおける埋め込みコンテナコンポーネントは、EC2 Linux サーバーにデプロイされ、FSx for ONTAP ボリュームを NFS クライアントとしてマウントします。このコンポーネントは、既存のファイルとフォルダーをセキュリティ ACL 設定とともに定期的に OpenSearch Serverless に送信します。FSx for ONTAP ファイルシステム上の NFS 共有から、企業固有のデータ (および関連するメタデータと ACL) を OpenSearch Serverless ベクトル検索コレクションのインデックスに格納します。 加えて、このソリューションでは RAG 実装用に Lambda 関数を使用します。この関数は、埋め込みコンテナコンポーネントによって格納された OpenSearch Serverless インデックスから会社固有のデータと関連メタデータ (ACL を含む) を取得して、生成 AI プロンプトを強化することで、Amazon Bedrock による RAG を可能にします。また、この Lambda 関数は、ユーザーとの会話履歴を Amazon DynamoDB テーブルに保存します。 エンドユーザーは、チャットボットアプリケーションまたは API Gateway インターフェイスから直接、自然言語プロンプトを送信することでソリューションと対話します。チャットボットコンテナは Streamlit を使用して構築され、 AWS Application Load Balancer (ALB) が前面に配置されます。ユーザーは ALB を通してチャットボット UI に自然言語プロンプトを送信すると、チャットボットコンテナは API Gateway インターフェイスと対話し、RAG 取得 Lambda 関数を呼び出してユーザーの応答を取得します。ユーザーは、プロンプトリクエストを API Gateway に直接送信して応答を取得することもできます。ドキュメントへの権限ベースのアクセスを実証するために、ユーザーの SID を明示的に取得し、その SID をチャットボットまたは API Gateway リクエストで使用します。RAG 取得用の Lambda 関数は、SID をドキュメント用に構成された Windows ACL と照合します。本番環境での追加の認証手順として、ユーザーを ID プロバイダーに対して認証し、ユーザーをドキュメント用に構成されたアクセス許可と照合することもできます。 次の図は、今回のソリューションのフローを示しています。まず、FSx for ONTAP を使用してデータ共有と ACL を設定し、次にこれらを埋め込みコンテナで定期的にスキャンします。埋め込みコンテナはドキュメントをチャンクに分割し、Amazon Titan Embeddings モデルを使用してこれらのチャンクから埋め込んだベクトルを作成します。次に、OpenSearch Serverless のベクトル検索コレクションにインデックスを設定することで、これらの埋め込んだベクトルを関連するメタデータとともに保存します。次の図は、エンドツーエンドのフローを示しています。 次のアーキテクチャ図は、ソリューションの全体像を示しています。 前提条件 次の前提条件の手順を完了してください。 Amazon Bedrock でモデルにアクセス できることを確認する。このソリューションでは、Amazon Bedrock にて Anthropic Claude v3 Sonnet を使用する。 AWS コマンドラインインターフェイス (AWS CLI) をインストールする。 Docker をインストールする 。 Terraform をインストールする 。 ソリューションをデプロイする このソリューションは、 GitHub リポジトリ からダウンロードできます。リポジトリをクローンし、Terraform テンプレートを使用すると、すべてのコンポーネントが必要な構成でプロビジョニングされます。 このソリューションのリポジトリをクローンする。 sudo yum install -y unzip git clone https://github.com/aws-samples/genai-bedrock-fsxontap.git cd genai-bedrock-fsxontap/terraform terraform フォルダーから、Terraform を使用してソリューション全体をデプロイする。 terraform init terraform apply -auto-approve このプロセスは完了するまでに 15～20 分かかることがあります。完了すると、terraform コマンドの出力は次のようになります。 api-invoke-url = "https://9ng1jjn8qi.execute-api.<region>.amazonaws.com/prod" fsx-management-ip = toset ( [ "198.19.255.230" , ] ) fsx-secret-id = "arn:aws:secretsmanager:<region>:<account-id>:secret:AmazonBedrock-FSx-NetAPP-ONTAP-a2fZEdIt-0fBcS9" fsx-svm-smb-dns-name = "BRSVM.BEDROCK-01.COM" lb-dns-name = "chat-load-balancer-2040177936.<region>.elb.amazonaws.com" データを読み込み、権限を設定する ソリューションをテストするには、FSx for ONTAP ボリュームにおいて SMB/CIFS クライアントである EC2 Windows サーバー ( ad_host ) を使用してサンプルデータを共有しユーザー権限を設定します。これらはのちに、埋め込みコンテナコンポーネントによって OpenSearch Serverless インデックスに格納されます。FSx for ONTAP SVM データボリュームをネットワークドライブとしてマウントし、この共有ネットワークドライブにデータをアップロードして Windows ACL に基づいて権限を設定するには、次の手順を実行します。 Terraform テンプレートの出力から ad_host インスタンスの DNS を取得します。 AWS コンソールで AWS Systems Manager Fleet Manager に移動し、 ad_host インスタンスを見つけて、 リモートデスクトップでログイン します。その際、ドメイン管理者ユーザー bedrock-01\Admin に対応するパスワードを AWS Secrets Manager から取得します。パスワードは、Terraform テンプレートの出力から Secrets Managerの項目で fsx-secret-id のシークレット ID を使用して見つけます。 FSx for ONTAP データ ボリュームをネットワークドライブとしてマウントするには、[ This PC ] の下で [ Network ] を選択 (右クリック) し、[ Map Network drive ] を選します。 ドライブを選択し、マウントに FSx for ONTAP 共有パス (\\<svm>.<domain >\c$\<volume-name>) を使用します。 Amazon Bedrock ユーザーガイド を共有ネットワークドライブにアップロードし、管理者ユーザーのみにアクセス権限を設定します ( [ Advanced ] で継承が無効になっていることも確認します)。 FSx for ONTAP ユーザーガイド を共有ドライブにアップロードし、権限が [ Everyone ] に設定されていることを確認します。 ad_host サーバー上で コマンド プロンプトを開き、次のコマンドを入力して管理者ユーザーの SID を取得します。 wmic useraccount where name = 'Admin' get sid チャットボットを使用して権限をテストする チャットボットを使用して権限をテストするには、Terraform テンプレートの出力から lb-dns-name の URL を取得し、Web ブラウザからアクセスします。 プロンプトクエリでは、誰でもアクセスできるように設定した FSx for ONTAP ユーザーガイドに関する一般的な質問をします。例えば「FSx for ONTAP ファイルシステムを作成するにはどうすればよいですか」と質問すると、モデルは、AWS マネジメントコンソール、AWS CLI、または FSx API を使用して FSx for ONTAP ファイルシステムを作成するための詳細な手順と出典をチャットウィンドウに返信しました。 次に、管理者アクセスのみが利用できる Amazon Bedrock ユーザーガイドに基づいて質問してみましょう。この例では、「Amazon Bedrock で基盤モデルを使用する方法」を質問したところ、モデルは質問に詳細な回答を提供するには情報が不十分であると返答しました。 チャット UI のユーザー (SID) フィルター検索で管理者 SID を使用し、同じ質問をします。するとモデルは Amazon Bedrock で FM を使用する方法の詳細手順を返信し、応答にはモデルが使用した出典が含まれています。 API Gateway を使用して権限をテストする API Gateway を使用してモデルを直接クエリすることもできます。Terraform テンプレートの出力から api-invoke-url パラメータを取得します。 curl -v '<api-invoke-url>/bedrock_rag_retreival' -X POST -H 'content-type: application/json' -d '{"session_id": "1","prompt": "What is an FSxN ONTAP filesystem?", "bedrock_model_id": "anthropic.claude-3-sonnet-20240229-v1:0", "model_kwargs": {"temperature": 1.0, "top_p": 1.0, "top_k": 500}, "metadata": "NA", "memory_window": 10}' 次に、FSx for ONTAP ユーザー ガイドに関連するクエリについて、全員からのアクセスで API Gateway を呼び出します。これを行うには、metadata パラメータの値を NA にして、全員からのアクセスを指定します。 curl -v '<api-invoke-url>/bedrock_rag_retreival' -X POST -H 'content-type: application/json' -d '{"session_id": "1","prompt": "what is bedrock?", "bedrock_model_id": "anthropic.claude-3-sonnet-20240229-v1:0", "model_kwargs": {"temperature": 1.0, "top_p": 1.0, "top_k": 500}, "metadata": "S-1-5-21-4037439088-1296877785-2872080499-1112", "memory_window": 10}' クリーンアップ 繰り返し課金されないようにするには、ソリューションを試した後、アカウントをクリーンアップしてください。terraform フォルダーから、ソリューションの Terraform テンプレートを削除します。 terraform apply --destroy まとめ この記事では、Amazon Bedrock と FSx for ONTAP を組み合わせたソリューションを紹介しました。FSx for ONTAP のファイル所有権と ACL を使用して、生成 AI アプリケーションの RAG シナリオで権限ベースのアクセスを提供します。このソリューションを使用すると、Amazon Bedrock で生成 AI アプリケーションを構築し、FSx for ONTAP ファイルシステムから企業固有の非構造化ユーザーファイルデータを使用して Amazon Bedrock の生成 AI プロンプトを強化できます。このソリューションにより、より関連性が高く文脈に即した正確な応答を提供できると同時に、承認されたユーザーのみがそのデータにアクセスできるようになります。さらにこのソリューションでは、FSx for ONTAP と Amazon Bedrock と一緒に AWS のサーバーレスサービスを使用することで、生成 AI アプリケーションの自動スケーリング、イベント駆動型コンピューティング、API インターフェイスを実現する方法、それぞれを示しています。 Amazon Bedrock と FSx for ONTAP の詳細については、次のリソースを参照してください。 Amazon Bedrock ワークショップ GitHub リポジトリ Amazon FSx for NetApp ONTAP ファイルストレージワークショップ NetApp helps customers unlock the full potential of GenAI with BlueXP workload factory and Amazon Bedrock 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Solutions Architect 吉澤が担当しました。 About the authors Kanishk Mahajan は、AWS の Principal, Solutions Architect です。AWS の ISV 顧客およびパートナー向けのクラウド変革とソリューション アーキテクチャをリードしています。Kanishk は、コンテナ、クラウド運用、移行とモダナイゼーション、AI/ML、回復力、セキュリティ、コンプライアンスを専門としています。彼は AWS においてこれらの領域の Technical Field Community (TFC) メンバーでもあります。 Michael Shaul は、NetApp の CTO オフィスの Principal Architect です。データ管理システム、アプリケーション、インフラストラクチャ ソリューションの構築に 20 年以上携わっており、クラウドテクノロジー、ビルダー、AI ソリューションに関して独自の深い視点を持っています。 Sasha Korman は、イスラエルとインドにまたがるダイナミックな開発および QA チームの技術リーダーです。プログラマーとして NetApp に入社して 14 年間のキャリアを持つ彼の実践的な経験とリーダーシップは、イノベーション、スケーラビリティ、信頼性を重視しながら複雑なプロジェクトを成功に導く上で極めて重要な役割を果たしてきました。

本ブログは 2024 年 2 月 22 日に公開された Blog ” AWS Customer Compliance Guides now publicly available ” を翻訳したものです。 AWS グローバルセキュリティ＆コンプライアンスアクセラレーション (GSCA) プログラム が、 AWS カスタマーコンプライアンスガイド (CCG) をリリースしました。CCG は、 AWS コンプライアンスのリソース ページから取得できます。業界をリードするコンプライアンスフレームワークが AWS セキュリティドキュメント とセキュリティのベストプラクティスにどのようにマッピングされているかを、お客様、 AWS パートナー 、および評価者が迅速に理解するのに役立ちます。 CCG は、130 を超える AWS サービスや機能に対して、16 の異なるコンプライアンスフレームワークにマッピングされたセキュリティガイダンスを提供します。お客様は、利用可能なフレームワークとサービスを選択し、コンプライアンスの観点を通して「クラウド内」のセキュリティが AWS サービスにどのように適用されるかを確認できます。 CCG は、AWS サービスの構成オプションに関連するセキュリティトピックと技術的管理策に重点を置いています。これらのガイドは、AWS サービス全体で一貫しているセキュリティトピックや管理策、あるいはポリシーやガバナンスなどお客様組織特有のものは扱いません。その結果、ガイドはより簡潔で、各 AWS サービスに特有のセキュリティとコンプライアンスの考慮事項に重点が置かれるようになりました。 ガイドに関するフィードバックを大切にしています。 アンケート にご回答いただき、あなたのご意見をお聞かせください。また、新しいサービスやフレームワークのリクエスト、改善の提案もお待ちしています。 CCG (Control-Based Cloud Configuration Guide) は、AWS サービスのユーザーガイドの要約を提供し、構成ガイダンスを以下のフレームワークのセキュリティ統制要件にマッピングします。 米国国立標準技術研究所 (NIST) SP 800-53 NIST サイバーセキュリティフレームワーク (CSF) NIST SP 800-171 System and Organization Controls (SOC) II Center for Internet Security (CIS) Critical Controls v8.0 ISO 27001 北米電力信頼性協議会 (NERC) 重要インフラ保護 (CIP) クレジットカード業界データセキュリティ基準 (PCI DSS) v4.0 米国防総省サイバーセキュリティ成熟度モデル認証 (CMMC) 医療保険の相互運用性と説明責任に関する法律（HIPAA） カナダサイバーセキュリティセンター (CCCS) ニューヨーク州金融サービス局 (NYDFS) 米国連邦金融機関検査協議会 (FFIEC) クラウドコントロールマトリクス (CCM) v4 情報セキュリティマニュアル (ISM) (オーストラリア) 政府情報システムのためのセキュリティ評価制度 (ISMAP) (日本) CCG は、以下の方法でお客様を支援できます： AWS ユーザーガイドを手動で検索して「クラウド内」のセキュリティ詳細を理解し、構成ガイダンスをコンプライアンス要件に合わせるプロセスを短縮します お客様のワークロードで実行されている AWS サービスに基づいて、リスク評価や監査に適用される統制の範囲を決定します 組織での使用を検討している新しい AWS サービスについて、デューデリジェンス評価を実施するお客様を支援します 評価者やリスクチームに、AWS サービスのセキュリティ統制範囲と、お客様が実装する責任のある統制範囲を特定するためのリソースを提供します。これにより、評価や内部セキュリティチェックに必要なエビデンスの範囲が影響を受ける可能性があります 様々なコンプライアンス文書要件を満たすため、または評価エビデンス要求に応えるために必要となる可能性のある、統制対応や手順などのセキュリティ文書を作成するための基礎を提供します AWS グローバルセキュリティ＆コンプライアンスアクセラレーション (GSCA) プログラム は、時間とコストの削減を支援することで、AWS 上でコンプライアンスに準拠したワークロードの構築を導き、自動化し、加速するのに役立つお客様を AWS パートナーとつなぎます。GSCA は、医療、プライバシー、国家安全保障、金融セクターのセキュリティ、プライバシー、コンプライアンス要件を満たす必要があるグローバルに企業をサポートしています。GSCA コンプライアンススペシャリストとつながるには、 GSCA プログラムのアンケート にご記入ください。 このブログに関するご意見やご感想がある場合は、以下の コメント セクションにコメントをお寄せください。このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Kevin Donohue Kevin は AWS ワールドワイドパブリックセクターのシニアセキュリティパートナーストラテジストで、顧客のコンプライアンス目標達成を支援することを専門としています。Kevin は 2019 年に AWS に入社し、AWS セキュリティアシュアランスで米国政府顧客をサポートしてきました。バージニア州北部を拠点とし、仕事以外では妻と娘と一緒に屋外で過ごすことを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました

本ブログは 2024 年 8 月 19 日に公開されたBlog ” Announcing AWS KMS Elliptic Curve Diffie-Hellman (ECDH) support ” を翻訳したものです。 データ保護のために暗号化をする場合、プロトコル設計者は通常、その速度と効率性から対称鍵アルゴリズムを好みます。しかし、インターネットのような信頼されていないネットワーク上でデータを交換する場合、 交換する当事者のみ が同じ鍵を知ることができるようにするのは難しくなります。非対称鍵ペアとアルゴリズムは、公開鍵を信頼されていないネットワーク上で共有できるようにすることで、この問題の解決に役立ちます。そして、鍵共有方式を使用することで、2 つの当事者は、自身の秘密鍵と相手の公開鍵を組み合わせて、同じ共有シークレットを導出できます。 AWS Key Management Service (AWS KMS) が、 楕円曲線 (ECC) KMS キーによる楕円曲線ディフィー・ヘルマン (ECDH) 鍵共有をサポート するようになったことを発表できることを嬉しく思います。新しい DeriveSharedSecret API アクションを使用することで、2 つの当事者間が導出された共有シークレットを使用して安全な通信チャネルを確立できるようになります。 このブログでは、新しい API アクションの概要を説明し、公開鍵のみを交換して共有シークレットを導出することで、安全な通信を確立する方法を解説します。次に、2 つの当事者間で共有シークレットを導出するために AWS KMS と OpenSSL を使用する方法を示すコマンド例を紹介します。 この新しい DeriveSharedSecret API アクションにより、お客様は相手方の公開鍵と AWS KMS 内に存在する秘密鍵を組み合わせて、共有シークレットを導出できます。この共有シークレットは、鍵導出関数 (KDF) を使用して対称暗号化鍵を作成するために使用できます。お客様は、この対称暗号化鍵を使用して、ローカルのアプリケーション内でデータを暗号化できます。 この相手方は、自身の対応する秘密鍵と AWS KMS のお客様の対応する公開鍵を組み合わせて、同じ共有シークレットを導出することができます。 2つの当事者が同じ共有シークレットを持つようになったので、交換するデータの暗号化と復号に使用できる対称暗号化鍵を生成できます。 DeriveSharedSecret は、お客様がアプリケーション内から自身の秘密鍵を使用するためのシンプルで安全な方法を提供します。これにより、楕円曲線統合暗号化方式 (ECIES) やエンドツーエンド暗号化方式 (E2EE) など、AWS KMS で保護されたキーを使用した新しい非対称暗号のユースケースが可能になります。 AWS KMS DeriveSharedSecret の概要 AWS KMS API リファレンスドキュメント では、 DeriveSharedSecret API アクションについて、さらに詳細に説明しています。次のステップは、API アクションの操作方法に関する大まかな説明です。 キーのタイプに非対称、キーの使用方法に キーアグリーメント (鍵共有) を選択し、サポートされているキー仕様を 1 つ選び、楕円曲線 (ECC) KMS キーを作成します。既存の ECC キーをキーアグリーメント用に変更することはできません。 相手方に、あなたの KMS キーに定義したキー仕様に一致する ECC キーを作成してもらいます。 既存の GetPublicKey API アクションを使用して、KMS キーに関連付けられた公開鍵を取得します。 信頼できる方法を通じて、相手方と公開鍵を交換します。 DeriveSharedSecret では、公開鍵を base64 エンコードされた DER 形式にしてください。 相手方の公開鍵と、指定した キーアグリーメント 用キーを、入力値として使用して共有シークレットを導入します。AWS KMS が現時点でサポートする鍵共有アルゴリズムは ECDH です。 相手方は、AWS KMS から取得した公開鍵と、生成した ECC キーペアに関連付けられた秘密鍵を使用して、共有シークレットを導出します。 前述のステップの結果、両者は秘密情報を交換することなく同じ出力を得ることができます。2 つの当事者の間で交換されたのは公開鍵のみです。 DeriveSharedSecret の出力は未加工の共有シークレットです。この共有シークレットは楕円曲線上の点の積であり、暗号鍵に必要なバイト数をはるかに超える可能性があります。暗号鍵をこの共有シークレットから導出するために、 米国国立標準技術研究所 (NIST) SP800-56A Rev. 3 のセクション 5.8 のガイダンスに従って、KDF (鍵導出関数) を使用することをお勧めします。 本ブログでは、 AWS CLI と OpenSSL コマンドラインを使用してこの手順を説明します。AWS Encryption SDK は本ブログでは詳しく説明しませんが、お客様のためのベストプラクティスを組み込んでいますので、 AWS KMS ECDH キーリング もあわせてご確認ください。 ユースケース例 ECDH 鍵共有を使用したい例として、エンドツーエンド暗号化が挙げられます。セキュアな通信のためのフレームワークを提供するプロトコルは存在しますが（例えば AWS Wickr 内など）、ここではこれらのプロトコルの背後にある簡略化された主要なステップを紹介します。この例では、Alice と Bob は両方ともメッセージングネットワークの一部です。 このネットワークは中央管理型のサービスによって管理されており、このサービスは Alice や Bob の暗号化されていないメッセージにアクセスできてはいけません。 図 1 ：ユースケース例で説明されているサービスの高レベルアーキテクチャ 図 1 に示すように、Alice と Bob はそれぞれ ECC キーペアを持ち、以下のステップで ECDH を使用して共有シークレットの導出を行います： Alice は、中央集中型キーストレージサービスに自身の公開鍵を登録します。キーストレージサービスの詳細な説明は、このブログでは扱いません。 Bob は、AWS KMS ユーザーであるため、AWS KMS の GetPublicKey アクションを呼び出して、ECC KMS キーペアの公開鍵を取得します。 Bob は、同じ中央集中型キーストレージサービスに自身の公開鍵を登録します。 Aliceは、Bob と暗号化されたメッセージを交換するために、中央集中型キーストレージサービスから Bob の公開鍵を取得します。 Bob は、Alice が彼とコミュニケーションを取りたがっていることを通知され、中央集中型キーストレージサービスから Alice の公開鍵を取得します。 Alice は、Bob の公開鍵と自身の秘密鍵を使用して、自身の暗号プロバイダーを利用して共有シークレットを導出します。 Bob は、Alice の公開鍵と自身の秘密鍵を使用して、 DeriveSharedSecret を利用して共有シークレットを導出します。 Alice と Bob は、同一の共有シークレットを持つことになります。この共有シークレットから、適切な KDF を使用して対称暗号化鍵を作成できます。この暗号鍵を使用して、Bob に送信可能な暗号文を作成できます。 ユースケース例の詳細な解説 AWS KMS を使用して ECDH 用の KMS キーを作成し、共有シークレットを導出するには、以下の手順を使用できます。説明のために、例として挙げたユースケースでは、ユーザー Alice は暗号化ツールとして OpenSSL を使用しています。以下に、AWS KMS ユーザーの Bob と OpenSSL ユーザーの Alice が、お互いの公開鍵を使用して共有シークレットを導出する方法を説明します。 一般的な前提条件 このサンプルソリューションを実装するには、以下の前提条件を満たしている必要があります： AWS CLI — 最新バージョンを推奨します。ここでの例では aws-cli/2.15.40 および aws-cli/1.32.110 を使用しています。 OpenSSL — ここでの例では OpenSSL 3.3.0 を使用しています。 両当事者（この例で使用するユースケースの Alice と Bob）が同じ楕円曲線暗号の ECC キーを持っています。次のセクション キー作成の事前準備 のステップで、これらのキーの作成方法を説明します。 キー作成の前提条件 Alice と Bob は、鍵生成時に同じ楕円曲線暗号を使用する必要があります。 DeriveSharedSecret API オペレーションは、ECC_NIST_P256、ECC_NIST_P384、ECC_NIST_P521 の楕円曲線に対応しており、これらは OpenSSL ではそれぞれ P-256、P-384、P-521 に対応します。AWS KMS がサポートする楕円曲線は、米国国立標準技術研究所 (NIST) によって承認された暗号化アルゴリズムです。AWS 中国リージョン の AWS KMS は SM2 キー仕様のみサポートしています。 Bob は鍵共有の目的で KMS の非対称キーを作成 Bob は AWS KMS で CreateKey API アクションを使用してキーペアを作成します。次の例では、Bob は KeySpec パラメータに ECC_NIST_P256 を、 KeyUsage パラメータに KEY_AGREEMENT を指定して ECC キーペアを作成します。 aws kms create-key \ --key-spec ECC_NIST_P256 \ --key-usage KEY_AGREEMENT \ --description "Example ECDH key pair" レスポンスは以下のようになります： { "KeyMetadata": { "AWSAccountId": "111122223333", "KeyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "Arn": "arn:aws:kms:us-east-1:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "CreationDate": "2024-06-25T13:06:24.888000-07:00", "Enabled": true, "Description": "Example ECDH key pair", "KeyUsage": "KEY_AGREEMENT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "ECC_NIST_P256", "KeySpec": "ECC_NIST_P256", "KeyAgreementAlgorithms": [ "ECDH" ], "MultiRegion": false } } ドキュメントの 非対称 KMS キーの作成 では、 AWS マネジメントコンソール を使用して、上記 CLI で作成した同じプロパティを持つ KMS キーペアを作成する方法が説明されています。このサンプルでは、デフォルトの KMS キーポリシー を持つ KMS キーを作成しますが、お使いの環境に適した最小権限の原則に従って、キーポリシーを確認し、設定することを推奨します。 注: KMS キーが作成されると、アカウント内のアクティビティを監視し記録するサービスである AWS CloudTrail によってログに記録されます。AWS KMS サービスへの API コールは CloudTrail にログとして記録され 、これを使用して KMS キーへのアクセスを監査できます。 KMS キーを KeyId の値ではなく人間が読みやすい文字列で識別できるようにするために、 KMS キーにエイリアスを作成 できます（ target-key-id の値 a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 を、ご自身の KeyId の値に置き換えてください）。エイリアスにより、KMS キーをより簡単に使用・管理できるようになります。 Bob は以下の CLI コマンドを使用して、KMS キーのエイリアスを作成します： aws kms create-alias \ --alias-name alias/example-ecdh-key \ --target-key-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 Alice は OpenSSL を使用して、鍵共有のための ECC 鍵を作成 OpenSSL の ecparam および genkey オプションを使用して、Alice は P-256 ECC キーを作成します。P-256 楕円曲線は、AWS KMS では ECC_NIST_P256 となります。 注: ECDH が機能するためには、OpenSSL の ECC キーの楕円曲線が、相手方（この例では Bob）が作成した ECC KMS キーと同じ楕円曲線暗号である必要があります。 openssl ecparam -name P-256 \ -genkey -out openssl_ecc_private_key.pem 以上で、事前準備のキー作成は完了です。 鍵交換と共有シークレット導出プロセス このセクションでは、Alice と Bob は公開鍵を共有し、お互いの公開鍵を取得し、同じ共有シークレットを導出する手順を概説します。Alice と Bob それぞれが導出した共有シークレットを比較し、両者が同じ共有シークレットを導出したことを説明します。 ステップ 1: Alice による OpenSSL 公開鍵の生成と中央サービスへの登録 AWS KMS では 公開鍵は DER 形式ある必要があります。そのため、この例では Alice は自身の ECC 秘密鍵を使用して、以下の CLI コマンドで DER 形式の公開鍵を作成します。 openssl ec -in openssl_ecc_private_key.pem \ -pubout -outform DER \ > openssl_ecc_public_key.bin.der 生成されたファイルの openssl_ecc_public_key.bin.der は DER 形式の公開鍵です。Alice はこれを中央集中型キーストレージサービスに保存する(または通信したい相手に送信する)ことができます。中央集中型キーストレージサービスの詳細については、このブログでは扱いません。 ステップ 2: Bob が ECC KMS キーの公開鍵を取得 Bob は、ECC KMS キーの公開鍵を取得するために、 GetPublicKey API アクションを使用します。Bob は、以下のように AWS CLI コマンド get-public-key を使用してこの API を呼び出します。 aws kms get-public-key \ --key-id alias/example-ecdh-key \ --output text \ --query PublicKey | base64 --decode > kms_ecdh_public_key.der AWS CLI コマンドで PublicKey をクエリした値は、DER 形式の X.509 公開鍵で、可読性のために base64 でエンコードされています。この base64 エンコードされた値を base64 コマンドでデコードし、デコードされた値を、ファイル kms_ecdh_public_key.der に出力しています 注: Boto3 などの AWS SDK のいずれかを使用してこの API を呼び出す場合、返される PublicKey の値は base64 エンコードされていません。 このユースケース例では、Alice は OpenSSL を使用しており、PEM 形式の公開鍵が必要です。Bob は、次のコマンドを用いて DER 形式の公開鍵を PEM 形式に変換します。 openssl ec -pubin -inform DER -outform PEM \ -in kms_ecdh_public_key.der \ -out kms_ecdh_public_key.pem kms_ecdh_public_key.pem ファイルは、PEM 形式の公開鍵です。 ステップ 3: Bob が公開鍵を中央集中型キーストレージサービスに登録 Bob は、ステップ 2 で取得した PEM 形式の公開鍵を、中央集中型キーストレージサービスに保存します。 ステップ 4: Alice が共有シークレット導出のために Bob の公開鍵を取得 ECDH 鍵共有を実行するには、関係する 2 つの当事者 (この例では Alice と Bob) が互いに公開鍵を交換する必要があります。Alice は、Bob に暗号化されたメッセージを送信するために、中央集中型キーストレージサービスから Bob の公開鍵を取得します。 Bob の公開鍵である kms_ecdh_public_key.pem は、すでに OpenSSL が想定する PEM 形式になっています。 ステップ 5: Bob が共有シークレット導出のために Alice の公開鍵を取得 ECDH 鍵共有を実行するには、関係する 2 つの当事者、Alice と Bob が互いに公開鍵を交換する必要があります。Bob は Alice が彼と通信したいという通知を受け取り、中央集中型キーストレージサービスから Alice の公開鍵を取得します。 Alice の公開鍵である openssl_ecc_public_key.bin.der は、AWS KMS が想定する DER 形式にすでになっています。 ステップ 6: Alice による OpenSSL を使用した共有シークレットの導出 Alice は、自身の秘密鍵と Bob の公開鍵を使用して、OpenSSL で共有シークレットを導出できます。Alice は、OpenSSL の pkeyutl コマンドの derive オプションを使用して共有シークレットを導出します openssl pkeyutl -derive \ -inkey openssl_ecc_private_key.pem \ -peerkey kms_ecdh_public_key.pem > openssl.ss openssl.ss ファイルには、共有シークレットがバイナリ形式で格納されます。 ステップ 7: Bob による AWS KMS を使用した共有シークレットの導出 Bob は、自身の秘密鍵 (AWS KMS 内で安全に保管されています) と Alice の公開鍵を使用して、AWS KMS を通じて共有シークレットを導出できます。以下は、Bob が AWS CLI コマンド derive-shared-secret を使用して DeriveSharedSecret API アクションを実行する例です。現時点のサポートされている鍵共有アルゴリズムは ECDH です。 PublicKey パラメータには Alice の公開鍵を渡します。 aws kms derive-shared-secret \ --key-id alias/example-ecdh-key \ --public-key fileb://path/to/openssl_ecc_public_key.bin.der \ --key-agreement-algorithm ECDH \ --output text --query SharedSecret | base64 --decode > kms.ss AWS CLI を使用すると、返された SharedSecret の値は可読性のために base64 エンコードされています。 base64 --decode コマンドを使用して、デコードされたバイナリ形式をファイルに保存します。 注: Boto3 などの AWS SDK のいずれかを使用してこの API を呼び出す場合、返される SharedSecret の値は base64 エンコードされていません。 kms.ss ファイルには、バイナリ形式で共有シークレットが含まれます。 ステップ 8: Alice が共有シークレットと適切な KDF を使用して、Bob への通信を暗号化するための暗号鍵を導出 次のコマンドを使用してステップ 6 と 7 でそれぞれ導出した共有シークレットの 2 つのファイルを比較し、同一であることを確認します diff -qs openssl.ss kms.ss これらのファイルが同一であることから、AWS KMS と OpenSSL の両方を使用して同じシークレットが導出されたことがわかります。 次のステップとして、共有シークレットを使用して、Alice は適切な 鍵導出関数 (KDF) を用いて対称暗号化鍵を導出します。この対称暗号化鍵を使用してデータを暗号化し、暗号文を Bob に送信します。 このブログでは、対称暗号化鍵を導出するステップについては説明しません。これは、ユースケースによっては複雑なトピックになる可能性があるためです。ただし、生の共有シークレットは均一ではないため、暗号鍵として使用しないでください。共有シークレットには多くのエントロピーがありますが、バイト文字列自体はランダムではありません。 NIST は、生の共有シークレット ( NIST SP800-56A Rev. 3 のセクション 5.8 で説明されている値 Z) に対して KDF を使用することを推奨しています。推奨される KDF については、 NIST SP800-56C Rev. 2 でより詳細に説明されています。その一例として、OpenSSL Single Step KDF (SSKDF) EVP_KDF-SS がありますが、この KDF を使用する際は、 FixedInfo などの他の値を慎重に選択する必要があります。 お客様が共有シークレットに対して使用する適切な KDF を選択できるよう、AWS Encryption SDK に AWS KMS ECDH キーリング が追加されました。キーリングは、コード内に実装する AWS Encryption SDK 内の構成要素です。キーリングは、データを保護するためのベストプラクティスを適用しながら、暗号鍵の管理を処理します。キーリングを使用して、鍵交換のための KMS キーを参照し、データを暗号化する関数を呼び出すことができます。データは NIST の推奨に従って導出された共有ラッピングキーを使用して暗号化され、Encryption SDK は暗号文に キーコミットメント を適用します。 まとめ このブログでは、2024 年 8 月に一般利用が開始された DeriveSharedSecret API アクションを使用して、安全に共有シークレットを導出する方法を紹介しました。信頼できないネットワーク上で秘密情報を共有することなく、2 つの当事者間で ECDH を使用する方法を説明しました。AWS CloudTrail ログを通じて AWS KMS キーの使用状況を追跡こともできます。共有シークレットから対称暗号化鍵を生成するには、KDF を使用する必要があることを述べました。データの暗号化には AWS Encryption SDK の使用を強くお勧めします。これは、対称暗号化鍵の生成に推奨される NIST の鍵導出関数 (KDF) を確実に使用します。 この投稿に関するフィードバックがある場合は、以下の コメント セクションにコメントを投稿してください。この投稿に関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Patrick Palmer Patrick は AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。世界中のお客様が AWS サービスを安全に使用できるよう支援し、暗号技術を専門としています。仕事以外では、成長する家族と過ごす時間とビデオゲームを楽しんでいます。 Raj Puttaiah Raj は AWS KMS のソフトウェア開発マネージャーです。運用の卓越性に焦点を当てて、AWS KMS の機能開発をリードしています。仕事以外では、ワシントン州の美しい自然の中で家族とハイキングを楽しんだり、2 人の息子の活動に同行したりして時間を過ごしています。 Michael Miller Michael はアイルランドを拠点とする AWS のシニアソリューションアーキテクトです。英国とアイルランドの公共部門のお客様のクラウド導入を加速させるのを支援し、セキュリティとネットワーキングを専門としています。以前の役職では、サービスプロバイダー、コンサルティング、金融サービス組織など、さまざまな分野でのアーキテクチャ設計と実装支援を担当してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2024/09/09 に投稿された Life Sciences Industry Guide to AWS re:Invent 2024 | AWS for Industries  を翻訳した記事です。 2024 年は、ヘルスケアとテクノロジーの岐路に立つイノベーションにとって歴史の残る年となります。 AWS re:Invent 2024 が近づくにつれ、業界のパイオニアと AWS の専門家が、生成 AI、機械学習、高度なデータ戦略によって促進されるテクノロジー、ユースケース、ブレークスルーを紹介する態勢を整えています。 2024 年 12 月 2 日から 6 日にかけてラスベガスで開催される今年のカンファレンスは、何百ものセッションにわたる豊富な知識を提供します。「2024 年：生成 AI の成果の年」をテーマにした Healthcare and Life Sciences (HLS) industry track  では、Merck, Geisinger, Gilead, Natera, Elevance Health などの業界リーダーからの洞察を取り上げます。 Come learn and build with us! 参加は こちらから登録 していただけます。 AWS re: Invent に参加すると、このようなことができます： 生成 AI を実際のヘルスケア・ライフサイエンスユースケースに適用して、ビジネスの様々な側面を変革するスキルを身につける ヘルスケア・ライフサイエンス向け専用の最新のソリューションについて知る AWS の専門家や同業他社とのネットワーキングを行う 今すぐ組織に適用できる、実用的な知識やベストプラクティスを学び持ち帰る 週の締めくくりには、最高のテクノロジーパーティーで成果を祝いましょう！ 参加に興味が湧いてきましたか？参加のためには次のことを行ってください： re: Invent についてより詳しく知るためには、 re:Invent website  を参照してください HLS Industry guide を確認し、関心のあるセッションを特定、アジェンダを計画しましょう   HLS Pavilion at the re:Invent Expo Hall ( Venetian Hall B ) を訪れて、最新の生成 AI デモを体験してください。また、2人の非常に特別な小児患者によってデザインされた限定版のピンを手に入れましょう！ おすすめセッション：ライフサイエンス ここからは、ライフサイエンスセッション参加者向けに厳選されたセッションをご覧ください。おすすめヘルスケアセッションについては、 healthcare industry guide to AWS re:Invent 2024  をご覧ください。 イノベーショントーク イノベーショントークでは、AWS の専門家がデータ、生成 AI、クラウド運用、モダナイゼーションなどの重要なトピックについて意見を交わします。 HLC201-INT | Accelerating healthcare & life sciences innovation with generative AI（生成 AI によるヘルスケアとライフサイエンスのイノベーションの加速） 12/5 (木) 12:30 PM – 1:30 PM (太平洋標準時) | Venetian, Level 5, Palazzo Ballroom B ブレイクアウトセッション ブレイクアウトセッションでは 60 分の講義形式のセッションを行います。この幅広い魅力は多くの聴衆に配信されます。セッションは録画されるため、見逃した場合は、re: Invent の後にオンデマンドで視聴できます。 HLS215 | How Merck improves drug design with biological foundation models）（Merck が生物学的基盤モデルを使用して医薬品設計を改善する方法） 12/3 (火) 12:00 PM – 1:00 PM (太平洋標準時) | Wynn, Upper Level, Cristal 7 HLS206 | Scale clinical diagnostic operations: Natera’s genomic innovation（大規模な臨床診断業務：Natera のゲノムイノベーション） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Wynn, Level 1, Latour 2 IOT204-S | Transform troubleshooting in manufacturing with AWS gen AI services (sponsored by Cognizant)（AWS 生成 AI サービスで製造業のトラブルシューティングを変革しましょう） 12/2 (月) 11:30 AM – 12:30 PM (太平洋標準時) | Venetian, Level 3, Murano 3305 MAM214 | Gilead Sciences: Executing a large-scale VMware transformation on AWS（Gilead Sciences：AWS での大規模な VMware トランスフォーメーションの実行） 12/2 (月) 4:30 PM – 5:30 PM (太平洋標準時) | MGM, Level 1, Grand 122 BIZ220 | How Moderna Is building a healthier supply chain（Moderna 社がより健全なサプライチェーンを構築する方法） 12/2 (月) 2:30 PM – 3:30 PM (太平洋標準時) | MGM, Level 3, Chairmans 366 CMP203 | Drive innovation and results with high performance computing on AWS（AWS でのハイパフォーマンスコンピューティングによるイノベーションと成果の促進） 12/3 (火) 12:00 PM – 1:00 PM (太平洋標準時) | Venetian, Level 3, Lido 3002 PRO203 | Merck advances healthcare data extraction using text-to-SQL on AWS（Merck、AWS で text-to-SQL 変換で医療データ抽出を推進） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | MGM, Level 3, Premier 318 PRO302 | Gilead Sciences: Operational excellence for cloud, data, and AI/ML（Gilead Sciences：クラウド、データ、AI/ML のオペレーショナル・エクセレンス） 12/4 (水) 10:00 AM – 11:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 232, Content Hub, Pink AIM255-S | Transforming the future of life sciences R&D with generative AI (sponsored by Accenture)（生成 AI でライフサイエンス研究開発の未来を変える） 12/4 (水) 11:30 AM – 12:30 PM (太平洋標準時) | Venetian, Level 3, Murano 3305 ビルダーセッション 60 分間のビルダーセッションでは、AWS の専門家が指導し、AWS での構築に関する実践的な学習を提供します。これには簡単なデモンストレーションと、それに続くガイド付きの実践体験が含まれます。ご自身のラップトップを持参してご参加ください。 HLS204 | Streamlining clinical protocol reviews with Amazon Q Business（Amazon Q Business による臨床プロトコルレビューの効率化） 12/2 (月) 10:30 AM – 11:30 AM (太平洋標準時) | Wynn, Level 1, Lafite 4, Builders’ 1 12/2 (月) 4:30 PM – 5:30 PM (太平洋標準時) | Wynn, Level 1, Lafite 4, Builders’ 1 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Wynn, Level 1, Latour 7 STG317 | Use your own proprietary data to build customized generative AI apps（あなた独自のデータを使用し、カスタマイズされた生成 AI アプリケーションを構築） 12/5 (木) 11:00 AM – 12:00 PM (太平洋標準時) | Caesars Forum, Level 1, Alliance 315 ワークショップ ワークショップは、参加者がグループに分かれて作業し、AWS を使用する際の問題の解決策を 2 時間で構築するインタラクティブなハンズオンセッションです。ご自身のラップトップを持参してご参加ください。 HLS205 | Building scalable drug discovery applications（スケーラブルな創薬アプリケーションの構築） 12/2 (月) 3:30 PM – 5:30 PM (太平洋標準時) | Wynn, Level 1, Margaux 2 HYB304 | Implement RAG without compromising on digital sovereignty（デジタル主権を損なうことなく RAG を実装する） 12/2 (月) 8:00 AM – 10:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 228 HYB305 | Cutting-edge AI: Real-time anomaly detection and forecasting（最先端の人工知能：リアルタイムの異常検出と予測） 12/4 (水) 9:00 AM – 11:00 AM (太平洋標準時) | Caesars Forum, Level 1, Summit 216 チョークトーク チョークトークは、AWS の専門家による少人数向けの 60 分間の講義です。実用的なアーキテクチャの課題に関する技術的な議論を促進するための、インタラクティブなホワイトボードセッションがあります。 HLS209 | Migrating regulated workloads on to AWS at scale（規制対象のワークロードを AWS に大規模に移行） 12/2 (月) 8:30 AM – 9:30 AM (太平洋標準時) | MGM, Level 1, 102 12/2 (月) 4:00 PM – 5:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 HLS201 | End-to-end biological foundation model workflows for drug discovery（創薬のためのエンドツーエンドの生物学的基盤モデルワークフロー） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) | Mandalay Bay, Level 3, South Convention Center , South Seas C 12/5 (木) 2:00 PM – 3:00 PM (太平洋標準時) | MGM, Level 1, 102 HLS303 | Accelerate cancer biomarker discovery with Amazon Bedrock Agents（Amazon Bedrock Agents で癌バイオマーカーの発見を加速） 12/2 (月) 1:00 PM – 2:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 12/4 (水) 1:00 PM – 2:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 CMP412 | High performance computing is a capacity challenge. We have solutions.（ハイパフォーマンスコンピューティングは容量に関する課題。私たちには解決策があります。） 12/3 (火) 4:00 PM – 5:00 PM (太平洋標準時) | Caesars Forum, Level 1, Academy 416 CMP406 | Making HPC and other R&D workloads accessible beyond the AWS console（HPC やその他の研究開発ワークロードを AWS コンソールからアクセスできるように） 12/3 (火) 1:00 PM – 3:00 PM (太平洋標準時) | MGM, Level 1, Boulevard 158 CMP326 | Accelerate AI innovation for healthcare and life sciences on AWS（AWS でヘルスケアとライフサイエンスのための AI イノベーションを加速） 12/4 (水) 10:30 AM – 11:30 AM (太平洋標準時) | Mandalay Bay, Level 3, South Convention Center, South Seas D HYB310 | Addressing data residency requirements with hybrid and edge services（ハイブリッドサービスとエッジサービスによるデータレジデンシー要件への対応） 12/4 (水) 8:30 AM – 9:30 AM (太平洋標準時) | MGM, Level 1, Boulevard 158 ライトニングトーク ライトニングトークは、エキスポホールで開催される 20 分間のシアタープレゼンテーションです。特定のお客様事例、サービスデモ、AWS パートナーサービスなどに特化してお話しします。 AIM242-S | Agentic AI and journey to gen AI value realization (Sponsored by ZS)（AI Agent と生成 AI の価値実現への道のり） MAM234-S | Cloud Transformation: Merck’s proven modernization factory model (Sponsored by HCLTech)（クラウド・トランスフォーメーション：Merck の実績あるモダナイゼーション・ファクトリー・モデル） PEX214 | AWS Partners accelerating industry modernization through LoB（LoB を通じて業界の近代化を加速している AWS パートナー） AIM247-S | Data’s renaissance: Gen AI and the new value of data (sponsored by ZS)（データのルネッサンス：生成 AI とデータの新しい価値） [注 : イベントカタログにセッションが増え次第、さらにセッションが追加されます] AWS for Industries Pavilion で AWS の専門家と出会い、アイデアを交換しましょう ヘルスケア・ライフサイエンス向けの最新の生成 AI イノベーションを見て、交流しましょう。AWS の業界サービスとソリューションを直接体験してください。あなたと同じクラウドの旅をしている AWS の専門家や仲間とつながりましょう。 AWS for Industries Pavilion 営業時間 (太平洋標準時) : 12/2 (月) 4:00 PM – 7:00 PM 12/3 (火) 10:00 AM – 6:00 PM 12/4 (水) 10:00 AM – 6:00 PM 12/5 (木) 10:00 AM – 4:00 PM パビリオンで予定されている生成 AI デモは以下の通りです： 生成 AI による創薬の変革 生成 AI による臨床試験の変革 生成 AI による患者と臨床医の体験の変革 さらに、 Undiagnosed Diseases Network  および John Hopkins 小児センターと提携して、小児患者さんがデザインした限定版のピンを配布します。未診断の病気と闘っている 11 歳のクーパーと拡張型心筋症の 7 歳のハナがデザインしたピンは、クラウドベースのイノベーションが患者に与え続けている影響を象徴的に思い出させてくれます。ベネチアンのヘルスケア＆ライフサイエンスエキスポパビリオンに立ち寄って、ピンを集めましょう。 それでは、ラスベガスでお会いできるのを楽しみにしています！ ヘルスケアとライフサイエンスの新時代を今すぐ開拓する方法の詳細については、 AWS for Healthcare and Life Sciences  をご覧ください。 おすすめヘルスケアセッションについては、 healthcare industry guide to AWS re:Invent 2024  をご覧ください。 Oiendrilla Das Oiendrilla Das は、AWS のライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリーダーです。彼女はライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。Oiendrilla はマーケティングの MBA 学位を取得しており、MBA を取得する前にバイオテクノロジーのエンジニアリングを修了しました。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティングのワールドワイドヘッドです。IBM や Cisco などの大企業や、2 つのクラウドベースのスタートアップで指導的役割を果たしてきました。直近では、Forrester Research/Sirius Decisions のグローバルアナリスト兼アドバイザーを務めました。彼女は、公共部門など、これまでサービスが行き届いていなかった業界で変化をもたらす企業でキャリアの多くを過ごしてきました。公共部門での経験から、医療、公共安全、教育、政府機関における人生を変える多くのテクノロジープログラムに取り組んできました。 Ryan Greene Ryan Greene は、AWS のグローバルヘルスケア及びライフサイエンスチームのシニアプロダクトマーケティングマネージャーです。ビルダーとしての考え方と、チームの運営方法を変革したいという情熱を持った彼は、複雑な問題に大規模に取り組むことを好みます。彼は 2 人の幼い子供たちからやる気を引き出し、革新的なアプローチを活用して世界で最も大規模な顧客の課題や作業負荷に対処することへのプロとしての関心を高めています。