PGA TOUR は、より良い統計データを収集し、広く普及、さらにはファンを競技に近づけるための施策として、2024年の ZOZO Championship で  TOURCast を日本で初披露しました。これは CDW がサポートする革新的なスコアリングシステム ShotLink の新バージョンになります。PGA TOUR がこのような最新技術をアジアに持ち込めたのは今回が初めてで、Amazon Web Services(AWS) のクラウドの柔軟性とスケーラビリティを活用することで、実現に向けた課題を乗り越えることができました。 「私たちは過去 2 年間で、スコアリングシステムを完全に新しい AWS のソフトウェアスタックに置き換えました。それによってコース上の技術設置が非常に柔軟かつ機動力があるものになり、今大会で TOURCast を初めて実現できたのです」と、PGA TOUR のゴルフ技術責任者である Ken Lovell 氏は説明します。 この技術革新の中核には、入力ソースを区別しないクラウドベースのインフラストラクチャがあります。レーダーシステム、カメラ、手動入力といった様々なデータ収集手段からの情報を、システムはシームレスに処理できるのです。この柔軟性が、PGA TOUR が独自の制約に直面した ZOZO Championship での導入を可能にしました。 ZOZO Championship のフェアウェイにおいて、PGA TOUR のボランティアが、ショットの詳細データを入力し、ShotLink Select Plus にフィードバックする特殊なGPS機器を設置しています  [写真提供: PGA TOUR] 日本では、選手にトラッキングデバイスを装着させる代わりに、「フェアウェイごとに特殊な GPS 機器を持った要員を配置し、ショットの詳細を手動で入力しました」と Lovell 氏は明かします。「そして AWS 技術を活用したテクノロジースタックのおかげで、アイデアから実際の運用までわずか 4 か月でできたのです」。 グリーン周辺に設置される ShotLink Select Plus のための、レンジファインダーとアンテナを備えた 3 脚式設置台の例  [写真提供: PGA TOUR] この新しいアプローチの革新性は、PGA TOUR が既存のインフラストラクチャとデータ統合の方法を試しているところにあります。「システムは入力方法を気にしません。座標と選手情報さえあれば、AWS ソフトウェアスタックが残りを処理してくれます」 この柔軟性は、PGA TOUR と AWS のパートナーシップの直接的な成果です。AWS のクラウド技術を活用することで、PGA TOUR は大会ごとの特性に合わせてスケールアップ/ダウンできるシステムを構築できました。Lovell 氏は次のように述べています。「AWS を選んだ大きな理由は、自分たちのビジネスが独自のものであることを理解していたからです。究極の モジュール性と柔軟性を求めていました」。 このクラウドベースのアプローチによる恩恵は柔軟性だけにとどまりません。PGA TOUR は、現地の小規模なチームだけで全体の運用を遠隔から管理できるようになりました。「フロリダ本社からこの大会のシステムを管理できました」と Lovell 氏は説明します。「全てクラウドベースなので、場所は関係ありません。デバイスレベルとソフトウェアレベルの両方で、通信障害に対処できるストアアンドフォワード機能を組み込んでいます」。 しかし、このグローバル展開には課題もあります。データ処理のため遠くまで移動する必要があり、レイテンシーが重要な懸念事項となっています。「データがどれくらい速く移動できるかを試しているところです」と Lovell 氏は認めます。チームは AWS Direct Connect などのオプションを検討しており、APACリージョンにエンドポイントを設ける可能性も探っています。AWS Direct Connect は、お客様のネットワークを AWS に直接接続し、一貫したパフォーマンスと低レイテンシーを実現するクラウドサービスです。 PGA TOUR はこの導入に慎重なアプローチを取っています。大会中は TOURCast をライブで提供しましたが、チームは大会後により詳細な結果を検証してから一般公開する予定です。この拡大は PGA TOUR にとって単なる技術的な成果以上の意味があります。より広範なグローバルカバレッジに向けた戦略的な一歩となるでしょう。 ゴルフがグローバルに成長を続ける中、柔軟なクラウドベースの技術への投資により、PGA TOUR は国際的なファンのニーズに対応できる体制が整いました。AWS を活用した TOURCast の展開により、PGA TOUR は、この取り組みを通じて、単にゴルフのスコアリングシステムを構築したにとどまらず、スポーツ分野におけるグローバルな技術革新を実現することに成功しました。 ビジネスの成長を加速させるためにAWSをどのように活用できるか、詳しくは AWS 担当者 までご相談ください。 —- 参考リンク AWS for Sports AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは AWS 山口が担当いたしました。原文は こちら をご覧ください。

Amazon DataZone は、アマゾンウェブサービス（AWS）、オンプレミス、およびサードパーティのソース全体に保存されているデータを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスです。2023 年 10 月に一般的提供を開始してから、継続して機能強化を続けています。 本ブログでは、Amazon DataZone の概要と、最近のアップデートや活用事例、簡単にはじめるための方法について簡単にご紹介します。詳細な情報のリンクも併せて記載しているので、ご興味がある方は、そちらの情報を確認いただき、理解を深めてください。 Amazon DataZone の概要と特徴 データ活用を進めていくにあたって、利用者は必要なデータを素早く発見して利用できることを求める一方で、管理者は適切な権限管理ルールに則り統制された環境を求めています。つまり、アジリティとガバナンスの両立が求められるわけですが、Amazon DataZone は、そのような要件を実現するソリューションです。 Amazon DataZone のコアコンポーネントは、図 1 に示す通り以下を提供します。 組織の境界を越えてデータを共有、検索するための Amazon DataZone ポータル ビジネス的な意味を蓄積し・共有するためのビジネスデータカタログ プロジェクトを作成してデータやツールなどの環境を、必要な人がアクセス可能になるまで IT 作業不要で実現する仕組み プロジェクト単位でだれがどのデータにアクセスできるかのアクセスコントロールと監査 図1 : Amazon DataZone のコアコンポーネント Amazon DataZone の詳細については、AWS Black Belt Online Seminar – Amazon DataZone Overview より確認いただけます。 PDF : https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-DataZone-Overview_1231_v1.pdf 動画 : https://www.youtube.com/watch?v=WGFJZNv2nDw （デモのパートは こちら からです） 2024 年の主要アップデート Amazon DataZone のアップデート情報については、ユーザガイドの What is new in Amazon DataZone? で紹介しています。どれもデータ活用に役立つ機能ですが、その中からピックアップしていくつかご紹介します。 主要アップデートサマリ ここで取り上げる Amazon DataZone アップデートを表 1 にまとめます。 日付 アップデート サマリ（ニーズ） 2024/4/3 AWS Glue Data Quality との統合 ・データ品質も参考にデータの利用判断をしたい 2024/6/14 高度な検索フィルタリング機能 ・効率的、かつ直感的にデータポータルから必要なデータを探したい 2024/6/17 カスタムブループリント ・既存リソースを Amazon DataZone に統合したい 2024/6/27 データリネージビジュアライゼーション機能（プレビュー） ・自分が作成したデータを誰が利用しているかを追跡したい ・データの出所を確認して分析に利用しているのが適切なデータか把握したい 2024/7/2 きめ細かなアクセス制御 ・共有するデータを行レベルおよび列レベルでデータをきめ細かく制御したい 2024/8/5 データプロダクトによるグループ化 ・共有するデータをグループ化してデータ共有のプロセスを簡素化したい ・特定のユースケースに必要なすべてのデータを簡単に見つけたい 2024/8/12 ドメインユニットと承認ポリシー ・ビジネスユニットやチームに関連するデータやプロジェクトを整理、作成、見つけたい 2024/10/17 AWS IAM Identity Center アカウントインスタンスのサポート ・AWS Organizations の組織インスタンスではなく、アカウントインスタンスを用いてユーザ管理、あるいは外部 IdP との SSO を実現したい 2024/10/18 プロジェクト内のメンバーに新しい肩書を追加 ・より細かくプロジェクト内のユーザーへの権限を制御したい 2024/10/30 Athena JDBC ドライバーによる認証をサポート ・Tableau、Power BI などのBI および分析ツールを使用して Amazon DataZone プロジェクトのサブスクライブ済みデータレイクアセットにクエリを実行したい  表1 : 主要アップデートサマリ ここからは、それぞれのアップデートについて紹介します。 Amazon DataZone と AWS Glue Data Quality の統合を開始（2024/4/3） AWS Glue Data Quality との統合が開始され、Amazon DataZone データポータルから、AWS Glue Data Quality の品質スコアを確認できるようになりました。また、API を使用して外部システムから品質スコアをインポートすることができます。これにより、データアナリストやデータエンジニアなどのデータコンシューマーは分析に使用するデータをデータポータルから検索する際に、データ品質スコアも参考に利用判断することができます。 図2 : Amazon DataZone データポータルで確認できるデータ品質（抜粋） 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-now-integrates-with-aws-glue-data-quality-and-external-data-quality-solutions/ 高度な検索フィルタリング機能を導入（2024/6/14） Amazon DataZone はビジネスデータカタログとして、組織全体で同じ定義が使用されるようにビジネス用語集を作成し、アセットに付与することができます。ビジネスカタログから必要なデータを検索するにあたって、ビジネス用語集からの検索機能を強化しました。具体的には、用語集の表示形式（図 4 左側）、「AND」「OR」検索（同図中央）、検索結果の調整に役立てられる選択したフィルターの要約（同図右上のオレンジ枠）です。これによって、コンシューマーはより効率的、かつ直感的にデータポータルから必要なデータを探すことができます。 図3 : データ用語集からのデータ検索 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-enhances-data-discovery-with-advanced-search-filtering/ AWS サービス向けのカスタムブループリント設定を開始（2024/6/17） Amazon DataZone は、カスタムブループリント設定により、既存の AWS IAM ロールや、Amazon S3 などの AWS サービスを使用して Amazon DataZone を設定できるようになりました。これにより、既存の Amazon S3 データレイクや Amazon Redshift データウェアハウス、AWS Glue ETL ジョブなどの AWS リソースを Amazon DataZone に統合できるようになるので、ガバナンスが強化されます。 図4 : 管理者によるカスタムブループリントのセットアップワークフロー 詳細については、以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/amazon-datazone-announces-custom-blueprints-for-aws-services/ データリネージビジュアライゼーション機能の開始（プレビュー）（2024/6/27） Amazon DataZone ではデータリネージのプレビューが導入され、お客様が OpenLineage 対応システムまたは API からのリネージイベントを視覚化し、ソースから使用までのデータ移動を追跡できるようになりました。これによって、データエンジニアなどのデータプロデューサーは、自分が作成したデータを誰が利用しているかを追跡するのに役立ちます。一方、データコンシューマーはデータの出所を確認することができるので、分析に利用しているのが適切なデータであるかどうかを把握するのに役立ちます。 図5 : Amazon DataZone データポータルで確認できるデータリネージ 詳細については、以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/news/introducing-end-to-end-data-lineage-preview-visualization-in-amazon-datazone/ 以下のブログでは、AWS Glue テーブルと ETL ジョブ、Amazon Redshift、Amazon Managed Workflows for Apache Airflow (MWAA) からリネージをキャプチャする方法について、CloudFormation スタック起動して確認することができます。 https://aws.amazon.com/jp/blogs/news/amazon-datazone-introduces-openlineage-compatible-data-lineage-visualization-in-preview/ きめ細かなアクセス制御の導入（2024/7/2） Amazon DataZone で、きめ細かなアクセス制御が導入され、データ所有者が行レベルおよび列レベルでデータをきめ細かく制御できるようになりました。例えば、テーブルに複数の地域のデータが含まれている場合、行フィルターを作成して、別々のプロジェクトに対して別々の地域の行へのアクセスを付与できます。さらに、列フィルターを使用すると、個人を特定できる情報 (PII) を含む列など、特定の列へのアクセスを制限して、必要かつ機密性の低いデータへのアクセスのみをデータコンシューマーに許可できます。 図6 : Amazon DataZone ポータルでの列フィルターの作成 詳細については、以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/news/enhance-data-security-with-fine-grained-access-controls-in-amazon-datazone/ データプロダクトによるビジネスユースケースベースのグループ化を提供（2024/8/5） Amazon DataZone で、特定のユースケースに必要なデータアセットをデータプロダクトとしてグループ化できるようになりました。例えば、マーケティングキャンペーンデータ、パイプラインデータ、顧客データといったマーケティング分析に必要となるデータをマーケティング分析というデータプロダクトとしてまとめることができます。データプロデューサーは、データプロダクトにビジネスコンテキストを追加し Amazon DataZone ポータルに公開することで、データコンシューマーはマーケティング分析に必要なすべてのデータを簡単に見つけることができます。 図7 : データプロダクトによるデータ共有プロセスの簡素化 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/blogs/big-data/introducing-data-products-in-amazon-datazone-simplify-discovery-and-subscription-with-business-use-case-based-grouping/ https://www.youtube.com/watch?v=MaXgOi0S0SQ ドメインユニットと承認ポリシーを発表（2024/8/12） Amazon DataZone で、ビジネスユニットやチームレベルでドメインを作成し、ビジネスニーズに応じてポリシーを管理できるようになりました。企業などの組織においては、複数のビジネスユニットやチームが階層型に構成されているケースが少なくありませんが、新しく導入されたドメインユニットにより実現できます。Amazon DataZone 管理者は、ドップレベルのドメイン配下に営業部門、マーケティング部門といったドメインユニットを作成し、ドメインユニットのオーナーを割り当てることができます。管理者やオーナーは、ドメインユニットに対するプロジェクトの作成や用語集、リソースの使用といったアクセスポリシーも設定できます。これにより、Amazon DataZone ユーザーは、ドメイン単位でカタログを参照や検索したり、特定のビジネスユニットが作成したデータをサブスクライブできます。 図8 : ABC Corpにおけるドメインユニットの例、ドメイン単位に承認ポリシーを設定できる 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/blogs/big-data/organize-content-across-business-units-with-enterprise-wide-data-governance-using-amazon-datazone-domain-units-and-authorization-policies/ https://www.youtube.com/watch?v=wGPzoPz1K4k AWS IAM Identity Center アカウントインスタンスのサポート（2024/10/17） Amazon DataZone で、AWS Organizations を設定していなくても、単一の AWS アカウントで AWS IAM Identity Center を有効できるようになりました。Amazon DataZone 管理者は AWS IAM Identity Center の有効化にあたって、組織インスタンスとアカウントインスタンスから選択することができます。これにより、AWS Organization の管理アカウントにアクセスできない場合でも、AWS IAM Identity Center のアカウントインスタンスを作成して、Amazon DataZone で該当インスタンスを有効化することによって、AWS IAM Identity Center によるユーザ管理や、Okta や Active Directory などの IdP と SSO を設定することができます。 プロジェクト内のメンバーに新しい肩書を追加（2024/10/18） Amazon DataZone で、プロジェクト内に追加するユーザー向けの肩書（権限ロール）に、従来の Owner, Contributor に加えてConsumer, Viewer, Steward が追加され、より細かくプロジェクト内のユーザーへの権限を制御できるようになりました。 これまで、プロジェクトにユーザーを追加する際にはそのユーザーを Owner もしくは Contributor として登録する必要があり、すべてのユーザーは Amazon DataZone 上で行うほとんどすべてのタスクを等しく行うことができました。今回、新たに追加された 3 つの肩書きにより、異なる役割をもつ多くの関係者をプロジェクトに追加して運用することがしやすくなりました。 表2 :肩書きと操作権限 Athena JDBC ドライバーによる認証をサポート（2024/10/30） Amazon DataZone は Athena JDBC ドライバーによる認証をサポートするようになりました。これにより、データコンシューマーは、Tableau、Domino、Power BI、MS Excel、SQL Workbench などの一般的な BI および分析ツールを使用して、Amazon DataZone 内のプロジェクトのサブスクライブ済みデータレイクアセットにクエリを実行できるようになりました。 図9 : これまでの Amazon DataZone データポータルのクエリエディタによるデータアクセス（上段）と、Athena JDBC ドライバによる BI および分析ツールからのアクセス（下段） 詳細については、以下のブログとビデオで解説しています。 https://aws.amazon.com/jp/blogs/big-data/expanding-data-analysis-and-visualization-options-amazon-datazone-now-integrates-with-tableau-power-bi-and-more/ https://www.youtube.com/watch?v=dFsoldpcF9M Tableau Desktop の詳細なセットアップ手順については以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/big-data/streamline-ai-driven-analytics-with-governance-integrating-tableau-with-amazon-datazone/ Amazon DataZone の活用事例 フォルクスワーゲンが複数のデータレイクにわたるデータアクセスを合理化した取り組み（2024/6/18） フォルクスワーゲン AG（VW）と AWS は 2019 年に戦略的パートナーシップを結び、デジタルプロダクションプラットフォーム（DPP）を共同開発するための戦略的パートナーシップを結びました。生産と物流の効率を 30% 向上させながら、生産コストを同程度削減する DPP の取り組みを進めていくにつれて、顕在化した以下課題に対して、Amazon DataZone を使用して効率的なデータアクセスを実現したかについて解説しています。 複数の独立したデータレイクに保存されているデータの共有 共有されたデータから利用可能なデータを発見してデータアクセスをリクエストするワークフローの円滑化 記事はシリーズ構成となっており、パート 1 について公開されています。 https://aws.amazon.com/blogs/big-data/how-volkswagen-streamlined-access-to-data-across-multiple-data-lakes-using-amazon-datazone-part-1/ ATPCO のイノベーションを加速させる取り組み（2024/7/25） ATPCO は航空会社が旅行会社などが顧客に適切なオファーを適切なタイミングで提供できるよう支援する航空小売業で、データ主導の意思決定を強化することを目指しています。同僚と話し合って潜在的なデータ資産を見つける状況から、Amazon DataZone などの AWS サービスを利用して、誰が何にアクセスできるのかを適切に管理しながら、すべての事業部門が高品質なデータを発見できるようにしてイノベーションを加速させる方法について解説しています。 解説にあたっては、ユースケースとして、航空券データ、価格データ、匿名化された顧客マスタといったデータソースと Amazon DataZone によるソリューション概要図も紹介しています。 図10 : ソリューション概要図 詳細については以下のブログで解説しています。 https://aws.amazon.com/blogs/big-data/how-atpco-enables-governed-self-service-data-access-to-accelerate-innovation-with-amazon-datazone/ フォルクスワーゲンオートヨーロッパが Amazon DataZone を使用してデジタルトランスフォーメーションを加速した取り組み (2024/10/31) フォルクスワーゲングループの工場であるフォルクスワーゲン・オートヨーロッパは、最先端のテクノロジーを活用してデジタル化への取り組みを強化するためデータ主導型の工場を目指していましたが、数日から数週間かかるデータアクセスまでのリードタイム、データコピーによる共有が引き起こす重複した作業やデータガバナンスの欠如とデータ品質の問題といった課題を抱えていました。この課題に対して、オンラインショッピング体験のような、データを利用するユーザーが分かりやすい仕様やビジネスコンテキスト、関連する属性を備えた高品質で安全なデータを閲覧してアクセスできるデータマーケットプレイスを構想し、ソリューションとして Amazon DataZone を使用したデータメッシュアーキテクチャを選択しました。ソリューションにより、データアクセス時間が数週間から数分に短縮されています。 ブログでは、ソリューションのキーとなるケイパビリティとアーキテクチャに加えて、データオーナー（データプロデューサー）、データエンジニア（データコンシューマー）、データソリューション管理者といった役割のユーザーが、データソリューションをどのように利用するかのユーザージャーニーについて紹介しています。 図 11 : ソリューションのキーとなるケイパビリティ（能力） 図 12 : ソリューションのアーキテクチャ 詳細については以下のブログで解説しています。 https://aws.amazon.com/jp/blogs/big-data/how-volkswagen-autoeuropa-built-a-data-mesh-to-accelerate-digital-transformation-using-amazon-datazone/ はじめるには Amazon DataZone のベーシックな機能を体験できるハンズオンとして Amazon DataZone ハンズオン(ベーシック) がありますが、ありますが、解説記事が builders.flash で公開されています。 https://aws.amazon.com/jp/builders-flash/202411/amazon-datazone-hands-on/ Amazon DataZone のコアコンポーネントを AWS CDK を用いて効率的にデプロイして管理する方法について以下のブログで解説しています。記事では、ドメイン、データポータル、ビジネスデータカタログなどの構築手順と、既存の AWS Glue データベースを Amazon DataZone のデータソースとして公開する方法が紹介されています。 https://aws.amazon.com/blogs/big-data/streamline-your-data-governance-by-deploying-amazon-datazone-with-the-aws-cdk/ まとめ 本ブログでは、Amazon DataZone の概要と、最近のアップデートや活用事例について紹介しました。 生成 AI が注目されていますが、差別化となるデータの重要性がますます高まっています。データを迅速かつ簡単にカタログ化、発見、共有、管理できるようにするデータ管理サービスである Amazon DataZone により、アジリティとガバナンスの両立しながら、データ活用を進めていくことができます。 本ブログが、皆さまのデータ活用の取り組みのお役に立てれば幸いです。 更新履歴 2024/7/29 新規作成 2024/8/19 データプロダクトと、ドメインユニットと承認ポリシーを追加 2024/10/23 AWS IAM Identity Center アカウントインスタンスのサポートと、プロジェクト内メンバーの新しい肩書きを追加 2024/11/7 Athena JDBC ドライバのサポートと事例を追加すると共に、Amazon DataZone ハンズオン(ベーシック) の解説記事のリンク（builders.flash）を追加 — 本ブログは、ソリューションアーキテクトの平井が作成しました。

本記事では、トラベルアシスタントアプリの作成方法について説明します。このアプリは、ユーザーの希望する目的地における人気の観光スポット、地域の体験、隠れた名所などをお勧めすることで、パーソナライズされた体験を提供します。このアプリの構築には、 AWS Amplify と Amazon Bedrock を使用します。 AWS Amplify Gen 2 は、バックエンド定義に TypeScript ベースのコードファーストの開発者体験（DX）を採用しています。Gen 2 の DX は、ホスティング、バックエンド、UI ビルド機能を備えた統合された Amplify 開発者体験と、コードファーストのアプローチを提供します。Amplify は、フロントエンド開発者がアプリのデータモデル、ビジネスロジック、認証、認可ルールの全てを TypeScript で表現するだけで、クラウドインフラストラクチャをデプロイできるようにします。Amplify は適切なクラウドリソースを自動的に設定し、基盤となる AWS サービスを手作業で統合する必要性を排除します。 Amazon Bedrock は、主要な AI 企業が提供する高性能な基盤モデル（FM）をフルマネージド型で提供するサービスです。これらの FM は単一のアプリケーションプログラミングインターフェース（API）を通じてアクセス可能で、安全で、プライベートで、責任ある生成 AI アプリケーションを構築するための機能も併せて提供されます。単一の API アクセスにより、異なる FM を柔軟に使用でき、最小限のコード変更で最新のモデルバージョンにアップグレードすることができます。 前提条件 AWS アカウント （Amplify は AWS 無料枠 の対象です） Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキストエディタ（このガイドでは VSCode を使用しますが、お好みの IDE を使用可能です） Amazon Bedrock での Claude 3 Haiku モデルへのアクセス権 リポジトリのクローン ステップ 1 : AWS Samples の リポジトリ に移動し、あなたの GitHub リポジトリにフォークします。 ステップ 2 : 以下のコマンドをターミナルで実行して、アプリをクローンします。 git clone https://github.com/ < YOUR_GITHUB > /travel-personal-assistant.git Bash ステップ 3 : 以下のコマンドをターミナルで実行して、新しくクローンしたリポジトリに VSCode でアクセスします。 cd travel-personal-assistant code . -r Bash VSCode が、次のセクションで説明するバックエンドの詳細を含む Amplify フォルダを含むリポジトリフォルダを開きます。 ステップ 4 : 以下のコマンドを実行して、Amplify パッケージを含む必要なパッケージをインストールします。 npm i Bash Amplify バックエンド 完成したアプリ（冒頭の GIF で示したもの）では、ユーザーは旅行に関する質問（例：「12 月にアイルランドに 7 日間行きたい」）を送信することで会話を開始します。コードはクローンしたリポジトリにあります。ここでは、Amplify アプリを Amazon Bedrock と接続するための主要なステップを説明します。 リポジトリには、auth（認証）、data（データ）、functions（関数）リソース用のディレクトリを含む amplify フォルダがあります。 デフォルトでは、 amplify/auth/resource.ts ファイルで設定された認証リソースは、ユーザーのサインアップメカニズムとしてメールを使用するように設定されています。 import { defineAuth } from '@aws-amplify/backend' ; /** * Define and configure your auth resource * @see https://docs.amplify.aws/gen2/build-a-backend/auth */ export const auth = defineAuth ( { loginWith : { email : true , } , } ) ; TypeScript amplify/data/resource.ts ファイルでは、文字列を返し、会話全体を含む JSON 文字列引数 conversation を引数にとる GraphQL クエリ chat を定義しています。認証は .authorization((allow) => [allow.authenticated()]) を使用して、認証されたユーザーのみがこのクエリにアクセスできるように設定されています。 .handler(a.handler.function(personalAssistantFunction)) の行は、このクエリのカスタムハンドラーとして personalAssistantFunction を設定します。 import { type ClientSchema , a , defineData } from "@aws-amplify/backend" ; import { personalAssistantFunction } from "../functions/personal-assistant/resource" ; const schema = a . schema ( { chat : a . query ( ) . arguments ( { conversation : a . json ( ) . required ( ) , } ) . returns ( a . string ( ) ) . authorization ( ( allow ) => [ allow . authenticated ( ) ] ) . handler ( a . handler . function ( personalAssistantFunction ) ) , } ) ; export type Schema = ClientSchema < typeof schema > ; export const data = defineData ( { schema , authorizationModes : { defaultAuthorizationMode : "userPool" , } , } ) ; TypeScript personalAssistantFunction Lambda 関数は、 amplify/functions/personal-assistant/resource.ts ファイルで定義・エクスポートされています。ここでは、環境変数 MODEL_ID を Claude 3 Haiku に設定しています。 import { defineFunction } from "@aws-amplify/backend" ; export const MODEL_ID = "anthropic.claude-3-haiku-20240307-v1:0" ; export const personalAssistantFunction = defineFunction ( { entry : "./handler.ts" , environment : { MODEL_ID , } , timeoutSeconds : 30 , runtime : 20 , } ) ; TypeScript amplify/functions/personal-assistant/handler.ts ファイルには、 personalAssistantFunction ハンドラーの実装が含まれています。ここでは、Bedrock ランタイムクライアントを初期化し、クエリの入力パラメータ conversation と systemPrompt 定数（応答方法に関するコンテキスト、指示、ガイドラインを Amazon Bedrock への提供するため）を使用して入力オブジェクトを生成し、それを使用して ConverseCommand を作成し、ランタイムクライアントを使用して Amazon Bedrock に送信します。応答のエラーを確認し、JSON 文字列として返します。 import { BedrockRuntimeClient , ConverseCommandInput , ConverseCommand , } from "@aws-sdk/client-bedrock-runtime" ; import type { Handler } from "aws-lambda" ; // Constants const AWS_REGION = process . env . AWS_REGION ; const MODEL_ID = process . env . MODEL_ID ; // Configuration const INFERENCE_CONFIG = { maxTokens : 1000 , temperature : 0.5 , } ; // Initialize Bedrock Runtime Client const client = new BedrockRuntimeClient ( { region : AWS_REGION } ) ; export const handler : Handler = async ( event ) => { const { conversation } = event . arguments ; const SYSTEM_PROMPT = ` To create a personalized travel planning experience, greet users warmly and inquire about their travel preferences such as destination, dates, budget, and interests. Based on their input, suggest tailored itineraries that include popular attractions, local experiences, and hidden gems, along with accommodation options across various price ranges and styles. Provide transportation recommendations, including flights and car rentals, along with estimated costs and travel times. Recommend dining experiences that align with dietary needs, and share insights on local customs, necessary travel documents, and packing essentials. Highlight the importance of travel insurance, offer real-time updates on weather and events, and allow users to save and modify their itineraries. Additionally, provide a budget tracking feature and the option to book flights and accommodations directly or through trusted platforms, all while maintaining a warm and approachable tone to enhance the excitement of trip planning. ` ; const input = { modelId : MODEL_ID , system : [ { text : SYSTEM_PROMPT } ] , messages : conversation , inferenceConfig : INFERENCE_CONFIG , } as ConverseCommandInput ; try { const command = new ConverseCommand ( input ) ; const response = await client . send ( command ) ; if ( ! response . output ?. message ) { throw new Error ( "No message in the response output" ) ; } return JSON . stringify ( response . output . message ) ; } catch ( error ) { console . error ( "Error in chat handler:" , error ) ; throw error ; // Re-throw to be handled by AWS Lambda } } ; TypeScript amplify/backend.ts ファイルでは、 addToRolePolicy メソッドを使用して、 personalAssistantFunction 関数のプリンシパルに新しいポリシーを追加します。ポリシーステートメントは、許可されたリソースとアクションを指定します。この場合、リソースは Claude 3 Haiku モデルの AWS ARN（Amazon Resource Name）で、許可されたアクションは bedrock:InvokeModel です。 import { defineBackend } from "@aws-amplify/backend" ; import { auth } from "./auth/resource" ; import { data } from "./data/resource" ; import { Effect , PolicyStatement } from "aws-cdk-lib/aws-iam" ; import { personalAssistantFunction , MODEL_ID } from "./functions/personal-assistant/resource" ; export const backend = defineBackend ( { auth , data , personalAssistantFunction , } ) ; backend . personalAssistantFunction . resources . lambda . addToRolePolicy ( new PolicyStatement ( { effect : Effect . ALLOW , actions : [ "bedrock:InvokeModel" ] , resources : [ ` arn:aws:bedrock:*::foundation-model/ ${ MODEL_ID } ` , ] , } ) ) ; TypeScript アプリを実行すると（次のセクションで説明）、 amplify_outputs.json という名前のファイルが自動的に生成されます。このファイルには API のエンドポイントの詳細が含まれています。 src/app/amplify-utils.ts では、以下のように Amplify クライアントライブラリを初期化・設定します。そして、Amplify バックエンドへのリクエストを容易にするためのデータクライアントを作成します。 import { generateClient } from "aws-amplify/api" ; import { Schema } from "../../amplify/data/resource" ; import { Amplify } from "aws-amplify" ; import outputs from "../../amplify_outputs.json" ; Amplify . configure ( outputs ) ; export const amplifyClient = generateClient < Schema > ( ) ; TypeScript src/app/layout.tsx ファイルでは、アプリのコンテンツを AuthWrapper コンポーネント（ src/app/components/AuthWrapper.tsx ）でラップしています。このコンポーネントは Amplify Authenticator を利用して、ユーザーがサインアップ、サインイン、パスワードリセット、多要素認証（MFA）のためのサインイン確認を行える完全な認証フローを提供します。 "use client" ; import { Authenticator } from "@aws-amplify/ui-react" ; import { ReactNode } from "react" ; interface AuthWrapperProps { children : ReactNode ; } export function AuthWrapper ( { children } : AuthWrapperProps ) { return < Authenticator > { children } < / Authenticator > ; } TypeScript アプリは、 src/app/page.tsx ファイルを使用して、AI アシスタントとチャットするためのコンポーネント（ src/app/components/Chat.tsx ）をユーザーに提供します。 "use client" ; import { Button , View , Heading , Flex , Text } from "@aws-amplify/ui-react" ; import Chat from "@/components/Chat" ; import { useAuthenticator } from "@aws-amplify/ui-react" ; export default function Home ( ) { const { user , signOut } = useAuthenticator ( ) ; return ( < View className = "app-container" > < Flex as = "header" justifyContent = "space-between" alignItems = "center" padding = "1rem" > < Text fontWeight = "bold" > { user ?. signInDetails ?. loginId } < / Text > < Heading level = { 3 } > Travel Personal Assistant < / Heading > < Button onClick = { signOut } size = "small" variation = "destructive" > Sign out < / Button > < / Flex > < View as = "main" > < Chat / > < / View > < / View > ) ; } TypeScript src/app/components/Chat.tsx ファイルでは、AI アシスタントとの会話を促進するためのシンプルなチャットインターフェースを作成しています。ユーザーのメッセージを取得するためのフォームを表示し、送信されると、 fetchChatResponse 関数を使用してチャットクエリを呼び出します。この際、現在の会話とユーザーの新しいメッセージをパラメータとして渡し、アシスタントの応答を取得して会話を更新します。 import React , { ChangeEvent , useEffect , useRef , useState } from "react" ; import { Button , Placeholder , View } from "@aws-amplify/ui-react" ; import { amplifyClient } from "@/app/amplify-utils" ; // Types type Message = { role : string ; content : { text : string } [ ] ; } ; type Conversation = Message [ ] ; export function Chat ( ) { const [ conversation , setConversation ] = useState < Conversation > ( [ ] ) ; const [ inputValue , setInputValue ] = useState ( "" ) ; const [ error , setError ] = useState ( "" ) ; const [ isLoading , setIsLoading ] = useState ( false ) ; const messagesRef = useRef ( null ) ; const handleInputChange = ( e : ChangeEvent < HTMLInputElement > ) => { setError ( "" ) ; setInputValue ( e . target . value ) ; } ; const handleSubmit = ( e : React . FormEvent < HTMLFormElement > ) => { e . preventDefault ( ) ; if ( inputValue . trim ( ) ) { const message = setNewUserMessage ( ) ; fetchChatResponse ( message ) ; } } ; const fetchChatResponse = async ( message : Message ) => { setInputValue ( "" ) ; setIsLoading ( true ) ; try { const { data , errors } = await amplifyClient . queries . chat ( { conversation : JSON . stringify ( [ ... conversation , message ] ) , } ) ; if ( ! errors && data ) { setConversation ( ( prevConversation ) => [ ... prevConversation , JSON . parse ( data ) , ] ) ; } else { throw new Error ( errors ?. [ 0 ] . message || "An unknown error occurred." ) ; } } catch ( err ) { setError ( ( err as Error ) . message ) ; console . error ( "Error fetching chat response:" , err ) ; } finally { setIsLoading ( false ) ; } } ; useEffect ( ( ) => { const lastMessage = conversation [ conversation . length - 1 ] ; console . log ( "lastMessage" , lastMessage ) ; ( messagesRef . current as HTMLDivElement | null ) ?. lastElementChild ?. scrollIntoView ( ) ; } , [ conversation ] ) ; const setNewUserMessage = ( ) : Message => { const newUserMessage : Message = { role : "user" , content : [ { text : inputValue } ] , } ; setConversation ( ( prevConversation ) => [ ... prevConversation , newUserMessage , ] ) ; setInputValue ( "" ) ; return newUserMessage ; } ; return ( < View className = "chat-container" > < View className = "messages" ref = { messagesRef } > { conversation . map ( ( msg , index ) => ( < View key = { index } className = { ` message ${ msg . role } ` } > { msg . content [ 0 ] . text } < / View > ) ) } < / View > { isLoading && ( < View className = "loader-container" > < p > Thinking ... < / p > < Placeholder size = "large" / > < / View > ) } < form onSubmit = { handleSubmit } className = "input-container" > < input name = "prompt" value = { inputValue } onChange = { handleInputChange } placeholder = "Type your message..." className = "input" type = "text" / > < Button type = "submit" className = "send-button" isDisabled = { isLoading } loadingText = "Sending..." > Send < / Button > < / form > { error ? < View className = "error-message" > { error } < / View > : null } < / View > ) ; } export default Chat ; TypeScript アプリの実行 ステップ 1 : Amplify は各開発者に個人のクラウドサンドボックス環境を提供し、迅速な構築、テスト、反復のための独立した開発スペースを提供します。クラウドサンドボックス環境を開始するには、新しいターミナルウィンドウを開き、以下のコマンドを実行します。 npx amplify sandbox Bash ステップ 2 : 以下のコマンドを実行して、ローカルホストの開発サーバーを起動します。 npm run dev Bash ステップ 3 : アプリのテスト後、 Ctrl+c でサンドボックスセッションを終了できます。サンドボックス環境のすべてのリソースを削除するプロンプトで Y を選択してください。 [ Sandbox ] Watching for file changes .. . File written: amplify_outputs.json ? Would you like to delete all the resources in your sandbox environment ( This cannot be undone ) ? ( y/N ) Y Bash アプリのデプロイ アプリが正しく機能することを確認したら、Amplify でデプロイしてホストしましょう。Amplify は、Git ブランチを使用した本番環境とステージング環境の設定を簡素化する、組み込みの CI/CD を備えたフルマネージド型のホスティングサービスを提供します。Gen 2 では、リポジトリの各 Git ブランチが、Amplify のフルスタックブランチに直接対応します。 ステップ 1 : AWS コンソールにサインインし、希望する AWS リージョンを選択します。AWS Amplify コンソールを開き、“Create new app” を選択します。 ステップ 2 : “Start building with Amplify“ ページで、“Deploy your app” から GitHub を選択し、“Next“ を選択します。 ステップ 3 : プロンプトが表示されたら、GitHub で認証を行います。自動的に Amplify コンソールにリダイレクトされます。アプリのリポジトリとメインブランチを選択し、“Next” を選択します。 ステップ 4 : 設定を確認し、“Next” を選択します。 ステップ 5 : 最後に、“Save and Deploy” ボタンをクリックしてデプロイプロセスを開始します。 ステップ 6 : デプロイプロセスが完了するのを待ち、“Visit deployed URL” ボタンをクリックして Web アプリを開くことができます。 リソースのクリーンアップ このチュートリアルが終了したら、予期しないコストを防ぐために、下図のように Amplify コンソールからアプリを削除してバックエンドリソースを削除することができます。 まとめ おめでとうございます！AWS Amplify Gen 2 と Amazon Bedrock を使用して、AI 搭載のトラベルアシスタントアプリの開発に成功しました。さらに、Amplify Hosting を使用して AWS 上にアプリをデプロイしました。Amplify Gen 2 を開始するには、 クイックスタートチュートリアル を試してみてください。また、フィードバックや機能リクエストを残すために、 コミュニティ Discord に参加することもできます。 本記事は、 Creating a Generative AI Travel Assistant App with Amazon Bedrock and AWS Amplify を翻訳したものです。翻訳は Solutions Architect の 都築 が担当しました。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people’s lives easier. You can find Mo on YouTube or on Twitter .

Blocksee は、非代替性トークン (NFT) やその他の暗号資産のマーケター向けに実用的な洞察を提供する Web3 の顧客関係管理 (CRM) とユーザーエンゲージメントソリューションを提供しています。 Blocksee は、Web3 製品マーケターがデジタルメンバーシップ、イベントチケット、プロモーションアセットに関心のあるユーザーから一次データを収集するため、Web サイトにコードスニペットを簡単に埋め込むか、または API にアクセスできるようにしています。 Amazon Managed Blockchain (AMB) などの AWS サービスによってサポートされている Blocksee は、従来のメールログインを利用した自動ウォレット作成から、NFT などのデジタル製品やサービスをユーザーが簡単に購入できるようにするクリック決済ソリューションまで、さまざまなツールを備えており、ブロックチェーンでサポートされたロイヤリティプログラム、トークンゲートされたコンテンツ、動的顧客ジャーニーを提供しようとするブランドにシームレスな移行を支援します。 デジタル資産と Web3 アプリケーションとのユーザー インタラクションに関するデータ駆動型の洞察を提供するために、Blocksee は Ethereum などの複数のパブリックブロックチェーンからオンチェーンデータの大量のデータを取り込み、分析する必要がありました。 このデータには、ファンジブルトークンやノン ファンジブルトークン (NFT) などのデジタル資産の現在および過去の所有権情報 (残高)、ならびに Web3 アプリケーションとそれらを下支えするスマートコントラクトとのユーザートランザクション/インタラクションが含まれていますが、これらに限定されるものではありません。 このデータを取得および処理するために、Blocksee はセルフマネージド型のブロックチェーン基盤から第三者のブロックチェーンデータプロバイダまでさまざまな技術ソリューションを検討しました。 抽出、変換、ロード (ETL) ワークフローとブロックチェーンデータのインデックス作成のためにブロックチェーンノードの運用に必要な計算、ストレージ、ネットワーキングリソースの高コストを考慮すると、セルフマネージド型のデータアーキテクチャではコスト効率の要件を満たすことはできないと Blocksee は判断しました。 ブロックチェーンノードの管理、データインデックス作成、ETL プロセスは特別なものではなく、自社で構築すると顧客向けの主要な機能開発に専念できなくなります。 Blocksee は次に、アプリケーションに必要なデータを提供できる第三者プロバイダを検討し、データニーズに対して複数の第三者プロバイダを使用したMinimum-Viable Product（MVP）を構築しました。しかし、Blocksee はデータの信頼性、コストパフォーマンス、データの品質に問題があり、ブロックチェーンデータのニーズに対する代替案を更に検討する必要がありました。Blocksee は、複数のプロバイダによる API からの集約された入力を使用するの方式から切り替え、パフォーマンスが高く信頼性のあるブロックチェーンデータを得るため、複数のパブリックブロックチェーンの統合ブロックチェーンデータ API である AMB Query を使用するようになりました。AMB Query を使うことで、Blocksee は複雑な複数のプロバイダによる API に対する開発サイクルを削減し、データニーズに対して予測可能な価格設定の単一の API を使用することでコストを最適化することができ、市場への投入時間を短縮することができました。 「AWS の Amazon Managed Blockchain サービスを利用する前の私たちのワークフローでは、チームが多数の RPC プロバイダーからデータフィードを集める必要があり、複雑な API の設定 と監視が必要でした。これにより開発期間が長くなり、ベンダーやステークホルダーとのフィードバックループが長期化していました。さらに、完全なデータセットを入手するために複数のサービスを支払う必要があったため、資金の非効率的な使用と、必ずしも高品質で信頼性の高いサービスを提供できるリソースを持たないスタートアップに過度に依存していました。Amazon Managed Blockchain を使えば、それらすべてを変えられます。信頼できる高速なブロックチェーンデータにアクセスできるようになり、当社のテクノロジースタックをより管理しやすく統合されたものにすることができました。」 – Eric Forst、Blocksee 共同創設者兼 CEO マーケターやプロジェクト管理者が Blocksee CRM ツールを立ち上げると、ブロックチェーンアドレス (ユーザー) に関するトークン残高データがスクリーン上に表示され、AI を用いたユーザーの行動分析などの追加の状況データと組み合わせて利用できるようになります。 以下は Blocksee のツールのスクリーンショットで、ユーザーが利用できるデータとインサイトの一例を示しています。 Blocksee は、ブロックチェインアドレスの ERC20 および ERC721 トークン残高を取得するために、AMB Query ListTokenBalances API を利用しています。これにより、特定のコントラクトによって生成された全てのトークンを照会できます。 ListTokenBalances API は、次のような様々な方法で利用できます。 特定のアドレス (コントラクトアドレスまたはウォレットアドレス) が保有しているすべてのトークンの残高をリストアップすること。 特定のコントラクトで作成されたすべてのトークンのオーナーとトークン残高をリストアップすること。 特定のトークン(例えば ERC-20 トークン)のすべてのオーナーの残高をリストアップすること。 1 つの API で、リストのそれぞれのアドレスに対して複数のトークンタイプの残高を取得できるようにしたことで、Blocksee が以前使用していたこのデータの取得と集約のメカニズムと比較して、パフォーマンスが 25 %向上し、コスト削減効果は 50 %と見積もられています。 Matt Kotnik さんは Blocksee の共同創設者兼 CTO で、AMB Query がアプリケーション実装に与えた影響について次のように述べています。 私たちは、 ListTokenBalances API を使用して、[ 前のプロバイダ ] に比べて 25 %以上のロード時間の改善ができるため、すでに大幅な読み込み速度の向上が見られています。また、Amazon のサービスが、チェーンにとらわれないシステムアーキテクチャを補完するものであるため、AMB はその他のブロックチェーンのサポート拡大にも貢献しています。これにより、デジタルインフラストラクチャの最も信頼できる名前の 1 つとのパートナーシップから得られる安心感があり、コア製品と顧客関係により重要な焦点を当てることができるようになりました。 AMB Query のデータクエリの REST API インターフェイスが標準化されているため、 一度に1 つまたは複数のブロックチェーンデータを問合せるリクエストの構文は大きく変わらないため、Blocksee は AMB Query でサポートされる新しいブロックチェーンを簡単に導入できます。 まとめ AMB Query が、米国東部 (バージニア北部) リージョンで一般提供開始になり、1秒未満のレイテンシーで履歴残高やトランザクションなどのブロックチェーンデータにアクセスできるようになりました。特別なインフラストラクチャを必要とすることなく、大規模かつ高速でブロックチェーンデータをお客様に提供します。 AMB Query のお客様は、主要なネットワークからのブロックチェーンデータを、実世界のアプリケーションがパフォーマンス要件を満たすスピードとスケールで受け取ることができます。お客様は、実行した API 呼び出しに対してのみシンプルで予測可能な料金を支払います。AMB Query の詳細については、 ユーザーマニュアル をご覧ください。その他の AMB 製品については、 Amazon Managed Blockchain をご覧ください。 本記事は、 How Blocksee built a Web3 CRM with blockchain data from Amazon Managed Blockchain Query を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津 颯騎 が担当しました。 著者について AJ Park は、AWS の Amazon Managed Blockchain チームでプロダクトマネージャーを務め、顧客向けのブロックチェーンと Web3 ソリューションの構築に情熱を注いでいます。それ以前は、20 年以上にわたりソフトウェア開発者とプロダクトマネージャーとしてデータ保護とストレージ分野で革新的な活動に取り組んでいました。 Forrest Colyer は、Amazon Managed Blockchain (AMB) サービスをサポートする Web3/Blockchain スペシャリスト ソリューションアーキテクトチームを管理しています。Forrest と彼のチームは、概念実証から本番環境まで、お客様のブロックチェーンワークロードの導入の各段階で深い技術的専門知識と戦略的指針を提供し、支援しています。コンソーシアムが主導するプライベートブロックチェーンソリューションと NFT や DeFi などのパブリックブロックチェーンの使用事例の両方の経験から、Forrest はお客様が高い影響力を持つブロックチェーンソリューションを特定して実装できるようサポートしています。

本ブログは 2024 年 10 月 26 日に公開されたBlog “ Exploring digital sovereignty: learning opportunities at re:Invent 2024 ” を翻訳したものです。 AWS re:Invent 2024 は、 Amazon Web Services (AWS) がクラウドコンピューティングのグローバルなコミュニティのために主催する学習型カンファレンスで、2024 年 12 月 2 日から 6 日まで、ネバダ州ラスベガスの複数の会場で開催されます。re:Invent では、クラウドを積極活用する人々が世界中から集まり、最新のクラウド業界のイノベーションを学び、AWS のエキスパートと会話し、人脈を築くことができます。深い技術的専門知識を身につけたい、投資の優先順位付けの方法を理解したい、設計段階からデジタル主権を考慮した AWS クラウドのサービスを詳しく知りたい、あるいは AWS Nitro System がワークロードのセキュリティをどのように強化するかを確認したいなど、re:Invent は私たちの デジタル主権 (Digital Sovereignty) ソリューションを探求する絶好の機会です。 今年は、 AWS Local Zones 、 AWS Dedicated Local Zones 、 AWS Outposts など、AWS ハイブリッドやエッジサービスに関するセッションやハンズオンを通じて、高度なデジタル主権コントロール、セキュリティ機能、インフラストラクチャの選択肢について学ぶ多くの機会があります。 Expo では、AWS Village 内の Digital Sovereignty & Data Protection kiosk を訪れて、デモを見たり、近日利用開始予定の AWS European Sovereign Cloud について学んだり、AWS メンバーに質問や相談をすることができます。AWS が設計したチップや Outposts デバイスを見るには、AWS Village の AWS Next Gen Infrastructure Hub をチェックしてください。また、 AWS Partner Network (APN) ブースを訪れて、 AWS デジタル主権のパートナー に会って、パートナープログラムの利点を確認することもできます。 ブレイクアウトセッションとライトニングトーク セッションタイトルのリンクを選択するとセッション情報と時間場所を確認できます。AWS re:Invent のお客様のアジェンダにセッションの追加もできます。 SEC229 | ブレイクアウト | デジタル主権：複雑性を克服し、将来への準備を整える Max Peterson、VP、Sovereign Cloud、AWS 組織は、進化するデジタル主権の状況において、増大する複雑性に直面しています。強固なデジタル基盤を構築することで、イノベーションを妨げることなく、今日に求められている要件を満たし、組織の将来に備える取り組みを簡素化できます。このセッションでは、暗号化サービスから、発表されている AWS European Sovereign Cloud まで、AWS のソブリンクラウドサービスがどのようにして、お客様独自のニーズに応えるためにより多くのコントロールと選択肢が提供されているかを確認できます。お客様が AWS 上の生成 AI を含む新しいテクノロジーを活用する際に、重要なワークロードをどのように安全に保護しているかの方法と、AWS パートナーが提供する新しいデジタル主権ソリューションについて学びます。 HYB201 | ブレイクアウト | AWS を必要なあらゆる場所で：クラウドからエッジまで Jan Hofmeyr, VP, EC2 Networking and Hybrid Edge, AWS, and Jeff Feist, Executive Director – Hosting Solutions, Merck & Co., Inc. ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、またはデータ主権の要件により、一部はオンプレミスやエッジに残るかもしれません。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、 AWS IoT Core などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像処理、スマート製造、データ レジデンシー (所在地) 要件のある生成 AI アプリケーションなど、ハイブリッドクラウドおよびエッジコンピューティングワークロードをどのようにサポートするかについて学びます。 HYB309 | ブレイクアウト | ハイブリッドクラウドサービスによるデータレジデンシーに関するベストプラクティス Sherry Lin, Principal Product Manager, AWS; Lakshmi VP, Specialist SA – Hybrid Edge, AWS; and Kevin Ng, Senior Director, Core Engineering Products, GovTech データのプライバシー、セキュリティ、デジタル主権に関する懸念から、世界中の多くの政府が個人データや機密データを国境内に保持するためにデータ レジデンシー規制を強化しています。複数の地域で事業を展開する組織にとって、進化するデータ レジデンシー規制に対応することは課題となる可能性があります。このセッションでは、AWS Well-Architected Framework に従って、AWS Local Zones、AWS Dedicated Local Zones、AWS Outposts などのハイブリッドクラウドサービスを使用する際のデータ レジデンシーに関するベストプラクティスを紹介します。 IOT202 | ブレイクアウト | AWS IoTを活用したエッジにおけるLLMのデプロイと稼働 Nikit Pednekar, Principal Product Manager, AWS, and Stefano Marzani, WW Tech Leader, SDX, AWS 生成 AI と大規模言語モデル (LLM) の登場により、これらの技術を IoT エッジにどのように適用できるか気になっているのではないでしょうか。実際にエッジで LLM を実行することには多くの利点があります。ネットワーク帯域幅の有効利用、オフライン処理、低レイテンシー、データ主権の確保から、コスト削減、セキュリティ、差別化まで様々です。このセッションでは、AWS IoT サービスとエッジでの LLM の使用が、ジェスチャー認識、音声制御のための自然言語処理、リアルタイム予知保全、エネルギー最適化、異常検知などの実用的な成果と革新的な機能によって、ソリューションをどのように強化できるかを学びます。 KUB310 | ブレイクアウト | Amazon EKS のエッジおよびハイブリッドのユースケース Chris Splinter, Product Manager, AWS, and Gokul Chandra Purnachandra Reddy, Senior Solutions Architect, AWS 製造、ヘルスケア、通信、金融サービスなどの業界では、低レイテンシー、データの依存性、データ主権、その他の規制上の理由により、オンプレミス、エッジ、またはハイブリッドで実行する必要があるワークロードがあります。AWS サービスでデータを利用できるようになるまで、AWS への完全な移行を待つ必要があるかもしれません。このセッションでは、 Amazon EKS Anywhere などのサービスを活用して、オンプレミスでコンテナワークロードを実行し、VMware ベースのワークロードのモダナイズをサポートする実用的なアーキテクチャを紹介します。また、オンプレミスの Kubernetes デプロイメントを AWS クラウドに移行するためのベストプラクティスについても学びます。 PEX110 | ライトニング・トーク | パートナープログラムで成長と能力を加速 Mike Cannady, Director, Partner Core Public Sector, AWS 公共部門のビジネスを推進する AWS パートナープログラムの最新情報をご確認ください。このライトニング・トークに参加して、パートナー向けに特化したイノベーション (生成 AI プログラム、デジタル主権、ソリューション構築、マネージドサービスなど) を探索してください。初心者でもベテランでも、洞察とユースケースを得て、成長を加速して参加者のジャーニーを向上させることができます。この進化し続ける環境で、自己開発を加速し、先駆けの地位を確保しましょう。 インタラクティブセッション (チョークトークとワークショップ) (訳者注: チョークトーク（Chalk talk）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問できることもあります。) HYB304 | ワークショップ | データ主権を損なわずに RAG を実装する Aditya Lolla, Senior Solutions Architect, Hybrid Edge, AWS, and Robert Belson, Senior Developer Advocate, AWS 政府や標準化団体がデータ保護とプライバシーに関する規制を策定する中、組織はクラウド上の生成 AI ツールの使用と、データ主権の要件を満たすためにオンプレミスに保持する必要がある規制対象データを組み合わせる必要性が高まっています。このワークショップでは、 Amazon Bedrock の Agents を AWS Outposts や AWS Local Zones などのハイブリッドおよびエッジサービスに拡張し、オンプレミスデータを使用した検索拡張生成 (RAG) アプリケーションを構築してモデルの性能を向上させる方法を学びます。Amazon Bedrock、 AWS Lambda 、AWS ハイブリッドおよびエッジサービスをハンズオンで体験し、ハイブリッド Amazon Simple Storage Service (Amazon S3) 互換ソリューションを使用して Amazon S3 準拠のワークフローを構築します。参加の際はラップトップをご持参ください。 WPS207 | チョークトーク | AWS がデジタル主権の要件を満たすためにどのように支援できるか Mehmet Bakkaloglu, Principal Solutions Architect, AWS, and Addy Upreti, Principal Technical Product Manager – Digital Sovereignty, AWS 公共部門や、ヘルスケア、金融サービス、通信などの規制対象産業のお客様が、クラウドジャーニーにおいてデジタル主権に関する課題にどのように対処しているかを共有しています。このチョークトークでは、AWS が設計段階からデジタル主権を考慮していること、そしてデジタル主権のニーズを満たすことができる様々な機能について学ぶことができます。さらに、これらのニーズを満たすための選択肢をさらに提供するために、AWS European Sovereign Cloud がどのように構築されているかを確認できます。AWS がお客様の要件を満たしながら、クラウド移行をどのように加速できるかについて説明します。 HYB310 | チョークトーク | ハイブリッドおよびエッジサービスによるデータレジデンシー要件への対応 Sedji Gaouaou, Senior Solutions Architect, AWS, and Fabio Rodriguez, Head of Hybrid Cloud Solutions Architect, AWS データ レジデンシーは、個人識別情報 (PII)、金融データ、医療データ、または国家安全保障に関する情報など、センシティブな情報を収集・保存する組織にとって重要な考慮事項です。複数の地域で事業を展開する組織が、データ レジデンシー要件を満たしながらイノベーションを推進できるよう、AWS は AWS リージョン、AWS Dedicated Local Zones、AWS Local Zones、AWS Outposts など、複数のグローバルインフラストラクチャソリューションを提供しています。このインタラクティブなチョークトークセッションでは、これらのインフラストラクチャソリューションがデータ レジデンシーのニーズを満たしながら、デジタルトランスフォーメーションを加速させるのにどのように役立つかを紹介します。 パートナーとのセッションを含むデジタル主権に関するコンテンツの全容については、 AWS re:Invent カタログ を参照し、デジタル主権 (Digital Sovereignty) でフィルターをして絞り込んでください。現地参加できない方は、 バーチャル参加用の無料パスに登録 して、基調講演やイノベーショントークのライブ配信を視聴し、オンデマンドのブレイクアウトセッションにアクセスできます。ラスベガスでお会いできること、またはライブ配信でご参加いただけることを楽しみにしています！ Marta Taggart Marta はシアトルを拠点とする AWS セキュリティ製品マーケティングのプリンシパル・プロダクトマーケティングマネージャーで、デジタル主権に焦点を当てています。仕事以外では、保護犬のジャックが最高の人生を送れるようサポートしています。 Rachel Zheng Rachel はハイブリッドクラウドとエッジコンピューティングに焦点を当てたシニアプロダクトマーケティングマネージャーです。仕事以外の時間には、ハイキングをしたり、ベイエリアの新しいレストランを開拓したりしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 10 月 2 日に公開された「 Enhancing data privacy with layered authorization for Amazon Bedrock Agents 」を翻訳したものとなります。 お客様は、自社のアプリケーション内で生成 AI を使用することにいくつかの利点を見出しています。ただし、生成 AI を使用すると、アプリケーションの脅威モデルを検討する際に新たな考慮事項が追加されます。これは生成 AI の利用が、オペレーション効率を高めるために顧客体験を向上させるためであっても、よりカスタマイズされた特定の結果を生成するためであっても、その他の理由であっても同様です。 生成 AI モデルは本質的に非決定論的です。つまり、同じ入力が与えられても、モデルの確率的性質により、生成される出力は異なる場合があります。 Amazon Bedrock などのマネージドサービスをワークロードで使用する場合、Amazon Bedrock がアクセスするデータの保護を確実にするのに役立つ追加のセキュリティ上の考慮事項があります。 本ブログでは、生成 AI サービスを使用する際のデータのコントロールで直面する可能性のある現在の課題と、Amazon Bedrock 内のネイティブソリューションと階層化された認可を使用してそれらを克服する方法について説明します。 定義 まず始めに、いくつかの言葉の定義を確認してみましょう。 Amazon Bedrock エージェント: Amazon Bedrock エージェント を使用すると、企業のシステムやデータソースにわたる複数ステップのタスクを自律的に完了できます。エージェントは、入力データを充実させてより正確な結果を得ることや、繰り返しの多いタスクの自動化に使用できます。生成 AI エージェントは、エージェントがアクセスできる入力と環境のデータに基づいて意思決定を行うことができます。 階層化された認可: 階層化された認可とは、初めにアクセスされるポイントからアプリケーションコンポーネント間で複数の認可チェックを実装する手法です。これには、サービス間の認可、アプリケーションコンポーネント全体で真のエンドユーザーのアイデンティティを伝達すること、そしてサービスの認可に加えて各操作にエンドユーザーの認可を追加することが含まれます。 信頼できるアイデンティティの伝搬: 信頼できるアイデンティティを伝搬することで、AWS リソースへのユーザーアクセスの定義、付与、およびログ記録がより簡単になります。信頼できるアイデンティティの伝播は OAuth 2.0 の認可フレームワークに基づいて構築されているため、アプリケーションはパスワードを共有しなくてもユーザーデータに安全にアクセスして共有できます。 Amazon Verified Permissions: Amazon Verified Permissions は、証明可能な正しい Cedar ポリシー 言語を使用するフルマネージド型の認可サービスであり、より安全なアプリケーションを構築できます。 チャレンジ AWS で構築する場合、データやお客様の情報を安全に保つのに役立ついくつかのサービスや機能があります。これには、 Amazon Simple Storage Service (Amazon S3) のデフォルト暗号化や AWS Key Management Service (AWS KMS) キーによる保存時の暗号化、または Amazon S3 のプレフィックスや Amazon DynamoDB のパーティションキーを使用してテナントのデータを分離することが含まれます。これらのメカニズムは、保存中のデータの処理やデータパーティションの分離には優れています。しかし生成 AI を搭載したアプリケーションがユーザーの入力に基づいてさまざまなデータ（異なるタイプの機微データ、複数のテナントのデータなど）にアクセスできるようになると、機微データが漏洩するリスクが高まります（AWS のデータプライバシーの詳細については、 データプライバシーに関するよくある質問 を参照してください）。これは、データへのアクセスが、ワークロードのなかで呼び出し元のプリンシパルに代わって信頼できないアイデンティティ (モデル) に渡されるためです。 多くのお客様が、ユーザーの入力に追加情報を付加して応答を改善するために、アーキテクチャに Amazon Bedrock エージェント を使用しています。またエージェントは、反復的なタスクを自動化し、ワークフローを効率化するためにも使用されます。たとえば、チャットボットは、医療提供者向けに患者の検査結果をまとめるなど、ユーザーエクスペリエンスを向上させるための便利なツールになります。ただし、チャットボットソリューションを実装する際には、潜在的なセキュリティリスクと緩和戦略を理解することが重要です。 一般的な生成 AI アプリケーションのアーキテクチャには、 Amazon API Gateway を介してチャットボットエージェントを呼び出すものがあります。API Gateway は Amazon Cognito または AWS Lambda オーソライザーを使用して API 呼び出しを検証し、その後チャットボットエージェントにリクエストを渡してその機能を実行します。 チャットボットエージェントにユーザーが入力プロンプトを提供できる場合、潜在的なリスクが生じます。この入力により、プロンプトインジェクション（ OWASP LLM:01 ）または機微情報の漏出（ OWASP LLM:06 ）の脆弱性につながる可能性があります。根本的な原因は、チャットボットエージェントがその機能を果たすために、さまざまなデータストア (S3 バケットやデータベースなど) へのアクセス権を持つ AWS Identity and Access Management (IAM) サービスロール による広範なアクセス権限を必要とすることです。適切なセキュリティコントロールがない場合、あるテナントの脅威アクターが、別のテナントに属するデータにアクセスしたり操作したりする可能性があります。 解決策 すべてのリスクを軽減できる単一のソリューションはありませんが、コンシューマーアプリケーションの適切な脅威モデルを用意してリスク (データへの不正アクセスなど) を特定することは重要です。AWS では、適切な脅威モデルを作成するのに役立つ、いくつかの生成 AI セキュリティ戦略を提供しています。本ブログでは、コンシューマーアプリケーションをサポートするソリューションを中心に、アプリケーション全体にわたる階層化された認可に注目します。 注 : これは、ワークフォースアプリケーション向けの Trusted identity propagation (TIP) と Amazon S3 Access Grants を使用して実現することもできます。 コンシューマー向けの OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) などの強力な認証プロセスを多要素認証 (MFA) と組み合わせて使用することで、API Gateway でエージェントを呼び出すためのアクセスを統制できます。図 1 に示すように、リクエストのヘッダーにある JWT トークンを使用して、エージェントにカスタムパラメーターを渡すことをお勧めします。このような構成では、エージェントが記述された機能を実行する前に、 Amazon Verified Permissions を使用して isAuthorized リクエストを評価し、呼び出しユーザーが要求されたデータにアクセスできることを確認します。このアーキテクチャを図 1 に示します。 図 1: 認可アーキテクチャ アーキテクチャの手順は次のとおりです。 クライアントはアプリケーションフロントエンドに接続します。 クライアントは、認証のための Amazon Cognito ユーザープール UI へリダイレクトされます。 クライアントは Amazon Cognito から JWT トークンを受け取ります。 アプリケーションフロントエンドは、クライアントから提示された JWT トークンを使用して Amazon Bedrock エージェントへのリクエストを認可します。アプリケーションフロントエンドは、 InvokeAgent API 呼び出しに JWT トークンを追加します。 エージェントはリクエストを確認し、必要に応じてナレッジベースを呼び出たり、Lambda 関数を呼び出したりします。エージェントは、アプリケーションフロントエンドから提供された JWT トークンを Lambda 呼び出しコンテキストに含めます。 Lambda 関数は JWT トークンの詳細を使用して、Verified Permissions を使用して DynamoDB テーブルへの以降の呼び出しを認可します(6a)。呼び出しが認可された場合のみ DynamoDB テーブルを呼び出します (6b)。 ディープダイブ Amazon Bedrock エージェントをトリガーする API Gateway の背後にあるアプリケーションを設計する場合を考えます。このとき、 AssumeRole により Amazon Bedrock へのアクセス権を付与する信頼ポリシーを使用して、エージェント用の IAM サービスロールを作成する必要があります。このロールにより、Amazon Bedrock はエージェントアクショングループの Lambda 関数用 OpenAPI スキーマを S3 バケットから取得でき、指定されたモデルへの bedrock:InvokeModel アクションが可能になります。エージェントのセッションデータを暗号化するためにデフォルトの KMS キーを選択しなかった場合は、カスタマー管理の KMS キーにアクセスするための権限を IAM サービスロールに付与する必要があります。ポリシーと信頼関係の例を次に示します。 次のポリシーは、Amazon Bedrock モデルを呼び出す権限をエージェントに付与します。“Resource“ では、承認された基盤モデル(FM)を対象としています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicy", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:us-west-2::foundation-model/your_chosen_model" ] } ] } Plain text 次に、Amazon Bedrock エージェントに s3:GetObject へのアクセスを許可するポリシーステートメントを追加します。このステートメントでは、アカウント番号が組織内のアカウント番号と一致する S3 バケットを対象とします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentDataStorePolicy", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::S3BucketName/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Account_Number" } } } ] } Plain text 最後に、定義されたロールを引き受ける権限を Amazon Bedrock に付与する信頼ポリシーを追加します。また、 混乱する代理問題 を防ぐため、サービスがアカウントに代わって呼び出していることを確認するための条件も追加しました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentTrustPolicy", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "Account_Number" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock:us-west-2:Account_Number:agent/*" } } } ] } Plain text Amazon Bedrock エージェントはサービスロールを使用しており 、一般には利用者のアイデンティティを伝搬しません。これは、テナントのデータを保護する上での潜在的な問題につながる可能性があります。エージェントが未分類のデータ（訳者注: 保護の必要ないデータ）にアクセスしている場合、認可の呼び出し元に基づいてアクセスをさらに分離する必要がないため、階層化された認可を追加する必要はありません。ただし、アプリケーションが機微データにアクセスできる場合は、認可をエージェントの機能の処理に加える必要があります。 そのためには、エージェントを呼び出してトリガーされる Lambda 関数に認可の階層を追加します。まず、エージェントを初期化して、 Verified Permissions への isAuthorized 呼び出しを行います。 Allow 応答があった場合にのみ、エージェントは残りの機能を実行します。Verified Permissions からの応答が Deny の場合、エージェントはステータス 403 またはわかりやすいエラーメッセージをユーザーに返す必要があります。 Verified Permissions には、データへのアクセス時にどのように認可を行うかを規定するポリシーがあらかじめ組み込まれている必要があります。たとえば、呼び出し元のプリンシパルが医師の場合に、患者の記録へのアクセスを許可する次のようなポリシーがあるかもしれません。 permit( principal in Group::"doctor", action == Action::"view", resource ) when { resource.fileType == Sensitive && resource.patient == doctor.patient }; Plain text この例では、この決定を処理する認可ロジックはエージェントから呼ばれる Lambda 内にあります。そのために、Lambda 関数はまず、Amazon Bedrock エージェントにカスタムパラメータとして渡された JWT をデコードしてエンティティ構造を構築し、呼び出し元のプリンシパルのアクセスを評価します。リクエストされたデータには isAuthorized 呼び出しも含める必要があります。このデータが Verified Permissions に渡されると、提供されたコンテキストとポリシーストア内のポリシーを評価しアクセス可否を決定します。ポリシー決定ポイント (Policy Decision Point: PDP) として、許可または拒否の決定はアプリケーションレベルで実施する必要があることに注意します。この決定に基づいて、データへのアクセスが許可または拒否されます。アクセスされるリソースは、アプリケーションがアクセス制御を評価しやすいように分類する必要があります。たとえば、データが DynamoDB に保存されている場合、患者は Verified Permissions スキーマで定義された階層的に参照されるパーティションキーで区切ることも考えられます。 結論 本ブログでは、AWS ネイティブサービスを使用して Amazon Bedrock エージェントを使用するコンシューマーアプリケーション全体に階層化された認可を適用することで、データ保護を向上させる方法を学びました。また、 アイデンティティプロセスを通じてアクセス制御の適用を改善する手順を説明しました。これは Amazon Bedrock エージェントを使用してアプリケーションを構築するのに役立ち、データの強力な分離を維持することで意図しない機密データの漏洩を防ぐことができます。 Verified Permissions と Amazon Bedrock エージェントを使用してアプリケーション全体に階層化された認可を適用する方法について詳しく学ぶには、「 Secure Generative AI Solutions using OWASP Framework 」ワークショップをお勧めします。 本ブログについて質問がある場合は、 AWS サポートにお問い合わせください 。 Jeremy Ware Jeremy は、生成 AI ワークロードの ID アクセス管理とセキュリティを専門とするシニアセキュリティスペシャリストソリューションアーキテクトです。Jeremy と彼のチームは、AWS のお客様が高度でスケーラブルで安全なワークロードを実装してビジネス上の課題を解決できるよう支援しています。Jeremy は長年にわたり、多くのグローバル企業でセキュリティの成熟度を向上させてきました。自由時間には、Jeremy は家族と一緒にアウトドアを楽しんでいます。 Yuri Duchovny Yuri はニューヨークを拠点とするプリンシパルソリューションアーキテクトで、クラウドセキュリティ、アイデンティティ、コンプライアンスを専門としています。Yuri は大企業のクラウド変革を支援し、企業が最適なテクノロジーと組織的な意思決定を行えるよう支援しています。AWS での職務に就く前は、アプリケーションとネットワークのセキュリティ、DoS、不正防止に注力をしていました。仕事以外では、スキー、セーリング、世界中への旅行を楽しんでいます。 Jason Garman Jason は、バージニア州北部に拠点を置く AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。Jason は、世界の大手組織が重大なセキュリティ課題を解決できるよう支援しています。AWS に入社する前にはサイバーセキュリティ業界で、スタートアップを含む官民を問わないさまざまな役割を果たしていました。彼は出版作家で、サイバーセキュリティ技術に関する特許を保有しており、家族と一緒に旅行するのが大好きです。 翻訳はプロフェッショナルサービス本部の池澤、藤浦が担当しました。

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. Panel Discussion: A History of Digital Transformation Forged with AWS Shimpei Otani, Group Executive Officer (CTO & CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. Shigeru Horikawa, Director (Infrastructure), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yasuhiro Kitaguchi, Director (SCM & Integration Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yuichi Murata, Director (Core Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Kempei Igarashi, Senior Manager, Retail, Consumer Goods & Services Business Group, Amazon Web Services Japan G.K. Career and Responsibilities of the Panelists First, the panelists talked about their own careers. Mr. Otani joined Fast Retailing in 2016 with a mission of internalizing engineering and embedding technology in the business. Currently he is the Chief Technology Officer and also in charge of security. Regarding the relationship with AWS, almost all Fast Retailing services run on AWS, leveraging it for over 12 years. He also shared the facts that he was actually an AWS Solutions Architect in his previous role and had visited Fast Retailing as a service provider during that time. Since joining in 2012, Mr. Horikawa has experienced shifting from on-premises to cloud, with 12 years of experience working with AWS. Entering a company like Fast Retailing meant a major shift in his goals as an engineer, from system implementation to business results themselves. Since joining in 2018, Mr. Kitaguchi has been responsible for developing common platforms and the data integration platform. Currently his focus is on logistics process reform and preparing digital tools. His AWS involvement began after joining Fast Retailing, consulting with AWS product teams when building new systems to determine optimal architectures. Mr. Murata joined in 2017 and experienced the Ariake Project from launch. Starting with developing back-end systems for e-commerce, he went through roles in infrastructure and quality assurance before becoming department manager overseeing in-house development (his current role). E-commerce heavily utilizes AWS with ongoing support. He also introduced a new initiative leveraging Amazon Connect to reform call center operations. Dawn Period – Fostering Culture The discussion began with the theme “Dawn Period – Fostering Culture”. Mr. Horikawa, with the longest tenure, looked back on episodes from when he joined. He learned AWS through seminars and vendor support. Before deciding to use AWS, he gained experience while receiving support from AWS Solutions Architects and others. Initially there were no architecture review processes, and failures like system outages due to lack of quality assurance occurred. Architecture reviews were born by learning from such failures. Mr. Otani shared stories about the Ariake automated warehouse project, which unlike IT projects, had physical constraints like installing the warehouse hardware, giving him a taste of the pains unique to an apparel company. The project was still chaotic then without a clear picture, but consistently recruiting talented people has created an environment conducive to exchanging wisdom. Addressing critical issues collaboratively naturally fostered the current culture. Mr. Horikawa also talked about negotiating with AWS over a 4TB database instance for an SAP implementation. At the time he believed it could only be done on-premises, but looking ahead to future growth, he negotiated with AWS and made it happen. This experience taught him that even seemingly impossible things could be achieved through proper negotiation. As described above, Fast Retailing fostered their current culture by overcoming various failures and challenges with AWS from the dawn period of adoption. Unafraid to challenge and collaborate to solve issues formed the foundation of their culture. Closely cooperating with AWS to nurture this new culture was a major factor enabling Fast Retailing’s digital transformation. Transition Period – Architectural Changes The next theme was the transition period when the team at Fast Retailing implemented many architectural changes. Mr. Murata discussed shifting from the conventional monolithic EC package to a headless platform architecture, achieving microservices, immutable infrastructure adoption, multi-region deployment, leveraging open source and managed services, and standardizing technology. He reflected on the complexity of business logic and challenges with performance and scalability. Mr. Kitaguchi explained how they initially started by just lifting and shifting their on-premise applications onto the cloud, and then gradually moved towards containerization and building CI/CD pipelines with global deployment in mind. Cost-conscious tool provision and close collaboration with business departments for cost awareness were also covered. Mr. Otani talked about standardization initiatives. The background of adopting Amazon Aurora and Amazon ElastiCache as a standard and establishing criteria for programming languages and frameworks was introduced. The struggles with proliferating tools seem to have driven the perception that some standardization is essential. On the other hand, Mr. Otani also pointed out the importance of maintaining appropriate flexibility in technology selection. Excessive standardization causes loss of flexibility, so preserving suitable options for engineers is also important. These standardization efforts occurred during large-scale concurrent development. Architectural transformation was carried out in stages looking ahead to global expansion, achieving a break-down into platforms and microservices, achieving standardization, etc. Expansion Period – Globalization Regarding globalization challenges, Mr. Murata talked about local considerations. They operate multiple brands across roughly 30 markets, requiring a global platform while also addressing needs from each country. Proper prioritization and efficiency are important, but a “global-solution” does not necessarily fit all regions. Aspects like delivery methods and data privacy handling require localization. Mr. Otani added that technical issues cannot always be decided solely by engineers, sometimes requiring management judgment considering geopolitical risks. Mr. Horikawa talked about network optimization changes. Initially all store communication concentrated to Tokyo, but now leveraging the AWS network fully, connecting each country directly to the nearest AWS Region improved speed and availability by utilizing the AWS backbone network. Mr. Kitaguchi said based on the characteristics of location-based systems with high customization and requirements variation, they take an approach of building global core aspects like consistent inventory management and streamlining shipping/receiving workflows, then adding localized custom wrappers. Cultural alignment is also important in multinational teams. Shared values represented in the mission statement foster decision-making and unity in diverse teams. Building an inclusive environment through mission sharing offers something to learn for any organization driving a cloud journey. Security Mr. Otani, also CSO, commented on security. Information systems today especially require enterprise-wide security uplift. Security encompasses many aspects beyond just technology, like executive awareness and physical measures. In addition to IT security, operational measures are indispensable for protecting customer information. Fast Retailing aims not just to meet IT security standards, but exceed them. He emphasized holistically addressing security aligned to corporate mission and ingraining appropriate standards into organizational culture. However, excessive security rigidness risks losing the creativity and added value that IT brings. Striking the right balance between security and IT flexibility is key, with an important security team role being to maintain that balance. Summary Closing comments by members are summarized as follows: Selecting cloud and platform products should consider not just current capabilities, but future evolution based on organizational culture. AWS was initially established to address the business challenges of Amazon, a company rooted in retail. AWS shares a customer-centric culture with Fast Retailing in many ways. Fast Retailing evaluated AWS as a company that continues to evolve in order to address customer needs. Reflecting on their 12-year collaboration, Fast Retailing aims to strengthen strategic partnership with AWS for global expansion. Finally, they concluded the panel discussion with a heartfelt message inviting engineers from diverse backgrounds to join them and grow the team. Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. The AWS Infrastructure Supporting Fast Retailing’s IT Shigeru Horikawa, Director, Infrastructure, Digital Business Transformation Services, Fast Retailing Co., Ltd. Mr. Horikawa from the Infrastructure team spoke about Fast Retailing’s history and the current status of AWS cloud utilization, as well as the ingenuity involved in operating a large-scale cloud environment with a small team. Fast Retailing needs to connect over 3,500 stores globally, support an ecommerce (EC) business in around 30 markets, and help sustain the entire supply chain, including warehouses and factories worldwide. To keep up with the rapid business expansion, instead of building data centers for each business, a cloud that can scale globally and procure infrastructure quickly became essential. A major reason for cloud adoption was the 2017 EC site downtime. Experiencing 3 days of downtime and facing issues like difficulty in on-premises capacity expansion and traffic control made them understand the need for cloud adoption. Fast Retailing’s cloud journey began around 2012 with the use of AWS for some campaign sites. In 2013, a cloud adoption project was launched in parallel with another initiative to modernize the existing legacy core systems. From 2016 to 2017, large-scale migration (lift & shift) from on-premises to cloud was carried out through the “Ariake Project” Around 2021, global expansion was accelerated further and AWS utilization expanded even more. The benefits of cloud adoption included: Scalability and capacity assurance: Easy scaling up and capacity expansion as needed Architecture modernization: Shift from legacy systems to modern architectures like microservices Securing engineers: Easier hiring of cloud engineers and improved acquisition of partners and developers Availability assurance: Establishment of cost-efficient backup sites across Availability Zones and regions for disaster recovery Infrastructure cost optimization: Adjust resources between peak and off-peak times to optimize infrastructure costs Current AWS usage includes over 60 accounts, 15+ regions, 13,000+ VMs, 3,000+ databases, and 120,000+ containers operated by a team of around 20 members. Various measures are taken to manage this large-scale infrastructure with a small team. Main initiatives include: Architecture reviews: Three review boards, Commerce, Enterprise, and CTO, review projects from planning to operational requirements and security from diverse perspectives Automation and codification: Adoption of Infrastructure as Code (IaC), cost management automation, standardized automated AWS account creation, etc. Self-service: Application teams can independently build, test, and deploy code with full responsibility on their part. Cost management: Visualize cost trends by system using tag-based cost allocation for application teams to manage costs with full responsibility on their part. Unified system monitoring platform: Consolidated disparate monitoring platforms so all the members can centrally view metrics and application behavior, reducing troubleshooting time Security measures: Leverage AWS security solutions for integrated multi-account security management. Aggregate security information into a security account integrated with a SIEM platform to enable early vulnerability detection and response Future initiatives include broader use of Kubernetes beyond ECS containers for more granular self-service parameter control, strengthening regional infrastructure teams to accelerate global expansion and achieve follow-the-sun operations, and building a global project promotion system. Through various measures like automation, self-service, and centralized monitoring, they have achieved large-scale cloud operations with a small team. Mr. Horikawa shared how companies accelerating global expansion can efficiently operate large-scale cloud environments using AWS. A Look Behind the Scenes of UNIQLO and GU’s E-Commerce Apps Shunsuke Akimoto, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Daisuke Sano, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, members of the Core Engineering team gave us a behind-the-scenes look at UNIQLO and GU’s e-commerce (EC) apps. First, Mr. Akimoto talked about a case of significant performance improvements and cost reductions in the cart function of the EC site. The cart function plays an important role when selecting and purchasing items on GU and UNIQLO apps and web services. The previous architecture had Application Load Balancer on top, with Amazon Elastic Container Service (Amazon ECS) below that, and the Amazon ECS API Service reading data from Amazon Aurora . However, with this configuration, the database became a bottleneck during traffic surges like popular item sales, causing response times to deteriorate significantly. There was also the issue that upgrading database instances increased costs, putting pressure on the infrastructure budget. To solve these issues, they decided to adopt Redis, a NoSQL database, as the main database. By using Amazon ElastiCache , they achieved major performance improvements while ensuring high scalability. The new architecture has the API Service directly reading and writing data to Amazon ElastiCache, with asynchronous data synchronization between Amazon ElastiCache and Amazon Aurora. This maximized the performance of Redis. Implementation ingenuity included creation of their own locking mechanism using Lua scripts and efficient extraction of updated carts using Redis Sorted Sets. Data migration was done with zero downtime, gradually migrating data to Redis while continuing operations. As a result, even with over double the traffic that previously caused issues, no performance degradation was observed. Response time improved significantly from over 10 seconds at p95 to 160ms, with potential for handling much larger traffic increases. Costs were also greatly reduced, with additional optimization through Amazon ElastiCache for Redis’ Data Tiering feature. Ultimately, database costs were reduced by over 60% with scalability assured for the next 10 years. They demonstrated how effectively leveraging cloud services can achieve both performance improvements and cost reductions simultaneously. Next, Mr. Sano talked about the search platform. Fast Retailing’s systems comprise interconnected microservices for each business function, with a data integration platform and API integration. The search platform is a microservice providing search functionality, utilizing inventory, pricing, product, and other information from other platforms. Main functions include keyword search, creating product lists for category pages, keyword suggestions, similar product listings, in-store inventory search, etc. Amazon OpenSearch Service is currently used by some platforms including the search platform. Three main features of Amazon OpenSearch Service are: Enabling registration of large amounts of data with flexible structures Enabling keyword search and flexible queries Fully managed service that easily scales in/out based on request volume Advantages of Amazon OpenSearch Service include high performance and scalability for read-heavy applications, and reducing development by having typical e-commerce search features built-in. Key requirements for global digital commerce search are efficiently supporting multiple brands, countries/regions, and language capabilities. These key requirements included: Functionality: Since building language-specific parsing in-house is difficult and inefficient, having built-in features like syntax analysis and normalization is important Ease of deployment: Adopting architecture where data automatically flows into Amazon OpenSearch Service Scalability: Easy scaling in/out Operability: Developing efficient tools for registering words and synonyms Future challenges include reducing operational costs of registering words and synonyms. Leveraging machine learning-based technologies (large language models, vector search, semantic search, etc.) are being considered to address future challenges. Other challenges are developing features to improve user experience beyond keyword search, and expanding to new regions in parallel with improving the search platform. Application Development Using Amazon ECS to Achieve Execution Control of Data Integration Infrastructure Kei Sakamoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Hirohito Yoshimoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, Mr. Sakamoto from the Integration Engineering Team introduced their data integration platform initiatives. The Integration Engineering Teams’ responsibilities include improving system development efficiency, as well as the development, management, and operational excellence of the data integration platform at Fast Retailing. As a digital consumer retailing company investing in end-to-end processes, data integration and batch processing became complex at large-scale. This required streamlining data, preparing tools for data utilization, and achieving high-speed processing to handle increasing data volumes after multi-brand launch and multinational expansion. They are addressing these challenges with two main concepts. First is preparing the batch processing framework, with a system that can control process dependencies and parallel distribution, organizing complex dependencies into more manageable forms. Second is preparing the data integration platform, building a cloud-native hub-and-spoke model platform to centrally manage all information and streamline data. Key features are easy routing control by definition, distributed deployment tailored to business domain characteristics, and covering various protocols and data formats. Four key requirements for this platform are: Stability: High stability required as it supports the business core Performance: Ability to plan for performance and capacity to withstand business fluctuations Portability: Easy distributed deployment Integration with diverse applications: Seamless integration with various applications Afterwards Mr. Yoshimoto introduced the specific architecture of the data integration platform, as well as challenges and ingenuity during development. The data integration platform is designed as a hub-and-spoke model system to efficiently integrate data between business domains, currently operating as 10 services across 2 clouds and 6 regions. Its development history began in 2015 as a batch processing platform, gradually expanding functionality to evolve into a data integration platform. Containerization and infrastructure codification were implemented in 2019, with enhanced multi-cloud support in 2021. Key considerations in development and operation include environmental reproducibility, scalability, ease of customization, cloud vendor independence, etc. Regarding task execution management using Amazon ECS, they independently implemented solutions to address issues like rate limits on API calls per time unit and difficulty with synchronous task status management. Specifically, the team wraps worker applications with a wrapper to operate as part of the overall framework, implementing a mechanism to synchronously grasp task status via heartbeats and callbacks. This avoids frequent polling queries to the ECS cluster for status checks, enabling more timely application execution monitoring and management. Three future challenges are: Further streamlining and self-service in deployment: Enabling business application teams to easily construct data integration mechanisms Enhancing integration with new services: Achieving stable integration with new digital reform services Promoting data utilization: Further integrating with data accumulation/analysis processes to create business value In closing, the speakers introduced how this initiative aimed to contribute to the business by consolidating complex data integration and batch processing, appropriately leveraging cloud services, and packaging as a solution. (To be continued in Part 3 ) Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture titled “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post will report on the contents in three parts. The job titles are as of the day of event. Opening: Business transformation and digital initiatives at Fast Retailing Shimpei Otani, Group Executive Officer (CTO and CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. First, Mr. Otani explained Fast Retailing’s business concept and the “Ariake Project” aimed at digital transformation. Under the mission statement “Changing clothes. Changing conventional wisdom. Change the world.”, Fast Retailing operates 8 brands including UNIQLO, GU, PLST, Theory, COMPTOIR DES COTONNIERS, and PRINCESSE tam tam. With around 3,600 stores in about 30 countries and regions, it has grown into one of the world’s largest apparel retailers with 2.7 trillion yen (as of August 2023 period) in revenue. UNIQLO in particular leads overseas operations, accounting for 60% of revenue. Aiming to provide “LifeWear” as the ultimate everyday clothes to enrich everyone’s lives and delivering high-quality clothes at affordable prices is the company’s concept. Through “PEACE FOR ALL” initiatives, Fast Retailing also focuses on social contribution, donating profits from collaboration T-shirts with well-known personalities and companies wishing for peace for people affected by conflict and discrimination. As part of digital transformation efforts, Fast Retailing is promoting the Ariake Project. Its aim is to shift from a manufacturing retailer to a “digital consumer retailing company” transforming operations to deliver only what customers truly want. Based on the insights from customers—customer voices—the goal is to connect planning, manufacturing/logistics, and sales digitally to deliver the right products in the right amounts at the right time. Around 110,000 employees worldwide work as one team, leveraging data to accurately grasp customer needs and respond swiftly. By visualizing and optimizing the entire process from planning to sales with data, the aim is to eliminate waste while improving customer satisfaction and reducing costs. Engineers play the core role, and as the name Digital Business Transformation Services suggests, the focus is not just on IT but on transforming how work is done. Specific initiatives include introducing RFID-based self-checkout systems to enable seamless shopping experiences across stores and e-commerce. Fast Retailing is also promoting logistics automation and efficiency through introducing autonomous delivery robots, showing a wide range of software and hardware initiatives. The Ariake Project aims to maximize digital capabilities to achieve its business transformation and shift to a “digital consumer retailing company”, while adopting cutting-edge technologies. The goal is to build an optimal platform on AWS and realize value provision to customers through this large-scale challenge. Through digital transformation, Fast Retailing seeks to fulfill its mission of “Changing clothes. Changing conventional wisdom. Change the world.”. Evolution of In-house Development at Fast Retailing Yuichi Murata, Director, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, Mr. Murata from the Core Engineering team that promotes in-house development at Fast Retailing introduced the company’s history of digital transformation and efforts in their in-house development. The company has long recognized the importance of incorporating digital technologies into operations, beginning with the introduction of a POS system in 1988, and started digital processing of product and sales information in-house in the 1990s. In the 2000s, an online store was opened, leading advancements of various digital transformations such as operations by store staff using digital devices in the 2010s. With the Ariake Project, a company-wide reform project that started in 2016, in-house engineering was formally launched. Through these in-house development efforts, reforms such as RFID-based self-checkout and inventory management, and building an e-commerce platform for global expansion have been realized. The background for bringing development in-house includes the strategy to fully shift from a manufacturing retailer to an information retailer by leveraging information. To achieve this, it was necessary to build platforms in-house. In addition, with the mindset “business = systems” deeply understanding operations, building simple and clear complete systems, and constructing systems that align with the future direction were considered important. When promoting in-house development, the company started with e-commerce, gradually expanding functions by establishing a membership base, opening a catalog site, and enhancing online store capabilities. Beginning such mechanisms with the country where they have newly launched business operations and expanding scope to both Japan and global markets were also key approaches. The organization has hired global talent, adopted English as the main language, and taken various other steps to promote a global environment. A hybrid system has also been adopted where full-time employees and partner companies form single scrum teams. For engineer talent development, the focus is on strategically nurturing senior engineers who understand the business and can reflect their views onto technical decisions. Specifically, an architecture review board has been established for training in breaking down various business requirements into system designs. Rotating board members enables continuous talent development. Major achievements of in-house development include improved speed in resolving issues and gaining control over systems. Since the company built the systems itself, it’s easy to identify problem areas and respond swiftly. Being able to make important decisions quickly, such as technology selection and understanding business logic, has also been a major result. Challenges include bridging the original apparel retailer culture and IT engineering culture, Japanese and global cultures, and handling global scale. Going forward, with a goal of 10 trillion yen in annual revenue, the aim is to build the world’s top level global engineering organization from Japan. To achieve this, continuously developing senior engineers who understand the business and who can make technical decisions will be indispensable. The company aims to provide the most rewarding workplace in the world for engineers, offering valuable opportunities to take on world-class business challenges and fostering an environment where engineers can grow the most by overcoming difficulties. Microservices Platform Supporting Global Expansion, Store and EC Integration, and Business Growth to 10 Trillion Yen Revenue Xiao She, Manager, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Natsuki Inoue, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, members of the Fast Retailing Core Engineering team introduced the microservices platform supporting global expansion, and initiatives to integrate e-commerce (EC) and brick-and-mortar stores. First, Mr. She gave an overview of past initiatives. Previously, different EC systems were used for each brand and region, resulting in high costs for function development and operations, as well as inefficiencies. Therefore, in 2017, renewal of EC was undertaken to provide one global EC solution worldwide. In 2020, the global EC package was released in Japan, followed by the US in 2021 and Korea in 2024. The new EC platform is unified not only in design but functionality as well. The basic policy for deploying the global EC platform is supporting multiple brands and accommodating different languages, payment methods, and legal systems in each country while achieving both global standardization and localization. Going forward, continuous rollout to regions across the world is planned in line with Fast Retailing’s business expansion. A key characteristic of Fast Retailing’s EC is integration with brick-and-mortar stores. In addition to common EC functions like purchase history, notifications, and chatbots, the system incorporates O2O (Online to Offline, Offline to Online) capabilities for integrating EC and brick-and-mortar stores. O2O services include: “store pickup” to have EC purchased items delivered to a store, “ORDER & PICK” to order inventory originally in a store via EC, and “store shipping” for direct shipping from store inventory to home. These realize benefits like free shipping, shorter delivery times, driving customers to stores, and optimizing warehouse capacity. Next, Mr. Inoue explained the system configuration and architecture of the EC platform. Fast Retailing develops and operates the EC system as a global platform, clearly separating front-end and back-end responsibilities. The back-end consists of microservices covering different business domains in a cross-brand manner, while front-ends are developed specifically for each brand. In terms of request flow, the structure is configured as follows: user device -> front-end client -> BFF (Backend for Frontend) -> back-end microservices. The BFF role is to aggregate data by calling multiple microservices and returning the response in a format convenient for the client. It also handles data caching and authentication/authorization. The back-end provides independent APIs as microservices covering specific business domains. For example, when a user purchases a product, microservices for shopping cart, product information, amount calculation, coupons, inventory, payment, order management, etc., receive the requests, execute the required logic, and return the results. The front-end consists of a responsive web SPA (Single Page Application) and native mobile apps. The SPA utilizes a common design system and internationalization to enable localization while maintaining unified architecture. Mobile apps also use some native Android/iOS code while building a common codebase with Flutter. As a tech stack, standardization is emphasized across infrastructure, middleware, programming languages, and frameworks. Go, Java, Spring Boot, Node.js, TypeScript etc. are adopted for back-end, while React for front-end, and Kotlin and Swift for mobile. Going forward, global expansion will be accelerated. Rollout will be gradual while addressing various requirements like local languages, payment methods, logistics, and regulations. To achieve the goal of 10 trillion yen annual revenue, handling increased traffic is an issue. Efforts will focus on end-to-end performance measurement and improvement to ensure scalability. O2O initiatives integrating EC and stores are also important. The goal is to enable purchasing desired products anytime, anywhere through seamless linkage between stores and EC. Convenience for customers will be pursued by advancing systems and leveraging the strength of the store network. (To be continued in Part 2 ) Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『生成 AI』『Direct to Consumer & ストリーミング』『コンテンツ制作』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 本ブログでは、AWS 展示の概要をブースセミナーでの展示紹介セッションと共にご紹介します。 AWS 展示コーナーの概要 展示ブースは、5つのソリューションエリアで構成されています。『生成 AI』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の3つは、 INTER BEE AWARD ノミネート作品です。 生成 AI このブースでは、AWS の生成 AI ソリューションでメディアと AI の融合を体感できます。例えば、 動画のメタデータ生成・抽出、要約・検索 、 シーン切り出し 、 スポーツデータ強化 、 ニュース自動要約・検索 、 動画セマンティック検索 、 広告自動生成 など、 AI が映像コンテンツを理解し新しい価値を生み出す先進的な機能をご覧いただくことができます。 展示するソリューションはカスタマイズが容易で、映像の検索や検索拡張生成（RAG）、コンテキスト広告や Shoppable Video の生成などの際にこのワークフローを活用することが可能です。なお、メタデータ等の保存と管理には、容量無制限で柔軟性の高いクラウドストレージの Amazon S3 と高い検索性を有する複数の目的別データベースを使用しています。 Direct to Consumer & ストリーミング このブースでは、クラウドの柔軟性と拡張性を生かした先進的な映像配信の実例を紹介します。デジタル時代のオンデマンドメディアに対応する、 オンデマンド配信 、 ライブ配信 、 パーソナライズド配信 、 動的広告挿入 などの機能を実演します。 例えば上の図は、メディアプレーヤーのリアルタイムログを収集/可視化するシステムのアーキテクチャ図です。OTT サービス事業者や消費者向けサービス事業者は、タイムリーな監視データを使った分析を行う必要があり、本ブースでは Amazon CloudFront のリアルタイムログや Amazon QuickSight を組み合わせてこれを実現しています。また、 Amazon Q を使った Generative BI 機能により、 自然言語による実践的なデータの洞察も可能です。 コンテンツ制作 このブースでは、AWS を活用した スケーラブルなコンテンツ制作環境 や クラウドレンダリング をご紹介します。 AWS Deadline Cloud の簡単なセットアップや CG のクラウドレンダリングのデモ、また Amazon DCV 経由のクラウドワークステーションでのコンテンツ制作ツールの使用感、Wacom Bridge を組み合わせたタブレットの操作感などを体験いただけます。 AWS Deadline Cloud は、カンタンな構築とコスト監視、柔軟な拡張性が特徴の新しいクラウドレンダリングのサービスです。このサービスを利用することで、大規模なクラウドレンダリングを従来の煩雑な管理を大幅に低減しながら実行できるようになるので、クリエイティブな作業に注力することができます。また本デモは、ブースに設置の NetApp ONTAP FlexCache とクラウドストレージの Amazon FSx for NetApp ONTAP を併用したハイブリッドストレージ構成となっており、高頻度データアクセスの高速化やネットワーク負荷の低減効果によって、オンプレミスのスタジオとクラウドをつないだ柔軟な制作環境を提供しています。 放送 – ライブクラウドプロダクション ライブクラウドプロダクションのブースでは、多種多様な映像伝送プロトコルを集約し、さまざまなソリューションを組み合わせてニュースのライブ映像を制作可能なワークフローを展示します。入力信号の1つには、AWS Elemental MediaLive の機能を持ち管理にクラウドを利用しながらも、オンプレミスでライブ動画エンコードを実行できる AWS Elemental MediaLive Anywhere を利用しており、稼働している実機を見ることもできます。 NRCS（Newsroom Compute System）のソリューションを組み合わせることで、 ニュース項目の生成や更新を効率的に実施する運用 や、映像信号のモニタリング環境も同時に展示します。 本ブースはまさに、 放送局の「回線センター」や「報道サブ」で必要な機能をクラウド上で実現した展示 となります。 本展示は、AP、Aximmetry Technologies、LiveU、Sony、Vizrt、Waves Audioなどの専門的なパートナーソリューションや複数のオープンソース、AWSのマネージドサービスを組み合わせて実現しています。また、各映像ソースの信号出力経路、コーデック、パフォーマンス等をリアルタイムに可視化するダッシュボードの展示も行なっています。 放送 – クラウドプレイアウト ユニゾンシステムズ、 Amagi、Ateme などの専門的なパートナーソリューションを組み合わせることで、営放システムと連携したクラウドプレイアウトシステムを展示します。クラウドを用いることで柔軟で効率的なワークフローを構築することができるため、急速な技術の進化に対応することが可能です。 オンプレミス上のマスターシステムを、多様な機能を持つこのクラウドプレイアウトシステムに移行することで、システムの柔軟性と効率性を向上させることが可能となります。また、地理的な場所に関係なく放送配信運行ができたり、さまざまなデータをダッシュボード上に可視化することも可能となっています。 終わりに 今回は、Inter BEE 2024 の AWS 展示についてご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWS ブースセミナーや出展者セミナー、 AWS スポンサー展示等に関する情報は、下記のブログからもご確認いただけます。皆様にお会いできるのを楽しみにしています。 AWS ブースセミナー、出展者セミナーの概要については こちら AWS スポンサー展示、AWS ブースツアーの概要については こちら まとめ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『生成 AI』『Direct to Consumer & ストリーミング』『コンテンツ制作』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 本ブログでは、AWS スポンサー展示の概要を中心にご紹介します。 AWS スポンサー展示コーナーの概要 AWS ブースでは、AWS を利用したメディアソリューションをパートナー 12 社とともにご紹介します。 スポンサー各社の展示概要: 1: ATEME ATEME ( アテメ ) が提供する、集信、3D 映像にも対応した各種エンコード、OTT、DAI から CDN までエンドツーエンドで対応した多機能集配信ソリューションを展示します。オンプレ、クラウドなど、プラットフォームに依存せずに使用できます。 2: 株式会社フォトロン スポーツコンテンツのクラウド上の制作に必要な、 映像の入出力、それらの収録と編集システムをパッケージでサービス提供します。規模のスケール、監視 などオペレーションを含めた総合的な環境をご用意します。 3: Evergent Technologies, Inc. Evergent マネタイズプラットフォームは、最新の技術と AI により、迅速な新規獲得、より良いエンゲージメント、より長いリテンションを実現します。AI を活用し最適な顧客体験を届け、解約率低減、売上最大化を可能にします。 4: 株式会社トラフィック・シム クラウドマスターでご活用いただけるマルチビュー / 同録 / アナライズや電流モニタリングなど、「難しいをひも解く」トラフィック・シムのクラウドサービスを展示します。 5: ソニーマーケティング株式会社 SaaS 型クラウドスイッチャー M2 Live をご紹介します。AI による映像解析サービス A2 Production では業務の DX 化をご提案します。 6: Amagi Amagi は、クラウド放送と広告ソリューションを提供する企業で、世界 150 カ国でコンテンツの配信・収益化をサポートし、24 時間 365 日の管理サービスを展開しています。 7: 株式会社 PLAY 動画や画像、字幕などのファイルや、配信プラットフォームへの入稿までを一括管理できる「KRONOSDRIVE」を展示し、ブラウザ上での動画や字幕の編集、AI を活用した機能などをご紹介します。 8: BytePlus Pte. Ltd. BytePlus Recommend による AutoML や Deep Retrieval など高度な機械学習技術を活用した業界でも定評あるレコメンデーション技術をご紹介します。様々なインサイトを活用し、顧客エンゲージメントを高めユーザー満足度を大きく向上させるソリューションやデモをご覧ください。 9: Datadog Japan 合同会社 世界中の動画配信事業者の皆様から支持されている、AWS でホストされたインフラとアプリケーション環境に統合的なオブザーバビリティとセキュリティを提供する Datadog の機能についてデモを交えてご紹介します。 10: New Relic 株式会社 放送業界の IT システムは、安定稼働だけでなく、顧客体験の向上や迅速な開発など様々な要件が求められます。高度な監視機能によって要件に応えるソリューションを、実ユーザーの活用事例に基づくデモを交えてご紹介します。 11: 株式会社ユニゾンシステムズ 営放システム（編成、営業、CM、放送）のクラウド化と、考査、番組入稿などの開発事例展示。クラウドで共通化されたメディアワークフローと、AI の活用事例についてご紹介します。 12: イノテック株式会社 ワークフローの自動化・省力化・マネタイズに貢献する最先端の海外ソフトウェア＆サービスをご紹介！ # AI 吹き替え # 自動字幕生成 # ファイル QC # リアルタイム配信品質監視 # 視聴動向分析 # リモート編集 # DAI AWS プレゼンテーションステージについて ブース内ミニステージでは、AWS スポンサーおよび AWS によるプレゼンテーションをはじめ、お客様から現場運用でのクラウド活用について発表いただく予定です。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) AWS ブースツアーについて AWS 展示ブースにお越しの皆様に AWS クラウドの活用シーンを深くご理解いただくべく、AWS スポンサーのサービスをはじめ AWS 各展示の見どころをご紹介するツアーを行います。 日付: 2024 年 11 月 13 日（水）、14 日（木）、15 日（金） 時間: 11:00 / 14:00 / 16:00 (各回所要時間約 45 分間を予定) 定員: 各会 12 名まで (登録制) 各回、以下のいずれかのテーマでツアーをご提供しますので、ご興味のある回およびご都合のよろしい時間を選んで お申し込み ください。 Create : コンテンツプロダクション、ライブプロダクションを巡るツアー Monetize : 生成 AI や分析システムを生かしたマネタイズソリューションを巡るツアー Deliver : コンテンツ配信・クラウドプレイアウトのソリューションを巡るツアー 是非 こちら よりご応募ください。 終わりに 今回は、Inter BEE 2024 の AWS スポンサーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWSブース展示や、ブースセミナー、出展者セミナーに関する情報は下記のブログからもご確認いただけます。 AWS ブース展示の概要については こちら AWS ブースセミナー、出展者セミナーの概要については こちら 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 石井 悠太が担当しました。

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースではブースセミナーが開催され、「Create. Deliver. Monetize.」をテーマに、メディア & エンターテインメント業界の客様講演を予定しております。また、幕張メッセ国際会議場では「コンテンツ制作・配信・収益化の最前線 ～ AWS クラウドで実現するイノベーション事例」と題し、メディア & エンターテインメント業界向けの最新動向、及びお客様事例登壇の登録制セミナーを予定しております。 本ブログでは、AWS ブースセミナー、AWS 出展者セミナーのご紹介をします。 AWS ブースセミナーの概要 AWSブース内ミニステージではお客様講演をはじめ、AWS スポンサーおよび AWS によるプレゼンテーションを予定しております。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) 次にお客様講演の概要を記します。 日本テレビ放送網株式会社：テレビ番組 画像生成 AI で「遊べる」web 開発 日本テレビ様の音楽番組「バズリズム 02」ではバカリズムがゲストとのトークを受けてイラストを描いており、その数は約400 点に上ります。この講演では、そのイラストを独自に学習させたモデルを活用した生成 AI の Web サービス開発の取り組みを紹介いただきます。安定したクオリティの確保、ユーザーにストレスない低遅延な画像生成、コンプライアンス面でセキュアなサービス提供といった特有の課題を解決されてゆきました。 株式会社 TBS テレビ：TBS テレビで広がる生成 AI / LLM の活用と未来展望 後日、更新致します。 株式会社 NTT ドコモ：AWS メディアサービスとマルチ CDN を活用した数百万同時視聴ライブの実現方法 NTT ドコモ様において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、AWS メディアサービスとCDNを中心にお伝いただきます。スケーラブルなAWS サービスを活用し通常ライブの運用と変わらずに大規模ライブ配信を実現した内容など、ライブ配信を検討している全ての方に参考となる内容です。 株式会社 AbemaTV：ABEMA のニュースコンテンツ制作における生成 AI 活用事例 ABEMA様 では、ニュースの配信ビジネスにおいて、インターネットを活用したマーケティング施策の強化に取り組んでおり、AI を含む最新技術の導入を進めています。本セッションでは、ABEMA TIMES を代表とするニュースオウンドメディアにおける AI 活用戦略を、具体的な事例とともにご紹介いただきます。 AWS 出展社セミナーの概要（2024年 11月 14日 12:00 – 13:30） 幕張メッセ国際会議場 1F「103」において「コンテンツ制作・配信・収益化の最前線 ～ AWS クラウドで実現するイノベーション事例」と題し、3 社のお客様より先進的な具体事例のご紹介、及び AWS から最新ソリューションのご紹介をします。AWS 出展社セミナーの聴講には InterBEE 公式サイトからの お申込み が必要となります。 講演概要は下記の通りとなります（以下、講演順）。 Amazon Web Services, Inc. / アマゾン ウェブ サービス ジャパン合同会社 テレビ局・動画配信・制作・コンテンツプロバイダーなどのメディア・エンターテイメント企業は、変化の激しい市場環境の中、既存の仕組みにとらわれないビジネス改革が求められています。本セッションでは「Create. Deliver. Monetize.」をテーマに AWS から最新のソリューションをご紹介します。 株式会社フジテレビジョン：大規模国際スポーツイベントにおけるクラウド制作 PoC について フジテレビ様は今回フランス・パリにて行われた大規模国際スポーツイベント環境の中でクラウド制作 PoC を行いました。海外での大型中継における現地制作環境と同様の環境を、AWS クラウド上に構築し、プログラム制作から中継まで、全てをクラウド上にて行う事を本 PoC の一つの目標とされました。クラウド制作環境の構成から、クラウド化によるメリット／デメリット、今後の課題と展望についてご紹介いただきます。 株式会社 NHK テクノロジーズ：SRT を用いたスポーツ大会中継の配信 NHK テクノロジーズ様は AWS を活用し、国際スポーツ大会の海外中継を SRT プロトコルで行いました。「AWS Elemental MediaConnect」を用いて低遅延・高品質な配信を行い、東京リージョンから各地域へAWS内のネットワークを経由し配信することで、安定性とコスト効率を両立されました。映像制作と伝送の一気通貫に弊社で対応することで、放送技術と IT 融合の事例をご紹介いただきます。 日本テレビ放送網株式会社：テレビ広告を進化させる Ad Reach Max (アドリーチマックス)プラットフォーム 内製化開発の取り組みと課題 Ad Reach MAX はアドテクノロジー、新技術の活用によりテレビ広告の概念を一新します。リードタイムが大幅に短縮され放送当日の直前までの発注・クリエイティブ変更が可能で全てがウェブ上で完結される本プラットフォームは内製で作られております。本セッションでは Ad Reach MAX が描く将来像、スケーラブルでサーバレスな内部構成実現にむけた内製エンジニア達の実体像を紹介いただきます。 終わりに 今回は、Inter BEE 2024 の AWS ブースセミナー、出展者セミナーについてご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWSブース展示やAWSスポンサー展示等に関する情報は下記のブログからもご確認いただけます。皆様にお会いできるのを楽しみにしています。 AWS ブース展示の概要については こちら AWS スポンサー展示、AWS ブースツアーの概要については こちら 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 金目 健二が担当しました。

この記事は Secure Cross-Cluster Communication in EKS with VPC Lattice and Pod Identity IAM Session Tags (記事公開日: 2024 年 9 月 18 日) を翻訳したものです。 ソリューション概要 アプリケーションを開発し、内部向けに API エンドポイントを公開したい場合は、 AWS Lambda 、 Amazon Elastic Container Service(ECS) 、 Amazon Elastic Kubernetes Service(Amazon EKS) などのさまざまなコンピューティングオプションを使用して、マイクロサービスを構築できます。そして、アプリケーションを複数の AWS アカウントと複数の Amazon Virtual Private Cloud(VPC) にまたがってデプロイできますが、それらをセキュアに接続する方法が必要です。 Amazon VPC Lattice はアカウント間の East-West トラフィック通信を可能にし、サービスディスカバリ・トラフィック管理・アクセス制御といった機能を提供します。Amazon EKS で取り組む場合、Amazon VPC Lattice には Kubernetes Gateway API を実装した AWS Gateway API Controller を利用します。 このアーキテクチャ全体のトラフィックは、通信の暗号化により保護できます。また、Amazon VPC Lattice の各 Service できめ細やかな AWS Identity and Access Management(IAM) による認可を有効にできます。暗号化のためには、プライベートドメインを管理する AWS Private Certificate Authority(CA) と、各サービスの証明書を作成する AWS Certificate Manager(ACM) を利用できます。認可のためには、Amazon VPC Lattice の IAM 認証ポリシー機能と、クラスター管理者が Kubernetes アプリケーションを設定して IAM アクセス許可を取得する方法をシンプルに実現する EKS Pod Identity を利用できます。これらのアクセス許可は、Amazon EKS コンソール、API、CLI を通じて、より少ないステップで直接設定できるようになりました。EKS Pod Identity を使用すると、IAM ロールを複数のクラスター間で再利用でき、ポリシー管理がシンプルになります。 以下の API を使用して、IAM ロールをPod の ServiceAccount に関連付けることができます。 aws eks create-pod-identity-association \ --cluster-name $CLUSTER_NAME \ --namespace $NAMESPACE \ --service-account $SERVICE_ACCOUNT \ --role-arn arn:aws:iam:: $AWS_ACCOUNT :role/ $POD_ROLE_NAME Bash Amazon EKS が使用できるようにするため、IAM ロール $POD_ROLE_NAME には、以下の信頼ポリシーが必要です。 { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Principal" : { "Service" : "pods.eks.amazonaws.com" } , "Action" : [ "sts:AssumeRole" , "sts:TagSession" ] } ] } Bash EKS Pod Identity が IAM ロールを引き受けると、IAM セッションにセッションタグを設定します。 これらのタグには、 eks-cluster-name 、 kubernetes-namespace 、 kubernetes-pod-name などの情報が含まれており、属性ベースのアクセス制御 (ABAC) に使用できます。 ABAC を使用すると、特定の Kubernetes Pod や、特定の EKS クラスター内の特定の Namespace 内からのみ、AWS リソースへのアクセスを許可できます。 この機能は、IAM 認証を有効にした場合に Amazon VPC Lattice サービスにアクセスするときにも使用でき、Amazon EKS 内または異なる EKS クラスター間のマイクロサービスに対して直接的かつ豊富なアクセス制御の仕組みを提供します。 Amazon VPC Lattice サービスにアクセスするために、 IAM 認証ポリシー を有効にした場合、アプリケーションのリクエストは AWS Sigv4 アルゴリズム (またはクロスリージョンの場合は Sigv4A )で署名する必要があります。これは、他の AWS サービスで使用されているのと同じ機能です。 アプリケーションコード内の AWS SDK を使用してリクエスト署名を実装できます( サンプル を参照)。これは推奨される方法ですが、アプリケーションコードを変更する必要があります。そこで、私たちは別のソリューションを提案します。関連する Amazon EKS Blueprints パターンは、アプリケーションコードを変更せず、サイドカープロキシを使用する異なるアプローチを示しています。 このプロキシは、Amazon VPC Lattice サービスをターゲットとするリクエストの Sigv4 署名を自動的に処理します。 Kubernetes クラスター内から AWS サービスとのシームレスな統合を可能にする、EKS Pod Identity と AWS Sigv4 署名機能をサポートする、幅広く採用されているプロキシとして、 Envoy を使用します。 さらに、Pod 間通信の暗号化のために、Amazon VPC Lattice サービスを HTTPS リスナーで設定できます。 アプリケーションコンテナが HTTPS リクエストの TLS 暗号化をサポートできない場合は、Sigv4 署名とともにこれを Envoy サイドカープロキシにオフロードできます。このセットアップでは、HTTPS として設定された Amazon VPC Lattice サービスへの HTTP リクエストをアプリケーションが生成し、リクエストは Envoy サイドカープロキシにルーティングされ、Envoy はクライアントとして Amazon VPC Lattice に署名された HTTPS リクエストを発行します。 アプリケーションが Amazon VPC Lattice サービスへの HTTP リクエストを行うと、リクエストは自動的にローカルの iptables ルールで Envoy サイドカーにルーティングされます。 そこから、Envoy はこのリクエストの Sigv4 署名を作成し、HTTPS で Amazon VPC Lattice にリクエストを転送します。また ACM によって発行されたプライベートドメイン証明書を検証するために、AWS Private CA を利用します。 プロキシの利用を簡単にするために、このパターンは Deployment の Annotations に依存しています。これにより、 Kyverno クラスターポリシーがトリガーされ、アプリケーション Pod 内に Envoy サイドカープロキシが自動的に注入されます。 ウォークスルー このソリューションは、 EKS Blueprints for Terraform に依存しています。EKS Blueprints は、Amazon EKS やその他の AWS サービスの具体的な使用法を示すパターンのコレクションです。ここでは、 network/cross-cluster-pod-communication を使用します。 このパターンは、以下の図にも示すように、3 つの Terraform スタックに分割されています。 1. 次の 2 つのスタックは、クラスターディレクトリの同じ Terraform コードを使用してデプロイされます。 Terraform の workspace 機能を使用して、クラスタースタックを 2 回インスタンス化し、2 つの EKS クラスター (cluster1 と cluster2) を作成します。 Amazon Route 53 のプライベートホストゾーンである example.com を、ダミーのプライベート VPC (プライベートホストゾーンを持つためだけにこの段階で作成) にアタッチします。 プライベートドメインを管理する AWS Private CA から、後ほど Amazon VPC Lattice サービスにアタッチするワイルドカードの ACM 証明書を作成します。 EKS Pod Identity によってアプリケーションで使用する IAM ロールも作成します。このロールは Amazon VPC Lattice サービスを呼び出す権限と、アプリケーションがプライベートドメインを信頼できるように AWS Private CA のルート証明書をダウンロードする権限を持っています。 2. 次の 2 つのスタックは、クラスターディレクトリの同じ Terraform コードを使用してデプロイされます。 Terraform の workspace 機能を使用して、クラスタースタックを 2 回インスタンス化し、2 つの EKS クラスター (cluster1 と cluster2) を作成します。 まず、スタックは専用 VPC (正確に同じ設定なのでオーバーラップする CIDR を持つ) を作成します。 そして、スタックは専用のマネージドノードグループを用いて EKS クラスターを作成します。 次に、いくつかの Amazon EKS と Kubernetes のアドオンをインストールします。 HTTPRoute および IAMAuthPolicy の定義から Amazon VPC Lattice オブジェクトの作成を管理するGateway API Controller カスタムドメイン名を含む HTTPRoute オブジェクトに基づいて、Route53 プライベートホストゾーンにレコードを作成する責務を持つ ExternalDNS そして最後に、アプリケーション Pod 内に Envoy プロキシを注入する責務を持つ Kyverno をデプロイします 次に、2 つの Helm チャートをインストールします。1 つ目のplatform という名前のチャートは、Amazon VPC Latticeサービスネットワークを作成する GatewayClass およびGateway オブジェクトを作成し、アプリケーションに Envoy プロキシを注入するために使用される Kyverno クラスターポリシーを作成します。2 つ目の Helm チャートである demo は、以下の図に示すように、最初のクラスターでは demo-cluster1、2 つ目のクラスタでは demo-cluster2 と名付けられたデモ用のアプリケーションをデプロイします。 Gateway API Controller が platform Helm チャートから作成された Gateway オブジェクトを検知すると、VPC と VPC Lattice サービスネットワークの間に VPC との関連付けを作成します。VPC との関連付けには、サービスネットワークへのインバウンドリクエストを許可する VPC 内の対象を定義するセキュリティグループを含めることができます。さまざまな条件を用いて、ネットワークを利用できる対象を制限することができます。たとえば、VPC 識別子によって制限することもできます。 単純化のため、このパターンは同じ AWS アカウントに閉じていますが、Amazon VPC Lattice は AWS Resource Access Manager(AWS RAM) を用いることで、クロスアカウントで使用できます。 Amazon VPC Lattice ターゲットグループのヘルスチェックは、Amazon VPC Lattice サービスからリクエストされます。Amazon VPC Lattice には、Terraform の定義によって EKS クラスターのセキュリティグループで許可する必要がある、特定の マネージドプレフィックスリスト があります。Amazon EKS アプリケーションがサービスネットワークに接続する必要がある場合は、適切なポートでノードグループのセキュリティグループからのインバウンドトラフィックを許可するために、VPC への関連付けのセキュリティグループも更新する必要があります。こちらについても Terraform で設定されます。 デモ用の Helm チャートは、デモサービスの定義を含むHTTPRoute オブジェクトを作成し、 カスタムドメイン名 を使用します。 apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: demo-cluster2 namespace: apps spec: hostnames: - demo-cluster2.example.com parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: lattice-gateway namespace: lattice-gateway sectionName: http-listener - group: gateway.networking.k8s.io kind: Gateway name: lattice-gateway namespace: lattice-gateway sectionName: https-listener-with-custom-domain rules: - backendRefs: - group: "" kind: Service name: demo-cluster2-v1 port: 80 weight: 1 matches: - path: type: PathPrefix value: / Bash Gateway API Controller は、関連する Amazon VPC Lattice リソース (サービス、リスナー、ターゲットグループ) を作成します。 このデプロイでは、各リスナー上の各サービスに対して TLS 終端を有効にします。これにより、トラフィックは各サービスに定義されたルートを尊重して、関連するターゲットグループに転送されます。 ターゲットグループは IP タイプとして設定されており、直接ターゲットとなる Kubernetes Service に関連づけられた Pod に転送します。 Amazon VPC Lattice サービスは、異なるクラスターから、ターゲットに対するリクエストを分散するように設定できます。 カスタムドメイン名を定義したため、Gateway API Controller は Kubernetes の DNSEndpoint オブジェクトも作成します。 kind: DNSEndpoint metadata: name: demo-cluster1-dns namespace: apps ownerReferences: - apiVersion: gateway.networking.k8s.io/v1beta1 blockOwnerDeletion: true controller: true kind: HTTPRoute name: app4 spec: endpoints: - dnsName: demo-cluster1.example.com recordTTL: 300 recordType: CNAME targets: - demo-cluster1-apps-082dc3111b7018633.7d67968.vpc-lattice-svcs.eu-west-1.on.aws status: observedGeneration: 1 Bash ExternalDNS は CRD による拡張を用いて、このオブジェクトを監視します。 以下を設定することで、ExternalDNS が DNSEndpoint カスタムリソース定義から読み取れるように構成します。 --source=crd --crd-source-apiversion=externaldns.k8s.io/v1alpha1 --crd-source-kind=DNSEndpoint API Gateway HTTPRoute をカスタムドメインを指定して作成すると、Amazon VPC Lattice はそのエントリの DNS エンドポイントを作成します。 この設定により、ExternalDNS はプライベートホストゾーンに専用の Route53 CNAME レコードを作成できるため、カスタムドメイン名からのトラフィックを Amazon VPC Lattice サービスのエンドポイントにルーティングできます。 これにより、内部サービスは内部ドメイン名を使用して検出およびアクセスできます。 Kubernetes Gateway オブジェクトには、Amazon VPC Lattice がリクエストの TLS セッションを終了するために使用する ACM 証明書の Amazon リソースネーム (ARN) も含まれています。 デモ用の Helm チャートは、HTTPRoute に関連付けられたIAMAuthPolicy オブジェクトもデプロイします。これは、各リクエストに Sigv4 アルゴリズムでの署名が必要であることと、demo-cluster2 のアプリケーションの場合、cluster1 EKS クラスターの apps Namespace からのリクエストのみが許可される ABAC ルールを定義しています。そして、demo-cluster1 のアプリケーションの場合は、cluster2 EKSクラスターの apps Namespace からのリクエストのみを受け入れます。 Amazon VPC Lattice サービスへのすべてのリクエストをログに記録するために、アクセスログのサブスクリプションを設定することもできます。ログは Amazon CloudWatch のロググループに記録されます。 デプロイ 関連する EKS Blueprints のパターンにあるデプロイ手順に従うことができます。 簡単なセットアップとして、以下のコマンドで実行できます。 # Clone EKS Blueprint repository git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git cd patterns/vpc-lattice/cross-cluster-pod-communication # Deploy the environment cd environment terraform init terraform apply --auto-approve # Deploy cluster 1 cd .. /cluster ./deploy.sh cluster1 eval ` terraform output -raw configure_kubectl ` # Deploy cluster 2 cd .. /cluster ./deploy.sh cluster2 eval ` terraform output -raw configure_kubectl ` Bash 3 つのスタックが正常にデプロイされると、クラスター間通信が意図したとおりに機能していることを検証するために、次のコマンドを実行できます。 これを実現するために、Pod 内に exec して HTTP でサービスをターゲットにする cURL コマンドを実行します。すでに説明したように、リクエストは HTTP で Envoy サイドカーにルーティングされ、AWS Private CA 証明書を使用して HTTPS で署名され転送されます。 1. cluster1 の app1 から、cluster2 の app2 を呼び出す→ 成功 $ kubectl --context eks-cluster1 exec -ti -n apps deployments/demo-cluster1-v1 \ -c demo-cluster1-v1 -- curl demo-cluster2.example.com Requesting to Pod ( demo-cluster2-v1-c99c7bb69-2gm5f ) : Hello from demo-cluster2-v1 Bash 2. cluster2 の app2 から、cluster1 の app1 を呼び出す → 成功 $ kubectl --context eks-cluster2 exec -ti -n apps deployments/demo-cluster2-v1 \ -c demo-cluster2-v1 -- curl demo-cluster1.example.com Requesting to Pod ( demo-cluster1-v1-6d7558f5b4-zk5cg ) : Hello from demo-cluster1-v1 Bash 前のコマンドのように認証フローを使用しない場合、Amazon VPC Lattice が未認証のリクエストを拒否することがわかります。 3. cluster1 app1 から、cluster1 app1 を呼び出し → 禁止 $ kubectl --context eks-cluster1 exec -ti -n apps deployments/demo-cluster1-v1 \ -c demo-cluster1-v1 -- curl demo-cluster1.example.com AccessDeniedException: User: arn:aws:sts::12345678910:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-1b575f8d-fb77-486a-8a13-af5a2a0f78ae is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:eu-west-1:12345678910:service/svc-002349360ddc5a463/ because no service-based policy allows the vpc-lattice-svcs:Invoke action Bash 4. cluster2 app2 から、cluster2 app2 を呼び出し → 禁止 $ kubectl --context eks-cluster2 exec -ti -n apps deployments/demo-cluster2-v1 \ -c demo-cluster2-v1 -- curl demo-cluster2.example.com AccessDeniedException: User: arn:aws:sts::12345678910:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-a5c2432b-b84a-492f-8cbc-16f1fa5053eb is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:eu-west-1:12345678910:service/svc-00b57f32ed0a7b7c3/ because no service-based policy allows the vpc-lattice-svcs:Invoke action Bash demo-cluster1 アプリケーションで IAMAuthPolicy がどのように定義されているかを確認できます。 kubectl --context eks-cluster1 get IAMAuthPolicy -n apps demo-cluster1-iam-auth-policy -o json | jq ".spec.policy | fromjson" { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Principal" : { "AWS" : "arn:aws:iam::12345678910:root" } , "Action" : "vpc-lattice-svcs:Invoke" , "Resource" : "*" , "Condition" : { "StringEquals" : { "aws:PrincipalTag/eks-cluster-name" : "eks-cluster2" , "aws:PrincipalTag/kubernetes-namespace" : "apps" } } } ] } Bash eks-cluster2 クラスターから apps Namespace に発信されるリクエストのみが許可されていることを確認できます。 クリーンアップ 将来的な課金を回避するために、EKS Blueprints パターンのクリーンアップセクションに従ってリソースを削除するか、次のスニペットを実行してください。 cluster2 Terraform スタックを削除することから始めます。 Kubernetes のコントローラーが、別のコントローラーや Kubernetes Node を削除する前に、外部リソースをクリーンアップできるよう、順番に処理する必要があることに注意してください。 ./destroy.sh cluster2 次に、cluster1 の Terraform スタックを削除できます。 ./destroy.sh cluster1 最後に、environment Terraform スタックを削除します。 cd ../environment terraform destroy -auto-approve まとめ このソリューションでは、Amazon VPC Lattice を使用して 独自のマイクロサービスアプリケーションに適用可能な EKS クラスター間のアプリケーション通信を保護する方法を、自動化されたサンプルを用いて、デモンストレーションしました。 このアプローチの主なメリットは以下のとおりです。 セキュアな通信： Amazon VPC Lattice を使用することで、EKS クラスター間の通信の転送中の暗号化、きめ細やかな IAM 認可ポリシーによる保護を実現できます。これにより、クラスターやアカウント間の転送であっても、アプリケーションデータのセキュリティと整合性を維持できます。 サービスディスカバリの簡素化： Gateway API Controller と ExternalDNS の統合により、カスタムドメイン名を使用してサービスを公開できるため、他のサービスがそれらを見つけて通信するのがより簡単になります。 スケーラビリティと柔軟性： Amazon VPC Lattice を使用することでアプリケーションを複数の VPC とアカウントに分散できるため、コンポーネント間のセキュアな接続性を維持しながら必要に応じてインフラストラクチャをスケールできます。 自動デプロイ： Terraform 用 EKS Blueprints を使用することで、EKS クラスター、Amazon VPC Lattice リソース、その他のサービスのデプロイと設定を自動化できるため、手動による誤りのリスクを減らし、一貫したデプロイを実現できます。 再利用性： このソリューションは、アプリケーションコードを変更することなく、EKS Pod Identity と Envoy プロキシを使用してセキュアな通信を可能にする方法を示しています。このアプローチは他のアプリケーションにも適用できるため、同じパターンとベストプラクティスを組織全体で再利用できます。 可観測性とモニタリング： Amazon VPC Lattice サービスのアクセスログを設定することで、クラスター間を流れるトラフィックの貴重な洞察を得られるため、問題をより効果的に監視およびトラブルシューティングできます。 全体として、このソリューションは Amazon VPC Lattice やその他の AWS サービスの力を利用して、Amazon EKS ベースのアプリケーションのクラスター間通信を包括的かつセキュアに実現するアプローチを提供します。この例で示されているパターンとベストプラクティスに従うことで、スケーラブルでセキュアな高可用性のマイクロサービスアーキテクチャを構築でき、これによりモダンなクラウドネイティブアプリケーションの要求を満たすことができます。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

Amazon Bedrock でモデルの推論をするには、はじめにモデルアクセスの有効化が必要です。また、デフォルトで割り当てられた制限を超えて推論等を行う場合は Quotas と呼ばれる制限値を引き上げる必要があります。デフォルトの制限値は サービスの適正な利用とパフォーマンスの維持向上を図るため継続的に調整が行われており 、その中であなたの AWS アカウントのモデルアクセスの有効化や推論等の制限値に影響が発生する場合があります。影響を受けた際、どのように対応すればよいのかを示すのが本記事の目的です。 生成 AI の注目が高まるにつれ、生成 AI 、Amazon Bedrock をきっかけに初めて AWS を利用する方もいらっしゃると思います。そうした場合、想定外の影響を受けたとき AWS でどのように対応や問い合わせをすればよいのか戸惑うことも多いと理解しています。本記事はその戸惑いを解消するためにあり、生成 AI で AWS を活用いただく誰もが、詰まることなく影響を解消するための手順を説明します。はじめに Amazon Bedrock を利用するための基本的な手順をおさらいし、その後影響が発生した際の対応手順を示します。 モデルアクセスの有効化をする方法 Amazon Bedrock は複数の基盤モデルに対し統一された API でのアクセスを提供します。「複数」の中のどのモデルを利用するかは、Amazon Bedrock の「モデルアクセス」で設定します。最小特権の原則に基づき利用できるモデルを明示的に選択する方式で、会社や開発組織の規約や性能要件に合致したモデルのみアクセスを許可できます。 Amazon Bedrock で「モデルアクセス」を有効化する方法は、“ Amazon Bedrock のはじめ方 ” の「1. Amazon Bedrock の準備」にまとめています。手順が不案内な場合は、こちらの記事を参照ください。注意点として、手順を進める前に、Amazon Bedrock を利用するリージョンを選択していることを確認してください。リージョンとはデータセンターが集積されている物理的ロケーションをさし、AWS Console の右上で設定できます。利用可能なリージョンは、 こちらのページで確認できます 。利用可能なモデルはリージョンごとに異なり、 Model support by AWS Region にて確認ができます。 制限値を引き上げする方法 Amazon Bedrock のモデルに対し送信および受信できるトークン数の上限は、制限がかけられています。デフォルトの制限値は “ Amazon Bedrock endpoints and quotas ” を参照ください。これは予想外の利用が発生して使用料金が急増するリスクの対処に役立つ一方、頻繁な実験や一定の使用量が必要なユースケースの実現には制限値を超えた利用を申請しておく必要があります。 制限値の上限緩和を申請する場合は、AWS Console から “quotas” と検索し、“Service Quotas” を選択してください。 この操作をする場合も、Amazon Bedrock を利用するリージョンを選択していることを確認してください。 設定値はリージョンごとに設定されています。 “Service Quotas” の画面に遷移したら、AWS のサービスとして “Amazon Bedrock” を選択し、「クォータの表示」を押下します。 概ね、“On-demand” の requests per minute が問題となると思います。該当モデルの制限値を選択し、遷移後に「アカウントレベルでの引き上げをリクエスト」することで新しい上限値をリクエストできます。必要な設定値は、ユースケース等からの見積りを基に算出ください。 トラブルへの対処方法 上記でご説明したモデルアクセスの有効化や制限値の引き上げは通常時の方法です。ここから本題として、通常の手順通りではできなくなってしまった場合の対応方法を説明します。 モデルアクセスの有効化ができない場合 モデルアクセスの有効化ができない場合、モデルのチェックボックスがグレーアウトされて選択できなくなっているか、そもそもモデルが有効化のページに表示されないケースがあり得ます。 まず、利用可能なモデルはリージョンごとに異なるため、現在 AWS Console で選択しているリージョンと、 Model support by AWS Region を見比べモデルのアクセスが該当リージョンで提供されているかご確認をお願いいたします。 モデルが提供されているにもかかわらず、グレーアウトあるいは表示されていない場合、「サポートセンター」から「ケースの起票」をお願いいたします。サポートセンターは、AWS Console の右上の のアイコンからアクセスできます。 サポートセンターの画面から「ケースの作成」を押下してください。 Enterprise および Business, Developer など、サポート契約されている場合は「技術」が選択できますので、そこから Amazon Bedrock のサービスを指定してケース起票をお願いいたします。サポート契約されていない方は、下図のように「アカウントと請求」「一般情報及び使用開始に当たって」「AWS および各種サービスの利用」を選択しケースの作成をしてください。 件名と説明を例示します ( ※この通りに書かないといけないというわけではありません )。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock でモデルアクセスの有効化ができない 説明 Amazon Bedrock で XXX のリージョンで YYY のモデルを利用するためにモデルアクセスの有効化を行おうとしたところ、チェックボックスがグレーアウトされている/リストに表示されておらず、有効化ができませんでした。該当リージョンでモデルが提供されていることは Model support by AWS Region で確認済みです。 本番環境での稼働を x/x に予定しており、検証をスケジュールに沿い進めるため有効化が行えるよう対応いただいてもよろしいでしょうか ? 制限値未満の利用にもかかわらずエラーが出る場合 Amazon Bedrock のモデルの利用制限は “ Amazon Bedrock endpoints and quotas ” に記載されていますが、ここで記載されている Quotas 未満の使用にも関わらず上限を超えた旨のエラーが発生する場合があります。 初手の対応方法として、クロスリージョン推論の利用を検討ください。Amazon Bedrock のリソース及び Quota はリージョンごとに設定されているため、複数リージョンの Quotas を有効に活用するのが効果的です。Amazon Bedrock は特定リージョンで推論に必要なリソースが枯渇していた場合、他のリージョンに推論をオフロードする “ クロスリージョン推論 ” が実装されています。こちらの機能を実装することで、よりリソースを冗長化した推論を行うことが出来ます。詳細は “ Amazon Bedrock の Cross Region Inference を試す ” などをご参照ください。 クロスリージョン推論を試してもエラーが発生する、あるいは国内にとどめる必要があるなどオフロードできない要件がある場合、上記同様にサポートセンターからケースの起票をお願いいたします。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock で Quotas 未満にもかかわらずエラーが発生する 説明 Amazon Bedrock で XXX のリージョンで YYY のモデルを Quotas 未満で利用しているにもかかわらず、ThrottlingExceptionが発生します。デフォルトの Quotas は “ Amazon Bedrock endpoints and quotas ” で確認済みです。クロスリージョン推論はすでに試していますが、エラーの発生頻度はお客様向けの提供に問題がないレベルには至っていません or アプリケーションの要件として ZZ のリージョンに閉じる必要があり、クロスリージョン推論は利用できません。本番環境での稼働を x/x に予定しており、検証をスケジュールに沿い進めるため有効化が行えるよう対応いただいてもよろしいでしょうか ? 制限値の引き上げができない場合 Quotas のラジオボタンがグレーアウトされている場合、“Service Quotas” の画面から制限値の引き上げを行うことが出来ません。「調整可能ではない」と記載されている場合は引き上げができません。 この場合、上限緩和したいクォータ名のリンクにアクセスすると Support Center に問い合わせるよう誘導があります。それに従い、モデルアクセスと同様にケースを作成し上限の緩和を申請します。なお、申請は必ず認可されるわけではない点はご了承ください。 件名と説明を例示します ( ※この通りに書かないといけないというわけではありません )。Quota の名前は適宜変更してください。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock で “ On-demand InvokeModel requests per minute for Anthropic Claude 3 Haiku ” の Quotas 変更ができない 説明 Amazon Bedrock で XXX のリージョンで件名のモデルの Quotas 上限を引き上げようとしたところ、アカウントレベルでの調整ができなかったためケースを起票させていただきました。現在、プロジェクトの検証のため・・・(以下、個別事情と希望する制限値について記載ください) おわりに 生成 AI のポテンシャルをすべてのデベロッパーの方に届けるため、AWS では日々リソースの最適化に努めています。その過程で意図しない影響が発生した際は、本手順に沿い解決を頂ければ幸いです。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 10月31日に開催したAWS AI Dayですが、たくさんのお客様にご来場を頂きました。この場を借りて御礼申し上げます。残念ながら参加できなかったという方もいらっしゃると思います。アーカイブ配信もありますので、ぜひご覧ください。「 AWSジャパン生成AI実用化推進プログラム 」の参加企業に登壇いただくライトニングトーク形式のセッションも開催し、各社さんのチャレンジをご紹介しています。我こそは、という方もまだ間に合います。ご応募をお待ちしています。 それでは、10 月 28 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「【開催報告&資料公開】 流通小売・消費財・EC 企業向け：クラウドと生成AI によるオペレーション改革」を公開 AWSではお客様の業界や、具体的な課題に特化した生成AIの活用例を集めて公開するとともに、お客様の新たな取り組みのヒントになる情報発信にも力を入れています。このセミナーもその活動の一環で、流通小売・消費財・EC企業とは切っても切り離せない「オペレーション」の改革をテーマにしています。お客様登壇の録画や、資料がまとまっていますので、ピンと来た方はぜひご一読ください。 ブログ記事「Enel が Amazon Bedrock を活用してスタッフの生産性を向上」を公開 海外事例記事の日本語訳です。Enelは32カ国でビジネスを行う大手総合電力会社です。そのお客様数は7,600万人に及び、サービス提供には多くの従業員が関わっています。その生産性工場は従来からの課題になっており、今回生成AIを活用することでITサービスデスクにおけるケース(問い合わせ)解決時間が1日から2分未満に短縮できたという事例です。 ブログ記事「Llama 3.x モデルのファインチューニングを Amazon SageMaker Pipelines の新しいビジュアルデザイナーで自動化する」を公開 Amazon SageMaker Pipelinesにはビジュアルデザイナーという機能があり、トレーニング・ファインチューニング・評価・デプロイといった一連のワークフローをグラフィカルに作成できます。この記事では、Meta社のLlama 3.xを題材にファインチューニングを行うパイプラインを構築する例をご紹介しています。この種のパイプラインは継続的なモデル改善という観点では必要不可欠ですので、参考にしていただけるケースは多いのではないでしょうか。 ブログ記事「社内に導入した生成 AI ツールの利用率伸び悩みを打破する : 先行事例に学ぶ 4 つのユースケース」を公開 上の方でも書きましたが、AWSではお客様のご協力を頂き、実務に根ざしたAI活用事例の公開に力を入れています。この記事では、「生成AIツールを導入したがあまり利用されていない」という悩みを抱えた方のヒントになりそうな事例をピックアップしてご紹介しています。 ブログ記事「生成 AI でサービスのトップラインを伸ばす！ : 業務効率化から進み、売上や利用の拡大を実現した事例 4 件に学ぶ」を公開 この記事はひとつ上の「先行事例に学ぶ4つのユースケース」と同じコンセプトの事例まとめですが、成約率向上などビジネス成果に直結する事例をピックアップしてご紹介しています。 ブログ記事「生成 AI を活用する鍵は組織横断のチームにあり : ML Enablement Workshop を活用した 4 つの事例から学ぶ」を公開 こちらも同様です。この記事ではML Enablement Workshopを活用して、生成AIを活用しビジネスを変革するために社内のチームや組織が有効に機能した事例を取り上げています。 サービスアップデート Meta社のLlama 3.1 8Bと70BがAmazon Bedrockでファインチューニング可能に 学習済みの基盤モデルに対して、ラベル付きデータを与えて目的とするタスクに特化させる手法がファインチューニングです。今回、Amazon Bedrockで動作するMeta社のLlama 3.1 8Bと70Bについて、ファインチューニングを実行できるようになりました。独自にインフラ環境を構築する必要がなくなり、ファインチューニングによるタスク特化型モデルの作成がこれまでよりも容易になるアップデートです。 Amazon BedrockでAnthropic Claude 3 Haikuのファインチューニングが可能に Amazon BedrockがAnthropic Claude 3 Haikuのファインチューニングに対応しました。独自のタスクに関するトレーニングデータセットを利用して、特定用途に対する精度や品質向上のためのカスタマイズを行うことによって目的に対する最適化が行えます。 Amazon Bedrockでコスト配分タグが利用可能に Amazon Bedrockでオンデマンドで基盤モデルを利用しているケースで、コスト配分タグを利用したコスト追跡が可能になりました。Bedrockで推論を行った際に、コストが発生した部門・プロジェクト・用途を特定しやすくなります。 Amazon Q Developerが開発者エクスペリエンスを向上させるインラインチャットをサポート Amazon Q Developerでインラインチャットという機能が利用できるようになりました。この機能ではエディタ内で対象となるコードを選択し、チャットを開始することで「コードを最適化する」「コメントを追加する」「テストを書く」などの作業をAmazon Q Developerに依頼することができます。なおこの機能は最新のAnthropic Claude 3.5 Sonnetを活用しています。 Amazon Redshift Serverless向けのAIによるスケーリングと最適化機能を発表 Amazon Redshift Serverlessで、スケーリングと最適化をAIで自動化できる機能が発表されました。データ量の変化やユーザ数、クエリの複雑度などを判断し、あらかじめ設定されたコストとパフォーマンスの優先度合いに従って自動的にスケーリングを行います。この機能は1日を通じたワークロードの傾向を学習しリソース管理を行うため、特に負荷の変動があるワークロードにおいて高いコストとパフォーマンスの最適化効果が見込めます。 Amazon RedshiftとAmazon Bedrockのインテグレーションを発表 Amazon RedshiftとAmazon Bedrockのインテグレーションが発表され、SQLのコマンドと利用してRedshiftに蓄えられたデータをAmazon Bedrockで動作する基盤モデルで活用できるようになりました。この機能を利用するとAmazon Redshiftのデータに対して、基盤モデルによる翻訳・テキスト生成・要約・分類・感情分析などを容易に実行できます。SQLで基盤モデルを呼び出すことができるので、既存のワークフローに組み込むことが容易だという点もポイントです。 Amazon SageMaker Notebook InstancesでJupyterLab 4 notebooksをサポート Amazon SageMakerのノートブックインスタンスでJupyterLab 4がご利用頂けるようになりました。パフォーマンスの高速化や、ノートブックのウィンドウ化などJupyterLab 4の最新機能や改善を利用できるようになります。 AWS GovCloud(米国西部)のAmazon BedrockでAnthropic Calude 3.5 SonnetとCalude 3 Haikuが利用可能に AWS GovCloud(米国西部)リージョンのAmazon BedrockでもAnthropicのClaude 3.5 SonnetとClaude 3 Haikuがご利用頂けるようになりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

バリデーターは、Ethereum のようなProof of Stake (PoS) ブロックチェーンプロトコルの基本的な構成要素です。バリデーターはチェーンの履歴を維持し、分散型金融アプリケーションから NFT コレクティブルまで、複雑な分散型アプリケーションを可能にするコンセンサスプロトコルを実行します。 プロトコルに参加するために、バリデーターは担保として資産を提供します。これにより、コンセンサスを形成する際に正しく動作することが保証されます。残念ながら、プロトコルは悪意のあるバリデーターと単なる過失を区別できないため、運用上のミスやバリデーターのクライアントソフトウェアのバグにより資産がリスクにさらされています。最良のケースでは小さな経済的なペナルティに、最悪の場合は資金全額が失われることにつながります。 このポストでは、Ethereum バリデータオペレーターを内部の脅威、バリデーターへの侵害、運用上のミス、クライアントのバグから守るために設計されたセキュアな鍵管理プラットフォームのハイレベルなアーキテクチャについて説明します。 以下のトピックについても扱います。 Ethereum のバリデーターを実行する際の課題と、関連するセキュリティおよびスラッシングリスク。 ※スラッシングとは、バリデーターの不正行為に対する罰金のことです。 リモート鍵管理ソリューションを使ってこれらの課題に取り組む考え方と、リスクを実質的に軽減するためにキーマネージャーが構築される必要がある根本的な目標。 Cubist の CubeSigner のハイレベル設計。CubeSigner は AWS Nitro Enclaves 上に構築された、セキュアな鍵管理プラットフォームで、エンドユーザーのウォレットからトレーディング、チームや運用のための鍵管理まで、ステーキングやその他のアプリケーションをサポートしています。 Ethereum バリデーターを実行する際の運用上の落とし穴 Ethereum の PoS プロトコルは、数十万のバリデーターにより実行されるコンセンサスプロトコルです。数秒おきにバリデーターは Ethereum のトランザクションを実行し、無作為に選ばれたバリデーターが提案した状態の変化と結果が一致する場合、これらのトランザクションをブロックチェーンに追加し、バリデーションメッセージに署名することでそれを証明します。バリデーターに、正直にチェーンの状態を報告するインセンティブを与えるため、このプロトコルではバリデーターに 32 ETH のステーキングを求めています。バリデーターが期待どおり振る舞う (トランザクションを改ざんしたりチェーンの状態を偽ったりしない) と、ステークされた資産に対して報酬が得られます。そうでない場合、ステークの一部が失われます。 バリデーターがチェーンの状態を改ざんしていた場合、ネットワークの安全性を損なったとしてスラッシュと呼ばれるペナルティが課されます。スラッシュされるとかなりの金銭的ペナルティを受け、プロトコルから締め出されます。また、オフラインになったり、署名が非常に遅くなったバリデーターにも、プロトコルの可用性を危険にさらしているので、軽い制裁が課されます。 残念ながら、検証ノード (ノード運営者) のミスと故意の不正行為を区別することはできません。検証ノードがブロックチェーンの状態に関して 2 つの矛盾するレポートを提出した場合、その矛盾が意図的な不正行為に起因するものなのか、検証ノードソフトウェアのバグによるものなのかを判別するのは不可能です。その結果、セキュリティ、正確性、またはパフォーマンスに関する様々な種類のミスをしたオペレーターは、スラッシング (ペナルティ) によって直接的に金銭的損失を被ることになります。これらのミスを防ぐには、深刻な課題があります。 セキュリティ – 1 つのバリデーターのステーキングキーは通常 32 ETH (執筆時点で約 8 万米ドル) を保護します。ただし、このような貴重なバリデーターのステーキングキーは、数分ごとに検証メッセージに署名する必要があるため、コールドストレージに保管できません。そのため、ノード運用者は ホットキーをシステム侵入から保護する必要があります。オープンソースのバリデータークライアント、ノードを 24 時間 365 日稼働させる運用要件、不正な運用者やソーシャルエンジニアリングなどの内部の脅威ベクトルがある複雑な環境において、これは特に困難です。 目標 – 攻撃者や悪意のある内部者から秘密の署名キーを盗まれたり、悪用されるのを防ぐキーマネージャーを作成する。 正確性 – 2 つの異なる競合するメッセージに署名したバリデーターは、競合する署名が誤りでも不正とみなされ、罰金 (スラッシング) が科されます。過去には、正直な運用者がバグのあるバリデータークライアントソフトウェア、マシン間でのバリデーターの移行エラー、バリデーターソフトウェアの更新ミスなどによって罰金を科されたこともあります。 目標 – 運用者がスラッシングから守られ、Beacon チェーンプロトコル仕様に従った正しい動作が保証されるキーマネージャーを作成する。 可用性 – 署名しなかったり遅れて署名した (たとえば 12 秒のスロット時間に応答しなかった) バリデーターは、報酬が減額されるか支払われません。そのため、ノード運用者は高可用性と信頼性のあるソリューションを設計し、低レイテンシー (通常は署名時の上限を 500 ミリ秒に設定) で応答する必要があります。 目標 – このようなレイテンシー、信頼性、可用性の目標を達成するのに役立つキーマネージャーを作成する。 リモートでの署名は、バグや運用ミスによるリスクを軽減 Ethereum の PoS Beacon チェーンに参加するために、ノードオペレーターは Lighthouse や Prysm などのバリデーター クライアントを使用します。バリデーター クライアントは、任意の数のバリデーターキーペアを含みます。各ペアは 1 つのバリデーターに対応しており、公開鍵がバリデーターの識別子、秘密鍵がバリデーター クライアントがそのバリデーターに代わってメッセージに署名するために使用されます。バリデーター クライアントはその後、これらの署名済みメッセージをビーコンチェーンネットワークに放送し、本質的にバリデーターのチェーン状態の見解を主張します。 Validator クライアントは、所有のマシン上で Validator キーを保持してローカルに署名することができます。または、リモートサイナーを使用することができます。リモートサイナーは、キーをリモートに保持し、Validator クライアントに対して署名 API を公開します。各エポックで、Validator クライアントは署名リクエストをリモートサイナーに送信し、サイナーから署名済みの Validation メッセージを受け取ります。ネットワーク経由のリモート署名はローカル署名より遅くなります。しかし、以下の理由から、オペレーターはリモートサイナーを使用しています。 セキュリティ– リモートサイナーを使用することで、バリデーター鍵を以下から隔離できます。 バリデーターのクライアント – これは外部の不信な環境 (他のビーコンチェーンノード) と対話し、信頼されない Ethereum Virtual Machine (EVM) コードを実行します。 インサイダー脅威 – ここにはノードの稼働状態を維持する運用者が含まれますが、彼らにはバリデーターの秘密鍵へのアクセスは不要です。 正確性– リモートサイナーを使用することで、 参照モニター (アンチスラッシングデータベースと連携したサイナー) を実装し、鍵がスラッシングを引き起こすようなメッセージに署名することを回避できます。 可用性– すべてのバリデーター鍵を処理するリモートサイナーを使用することで、ノード運用者がバリデーターのクライアントを自動的にスケールし、クラッシュ時に新たにスピンアップできるようになります。 リモートサイナーは、これらの特性を考慮して設計される必要があります。Web3Signer のような一般的なサイナーを単純に使用しただけでは、これらの特性を得られません。例えば、リモートサイナーは、キーにアクセスできるユーザーを制限する必要があります。つまり、承認されたユーザー (およびバリデータクライアント) のみにアクセスを制限し、キーをサイナー自体に封印します。そして、キーで何ができるのかを制限する必要があります。そうしないと、侵害やインサイダー脅威がキーの盗難につながる可能性があります。 リモートサイナー自体は、高可用性で耐障害性がある必要があり、グローバルで高可用性のスラッシング防止データベースを使用する必要があります。そうしないと、サイナーや OS の更新、マシン障害、ネットワーク障害がスラッシングイベントの原因となる可能性があります。 最後に、リモートサイナーはローカル (安全ではない) 署名ほど高速である必要はありませんが、バリデータの待機時間は重要です。遅すぎる (一般的に 1 秒以上) と、バリデータがメッセージ署名が遅れ、オペレーターに金銭的損失が発生します。 以下のセクションでは、Nitro Enclaves ベースの CubeSigner リモート署名ソリューションを実装することで、セキュリティ、正確性、および可用性のゴールを達成した方法について詳しく説明します。 Cubist CubeSigner – Architecture overview 前述の、正確性、セキュリティ、パフォーマンスと信頼性の課題に対処するために、私たちは AWS Key Management Service (AWS KMS)、 Amazon DynamoDB 、そして Nitro Enclaves を利用した、新しいリモート署名サービス CubeSigner を構築しました。 検証クライアントからのメッセージを処理するためにサイナーが実行する手順は次のとおりです。 Amazon API Gateway 上の HTTP インターフェース経由で、検証メッセージを受け入れます。 DynamoDB に保存された署名履歴を使用して、そのメッセージがスラッシングするかどうかを確認します。 スラッシングしない場合は、AWS KMS とセキュアなキーを使用して署名します。 次の図は、このソリューションアーキテクチャを示しています。 次のセクションでは、これらの 3 つのステップを詳しく説明します。 認証されたハイレベルの署名 API 署名者は、Lighthouse や Prysm などの検証クライアントがそのまま使える API を公開する必要があります。シンプルながら低レベルの署名エンドポイントを公開する AWS KMS API とは異なり、この API はイーサリアム Beacon チェーン特有のハイレベルのバリデーター メッセージを処理する必要があります。このハイレベル API は必須です。なぜなら、メッセージの内容に基づいて、バリデーター メッセージに対してスラッシング防止ポリシーを適用できるからです。代わりにメッセージの生ハッシュを受け取って署名するだけでは、特定のメッセージがスラッシングの対象となる可能性があるかどうかを判断することはできません。 スラッシングを防ぐだけでなく、このハイレベルの API は、検証要求が認証済みの検証ノードから来たものであることも保証する必要があります。そうしないと、単一のクライアントが侵害されれば、すべての検証ノードとすべてのキーが侵害されてしまいます。CubeSigner はさらに進んで、細かい権限範囲による認証を使用しています。権限範囲は認証セッションを制限して、特定のアクション (例えば検証) のみを実行できるようにします。検証ノードに検証の権限範囲のみを与えることで、ノードオペレーターはそれらの検証ノードが、例えば Exit メッセージに署名したり、検証プロトコルから出ることを防ぐことができます。これにより、オペレーターが誤って検証ノードを出ることを防ぎ、代わりに出ようとする攻撃者からオペレーターが報酬を失うのを防ぎます。 CubeSigner は、発信者のアイデンティティを判別するためのカスタム認証スキームを実装した AWS Lambda authorizersと API Gateway を利用しています。各許可された署名リクエストは、CubeSigner の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに送信され、まず許可されたスコープがリクエストを許可しているかを確認します。次に、署名者がメッセージの署名ルートハッシュを計算し、そのハッシュの署名がスラッシングを引き起こさないようにアンチスラッシングポリシーを適用して署名を行い、署名をバリデーター クライアントに返します。次に、アンチスラッシングと署名そのものについて説明します。 スラッシング対策 CubeSigner はポリシーエンジンであり、アンチスラッシングを実装しています。署名要求を承認した後、CubeSigner は Ethereum の組み込みアンチスラッシングを含む複数のポリシーを適用します。アンチスラッシングポリシーは EIP-3076 に従い、バリデーター がすでにコミットした Chain 履歴と矛盾するメッセージに署名しないことを保証します。つまり、ポリシーには状態を保存する必要があります。CubeSigner は DynamoDB をデータベースとしてこのポリシーを適用します。すべてのバリデーター 鍵に対して、署名したメッセージを原子的かつ条件付きで記録し、ある特定のスロット番号に対して複数の署名が生成されないことを保証します。 DynamoDB は、あらゆるスケールのハイパフォーマンスアプリケーションを実行するために設計された、フルマネージド、サーバーレスのキーバリューの NoSQL データベースです。DynamoDB には、組み込みのセキュリティ、継続的なバックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、そしてデータのインポートおよびエクスポートツールが備わっています。可用性と一貫したパフォーマンスは、ブロックチェーンバリデーターの実行時に特に重要です。これらが停止したり、レイテンシーやデータ不整合が発生すると、直接的な金銭的損失につながる可能性があるためです。これらの要件を踏まえると、DynamoDB は、単一ミリ秒で一貫したパフォーマンスと 99.999 % の可用性を備えている点で適しています。DynamoDB のパフォーマンス、コスト、スケーラビリティ機能の詳細については、 Amazon DynamoDB 機能 を参照してください。 安全な署名 3 つ目の層は、CubeSigner 仮想ハードウェアセキュリティモジュール (vHSM) です。この層は、キーを攻撃者から守るために、ハードウェアセキュリティモジュール(HSM)内で AWS KMS を利用してバリデーションメッセージに署名を付けます。 HSM と AWS KMS 銀行業務やドメイン証明書の管理など、セキュリティが重要な業務分野では、鍵管理に関するタスク (キーの保管や署名など) を HSM に外部委託することが一般的です。HSM は、暗号化の秘密鍵を物理的ハードウェアに紐付けた専用のデバイスです。このため、非常に盗難が難しくなっています。たとえば標準的な HSM では鍵の抽出攻撃を行うには電子顕微鏡のある研究室が必要です。そうしない場合、盗難を検知すると自己破壊します。 ただし、HSM 単独での利用は比較的難しくなります。高水準言語で記述されたアプリケーション内から HSM にアクセスするには、通常、ベンダー固有の SDK が必要となり、アプリケーション自体が PKCS11 API 標準に準拠している必要があります。AWS では、アクセス可能な HSM ベースの鍵管理サービスである AWS KMS を提供しています。AWS KMS は、 FIPS 140-2 セキュリティレベル 3 に分類される HSM で保護された暗号化キーを作成/管理できるフルマネージドサービスです。さらに、標準の AWS SDK (例えば、Rust 向けの aws-sdk-kms )から利用できます。 AWS KMS を単独で使用しない理由 AWS KMS だけでは、バリデーターに対して安全な鍵管理ソリューションを構築するには不十分です。1つ目の課題は技術的なものです。 Ethereum バリデーターは Boneh-Lynn-Shacham (BLS) 署名スキームを使用して署名する必要がありますが、HSM はまだ National Institute of Standards and Technology (NIST) との規制の整合性の課題により、BLS をサポートしていません。HSM は主に、ブロックチェーン業界外で普及している RSA や Elliptic Curve Digital Signature Algorithm (ECDSA) などの暗号化署名スキームの提供に重点を置いています。新しい署名スキームのサポートを拡張するには、通常、HSM 自体のローレベルのファームウェアアップグレードが必要になります。 たとえ HSM が BLS 署名を生成できたとしても、次のような課題に直面するでしょう。待ち時間と処理能力です。Ethereum ノードオペレーターは数百から数千の承認者を実行していますが、すべての承認者が約 1 秒 (暗号化処理とネットワーク往復を含む) で署名を生成する必要があります。ほとんどの HSM はパブリックキー暗号化処理のバッチ処理に最適化されていません (例えば、KMS での 100 件の ECDSA 署名処理のレイテンシ合計では、1 秒制限を超えてしまいます)。さらに、HSM は一般的に処理能力に制限があります (デフォルトでは、AWS KMS は 1 秒間に 300 件の楕円曲線非対称暗号化処理しかできません)。AWS KMS HSM と Nitro Enclave を組み合わせることで、セキュリティを確保したまま、これらの問題を解決できる vHSM を実装できます。 Nitro Enclaves は分離された、堅牢な制約のある仮想化コンピューティング環境です。AWS Nitro Systemは専用ハードウェアと軽量のハイパーバイザによって、強固な分離、Nitro Security Moduleによるハードウェア生成エントロピー、暗号認証といった機能を提供します。これにより、Enclaves の信頼性を検証し、許可されたコードのみが実行されることを確認できます。 Nitro Enclavesと AWS KMS を利用する CubeSigner の仕組み CubeSigner vHSM は、BLS などの主要な署名方式をソフトウェアで実装し、このコードを Nitro Enclave 上で実行します。これにより、任意の署名スキームをサポートでき、HSM よりもはるかに高速に署名を行うことができます。 vHSM はすべての署名キーを AWS KMS ベースのラッピングキーを使って暗号化します。トランザクションの署名要求を受けると、暗号化された署名キーとラッピングキーをEnclaves に取り込み、署名キーを復号化し、トランザクションに署名して、ユーザーに返します。vHSM での署名処理は、検証に十分な速度で行われ、パフォーマンスに影響を与えることはありません。その理由はネットワーク遅延を含めても 500ms 以下の時間しかかからないためです。 メッセージの署名には単一の署名キーの復号化が必要ですが、HSM は対称暗号化操作に最適化されています。例えば、AWS KMS では、デフォルトで毎秒 50,000 回の対称暗号化/復号化操作を実行できます。Nitro Enclave は、高速で非対称暗号操作 (例えば、署名の生成) を行えます。CubeSigner は、すべての暗号化された署名鍵 (この例では BLS バリデーター鍵ですが、一般的には任意の署名スキームの鍵) を DynamoDB に保存します。これにより、鍵のレプリケーション、バックアップ、DynamoDB のスケーラビリティとパフォーマンスの活用が可能になります。 ラッピングキーは AWS KMS を使用して保存および管理され、ノードオペレーターごとに 1 つのラッピングキーがあります。この鍵はEnclaves 内の vHSM にシールされ、AWS ルートユーザーからはアクセスできなくなっています。つまり、誰もラッピングキーを使用または抽出できません。KMS キーをEnclaves にシールすることは極めて強力な基本操作です。これにより、vHSM がオペレーターの署名キーを復号化できる唯一のコンポーネントであることが保証され、ソフトウェア上で HSM のようなハードウェア抽象化を実装することが可能になります。 Enclaves 内のコードだけがシークレットキーにアクセスできるため、キーを安全に保つには、Enclaves 内のコードを安全に保つことに尽きます。この目的で、コードは次の機能を備えています。 Rust で実装 – コードが秘密情報をメモリやサイドチャネルから漏洩しないように、低レベルで秘密情報の扱い方を制御できるため、Rust で開発しました。また、Rust を使用すれば、Enclaves 内で実行されるコードの安全性を証明する検証技術を簡単に使えます。 少ない依存関係 – cargo vet を使って依存関係を管理し、Rust の使用により、マッシブな実行時システム (JVM など)、複雑な Just-In-Time コンパイラ (JavaScript エンジンなど)、そして、それらに付随する大規模なサプライチェーンから解放されます。 最小権限 – Enclaves 内で実行されるコードのインターフェースが攻撃対象の表面積となります。当社の vHSM は、vsock 通信チャネルを使い、小さくタイプ安全なインターフェースを実装しています。 これは、他のサイナーとは異なり、Enclaves の境界を越えて任意のネットワーク要求をプロキシするようなものではありません。 接続先の制限 – vHSM から外部に通信できるのは、AWS KMS への安全な通信経路のみです。詳細については、 How AWS Nitro Enclaves uses AWS KMS を参照してください。しかし、ここでもサイナーはチャネルが侵害される可能性があると想定し、特定のEnclavesに関連付けられた一時的な秘密鍵と公開鍵を使用して、AWS KMS からの結果を証明書内の公開鍵で暗号化します。このようにすれば、AWS KMS の復号要求が発せられたEnclaves内でのみ、その復号結果を読み取ることができます。 おわりに このポストでは、Ethereum のバリデーターノードを運用する際の運用上の落とし穴やトラップについて説明し、特にノードオペレーターが日々直面する安全性、正確性、可用性の課題のバランスについて取り上げました。ノードにローカルでキーを管理することに対し、リモートに署名することにより、これらの課題に対処できます。しかし、リモートサイナーの設計が重要です。そのため、Nitro Enclave に基づくリモートシグニングソリューション CubeSigner の設計を詳しく説明し、CubeSigner がオペレーターが直面する安全性とペナルティの課題に対処するだけでなく、運用コストを大幅に削減でき、高可用性のバリデータークラスターを実行するのにも役立つことを示しました。 Cubist のCubeSigner サンドボックスアカウントに登録し、AWS Blockchain Node Runners テンプレートを使用して イーサリアムのバリデーターを起動し、独自のイーサリアムのバリデーターノードを実行することをお勧めします。 本記事は、 Use AWS Nitro Enclaves to build Cubist CubeSigner, a secure and highly reliable key management platform for Ethereum validators and beyond を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津 颯騎 が担当しました。 著者について フレイザー・ブラウン は、Cubistの共同創設者兼最高技術責任者（CTO）です。また、カーネギーメロン大学コンピューターサイエンス学部の助教授でもあります。彼女の研究は、セキュリティとプログラムの正確性に焦点を当てており、実運用システムの（一部の）検証から、実際のコードベースにおける悪用可能なバグの自動検出まで幅広く取り組んでいます。例えば、彼女が開発したツールは、人気のあるChromeやFirefoxブラウザにおいて、多くのゼロデイ脆弱性や報奨金対象のバグ、そしてCVE（共通脆弱性識別子）を発見しています。 デイアン・ステファン は、Cubistの共同創設者兼チーフサイエンティストです。また、カリフォルニア大学サンディエゴ校のコンピューターサイエンス・エンジニアリング学科の准教授でもあります。彼の研究は、セキュリティとプログラミング言語の交差点に位置し、特に実運用環境で展開される安全なシステムの構築に重点を置いています。2019年にVMwareに買収された、ランタイムセキュリティのスタートアップ企業Intrinsicの共同創設者でもありました。 デイビッド-ポール・ドーンザイファー は、AWSのブロックチェーン開発アーキテクトです。彼は顧客がエンドツーエンドのブロックチェーンソリューションを設計、開発、スケーリングするのを支援することに注力しています。彼の主な専門分野はデジタル資産のカストディと鍵管理ソリューションです。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今期から 週刊 AWS を担当させていただくことになり、わくわくしております。これからよろしくお願いいたします。 11 月 7 日 (木) 10:00 – 12:00 に データガバナンス事例祭り が開催されます。企業内のさまざまなデータを AWS サービスと最新のアプローチを活用して実現しているお客様より、具体的な取り組みについてお話しいただく予定でおります。私自身もデータ分析案件でお客様を支援させていただくことが多く、こちらのイベントを楽しみにしています。ぜひ、ご都合があえばご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年10月28日週の主要なアップデート 10/28(月) Meta の Llama 3.1 8B および 70B モデルが Amazon Bedrock で ファインチューニング が可能に Amazon Bedrock は、Meta 社の Llama 3.1 70B および Llama 3.1 8B モデルのファインチューニングをサポートするようになり、企業がこれらの生成 AI モデルを自社のデータでカスタマイズが可能になりました。Llama 3.1 モデルは、128K のコンテキスト長さ (Llama 3 の 16 倍) など、以前のバージョンに比べて大幅な改善が施されており、長いテキストから大量の情報にアクセスして処理することができるようになっています。また、ファインチューニングを使用すると、Llama 3.1 モデルを特定のドメインのタスクに適合させ、特殊な使用例におけるモデルのパフォーマンス向上が期待できます。 AWS Trust & Safety Center が AWS re:Post で利用可能に AWS Trust & Safety Centerでは、AWS のお客様が、不正利用が疑われる AWS 上のアクティビティやコンテンツを報告する方法や、AWS Trust & Safety から送信される不正利用通知の対処方法に関する情報を提供します。 さらに、お客様がアプリケーションを保護するために使用できる AWS サービスや、デジタルメッセージングのベストプラクティスについても詳しく説明しています。 たとえば、お客様が AWS ネットワーク上で不審なアクティビティを検出した場合、Abuse Reporting FAQs を参照し、AWS サービスの禁止された使用方法、Abuse Report の提出方法、AWS Trust & Safety に連絡するタイミングについての情報を得ることができます。 10/29(火) AWS CodeBuild がビルドの自動リトライをサポート AWS CodeBuild は、ソースコードをコンパイルし、テストを実行し、デプロイ準備の整ったソフトウェアパッケージを生成する、フルマネージドの継続的インテグレーションサービスです。 この新機能により、CodeBuild プロジェクトに再試行の上限を設定することができ、CodeBuild はその上限まで失敗したビルドを自動的に再試行します。 これにより、断続的な障害による中断を回避し、手動でビルドを監視してリトライするためのインフラストラクチャを追加する必要がなくなります。 AWS Clean Rooms がコンピュートサイズを設定可能な Spark SQL をサポート AWS Clean Rooms Spark SQL を提供開始し、お客様は Spark SQL を使ってカスタムクエリを実行できるようになりました。これにより、これにより、Spark エンジンを使ったAWS Clean Rooms コラボレーションが作成できます。Spark SQL 実行時に様々なインスタンスタイプを設定することができ、ワークロードをサポート可能です。Spark SQL の構文を使って大規模データセットにクエリが実行でき、パフォーマンス、スケール、コストに応じてリソースをカスタマイズできます。詳細は、 AWS Clean Rooms をご覧ください。 10/30(水) AWS DataSync データ転送のパフォーマンスとスケーラビリティを向上 Amazon S3 ロケーション間のデータ転送において、パフォーマンス、スケーラビリティ、オブザーバビリティを改善しました。AWS DataSync は、安全かつ確実にネットワーク経由でファイルを移動する高速データ転送サービスです。 追加された新機能では、DataSync タスクを Basic モードまたは Enhanced モードで実行するように設定できるようになりました。 特に、Enhanced モードでは、データの準備、転送、検証を並行して行うことで、データ転送プロセスを最適化および合理化し、ほとんどのワークロードで Basic モードよりも高速に実行できます。 詳細は AWS DataSync のドキュメント をご覧ください。 Amazon CloudWatch がプロビジョニングされたパフォーマンスを超える EBS ボリュームを監視可能に アプリケーションが Amazon EBS ボリュームのプロビジョニングされたパフォーマンスを超えようとしている場合に確認できる新しい 2 つの Amazon CloudWatch メトリクスが追加されました。2 つのメトリクスである Volume IOPS Exceeded Check と Volume Throughput Exceeded Check は、駆動された IOPS またはスループットが EBS ボリュームのプロビジョニングされたパフォーマンスを超えているかどうかを監視します。これにより、プロビジョニング不足の EBS ボリュームに起因する待ち時間の問題を迅速に特定し、対応することができます。 AI によるスケーリングと最適化を備えた Amazon Redshift Serverless を発表 Amazon Redshift Serverlessは、クラウドデータウェアハウスにおける AI 主導の次世代スケーリングと最適化をリリースしました。AI が活用されることにより、データ量の変化、同時ユーザー数、クエリの複雑さなど、すべての主要な次元にわたってワークロードの変化に合わせて自動的にスケーリングし、価格性能目標を達成・維持されます。 手動による介入なしに、変動するワークロードに対して最大 10 倍の価格パフォーマンスを提供できることが、 Amazon 内部のテストで実証されています。AI 主導のスケーリングと最適化により、パフォーマンスとコストを合理化しながら運用のオーバーヘッドを削減し、Amazon Redshift Serverless をよりスマートで効率的な活用が可能になります。 AWS Blog もご覧ください。 10/31(木) Amazon Aurora オペレーティングシステムのアップグレードのためのローリングアップグレードをサポート Amazon Aurora は、OS のアップグレードをローリングアップグレードでサポートしました。Aurora は、Aurora クラスターエンドポイントまたはリーダーエンドポイントを使用する際、データへの読み取りアクセスを維持しながら、Aurora データベースクラスターのオペレーティングシステムバージョンをシームレスにアップグレードします。 この機能により、データベースが 1 つ以上のリーダーインスタンスを持つクラスターの読み取りトラフィックに対応しつつ、一度に数個のリーダーインスタンスにアップグレードを自動的に適用します。Aurora クラスターのオペレーティングシステムをアップグレードする方法の詳細については、 技術ドキュメント をご覧ください。 11/1(金) Amazon Bedrock での Anthropic の Claude 3 Haiku の ファインチューニング を提供開始 Amazon BedrockでAnthropic の Claude 3 Haiku モデル の ファインチューニング が可能になりました。 Claude 3 Haikuは、Anthropic の 最もコンパクトなモデルであり、Anthropic によれば、そのインテリジェンスカテゴリーでは市場で最も手頃な価格で最速のオプションの一つです。 独自のタスクに特化したトレーニングデータセットを提供することで、Claude 3 Haiku をファインチューニングおよびカスタマイズし、モデルの精度、品質、一貫性を向上させ、生成 AI をさらにビジネス向けにカスタマイズすることができます。詳細は、 ローンチブログ 、 テクニカルブログ 、また ドキュメント をご覧ください。 Amazon WorkSpaces WSP は TCP/UDP ポート 443 経由のデスクトップ トラフィックが利用可能に Amazon WorkSpaces Amazon DCV 対応デスクトップ・トラフィックは、ポート 443 上の TCP と UDP の両方をサポートしました。 この機能は自動的に使用され、設定の変更は必要ありません。 また、ポート 4195 をご利用のお客様は、引き続きご利用いただけます。たとえば、WorkSpaces を管理する組織は、ユーザーが WorkSpaces に接続するクライアントネットワークを管理する組織と同じとは限らず、各ネットワークは独立して管理されているため、管理上の課題、遅延、またはアウトバウンドのアクセスルールを変更するための障害が発生します。追加された新機能により、WorkSpaces クライアントアプリケーションは、最適なパフォーマンスのために UDP（QUIC）を優先しますが、UDP がブロックされた場合は TCP にフォールバックされ、お客様は固有の TCP/UDP 4195 のユニークポートを開放する必要がなくなりました。詳細は、 Amazon WorkSpaces Administration Guide をご覧ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2024 年 10 月 30 日、AWS AppSync に AWS AppSync Events の機能が追加されました。この機能を使うと、開発者は安全で高性能なサーバーレス WebSocket API を使って、リアルタイムのイベントデータを数人または数百万人のサブスクライバーに簡単にブロードキャストできます。AWS AppSync Events を使えば、開発者はもう WebSocket インフラストラクチャの構築、コネクション状態の管理、ファンアウトの実装を心配する必要がありません。開発者は単に API を作成し、WebSocket 接続が行われているクライアントにサブスクライブされるイベントをパブリッシュするだけです。 AWS AppSync Event API はサーバーレスなので、すぐに始められ、自動的にスケーリングされ、利用した分だけ支払えばよいというメリットがあります。このブログでは、AWS AppSync Events および、AWS AppSync Event API とは何かを説明し、開発者がどのように始められるかを説明します。 リアルタイムのイベント更新は現在のアプリの重要な機能であり、ユーザーに差別化された経験を提供します。ライブスポーツのスコア、グループチャットメッセージ、価格レベル、または位置情報の更新など、開発者は最新の情報をリアルタイムに提供するアプリを構築したいと考えています。しかし、この機能を実装するのは簡単ではなく、スケーリングが難しくなります。これが AWS AppSync Events によって変わります。AWS AppSync Event API は簡単に設定でき、開発者はすぐに作業を開始し、標準の Web API を使用して WebSocket エンドポイントに接続できます。AWS AppSync Event API はサーバーレスで、接続されている数百万のクライアントにリアルタイムの更新をパブリッシュできるようスケールします。イベントドリブンアーキテクチャに投資してきた組織向けに、AWS AppSync Events は HTTP エンドポイントによるパブリッシュをサポートしています。これにより、 Amazon EventBridge などの一般的なサービスとの統合が簡単になり、バックエンドから生成されたイベントを Web およびモバイルアプリに簡単にパブリッシュできます。 AWS AppSync Events では、最初に API を作成し、どの認証モードがサポートされているかなどの基本的な設定を定義します。次に、名前空間に名前を割り当てることによりチャネル名前空間を作成します。これは、その名前空間内のすべてのチャネルの接頭辞にもなります。チャネル名前空間は、そのチャネルの機能を定義します。 たとえば、名前が messages のチャネル名前空間では、 /messages で始まるチャネルを公開およびサブスクライブできます。名前空間内のチャネルは一時的なものであり、必要に応じて作成されます。たとえば、必要に応じて /messages/group/admin または /messages/user/JohnDoe にイベントを公開できます。特定のチャネル /messages/user/JohnDoe のイベントをサブスクライブすることも、チャネルパスの最後にワイルドカードを使用して /messages/* または /messages/user/* のようなサブセットをサブスクライブすることもできます。 コンソールを使ってはじめる 始めるには、 AWS AppSync Console にアクセスしてください。そこで [Create API (API を作成)] を選択し、[Event API] を選んでください。API に名前を付け、[Create (作成)] を選択します。数秒で API が作成され、使用できる状態になります。コンソールでは、サービスがイベント API、デフォルトの名前空間、API キーを作成します。同じ結果を AWS CLI、AWS SDK、AWS CloudFormation、AWS CDK でも実現できます。 次に、 Pub/Sub エディタ に移動します。このエディタでは、コンソールから直接公開とサブスクライブを簡単に行えます。アイデアをすばやくテストし、機能を確認するのに最適なツールです。エディタを使用して、HTTP 経由でイベントを公開し、WebSocket 接続でサブスクリプションを設定できます。イベントを受信するには、[Subscribe] セクションで [Connect]、次に [Subscribe] を選択します。あとはチャネルに公開されたイベントを受信できる状態になります。HTTP エンドポイントでは、最大 5 件のイベントをまとめて公開できます。コンソールから公開するには、JSON オブジェクトの配列を入力するだけです。 例えば、Publish セクションに以下の値を入力してください。 [ { "message": "hello world!" }, "New WebSocket API!", true, 100, ["L", "G", "T", "M"] ] 5 イベントを Subscribe セクションで受信しました！ アプリケーションとの統合 AWS AppSync Events を使用するアプリケーションを構築するのは簡単です。 AppSync Events 用の AWS Amplify クライアント を使用でき、API の構成情報はコンソールの Integrations (統合) タブにあります。 Web ブラウザから API に接続するための外部依存関係はありません。以下の JavaScript のコード例は、ブラウザの Web API WebSocket を使ってエンドポイントに接続する方法を示しています。このコードを使用するには、Event API Settings (設定) ページから HTTP および リアルタイム DNS 名を取得し、API キーをコピーします。次に、ページの開発者コンソールを開きます。スニペットの値を指定し、スニペットを開発者コンソールのエディタに貼り付け、コードを実行します。 const REALTIME_DOMAIN = '' const HTTP_DOMAIN = '' const API_KEY = '' const authorization = { 'x-api-key': API_KEY, host: HTTP_DOMAIN } function getAuthProtocol() { const header = btoa(JSON.stringify(authorization)) .replace(/\+/g, '-') // Convert '+' to '-' .replace(/\//g, '_') // Convert '/' to '_' .replace(/=+$/, '') // Remove padding `=` return `header-${header}` } const socket = await new Promise((resolve, reject) => { const socket = new WebSocket( `wss://${REALTIME_DOMAIN}/event/realtime`, ['aws-appsync-event-ws', getAuthProtocol()]) socket.onopen = () => { socket.send(JSON.stringify({ type: 'connection_init' })) resolve(socket) } socket.onclose = (evt) => reject(new Error(evt.reason)) socket.onmessage = (event) => console.log('=>', JSON.parse(event.data)) }) socket.send(JSON.stringify({ type: 'subscribe', id: crypto.randomUUID(), channel: '/default/*', authorization })) ブラウザの Web API  fetch メソッドを使用してイベントを送信できます。 たとえば、開発者コンソールで次のように実行します。 const event = { "channel": "/default/introductions", "events": [ JSON.stringify({message:'Hello World! Introducing AWS AppSync Events!'}) ] } const response = await fetch(`https://${HTTP_DOMAIN}/event`, { method: 'POST', headers: authorization, body: JSON.stringify(event) }) console.log(response) 接続、承認、WebSocket の使用についてより詳しく知るには、 ドキュメント を参照してください。 イベントハンドラの操作 AWS AppSync Events を使用すると、発行したイベントが処理されたときや、クライアントがチャネルをサブスクライブしようとしたときにビジネスロジックを定義できます。これは、チャネル名前空間内に定義された関数であるイベントハンドラーで行われます。イベントハンドラーはオプションであり、チャネル名前空間の範囲内にあります。AWS AppSync Events は onPublish ハンドラと onSubscribe ハンドラの 2 種類のハンドラをサポートしています。onPublish ハンドラーは、イベントが受信されたときに呼び出され、接続されているクライアントにイベントがブロードキャストされる前に実行されます。onPublish ハンドラから、イベントペイロードの形状を変換したり、イベントをフィルタリングしたり、発行されたイベントを拒否したりできます。ハンドラーは APPSYNC_JS ランタイムで実行されるため、JavaScript を記述するだけです。たとえば、イベントを変換するには、 map をイベント配列に適用し、イベントの id とイベントの payload を返すようにします。 export function onPublish(ctx) { return ctx.events.map(event => ({ id: event.id, payload: { ...event.payload, message: event.payload.message.toUpperCase() } })) } 特定のイベントを除外し、サブスクライブしているクライアントにブロードキャストされないようにするためには、リストからフィルタリングし、ブロードキャストしたい部分だけを返します。たとえば、イベントの配列に対して filter を呼び出すことができます。 勝率が 90 % を超えるゲームのイベントのみをブロードキャストしたい場合を想像してみましょう。 export function onPublish(ctx) { return ctx.events.filter(event => event.payload.odds > 0.9) } フィルタリングを使えば、イベントをサイレントに破棄できますが、イベントを破棄するときにパブリッシャーにエラーを返すこともできます。 たとえば、イベントに必ず挨拶メッセージが含まれるようにして、パブリッシャーにエラーを返す場合は以下のようになります。 export function onPublish(ctx) { return ctx.events.map(event => { if (!event.payload.message) { return { ...event, error: 'You should always included a greeting.' } } return event }) } クライアントがサブスクリプションを確立しようとするときに、onSubscribe ハンドラが呼び出されます。 util.unauthorized() を呼び出すことでサブスクリプションを拒否できます。 Amazon Cognito User Pools で認証されたユーザーを自分のチャネルのみに制限したい場合は以下のようになります。 export function onSubscribe(ctx) { if (ctx.info.channel.path !== `/messages/inbox/${ctx.identity.username}`) { console.error(`user ${ctx.identity.username} tried connecting to wrong channel: ${ctx.info.channel.path}`) util.unauthorized() } } クライアントは、パターン /messages/inbox/<username> に一致するチャネルにのみサブスクライブできるようになりました。 イベントドリブンアーキテクチャ AWS AppSync Events は、イベントドリブンアーキテクチャパターンにシームレスに組み込むことができます。Amazon EventBridge を使えば、API の送信先を設定して、イベントを AWS AppSync Events の HTTPS エンドポイントに転送できます。 EventBridge コンソールで、新しい接続を作成し、認証タイプは [API Key]を選択します。 API キー名 には x-api-key と入力し、 Value にはあなたの API キーの値を入力します。次に、新しい API destination を作成します。 API destination endpoint には https://<HTTP_DOMAIN>/event という形式を使用します。ここで <HTTP_DOMAIN> は、前に控えた HTTP ドメインです。 HTTP メソッド は POST に設定します。 Connctions type は、新しく作成した接続を選択し、を作成します。これで、この宛先をターゲットに設定したルールを作成できます。ターゲットの入力パス (InputPath) には "$.detail" を指定すれば、イベントの詳細全体が Event API に転送されます。 AWS AppSync Events にイベントを転送できるようになりました。たとえば、次の イベントの詳細 を使用して EventBridge に発行できます。 { "channel": "/default/introductions", "events": [ "{\"message\":\"Hello from EventBridge!\"}" ] } API の機能の探索 API に複数の認証モードを設定し、それぞれのチャネル名前空間で異なる認証動作を設定することができます。API にカスタムドメインを関連付けて、さらなる保護のために AWS Web Application Firewall を付加できます。また、 Amazon CloudWatch メトリクス および Amazon CloudWatch Logs との統合もサポートされているため、API のパフォーマンスを完全に把握できます。 今後の展開 このブログでは、AWS AppSync Events を紹介し、AWS AppSync Event API を始める方法を説明しました。チャネル名前空間、チャネル、ハンドラ、Amazon EventBridge との統合方法についても説明しました。 AWS AppSync Events のリリースは重要なマイルストーンとなりますが、これはスタートに過ぎません。間もなく、双方向の WebSocket とデータソースのサポートを追加する予定です。これにより、カスタムデータソースと送信先を作成でき、Amazon DynamoDB や Amazon Aurora などのデータソースを使用してイベントを拡張または永続化できるようになります。ハンドラーの代替として AWS Lambda 関数のサポートも予定しています。また、型の形状を簡単に共有および適用できるようにするため、スキーマのバリデーションをサポートする予定です。乞うご期待ください。 まとめ AWS AppSync Events は、AWS AppSync が利用可能なすべてのリージョンで利用できるようになりました。最初のイベント API を作成するには、AWS AppSync コンソールにアクセスしてください。AWS AppSync Events はサーバーレスで、AWS AppSync Event API 操作と実際のリアルタイム接続時間に対してのみ料金が発生します。毎月 25 万回の無料のリアルタイム Event API 操作をご利用いただけます。AWS AppSync Events の詳細については、 ドキュメント をご覧ください。価格に関する詳細は、 価格 ページをご確認ください。 AWS AppSync を使えば、アプリケーションをイベント、データ、AI モデルに簡単に接続できます。AWS AppSync Events を利用すれば、任意のイベントソースから発行された更新を、サーバーレス WebSockets 経由でサブスクライブしているクライアントに送信し、リアルタイムの体験を実現できます。また、AWS AppSync GraphQL では、単一の GraphQL API エンドポイントを使って、アプリケーションを複数のデータベース、マイクロサービス、AI モデルに接続できます。 本記事は「 Announcing AWS AppSync Events: serverless WebSocket APIs to power real-time web and mobile experiences at any scale 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は、2024 年 10 月 15 日に Tarush Gupta によって執筆された「 Enhance your real-world skills with AWS Cloud Quest and AWS Jam 」を翻訳したものです。 今日の急速に進化するテクノロジー環境では、実践的な経験とスキルを身につけることが重要であり、キャリア形成に役立ちます。AWS はこのニーズを認識しており、AWS Cloud Quest や AWS Jam などの魅力的でインタラクティブな学習リソースを提供しています。これらの学習体験は技術的な概念を教えるだけでなく、実践的なスキルを身につけるための没入感のある環境を提供します。AWS が提供するこれらの学習に関する取り組みが、プロフェッショナルな環境で役立つ、実践的なスキルを身につけるのを助ける方法を探ってみましょう。 AWS Cloud Quest とは AWS Cloud Quest はゲームベースの学習体験で、AWS サービスの使い方を楽しく、やりがいのあるものにするために設計されています。学習者は一連の課題、クエスト、パズルを通じて旅に出ることになり、そこでは実際のシナリオを解決するために AWS サービスの知識を適用する必要があります。学習者はタスクを完了することでレベルを上げ、新しいコンテンツを利用できるようになり、ダイナミックで魅力的な方法で AWS の概念に対する理解を深めることができます。クエストの課題をすべて完了するとデジタルバッジが授与され、スキルの習熟度を示すことができます。現在利用可能な AWS Cloud Quest には複数のバージョン (訳者注: カテゴリ、ロールを表します) が用意されており、いくつか例を挙げると、 AWS Cloud Quest: Cloud Practitioner (無料でプレイ可能) 、 AWS Cloud Quest: Solutions Architect 、 AWS Cloud Quest: Generative AI 、 AWS Cloud Quest: Security Specialty などがあり、AWS Skill Builder のサブスクリプションに登録することにより利用可能です。ヘルスケア、金融サービス、自動車および製造向けの AWS ソリューションを深く知りたい方は AWS Industry Quest もあわせてご覧ください。 訳者補足: 2024 年 11 月現在、日本語で学習可能な AWS Cloud Quest のロールは下記の通りです。なお、Cloud Quest 日本語版に関しては こちらの記事 もあわせてご参照ください。 Cloud Practitioner Solutions Architect Machine Learning Generative AI AWS Jam Journey と チーム向け Jam について AWS Jam は、 AWS のサービスとソリューションを実験するためのシミュレーション環境を提供する、もう 1 つの実践的な学習オプションです。これには個人、またはチームの一員として参加可能です。指定された時間枠内で AWS のツールとテクノロジーを使用し、現実世界の課題を解決するための実践的な経験と自信を得ることができます。個人で取り組みたい場合は、機械学習、セキュリティ、DevOps など、12 以上の種類が用意されている AWS Jam Journey をチェックしてください。チーム向けの AWS Jam では、実際のユースケースやシナリオを取り上げたイベントが用意されており、参加者は、AWS のサービスがビジネス上の課題にどのように対処し、イノベーションを推進できるかについて、実践的な洞察を得ることができます。どちらも AWS Skill Builder のサブスクリプションで利用可能です。 特徴 1: ハンズオンによる実践的な学習 AWS Cloud Quest と AWS Jam の主な特徴の 1 つは「実践的な学習を重視していること」です。学習者は情報を受け身で消費するのではなく、シミュレーション環境で AWS のサービスを自ら操作していきます。この実践的なアプローチにより、学習者は実際のシナリオで遭遇する可能性のある課題に対して、実験したり、ミスをしたりしながら、自らの経験から学習することができます。実践的な演習やシナリオに取り組むことで、学習者は実際のプロジェクトや環境で自分のスキルを適用するために必要な自信を身につけ、習熟度を高めます。AWS Jam では、行き詰まった場合に手がかりを求めることも可能ですが、ゲーム内では「ヒントに頼らない問題解決や探索」が奨励されます。学習者が求めるヒントやガイダンスが少ないほど、最後に得られる得点が高くなります！ 特徴 2: 現実世界で役立つ、実用的なスキルの構築 AWS Cloud Quest と AWS Jam は、共に「実際の能力の構築に重点を置いている部分」が従来のトレーニング方法と異なる部分です。AWS Cloud Quest では、リーダーボード、実績、ソーシャル要素などのゲーミフィケーション要素が、学習者が習得と卓越性を目指して努力する動機付けとなります。現実世界の課題とシナリオをシミュレートすることで、学習者は問題解決スキル、批判的思考能力、情報に基づいた意思決定能力を身に付けることができます。これらはすべて、現代のテクノロジー業界で成功するために不可欠な能力です。AWS Jamでは、チームとして協力する機会があり、業務環境で不可欠なコラボレーション、コミュニケーション、チームワークのスキルを育むのに役立ちます。AWS Jam イベントでは、学習者が同僚、メンター、業界の専門家と交流し、ネットワークを広げる機会があります。これらの人脈は、貴重な洞察、キャリアの機会、そしてイベントを超えた協力関係につながる可能性があります。 最後に AWS Cloud Quest と AWS Jam は、AWS のクラウドコンピューティングの技術的スキルを高め、実社会での能力を高めたいと考えている個人にとって非常に貴重なリソースです。これらのプラットフォームは、ゲーミフィケーション要素、実践的な学習体験、現実世界のシナリオを組み合わせることで、学習者がプロフェッショナルな環境で成功するための準備を整える、ユニークで効果的な学習アプローチを提供します。経験豊富な IT プロフェッショナルの方にも、クラウドの旅を始めたばかりの方にも、AWS Cloud Quest と AWS Jam は、絶え間なく変化するクラウドテクノロジーの世界で学び、成長し、優れた能力を身につける機会を提供します。 翻訳は Technical Instructor の 室橋 が担当しました。

これは 2015 年のブログ記事「 Amazon SES Best Practices: Top 5 Best Practices for List Management 」の 2024 年更新版です。効果的なメーリングリスト管理の基本原則は依然として先のブログが参考になりますが、この 9 年間で状況は大きく進化しました。更新された本ブログは、 Amazon Simple Email Service (SES)の顧客に最新のベストプラクティスと洞察を提供し、高い配信率を確保し、強力な送信者の評価を維持することを目的としています。 2024 年版で含まれる主な変更点と更新点は次のとおりです。 悪意を持つ者やボットによる登録を防ぐため、CAPTCHA を使って登録フォームを保護するためのガイダンス 複数のメールボックスプロバイダ (MBP) による 新しい要件 のため、メール配信のバウンス率、苦情率、遅延を監視することの重要性が高まっている Amazon SES の Virtual Deliverability Manager (VDM) ツールの紹介と、それが配信性の問題を特定するのに役立つ簡単な説明 不活性の購読者を積極的に削除することを含む、エンゲージドサブスクライバーリストを維持するための更新された推奨事項 業界全体でワンクリック解除 (one-click unsubscribe) 機能の採用が必須となり、その利点への重点 メールリストを自然に育てる必要性を強調し、購入したリストや同意を得ていないリストの使用を避けること この更新されたガイドラインで紹介されたベストプラクティスに従うことで、Amazon SES のお客様はメールキャンペーンが受信トレイに届く可能性を最大にできます。これらのベストプラクティスに従うことで、購読者の信頼も得られ、メールマーケティングへの投資に対するより高いリターンが得られます。 このブログでは、メール送信の強力な評判を維持し、高い配信率を確保するために役立つ、以下の最新のベスト プラクティスについて説明します。 確認付きオプトイン (ダブルオプトイン) を使用する バウンス、苦情、配信遅延を慎重に監視する 関心が薄れた購読者を削除して、エンゲージメントの高い購読者リストを維持する 簡単に解除できるようにして、クリーンで適切なリストを維持する 自然な方法でリストを育てることで信頼を築く 確認付きオプトイン (ダブルオプトイン) の利用 アクティブで関与するユーザーにターゲットを絞ることは、強力な送信者の評価を維持する上で最も効果的な方法の一つです。この効果が実証されているベストプラクティスは、確認済みオプトイン(ダブルオプトインとも呼ばれる)として知られています。この方法は簡単に実装でき、大変効果的です。ユーザーがウェブサイト上のフォームを使ってメールアドレスで受信登録やスペシャルオファーの申し込みを行った場合、受信の確認メールをリクエストされたアドレスに送信し、メール配信を承諾するリンクをクリックするよう依頼する必要があります。このリンクをクリックすることで、メールアドレスの所有者が明示的にメール受信に同意したことになります。受信者がリクエストを確認後、そのメールアドレスをアクティブな配信リストに追加します。現在ほとんどのユーザーはこのタイプの確認プロセスに慣れており、正当なユーザーは問題なく自身の関心を確認することができます。 オンラインのボットやその他の自動化ツールや不正行為が増えたことで、確認済みオプトインに関する当社の指針は進化を遂げました。高い送信者評価を維持するため、現在はウェブ上の登録フォームを CAPTCHA (またはそれに類する仕組み) で保護することを推奨しています。こうすれば、配信リストへの参加リクエストが実在する人間からのものであり、ボットや不正な自動化ツールではないことが保証されます。リクエストの送信者が人間であることを証明できた後に、初めてそのメールアドレスを受領し、確認メールを送信します。この追加の保護層により、ボットや不正な送信者がユーザーに無断で登録することを防ぎます。 CAPTCHA はダブルオプトインプロセスの基盤となる要素になりました。登録プロセスを CAPTCHA で保護することで、ユーザーに送信されるオプトイン確認メッセージの無作為な送信を最小限に抑えられ、その結果、メールボックスプロバイダーがこうしたメッセージをスパムとしてブロックするリスクが軽減されます。確認メッセージがブロックされてしまえば、ダブルオプトインのプロセスそのものが機能しないためです。 Figure 1: AWS WAF CAPTCHA examples. 確認済みオプトインにより、メール受信者の正当性を事前に検証することで、偽のメールアドレス、タイプミス、ボットや悪意のある送信者による不正な登録などに起因するバウンスの数を削減できます。このような無効なアドレスは送信者評価に悪影響を及ぼすため、非常に重要な対策です。 Figure 2: A diagram showing the ideal confirmed opt-in architecture to limit risk of bot abuse. ウェブ登録フォームに CAPTCHA を追加することで、人間がプロセスに関与していることを証明できます。 リンクをクリックすることにより、メールボックスにアクセスできる人物またはアプリケーションが存在することを証明できます。 受信者が正しいワンタイムパスコード (OTP) をウェブフォームに入力する必要があることで、登録を要求した人物が確認の人物と同一であることを証明できます バウンス、苦情、配信遅延などのイベントを監視することで、メールアドレスが有効で、受信者が確認メッセージをスパムとしてマークしていないことが証明できます。 ウェブフォームの不正使用の兆候がある場合に、確認メッセージを送信する際にサブドメインを使用して、配信性に対する評判への影響を軽減します。 ウェブフォームの不正使用の兆候がある場合は、受信者がメッセージをスパムとしてマークしないように、不正使用を報告する簡単なオプションを受信者に提供します。 確認済みオプトインにより、メッセージを明示的に受信に同意した購読者のみに送信できるようになるため、苦情の発生リスクが更に低減されます。簡単なワンクリック解除のオプションを受信者に提供することで、受信者のコミュニケーション設定を尊重する姿勢を示せます。 多くの成功した送信者は、この確認のタイミングでウェルカムメールを直ちに送信し、以下の 2 つの重要なメリットを得ています。 エンゲージメントを高める: 新規の購読者に温かい歓迎の言葉を伝えながら、うまく再エンゲージメントを促し、ブランドが新鮮な印象を与え続けます。 二重の確認: このようなメールには、受信者の同意を二重に確認し、メール受信の意思を確認するための呼びかけ(CTA: call-to-action) が含まれていることが多いです。 ブランドの信頼性を高める: 受信者が簡単に購読を解除できる方法を提供することで、いつでも購読解除できる自信を持ってもらえます。 バウンス、クレーム、配信遅延を注意深く監視する 更新情報: メールボックス プロバイダによる最近の変更により、これらのメトリクスを監視することがさらに重要になりました。2024 年 2 月以降、Google、Yahoo、Microsoft などのメールボックス プロバイダは、すべての大量送信者に 0.3%以下のスパム苦情率を維持することを求めています。これらのメールボックス プロバイダは、低いスパム苦情率を維持することで、配信率の向上、送信者の評価の維持、受信者の受信トレイの使用体験向上につながると説明しています。 最新の業界基準と要件を完全に理解するために、次のことをお勧めします: 概要を読む : 主要なコンプライアンス ガイドラインを把握する ウェビナーを視聴する : AWS チームと Gmail チームによって提示された詳細な内容とベストプラクティスについて掘り下げましょう。 Amazon SES では、 バウンスとクレーム 、 配信遅延イベント に関する実際のフィードバックを イベント配信機能 を通じて入手できます。これにより、問題のあるメールアドレスを素早く特定して削除し、健全な購読者リストを維持することができます。 ハードバウンスやクレームを受け取った場合は、そのメールアドレスをリストから削除し、根本原因を調査することが不可欠です。例えば、新規登録でのバウンスやクレーム率の急増は、フェイクの登録が原因かもしれません。そのような場合は、確認付きオプトイン(メーリングリスト構築におけるベストプラクティス)を活用することで、この問題を軽減できます。サインアップと OTP に別のドメインを使用すれば、マーケティングやプロモーション向けメッセージとは別に、サインアップやその他のトランザクション メッセージのバウンスやクレームを区別できます。詳細は こちら をご覧ください。 Amazon SES の Virtual Deliverability Manager (VDM)は、追加のダッシュボードを構築する必要がなく、配信可能性のトレンドと潜在的な問題を特定できる機能です。VDM は、送信データに関する深い洞察を提供し、配信率の向上に役立つアクションを示してくれます。VDM を使えば、バウンス率、クレーム率、その他の主要な指標(KPI)を監視し、メール配信の成功指標を把握できます。VDM を活用すれば、アカウント レベルの統計情報からメッセージレベルまでドリルダウンし、配信可能性の問題を特定できます。これにより、すべての配信率データの中から問題のあるメールを見つける必要がなくなります。主な機能は次のとおりです: バウンスの詳細 : VDM を使えば、受信者のメールアドレス、タイムスタンプ、メールボックスプロバイダから直接受け取る SMTP レスポンスコードごとにバウンスしたメールを特定できます。バウンスの種類 (永続的/一時的) や受信者のドメインごとにメールをグループ化して分析し、メッセージの遅延が大きな問題に発展する前に適切な対処ができます。 苦情 : メールをスパムとしてマークした受信者を特定し、アクティブなメーリングリストから削除できます。 注意点: Gmail の受信者向けの指標追跡に関しては、 Google Postmaster Tools も監視し、スパム苦情率を低く抑える必要があります。 配信メトリクス : 配信の試行、再試行、成功を監視し、リアルタイムのデータに基づいて配信率の向上に向けた意思決定ができます。 VDM は、送信者の評価や配信率を損なうおそれのあるバウンスや苦情などの潜在的な問題を事前に警告してくれます。早期に対処することで、メールが必ず受信トレイに届くよう配信率を持続的に改善できます。 VDM は有料サービスですが、Amazon SES ユーザー向けに 無料でテストできる仕組み があります。 詳しくは次のリソースを参照してください: Explore the Improve Email Deliverability with VDM : VDM の機能と利点について学ぶリソース Amazon QuickSight を使用して AWS Console の外部から VDM と DMARC レポートにアクセスする方法を確認する Amazon SES のバウンスや苦情の監視に関する追加のガイダンスは、次のリソースを参照してください: Amazon SES ドキュメンテーション: Amazon SES の送信アクティビティの監視 Amazon SES におけるメール配信可能性の理解 Amazon SES ブログ記事: Analyzing Amazon SES event data with AWS Analytics Services Handling Bounces and Complaints Improve email delivery rates with email delivery and engagement history for every email Amazon SES – How to track email deliverability to domain level with CloudWatch 非アクティブな受信者を削除して熱心な購読者リストを維持 メールマーケティング担当者は、購読者がメールを開封していない場合、またはメール内の行動を促す呼びかけ (CTA) に対応していない場合、送信したコンテンツにはもう関心がないという前提のもとで運営する必要があります。このカテゴリに該当する購読者は、定期的にメーリングリストから削除して、購読者リストが健全で興味をそそられるようにする必要があります。次の 2 つのアプローチで購読リストを定期的に見直して更新することで、キャンペーンの成功と配信率を高めましょう。 Amazon SES による購読者のエンゲージメントのトラッキング Amazon SES には、イベント、メトリックス、統計を使用して送信アクティビティをモニタリングする方法が用意されています。これらのモニタリング方法を使用して、送信したメールに対する顧客のエンゲージの割合を測定できます。たとえば、 SES のドキュメント で説明されている設定セットでカスタムメールドメインの使用を設定する場合、SES のイベントパブリッシングを利用することで、全体的な開封率とクリックスルー率を確認できます。 Figure 3: Serverless Architecture to Analyze Amazon SES events E メール送信アクティビティを詳細なレベルでトラックするには、AWS ブログ記事「 Analyzing Amazon SES event data with AWS Analytics Services 」を参照してください。 エンゲージメントがない購読者を積極的に削除 購読者がメーリングリストに登録しても、メッセージの開封やクリックを行わずエンゲージしていないシナリオを想像してみてください。このアクティビティの欠如は、購読者の関心がなくなっていることを示している可能性があります。これに対処するには、業界標準に基づいて適切なエンゲージメント期間（たとえば、開封やクリックがない期間が 6 か月間）を設定することをおすすめします。ただし、購読者にメールを送信する頻度によっては、この期間を調整する必要がある場合があります。たとえば、毎日ニュースレターを送信する場合、操作がない期間が 6 か月間で購読者を削除というのは長すぎる可能性があります。逆に、毎月のアップデートのみを送信する場合は、6 か月の期間を設定することは適切な場合があります。重要なのは、適切なバランスを見つけることです。明らかに興味を失った購読者は削除しますが、通常のメール頻度ほど頻繁に反応しない購読者は急いでリストを選別しないでください。特定のメール頻度に合わせてエンゲージメント期間を調整することで、購読者リストをアクティブでエンゲージメントの高い状態に保つことができます。 「ウィンバック」メールキャンペーンの検討 完全に非アクティブな購読者をリストから削除する前に、特別な「ウィンバック」メールを送信することを検討してください。再エンゲージメントを図るこの最後の試みは、貴重な購読者を取り戻すための効果的な戦略となり得ます。ウィンバックメールには、受信者が送信したメッセージに再び関心を持ってもらえるよう、明確で説得力のある行動を促す呼びかけ (CTA) を記載する必要があります。これには、ユーザーの設定を更新したり、メッセージに関心を示したことを確認したりすることが含まれる場合があります。これらの購読者にもう一度チャンスを与えることで、リストの一部を再度有効にしても、それらの受信者を維持できる場合があります。ただし、ウィンバックメールでも返答が得られない場合は、アクティブなメーリングリストからそれらのアドレスを削除して、健全で熱心な購読者ベースを維持するのが最善です。 確認済みのダブルオプトインプロセスを経て最初にオプトインした購読者であっても、時間が経つと非アクティブになる可能性があります。これらのメールアドレスは破棄され、ドメイン所有者によってスパムトラップに変換されることがあります。スパムトラップは、リスト作成や長期的なリストハイジーンに関するベストプラクティスに従っていない可能性のある送信者を特定するために組織が使用するメールアドレスです。これらの使用頻度の低いアドレスに電子メールを送信し続けると、いくつかの悪影響が発生する可能性があります。そのドメインがメールボックスプロバイダーでの評判が悪くなったり、リアルタイムのブロックリストに載ったりして、複数のメールボックスプロバイダーへの配信に影響を与える可能性があります。場合によっては、Amazon SES サービスが停止されることがあります。 これらの潜在的な落とし穴を回避し、送信者の評判を維持するには、エンゲージメントのない購読者を積極的に削除することが唯一の方法です。 このトピックの詳細については、次のリソースを参照してください。 Analyzing Amazon SES event data with AWS Analytics Services Amazon SES 送信アクティビティのモニタリング So You’ve Hit a Spamtrap? メールに反応しない購読者を積極的に削除すると、購読者ベースを新鮮で魅力的な状態に保ち、全体的な配信率とキャンペーンの成功率を向上させることができます。追加の利点として、非アクティブな購読者を排除することで、真に関心のある購読者にのみ連絡できるため、メール送信コストが削減され、メールキャンペーンの投資収益率が向上します。 非アクティブな購読者を削除することは、確認済みのオプトインプラクティスを効果的に補完するものであり、健全でパフォーマンスの高いメーリングリストを維持するのに役立ちます。 登録解除を簡単にし、クリーンで規制に準拠したリストを維持できるようにする 更新:主要なメールプロバイダーによる 最近の変更 により、受信者に明確で使いやすい登録解除オプションを提供することがさらに重要になっています。 2024年2月の時点で、GoogleとYahooはすべてのメールの一括送信者に対し、メッセージ内に目立つ購読解除リンクを含めることを義務付けています。2024年6月には、 ワンクリック購読解除ヘッダー （ RFC 2369 および RFC 8058 で定義）の実装も業界全体で義務付けられました。 Figure 4: A diagram of one-click unsubscribe flow. 業界全体を対象とした新しい一括送信者要件は、最終的に送信者と受信者の両方に次のメリットをもたらします。 スパム苦情の軽減 — 簡単に登録解除できるオプションにより、不満を抱いている受信者がメールをスパムとしてマークする可能性が低くなります。これにより、送信者の評判が好調に保たれます。 送信者評価の向上 — 購読者がエンゲージし、同意を得たクリーンなメールリストを作成することで、送信者の評価が健全に保たれ、メッセージがスパムフォルダではなく受信トレイに確実に届きます。 メール送信に関する購読者の希望を尊重することが重要です。受信者にコミュニケーション設定を管理するためのわかりやすく簡単な登録解除方法を提供することで、メーリングリストをクリーンでコンプライアンスに準拠したものに保ち、送信者の評判を維持するのに役立ちます。 米国 、 カナダ 、ヨーロッパやアジアの一部を含む多くの地域では、送信者に明確でアクセスしやすい登録解除メカニズムを提供することを義務付ける法律が採用されています。これらの規制に従うことで、送信やローカルメッセージングの法律に関連する潜在的な法的問題を回避できます。 Amazon SES には ドキュメント に記載されている一括送信者要件をサポートする基本的なサブスクリプション管理機能があります。SESのお客様の中には、エンドユーザーからの登録解除要求を処理するために、より包括的な独自のシステムを開発および導入することを選択しているお客様もいます。このトピックの詳細については、AWS ブログ記事「 Using one-click unsubscribe with Amazon SES 」を参照してください。 リストを自然に育てて信頼を築く 近道の誘惑を避ける ブローカーから購入したメーリングリストを使用するなど、近道を取りたくなるかもしれません。ただし、これらの「オプトイン」アドレスは、多くの場合、あなたのものではなく、ブローカーのリストにサインアップした受信者のものです。これらの自然ではないリストに頼ると、悲惨な結果につながる可能性があります。 スパムの苦情: メールの受信に同意しない受信者は、メールをスパムとしてマークし、送信者の評判を傷つける可能性がはるかに高くなります。 法的問題: 多くの国で、特に新しい 0.3% 未満のスパム率要件では、同意のないメーリングリストの使用を禁止する厳しい法律が制定されています。 登録解除と信頼の喪失: 求められていないメールを送信すると、登録解除率が高くなり、ブランドの評判が損なわれる可能性があります。 リストを自然に構築することに焦点を当てる ブローカーからリストを取得する代わりに、確認付きオプトインや簡単な登録解除のオプションなど、これまでに説明したベストプラクティスに従って、自然にメーリングリストを作成することに集中してください。これにより、コンテンツを真に受け取りたいと思っている熱心な購読者を引き付けて維持することができ、送信者と受信者の良好な関係と信頼を築くことができます。 個人の好みを尊重する 組織内であっても、各受信者のコミュニケーションの好みを尊重することが重要です。ブランド A からのメールにサインアップした場合、ブランド A とブランド B が同じ会社のものであってもブランド B からのメッセージを受け取りたいとは限りません。このような種類のブランド間の迷惑メールを送信すると、評判が悪くなり、スパムの苦情につながる可能性があります。このよくある落とし穴を避けるには、ブランドごとに個別のメーリングリストを作成します。これにより、受信者は明示的にオプトインしたコンテンツのみを受け取ることができ、信頼とエンゲージメントが高まります。 自然に成長し、エンゲージメントの高いメーリングリストがもたらす長期的なメリットは十分に文書化されており、配信率の向上、開封/クリック率の向上、メールマーケティングへの投資収益の向上などがあります。 スパムフォルダではなく受信ボックスに振り分ける：リスト管理の効率化がもたらすメリット この最新ガイドでは、Amazon SES のお客様が送信者の高い評判を維持し、高い配信率を確保するのに役立つ、E メールリスト管理の 5 つの重要なベストプラクティスを探ってきました。 最初に、確認済みオプトイン（ダブルオプトイン）の重要性と、CAPTCHA を組み込むことがボットや悪意のあるユーザーの登録を防ぐための基本的な要素になった経緯について説明しました。購読者の正当性を事前に検証することで、無効なアドレスによる影響を最小限に抑え、フォームの不正使用による苦情の可能性を減らすことができます。 次に、バウンス、苦情、配信遅延などの主要な指標を注意深く監視する必要性が高まっていることを強調しました。E メールプログラムの配信可能性に関する重要なインサイトを提供できる Amazon SES Virtual Deliverability Manager のような E メール管理ツールや機能について説明しました。送信者の評判を維持し、メッセージが受信トレイに流れ続けるためには、配信性の問題に早期に対処することが重要です。 また、非アクティブな受信者を積極的に削除したり、ターゲットを絞った「ウィンバック」キャンペーンを検討したりするなど、エンゲージメントの高い購読者リストを維持するための戦略についても説明しました。リストを新鮮で応答性の高い状態に保つことで、受信ボックスへの配置やキャンペーンのパフォーマンスが向上するという形で成果が得られます。 受信者が簡単に登録解除できるようにすることは、コンプライアンスのためだけでなく、信頼を築き、スパム苦情を減らすためにも同様に不可欠となっています。メールボックスプロバイダーが現在求めているワンクリック購読解除の標準は、送信者と受信者の両方にメリットをもたらします。 最後に、購入したメーリングリストのような近道よりも、自然にリストを成長させることの重要性を強調しました。自社のブランド内であっても、個人の好みを尊重することで、コンテンツに真に関心を持つ購読者を引き付け、維持することができます。 メーリングリスト管理の5つのベストプラクティスを実践することで、顧客やエンドユーザーとの長期的なコミュニケーション手段となるメールリスト形式のマーケティング資産を構築して維持できるようになります。 ご不明な点がある場合や詳細なガイダンスが必要な場合は、 SESフォーラム でお気軽にお問い合わせください。私たちは、お客様が進化するEメール環境に対応し、Amazon SESへの投資の可能性を最大限に引き出すお手伝いをします。 著者について Brett Ezell is your friendly neighborhood Solutions Architect at AWS, where he specializes in helping customers optimize their SMS and email campaigns using Amazon Pinpoint and Amazon Simple Email Service. As a former US Navy veteran, Brett brings a unique perspective to his work, ensuring customers receive tailored solutions to meet their needs. In his free time, Brett enjoys live music, collecting vinyl, and the challenges of a good workout. And, as a self-proclaimed comic book aficionado, he can often be found combing through his local shop for new books to add to his collection. Zip is an Amazon Pinpoint and Amazon Simple Email Service Sr. Specialist Solutions Architect at AWS. Outside of work he enjoys time with his family, cooking, mountain biking and plogging. Jesse Thompson is an Email Deliverability Manager with the Amazon Simple Email Service team. His background is in enterprise development and operations, with a focus on email abuse mitigation and encouragement of authenticity practices with open standard protocols. Jesse ’ s favorite activity outside of technology is recreational curling. 翻訳はソリューションアーキテクトの松岡勝也が担当しました。原文は こちら です。