9月4日より、 Stability AI の 3 つの新しい Text-to-Image モデル (Stable Image Ultra、Stable Diffusion 3 Large、Stable Image Core) を Amazon Bedrock で使用できるようになりました。これらのモデルは、複数サブジェクトのプロンプト、画質、タイポグラフィのパフォーマンスを大幅に改善し、マーケティング、広告、メディア、エンターテインメント、小売など、さまざまなユースケースで質の高いビジュアルを迅速に生成するために使用できます。 これらのモデルは、すばらしいフォトリアリズムで画像を生成することに秀でており、優れたディテール、色、ライティングを誇り、リアルな手や顔をレンダリングするなどの一般的な課題に対処します。モデルの高度なプロンプト理解により、空間推論、構成、スタイルを含む複雑な指示を解釈できます。 Amazon Bedrock で使用できる 3 つの新しい Stability AI モデルは、さまざまなユースケースをカバーしています。 Stable Image Ultra – プロフェッショナルな印刷メディアや大判の用途に最適な、極めて質の高いフォトリアリスティックな出力を生成します。Stable Image Ultra は、優れたディテールとリアリズムのレンダリングに秀でています。 Stable Diffusion 3 Large – 生成速度と出力の質のバランスに優れています。ウェブサイト、ニュースレター、マーケティング資料など、ボリュームが多く、質の高いデジタルアセットを作成するのに最適です。 Stable Image Core – 高速で手頃な料金の画像生成に最適化されており、アイデア出しの最中にコンセプトを迅速にイテレーションするのに最適です。 次の表は、モデルの主な特徴をまとめたものです。 特徴 Stable Image Ultra Stable Diffusion 3 Large Stable Image Core パラメータ 160 億 80 億 26 億 入力 テキスト テキストまたは画像 テキスト タイポグラフィ 大規模な表示向けに カスタマイズ 大規模な表示向けに カスタマイズ さまざまなサイズやアプリケーションにわたる 汎用性と読みやすさ 視覚的な 美しさ フォトリアリスティックな 画像出力 非常にリアルで 細部まできめ細かい 優れたレンダリング、 詳細指向ではない Stable Diffusion XL (SDXL) と比較した場合の Stable Image Ultra と Stable Diffusion 3 Large の主な改善点の 1 つは、生成された画像のテキストの質です。革新的な Diffusion Transformer アーキテクチャにより、スペルやタイポグラフィのエラーが少なくなっています。このアーキテクチャは、画像とテキストに 2 つの個別の重みセットを実装しますが、2 つのモダリティ間での情報の流れを可能にします。 これらのモデルを使用して作成された画像をいくつかご紹介します。 Stable Image Ultra – プロンプト: photo, realistic, a woman sitting in a field watching a kite fly in the sky, stormy sky, highly detailed, concept art, intricate, professional composition. Stable Diffusion 3 Large –  プロンプト: comic-style illustration, male detective standing under a streetlamp, noir city, wearing a trench coat, fedora, dark and rainy, neon signs, reflections on wet pavement, detailed, moody lighting. Stable Image Core – プロンプト: professional 3d render of a white and orange sneaker, floating in center, hovering, floating, high quality, photorealistic. Amazon Bedrock の新しい Stability AI モデルのユースケース Text-to-Image モデルは、さまざまな業界の企業に変革の可能性を提供するとともに、マーケティング部門や広告部門のクリエイティブワークフローを大幅に合理化できます。これにより、キャンペーン、ソーシャルメディアコンテンツ、製品モックアップのために、質の高いビジュアルを迅速に生成できます。クリエイティブプロセスを迅速化することで、企業は市場のトレンドにより迅速に対応し、新しい取り組みの市場投入までの時間を短縮できます。さらに、これらのモデルはブレインストーミングセッションを強化できるため、さらなるイノベーションにつながるコンセプトを、即座に、かつ、視覚的に表現できます。 e コマースビジネスでは、AI 生成画像を使用することで、多様な製品ショーケースやパーソナライズされたマーケティング資料を大規模に作成できます。ユーザーエクスペリエンスやインターフェイスデザインの領域では、これらのツールによってワイヤーフレームやプロトタイプを迅速に生成し、デザインのイテレーションプロセスを加速できます。Text-to-Image モデルを採用することで、さまざまなビジネス機能にわたるビジュアルコミュニケーションにおいて、大幅なコスト削減、生産性の向上、競争力の向上を実現できます。 さまざまな業界のユースケースの例をいくつかご紹介します。 広告とマーケティング Stable Image Ultra: 高級ブランドの広告やフォトリアリスティックな製品ショーケース Stable Diffusion 3 Large: 質の高い製品マーケティング画像や印刷キャンペーン Use Stable Image Core: ソーシャルメディア広告のビジュアルコンセプトの迅速な A/B テスト E コマース Stable Image Ultra: 高級製品のカスタマイズやオーダーメイドの商品 Stable Diffusion 3 Large: e コマースサイト全体のほとんどの製品ビジュアル Stable Image Core: 製品画像の迅速な生成と、リストの最新状態の維持 メディアとエンターテインメント Stable Image Ultra: 超リアルなキーアート、マーケティング資料、ゲームビジュアル Stable Diffusion 3 Large: 環境テクスチャ、キャラクターアート、ゲーム内アセット Stable Image Core: ラピッドプロトタイピングとコンセプトアートの探索 それでは、これらの新しいモデルの実際の動作を、まずは AWS マネジメントコンソール を使用して、次に AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用して見てみましょう。 Amazon Bedrock コンソールでの新しい Stability AI モデルの使用 Amazon Bedrock コンソール で、ナビゲーションペインから [モデルアクセス] を選択し、 [Stability AI] セクションの 3 つの新しいモデルへのアクセスを有効にします。 アクセスできるようになったので、ナビゲーションペインの [プレイグラウンド] セクションで [画像] を選択します。モデルには、 [Stability AI] と [Stable Image Ultra] を選択します。 プロンプトとして、次のように入力します。 A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says "Stable Image Ultra in Amazon Bedrock". 他のオプションはすべてデフォルト値のままにし、 [実行] を選択します。数秒後、要求した内容が表示されます。画像は次のとおりです。 AWS CLI での Stable Image Ultra の使用 コンソールの [画像プレイグラウンド] にいる間に、プレイグラウンドウィンドウの角にある 3 つの小さなドットを選択し、 [API リクエストを表示] を選択します。このようにして、コンソールで実行した操作と同等の AWS コマンドラインインターフェイス (AWS CLI) コマンドを確認できます。 aws bedrock-runtime invoke-model \ --model-id stability.stable-image-ultra-v1:0 \ --body "{\"prompt\":\"A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says \\\"Stable Image Ultra in Amazon Bedrock\\\".\",\"mode\":\"text-to-image\",\"aspect_ratio\":\"1:1\",\"output_format\":\"jpeg\"}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ invoke-model-output.txt Stable Image Core または Stable Diffusion 3 Large を使用するために、 モデル ID を置き換える ことができます。 前述のコマンドは、テキストファイル内の JSON オブジェクト内に Base64 形式で画像を出力します。 1 つのコマンドで画像を取得するために、出力 JSON ファイルを標準出力に書き込み、 jq ツールを使用してエンコードされた画像を抽出し、その場でデコードできるようにします。出力は img.png ファイルに書き込まれます。完全なコマンドは次のとおりです。 aws bedrock-runtime invoke-model \ --model-id stability.stable-image-ultra-v1:0 \ --body "{\"prompt\":\"A stylized picture of a cute old steampunk robot with in its hands a sign written in chalk that says \\\"Stable Image Ultra in Amazon Bedrock\\\".\",\"mode\":\"text-to-image\",\"aspect_ratio\":\"1:1\",\"output_format\":\"jpeg\"}" \ --cli-binary-format raw-in-base64-out \ --region us-west-2 \ /dev/stdout | jq -r '.images[0]' | base64 --decode > img.png AWS SDK での Stable Image Ultra の使用 Stable Image Ultra を AWS SDK for Python (Boto3) で使用する方法は次のとおりです。このシンプルなアプリケーションは、Text-to-Image プロンプトをインタラクティブに要求し、Amazon Bedrock を呼び出して画像を生成します。 import base64 import boto3 import json import os MODEL_ID = "stability.stable-image-ultra-v1:0" bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-west-2") print("Enter a prompt for the text-to-image model:") prompt = input() body = { "prompt": prompt, "mode": "text-to-image" } response = bedrock_runtime.invoke_model(modelId=MODEL_ID, body=json.dumps(body)) model_response = json.loads(response["body"].read()) base64_image_data = model_response["images"][0] i, output_dir = 1, "output" if not os.path.exists(output_dir): os.makedirs(output_dir) while os.path.exists(os.path.join(output_dir, f"img_{i}.png")): i += 1 image_data = base64.b64decode(base64_image_data) image_path = os.path.join(output_dir, f"img_{i}.png") with open(image_path, "wb") as file: file.write(image_data) print(f"The generated image has been saved to {image_path}") アプリケーションは、結果として得られる画像を output ディレクトリ (存在しない場合は作成されます) に書き込みます。既存のファイルを上書きしないように、コードは既存のファイルをチェックして、 img_<number>.png 形式で使用可能な最初のファイル名を見つけます。 Stable Diffusion モデルの使用方法の他の例は、 AWS ドキュメント の「 コードライブラリ 」でご覧いただけます。 お客様の声 Stability AI の Global Alliance Director である Ken Hoge 氏から、Stable Diffusion モデルが Text-to-Image から、動画、音声、3D へと業界をどのように再編しているか、また Amazon Bedrock がオールインワンで安全かつスケーラブルなソリューションでお客様をサポートする方法を学びましょう。 Stride Learning の Product Owner である Nicolette Han 氏とともに、読書が生き生きとした体験になる世界に足を踏み入れましょう。Amazon Bedrock と AWS のサポートにより、Stride Learning の Legend Library は、子供向けの物語の魅力的で安全なイラストを作成するために AI を使用して、若者が文学に関わり、理解する方法を変革しています。 知っておくべきこと 新しい Stability AI モデルである Stable Image Ultra 、 Stable Diffusion 3 Large 、および Stable Image Core は、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で9月4日からご利用いただけます。このリリースにより、Amazon Bedrock は、創造性を高め、コンテンツ生成ワークフローを加速するための幅広いソリューションを提供します。ご自身のユースケースのコストを理解するには、 Amazon Bedrock の料金ページ をご覧ください。 Stable Diffusion 3 の詳細については、基盤となるテクノロジーを詳細に説明する 研究論文 をご覧ください。 まずは、 「Amazon Bedrock ユーザーガイド」の Stability AI のモデルのセクション をご覧ください。他のユーザーがソリューションで生成 AI をどのように使用しているかを知り、詳細な技術コンテンツで学ぶには、 community.aws にアクセスしてください。 – Danilo 原文は こちら です。

AWS ヒーロープログラム では、AWS コミュニティ内で意義ある貢献をしている優れた個人を表彰しています。これらの技術エキスパートは、インサイト、ベストプラクティス、革新的なソリューションを惜しみなく共有し、他のユーザーが AWS で効率を高め、より迅速に構築できるように支援しています。ヒーローとは、多大な貢献とリーダーシップを通じて、より広範な AWS コミュニティを強化することに尽力しているソートリーダーです。 AWS ヒーローの最新のグループをご紹介します! Faye Ellis 氏 – ロンドン (英国) コミュニティヒーローである Faye Ellis 氏は、Pluralsight の Principal Training Architect です。Ellis 氏は同社において、組織や個人が AWS スキルを身に付けられるようサポートすることに特化して取り組んでおり、世界中の何百万もの人々に AWS を教えてきました。同氏はまた、世界中の人々がやりがいのあるクラウドキャリアを築けるようにすることにも尽力しています。IT 業界で 10 年超の経験を持つ同氏は、ミッションクリティカルなシステムの設計とサポートに関する専門知識を活かして、アクセスしやすく理解しやすい方法でクラウドテクノロジーを説明しています。 Ilanchezhian Ganesamurthy 氏 – チェンナイ (インド) コミュニティヒーローである Ilanchezhian Ganesamurthy 氏は現在、北欧の大手 IT サービス企業である Tietoevry で Director – Generative AI (GenAI) and Conversational AI (CAI) を務めています。2015 年以来、同氏は AWS User Group India に積極的に関与しており、2018 年には AWS User Group Chennai の共同主催者の役割を務めました。同グループのメンバーは 4,800 人にまで増えています。Ganesamurthy 氏は多様性と包括性を推進し、次世代のクラウドエキスパートを育成することの重要性を認識しています。同氏は AWS Cloud Clubs の強力な支持者であり、クラウドプロフェッショナルを目指す人々をサポートするために、業界のつながりを活用して、チェンナイ支部がイベントやネットワーキングを主催するのを支援しています。 Jaehyun Shin 氏 – ソウル (韓国) コミュニティヒーローである Jaehyun Shin 氏は、韓国のオンラインファッション小売業者である MUSINSA の Site Reliability Engineer です。同氏は 2017 年に AWS Korea User Group (AWSKRUG) に参加し、それ以来、AWSKRUG Serverless and Seongsu Groups の共同所有者を務めています。この間、Shin 氏は AWS コミュニティビルダーとして、専門知識を活かして新しい Korea User Group のリーダーをメンタリングおよび育成してきました。また、AWS Community Day やハンズオンラボのイベント主催者としても積極的に活動し、韓国の AWS コミュニティをさらに強化してきました。 Jimmy Dahlqvist 氏 – マルメ (スウェーデン) サーバーレスヒーローである Jimmy Dahlqvist 氏は、AWS アドバンストティアサービスパートナーであり、スウェーデンの大手コンサルティング会社の 1 つである Sigma Technology Cloud の Lead Cloud Architect and Advisor です。2024 年、同氏は自身のすべてのサーバーレスアドベンチャーの拠点として Serverless-Handbook を立ち上げました。Dahlqvist 氏は AWS 認定の対象分野の専門家でもあり、AWS 認定があらゆる人々にとって公平であるようにするワークショップに定期的に参加しています。 Lee Gilmore 氏 – ニューカッスル (英国) サーバーレスヒーローである Lee Gilmore 氏は、イングランド北東部のニューカッスルに拠点を置く AWS コンサルティングパートナーである Leighton の Principal Solutions Architect です。テクノロジー業界で 20 年超の経験を持つ同氏は、過去 10 年間にわたって、サーバーレスおよびクラウドネイティブテクノロジーを専門としてきました。Gilmore 氏は、自らの仕事の中心であるドメイン駆動型設計とイベント駆動型アーキテクチャに熱心に取り組んでいます。さらに、serverlessadvocate.com で詳細な記事を定期的に執筆するとともに、GitHub でオープンソースのフルソリューションを共有し、国内外のイベントで頻繁に講演しています。 Maciej Walkowiak 氏 – ベルリン (ドイツ) DevTools ヒーローである Maciej Walkowiak 氏は、ドイツのベルリンを拠点とする独立 Java コンサルタントです。同氏は約 20 年にわたって、高速かつスケーラブルでメンテナンスが容易な Java アプリケーションの設計と開発において、スタートアップから大企業まで、さまざまな企業をサポートしてきました。これらのアプリケーションの大部分は、ソフトウェア構築に同氏が好んで使用するツールである Spring Framework と Spring Boot をベースとしています。2015 年以来、同氏は Spring エコシステムに深く関わっており、AWS API と Spring プログラミングモデルをつなぐ GitHub の Spring Cloud AWS プロジェクトを率いています。 御田 稔 氏 – 東京 (日本) コミュニティヒーローである 御田 稔 氏は、KDDI アジャイル開発センター株式会社 (KAG) のテックエバンジェリストです。2021 年に Japan AWS User Group (JAWS-UG) に参加し、現在は東京支部、SRE 支部、NW-JAWS の 3 つのコミュニティの運営をリードしています。近年は AWS で生成 AI を活用することに注力しており、Amazon Bedrock の入門レベルの技術書をコミュニティメンバーと共同執筆し、日本で出版しました。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブサイト にアクセスしてください。 – Taylor 原文は こちら です。

本ブログは 2024年8月9日に公開された「 Using SAW to diagnose common issues in your AWS environment 」を翻訳・一部改変したものとなります。 はじめに AWS環境でシステム問題を手動でトラブルシューティングし解決することは、繰り返し作業が多く、間違いが起こりやすいです。 AWSサポートでは、AWSのお客様がセルフサービスによる診断と修復を可能にする機能であるサポートオートメーションワークフロー（SAW）を提供しています。 SAWは、 AWS System Manager を活用して、トラブルシューティングプロセスを簡素化し、解決手順を示す、使いやすい厳選されたオートメーションランブックを提供しています。 ランブックを使用すると、接続問題のトラブルシューティング、権限エラーの診断、 Amazon Elastic Compute Cloud（Amazon EC2） アクセスのリセットなどをすばやく行うことができます。 オートメーションランブック（プレフィックスは AWSSupport または AWSPremiumSupport です）は、Amazon EC2、 Amazon Simple Storage Service（Amazon S3） 、 Amazon Elastic Kubernetes Service（EKS） 、 Amazon Elastic Container Service（ECS） などのさまざまなAWSサービスで利用できます。 この記事では、SAW がどのようにトラブルシューティングを自動化して、AWS環境の一般的な問題を診断するかを説明します。 オートメーションランブックによって合理化されたトラブルシューティングにより、システム問題の根本原因の分析と修復をより迅速に行うことができます。 サポートオートメーションワークフロー（SAW）とは AWS Systems Manager SAW について学ぶ前に、SAW の基盤である AWS System Managerとは何かを理解する必要があります。AWS Systems Managerは、AWSのアプリケーションとリソースの運用ハブであり、安全なエンドツーエンドの管理ソリューションです。 SAWは、 Amazon Systems Manager Automation の上に構築されたオートメーションランブックです。これらのランブックは、AWSリソースの一般的な問題のトラブルシューティングや、ネットワークの問題の特定、ログの収集と分析などに役立ちます。 AWS環境でのトラブルシューティングと診断の強化 SAW は、Amazonの哲学の核心である、Customer Obsession を表しています。 SAWの起源は顧客体験に根ざしています。 お客様が AWS サポートにお問い合わせすると、当社のエンジニアが問題を解決し、解決策とともに問題を文書化します。 その中で、繰り返し発生する問題の傾向と、顧客体験を向上させる可能性を確認しました。 これらの洞察から、お客様をより良くサポートするため、セルフサービスを可能にするカスタムツールを構築しました。 SAWは、当社の経験、ベストプラクティス、長年にわたって学んだ教訓を活用して、反復的で時間のかかる手動の顧客タスクを排除し、発生する可能性のあるさまざまなトラブルシューティングの問題に対処するための強力なツールとなっています。 SAWが役立つユースケースには、SSH接続の問題のトラブルシューティング、EC2のディスク使用状況の分析、Amazon S3の問題の診断、Amazon EKSまたはAmazon ECS環境での重要なログの収集などがあります。 これらのランブックは、EC2インスタンスへのSSHアクセスがない場合や、インスタンスがAWS System Manager VPCエンドポイントの有効になっているプライベートサブネットにある場合に特に役立ちます。 次のような他のユースケースも見つかるかもしれません。 診断、トラブルシューティング、修復： AWSPremiumSupport-Troubleshootec2DiskUsage を使用して、Amazon EC2インスタンスのディスク使用に関する問題を調査し、場合によっては修正します。さらに、ボリューム、パーティション、ファイルシステムの拡張をオペレーティングシステム（OS）レベルで自動化することもできます。 管理分析と設定更新の自動化： AWSSupport-EnableVPCFlowLogs を使用して、AWS アカウントの複数のサブネット、ネットワークインターフェイス、VPC の Amazon VPC フローログを設定します。 コスト最適化と運用レビュー： AWSPremiumSupport-PostgreSQLWorkloadReview 使用して、Amazon Relational Database Service（Amazon RDS）のPostgreSQLデータベース使用統計のスナップショットをキャプチャします。 診断目的のログ収集:たとえば、 AWSSupport-CollecteKSInstanceLogs を利用して、クラスターの問題をトラブルシューティングするために、Amazon Elastic Kubernetes Service（Amazon EKS）からオペレーティングシステムレベルのログファイルを収集できます。 さまざまなユースケースに役立つ他のランブックを見るには、 SAW のランディングページ にアクセスしてください。役立つリストがあります。 SAWを使用して手動プロセスを合理化し、時間と労力を節約する方法を見ていきましょう。 SAWの使用を開始する 前提条件 SAWを続行するには、以下が必要です。 使用する AWS Identity and Access Management（IAM）ユーザまたは IAM ロールに、 Systems Manager コンソール にアクセスするための 最低限必要な IAM 権限 があることを確認してください。 ランブックを開始するために、次の権限があることを確認してください。 ssm:StartAutomationExecution ssm:GetAutomationExecution ssm:SendCommand プレフィックス AWSPremiumSupport が付いたランブックを使用する場合は、AWSビジネスまたはエンタープライズサポートプランを利用していることを確認してください。 ランブックがEC2インスタンスでアクションを実行するためには、 AWS Systems Manager Agent（SSM Agent） がインストールされ必要な権限が付与されていることを確認してください。そのためには、AWS 管理ポリシー AmazonSsmManagedInstanceCore を EC2インスタンスプロファイルに対応するIAMロールにアタッチする必要があります。 SAW ランブックを使用するには、 AWS Systems Managerコンソール に移動し、使用するAWSリージョンを選択します。 Systems Managerコンソールで、左側のナビゲーションメニューの [共有リソース] セクションの下にある [ドキュメント] を探してください。 ここでは、Amazonが提供しているすべてのAWS Systems Managerドキュメントを見ることができます。 AWS サポートが管理する SAW ランブックを見つけるためには、検索ボックスに AWSSupport と入力してください。 まず、 AWSSupport-ListEC2Resources ランブックを例に見てみましょう。 このドキュメントは、AWSアカウントの EC2 インスタンス、Elastic IP、EBSボリューム、Auto Scaling グループなどのEC2関連リソースを一覧表示するのに役立ちます。 ランブックを実行するには、「 オートメーションを実行する 」を選択します。 実行が完了すると詳細が表示され、実行結果の出力が表示されます。 AWS CLIを使用してランブックを実行する場合は、 aws ssm start-automation-execution コマンドを使用することで実行できます。 以下は、すべてのAWSリージョンのEC2リソースを一覧表示するコマンド例です。 aws ssm start-automation-execution --document-name "AWSSupport-ListEC2Resources" --parameters '{"RegionsToQuery":["All"]}' 出力: { "AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1" } オートメーションのステータスを取得するには、次のコマンドを実行します。 aws ssm describe-automation-executions \ --filter "Key=ExecutionId,Values=6053b7c6-7ec7-4b9b-b52c-04ddd912ede1" 上記コマンドの values の値を、手元の Automation ExecutionId に置き換えてください。 出力: { "AutomationExecutionMetadataList": [ { "AutomationExecutionId": "6053b7c6-7ec7-4b9b-b52c-04ddd912ede1", "DocumentName": "AWSSupport-ListEC2Resources", "DocumentVersion": "7", "AutomationExecutionStatus": "InProgress", "ExecutionStartTime": "2024-03-13T09:53:45.685000+00:00", "ExecutedBy": "arn:aws:sts::123456789012:assumed-role/Administrator/Admin", "LogFile": "", "Outputs": {}, "Mode": "Auto", "CurrentStepName": "listVolumes", "CurrentAction": "aws:executeScript", "Targets": [], "ResolvedTargets": { "ParameterValues": [], "Truncated": false }, "AutomationType": "Local" } ] } ユースケース SSH接続の問題のトラブルシューティング AWSSupport-TroubleshootSSH ランブックは、Linux SSHの一般的な問題を解決します。 このランブックは、 Amazon EC2Rescue tool for Linux (ec2rl) の実行を効率化し、SSH経由でLinuxマシンにリモート接続できない一般的な問題を修正 します。 このランブックでは、AWS Systems Managerによって管理されていないEC2インスタンスもサポートします。 オフライン修復を指定すると、修正プロセス中に EC2 インスタンスが自動的に停止・起動します。 AWS Systems Manager エージェントが EC2 インスタンスにインストールされているかに関わらず、このランブックは、EC2インスタンスに接続できないときにSSHエラーを診断して問題を解決するのに役立ちます。 たとえば、SSHの設定ミスのためにEC2インスタンスに接続できない場合は、このランブックを起動して、数回クリックするだけでこのエラーから回復できます。 $ ssh ec2-user@1.2.3.4 ssh: connect to host 1.2.3.4 port 22: Connection refused 分析したいEC2インスタンスを選択し、ランブックを実行します。 EC2インスタンスにSSMエージェントがインストールされている場合は、 インスタンスプロファイルに十分なIAM権限があり 、AWS System Managerで管理できることを確認してください。 そうでない場合は、ランブックのオフライン修復を使用することで、問題のあるインスタンスの設定を見直します。 設定の見直しでは、問題のあるインスタンスの EBSボリュームをデタッチし、レスキューインスタンスアタッチした上で設定を確認します。不適切な設定が修正されたのち、 EBS ボリュームは元のインスタンスに再度アタッチされます。 このオートメーションはインスタンスを停止し、操作を試みる前にAMIを作成することに注意してください。 インスタンスストアボリューム に保存されているデータは失われます。 Elastic IPアドレスを使用していない場合、パブリックIPアドレスは変更される可能性があります。 オフライン修復を使用するには、問題のあるEC2インスタンスを選択し、次のパラメータを使用してこのランブックを実行します。 Action: FixAll (CheckAllはオフラインモードではサポートされていません) AllowOffline: True Subnet: {EC2 インスタンスと同じサブネットを選択} オフライン修復でオートメーションを実行すると、レスキュー EC2インスタンスが作成されます。レスキュー EC2 インスタンスに問題のあるインスタンスのEBSボリュームがアタッチされ、エラーの修正が行われます。 オートメーションが完了したら、実行結果とリソースを確認できます。 私の場合は、誤って構成されたSSHファイルが修正され、EC2インスタンスに正常に接続できました。このエラーの修正には1〜2分しかかかりません。 EC2アクセスとパスワードの回復 AWSSupport-ResetAccess ランブックは、WindowsとLinuxの両方でEC2管理権限が失われたアクセス問題を解決することを目的としたランブックです。 このランブックは、指定した EC2 インスタンスで EC2Rescue ツールを使用して、EC2 コンソール経由で EC2 インスタンスのパスワード復号化を再度有効化するか（Windows）、新しい SSH キーペアを生成して追加します（Linux）。 EC2 Windowsインスタンスのキーペアを紛失した場合、このオートメーションによりパスワード対応のAMIが作成され、新しいキーペアを使用して新しいEC2インスタンスを起動できます。 SSHのトラブルシューティングランブックと同様に、このオートメーションによりインスタンスが停止するため、ステップを実行する前に、アタッチされた インスタンスストアボリューム （存在する場合）にデータが残っていないことを確認してください。 さらに、Elastic IPアドレスを使用していない場合、インスタンスを停止するとパブリックIPアドレスが変更される可能性もあります。 EC2インスタンスへのアクセスを回復するには、EC2インスタンスを選択してランブックを実行するだけです。 SubnetId には問題のあるEC2インスタンスと同じサブネットIDを選択するか、デフォルト値の CreateNewVPC のままにします。ドキュメント「 EC2 インスタンスでのパスワードと SSH キーのリセット 」を参照してください。 ステップが実行されると、次のステップの手順が出力セクションに表示されます。 このランブックは、オートメーションの一環として、バックアップAMIとパスワード対応の AMIを作成します。 キーペアを紛失したときのアクセスを回復するには、パスワード対応の AMIを使用して、新しいキーペアで新しいEC2 Windowsインスタンスを起動できます。 同様に、同じランブックを使用して、EC2 LinuxインスタンスのSSHアクセスを回復できます。 この方法では、新しい SSH プライベートキーが作成され、暗号化された状態で AWS System Manger Parameter Store に保存されます。パラメータ名は /ec2rl/openssh/{インスタンス ID}/key です。 私の場合、オートメーションにより、 -----BEGIN OPENSSH PRIVATE KEY----- で始まる新しい OpenSSH プライベートキーが生成されました。ファイルを保存してRSA形式に変換します。RSA形式 —–BEGIN RSA PRIVATE KEY—– のプライベートキーを入手した場合はこの手順を省略できます。 $ chmod 600 saw.pem $ ssh-keygen -p -N "" -m pem -f saw.pem Key has comment 'Added by EC2 Rescue for Linux' Your identification has been saved with the new passphrase. 取得したプライベートキーを使用して、EC2 Linuxインスタンスに正常に接続できます。 $ ssh -i saw.pem ec2-user@1.2.3.4 EC2のディスク使用量を分析し、空きディスク容量を増やす AWS ビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランのお客様は、 AWSPremiumSupport-Troubleshootic2DiskUsage ランブックを利用して、EBSボリュームの使用状況を分析したり、オペレーティングシステム（OS）レベルでパーティションやファイルシステムの拡張を自動化したりすることもできます。 AWSリージョン、AWS中国リージョン、AWS GovCloud（米国）リージョンで利用でき、WindowsインスタンスとLinuxインスタンスの両方をサポートしています。 ディスク容量を増やすプロセスの効率化の詳細については、 AWS re:Post の記事 を参照してください。 たとえば、Linuxファイルシステムの空きディスク容量が不足していて、それらを拡張したい場合は、まずEBSボリュームのサイズを増やし、 複数の AWS CLI コマンドを実行してファイルシステムを拡張する必要があります 。 EC2インスタンスが多い大規模な環境では、多大な時間と労力がかかり、運用の負担になる可能性があります。 aws ssm start-automation-execution コマンドまたは StartAutomationExecution APIでオートメーションランブックを活用して、オートメーションをバッチで実行できます。 ディスク使用量の診断に役立つだけでなく、問題を修復して、ボリュームとそのファイルシステムを一度に拡張することもできます。 EKSまたはECSノードから重要なログを収集します Amazon Elastic Kubernetes Service（EKS）とAmazon Elastic Container Service（ECS）は、AWS上のフルマネージドなコンテナオーケストレーションサービスです。 どちらも、コンテナ化されたアプリケーションを実行するための異なるコンピューティングオプションを提供します。 コンピュートリソースの典型的なタイプの1つは、EC2インスタンスの使用です。インスタンスをクラスターに追加して、Amazon EKS または Amazon ECS で管理できるようにする必要があります。 しかし、インスタンスにトラブルシューティングが必要な問題がある場合は、 EKS Log Collector または ECS Log Collector を使用して、エラーを特定するための重要なシステムレベルの情報（kubelet、ECSエージェント、システム構成など）を収集することが不可欠です。 ただし、EC2インスタンスがSSHアクセスを提供しないか、プライベートネットワークの設定によって制限されているため、スクリプトの実行とログの収集が難しい場合があります。 AWSSupport-CollectEKSInstanceLogs と AWSSupport-CollectECSInstanceLogs はこれらの問題の解決に役立つランブックです。 どちらもEKSまたはECSからのログ収集プロセスを自動化し、収集手順を簡素化します。これらのランブックでは SSMが管理するEC2インスタンスを選択できます。ログ収集スクリプトを実行した結果は EC2 インスタンスに保存されます。 さらに、バンドルログをAmazon S3バケットにアップロードするオプションも提供しています。これは、複数のインスタンスを一元的に確認する必要がある場合に役立ちます。 EKSクラスターのトラブルシューティング AWSSupport-TroubleshooteKSWorkerNode は、 Kubernetes ワーカーノードが Amazon EKSクラスターに参加できない 原因を迅速に特定するのに役立つ典型的なランブックです。 Amazon EKS クラスターには、ノードと呼ばれるワーカーマシンのセットがあります。 ほとんどのユースケースでは、 EKS に最適化された AMI で EC2インスタンスを起動し、それをクラスターのコンピュートリソースとして登録する必要があります。 ただし、クラスターにノードを追加するときに失敗する可能性のある要因がいくつかあります。たとえば、VPC設定の誤り、ユーザーデータの誤り、必要なタグの欠落、接続の問題などです。 以前は、各構成を確認してこれらの問題のトラブルシューティングを行っていましたが、明らかではないエラーを見逃すこともありました。ランブックを使用して、これらすべての時間を節約できます。 可能性のあるエラーと原因が Outputs セクションに表示されます。 さらに、AWSビジネス、Enterprise On-Ramp、またはエンタープライズサポートプランに加入しているお客様は、 AWSPremiumSupport-TroubleshooteKSCluster ランブックにもアクセスできます。 Kubernetes Cluster Autoscaler、内部ロードバランサーの作成に関する問題、ワーカーノードの使用する AMI のレビュー、Amazon ECR からのイメージの取得失敗、マネージドノードが安定しないなど、Amazon EKS 環境でよくあるエラーをトラブルシューティングする別のオプションを提供します。 どのようなチェックが実行されるかについては、 AWS re:Post の記事 を参照してください。 ECSのトラブルシューティング Amazon ECSは、コンテナ化されたアプリケーションのライフサイクルを管理するためにECSタスクを使用します。 ただし、ECSタスクはさまざまな理由で開始できず、根本原因を特定するのが難しい場合があります。 AWS Support-TroubleshootsTaskFailedToStart は、このような状況に役立つランブックです。 構成を自動的に見直して接続をテストすることで、タスクの開始を妨げる可能性のある一般的な問題の分析プロセスを合理化し、問題を解決するために実行可能なガイダンスを提供します。 たとえば、パブリックサブネットで次の接続エラーでECSタスクを開始できない場合を考えます。 ルートテーブルとネットワークの設定、さらに、VPCとサブネットのネットワーク設定タスクをが正しいことを確認しましたが、タスクを開始できない根本原因が不明です。 この場合、入力パラメータ ClusterName と TaskId を使用してランブックを実行することで、失敗したタスクを診断できます。今回は、ECSタスクを起動するときにパブリックIPの自動割り当てオプションを有効していなかったことが原因として出力されました。また、Output セクションでは問題の対処法も確認できます。 SAW についてもっと知る この投稿では、サポートオートメーションワークフローのいくつかのユースケースを説明し、トラブルシューティングプロセスをどのように強化できるかを学びました。 AWSサポートは継続的にトラブルシューティング技術を革新し、より良いサポート体験を提供することに専念しています。 AWS SAWの可能性をまだ探っていない人は、今日試してみることを勧めます。 What’s New with AWS から、新機能に関する発表を購読してください。 AWS サポートチームが作成した AWS Support self-service runbooks の使用方法 をご覧ください。 AWS YouTubeチャンネルでデモ AWS Supports You: Using Support Automation Workflows を見てください。 Systems Manager オートメーションランブックリファレンスを確認してください。これは、AWS Systems Manager で利用できるさまざまなオートメーションランブックに関する詳細情報を提供する包括的なリソースです。 定義済みの各ランブックには、詳細な説明、ステップバイステップの説明、入力と出力の例が記載されています。 特定のAWSサービスに基づいて分類された幅広いランブックを見つけることができます。 著者略歴 Eason Cao Eason は、AWSコンテナソリューションを専門とし、5年以上の業界経験を持つシニアクラウドサポートエンジニアです。 AWSのコンテナサービスの専門家として、顧客がクラウド環境の課題を克服し、分散システムを最適化できるよう支援することに専念しています。 翻訳はクラウドサポートアソシエイトの Ayu Sonoda が担当しました。

この記事は、 SaaS authentication: Identity management with Amazon Cognito user pools を翻訳したものです。 Amazon Cognito は、数百万人のユーザーにスケールできるカスタマーアイデンティティおよびアクセス管理 (CIAM) サービスです。 Cognito 開発者ガイド では利用可能なマルチテナンシーモデルについて詳しく説明されていますが、どのモデルを使うべきかを判断するのは時に難しい場合があります。このブログ記事では、各モデルを使う際のガイダンスを提供し、お客様の意思決定に役立つよう、長所と短所を確認します。 Cognito の概要 Amazon Cognito は、Web およびモバイルアプリのユーザーアイデンティティ管理とアクセス制御を行います。Cognito の ユーザープール を使えば、アプリにサインアップ、サインイン、アクセス制御を追加できます。Cognito ユーザープールは、特定の AWS リージョン 内のユーザーディレクトリで、ユーザーはアプリケーションに対して認証とユーザー登録ができます。さらに、Cognito ユーザープールは OpenID Connect (OIDC) のアイデンティティプロバイダー (IdP) でもあります。アプリユーザーは、ユーザープールに直接サインインするか、サードパーティの IdP を経由して連携できます。Cognito は、認証が成功すると、バックエンド API やリソースへのセキュアなアクセスに使えるユーザープールトークンを発行します。 Cognito は 3 種類のトークンを発行します: ID トークン – 名前、メールアドレス、電話番号などのユーザーアイデンティティクレームが含まれます。このトークンタイプは、ユーザーを認証し、アプリや API ゲートウェイでの認可決定を可能にします。 アクセストークン – ユーザークレーム、グループ、許可されたスコープが含まれます。このトークンタイプは、認証されたユーザーとアプリケーションの権限に基づいて、API 操作へのアクセスを許可します。また、アプリケーションやサービス内で、ユーザーベースの詳細なアクセス制御を可能にします。 リフレッシュ (更新) トークン – ID トークンとアクセストークンの有効期限が切れた場合に、新しいトークンを取得します。アクセストークンと ID トークンは短命ですが、リフレッシュトークンは長命です。デフォルトでは、リフレッシュトークンはユーザーがサインインしてから 30 日後に期限切れになりますが、これは 60 分から 10 年の範囲で設定できます。 トークンの使用方法とその内容の詳細については、 Cognito 開発者ガイド を参照してください。 マルチテナンシーアプローチ Software as a Service (SaaS) アーキテクチャでは、しばしばサイロ、プール、ブリッジのデプロイメントモデルが使われます。これらのモデルは、Cognito のような CIAM サービスにも適用されます。サイロモデルは、テナントを専用リソースに分離します。プールモデルは、リソースをテナント間で共有します。ブリッジモデルは、サイロ化されたコンポーネントとプール化されたコンポーネントを接続させて使います。この記事では、SaaS アイデンティティ管理における Cognito のサイロモデルとプールモデルを比較します。 リソースの持ち方を複数のティアごとに分けることで、サイロモデルとプールモデルを組み合わせることも可能です。たとえば、機密性の高いテナントデータ用のサイロ化されたティアと、共有機能用のプール化されたティアを持つことができます。これはサイロモデルに似ていますが、ティアに接続するためのルーティングの複雑さが加わります。複数のプールやサイロがある場合、これは純粋なサイロモデルと同様のアプローチですが、管理するコンポーネントが増えます。 これらのモデルの詳細については、 AWS SaaS Lens を参照してください。 以下のセクションでは、5 つのパターンを詳しく説明し、それぞれのパターンが使える状況、長所と短所を探っています。この記事の残りの部分では、これらのさまざまなパターンの詳細を掘り下げ、独自の要件と制約に最もよく合ったものを選択できるようにしています。 パターン 1: カスタム属性を使った SaaS アイデンティティの表現 SaaS アプリケーションでマルチテナンシーを実装するには、テナントコンテキスト (訳者注: テナント識別子やティア) をユーザーのアイデンティティ (訳者注: メールアドレスなどのユーザー属性) に関連付ける必要があります。これにより、SaaS アプリケーションを構成するマルチテナントポリシーや戦略を実装できます。Cognito には、アイデンティティを表す情報である ユーザープール属性 があります。名前やメールアドレスなどの 標準属性 はユーザーのアイデンティティを記述するものです。Cognito はまた、 ユーザーとテナントの関係 を保持するための tenantId などの カスタム属性 をサポートしています。 Amazon Cognito でカスタム属性をマルチテナンシーに使うことで、各ユーザーのテナントコンテキストをユーザープロファイルに保存できます。 マルチテナンシーを有効にするには、 tenantId のようなカスタム属性をユーザープロファイルに追加します。新規ユーザー登録時に、この tenantId 属性にユーザーが所属するテナントを示す値を設定できます。たとえば、 tenantId が “1234” のユーザーは Tenant A に、 tenantId が “5678” のユーザーは Tenant B に所属します。 この tenantId 属性値は、ユーザー認証成功後に ID トークンで返されます (この値は トークン生成前の Lambda トリガー を使ってアクセストークンにも追加できます)。アプリケーションはこのクレームを検査し、ユーザーが所属するテナントを判断できます。 tenantId 属性は通常 SaaS プラットフォームレベルで管理され、ユーザーやアプリケーション層からは読み取り専用です (注: SaaS プロバイダーは tenantId 属性を読み取り専用に設定する必要があります)。 テナント ID を保存するだけでなく、カスタム属性を使ってさらにテナントコンテキストをモデル化できます。たとえば tenantName 、 tenantTier 、 tenantRegion などの属性を定義し、アプリケーションに関連する情報コンテキストを適切に設定できます。ただし、カスタム属性をデータベースのように使わないよう注意が必要です。アイデンティティを表すものであり、アプリケーションデータを保存するものではありません。カスタム属性には、付与するアクセス権限の決定と JSON Web トークン (JWT) をコンパクトに保てる範囲の情報を含めるべきです。また、 Cognito ディレクトリに保存される情報は比較的静的である必要があります。頻繁に変化するデータを更新するには、ディレクトリを変更する必要があり、面倒です。 カスタム属性自体は、Amazon Cognito ユーザープールの作成時に定義する必要があり、最大 50 のカスタム属性を作成できます。プールが作成されると、これらのカスタム属性フィールドがそのユーザープールの全ユーザープロファイルに存在するようになります。ただし、まだ値は設定されていません。実際のテナント属性値は、ユーザープールに新しいユーザーが作成された時にのみ設定されます。これには 2 つの方法があります。 ユーザー登録時に、 確認後の Lambda トリガー を使って、ユーザーの入力に基づき適切なテナント属性値を設定できます。 管理者ユーザーが AdminCreateUser API 操作で新しいユーザーをプロビジョニングし、その時にテナント属性値を指定できます。 ユーザー作成後、必要に応じて管理者が AdminUpdateUserAttributes API 操作、またはユーザーが UpdateUserAttributes API 操作でカスタムテナント属性値を更新できます。ただし、ポイントはカスタム属性自体はユーザープール作成時に事前定義する必要があり、値はユーザー作成とプロビジョニングフローの後に設定されることです。図 1 は、カスタム属性が ID トークンに関連付けられ、その後ダウンストリームのアプリケーションで使用される様子を示しています。 図 1: カスタム属性を使ってテナントコンテキストを関連付ける 図 1 に示すように: ユーザープロファイルからのカスタムテナント属性値が、ユーザー認証成功後に生成される Cognito ID トークンに含まれます。これらの値は、 Amazon API Gateway などの他の AWS サービスのアクセス制御に使用できます。 Amazon API Gateway に Lambda オーソライザー関数を設定し、ID トークン署名を検証 (この目的には aws-jwt-verify ライブラリ を使用できます) し、各リクエストのテナント ID クレームを検査できます。 Lambda オーソライザー関数は、ID トークンから抽出したテナント ID 値に基づき、認証済みユーザーがアクセスを許可されているバックエンドリソースやサービスを判断できます。 この方法を使うと、 このブログ記事 で説明されているように、ユーザークレームに加えてテナントクレームをコンテキストとして使用することで、細かいアクセス制御を提供できます。ユーザーアイデンティティと関連テナントの詳細を 1 つのトークンに埋め込むこのパターンを、AWS では SaaS アイデンティティ と呼んでいます。 個別のユーザープール、共有プール、カスタム属性を使うマルチテナンシーアプローチは、いずれもユーザーのアイデンティティにテナントコンテキストを埋め込むことに依存しています。これは、Cognito が認証後に発行する JWT にテナント情報が入ったクレームを含めることで実現されます。 JWT はユーザー名、メールアドレスなどのユーザーアイデンティティ情報をエンコードします。テナント識別子やメタデータを含むカスタムクレームを追加することで、テナントコンテキストがユーザーアイデンティティに密接に関連付けられます。JWT に埋め込まれたテナントコンテキストにより、アプリケーションは各ユーザーに関連付けられたテナントに基づいてアクセス制御と認可を実装できます。 発行された JWT のユーザーアイデンティティ情報とテナントコンテキストの組み合わせが SaaS アイデンティティ、つまりユーザーとテナントの両次元にまたがる統合アイデンティティを表します。アプリケーションはこの SaaS アイデンティティを使って、マルチテナントのロジックやポリシーを実装します。 パターン 2: 共有ユーザープール (プールモデル) 単一で共有された Amazon Cognito ユーザープールは、マルチテナント SaaS アプリケーションのアイデンティティ管理を簡素化します。1 つに統合されたプールでは、変更と設定がテナント全体に一か所で適用されるため、オーバーヘッドを削減できます。 たとえば、パスワードの複雑さのルールやその他の設定をユーザープールレベルで 一度定義すると、これらの設定がテナント間で共有されます。新しいテナントを追加する際は、既存の共有プールの設定を使用するため、テナントごとに同じ設定をしなくて済み、効率化されます。新しいテナントをオンボーディングする際に、テナントごとに個別のプールをデプロイする必要がなくなります。 さらに、共有プールから発行されるトークンは、同じ発行者 (Issuer) によって署名されます。共有プールを使用する場合、トークンはテナント固有の発行者にはなりません。共通のアイデンティティニーズを持つ SaaS アプリでは、テナントごとのカスタマイズができなくなりますが、共有マルチテナントプールを使用することは、迅速なオンボーディングに適しています。 プールモデルの長所: このモデルでは、テナントに対して単一の共有ユーザープールを使用します。これにより、複数のユーザープールを設定する代わりに、ユーザー属性を設定するだけでオンボーディングが簡素化されます。 テナントは同じアプリケーションクライアントとユーザープールを使用して認証するため、SaaS クライアントの設定が単純になります。 プールモデルの短所: 1 つのプールを共有するため、パスワードポリシーや MFA などの設定は統一され、テナントごとのカスタマイズは不可となります。 リソースクォータ の一部 (アプリケーションクライアントの数やカスタム属性の数など) はユーザープールレベルで管理されるため、このモデルを採用する際はクォータを慎重に検討する必要があります。 パターン 3: グループベースのマルチテナンシー (プールモデル) Amazon Cognito ユーザープールでは、管理者がグループを追加し、ユーザーをグループに関連付けることができます。これにより、Cognito によって管理され、 ID トークン 内で利用可能な特定の属性 ( cognito:groups と cognito:roles ) が導入されます ( アクセストークン には cognito:groups 属性のみが含まれます)。 これらのグループを使用して、各テナントごとにグループを作成することで、マルチテナンシーを実現できます。ユーザーは、カスタムの tenantId 属性の値に基づいて、適切なテナントグループに割り当てることができます。次に、アプリケーションは、トークンにエンコードされたユーザーのテナントグループメンバーシップに基づいてリソースとデータへのアクセスを制限する認可ロジックを実装できます。これにより、Cognito のネイティブグループ構造を利用してテナント分離とアクセス制御を提供し、カスタム属性に完全に依存する必要がなくなります。 トークンに含まれるグループ情報は、ダウンストリームのサービスで認可決定に使用できます。グループは、より細かいアクセス制御のためにカスタム属性と組み合わせて使用されることが多くあります。たとえば、 AWS SaaS Factory チーム が開発した SaaS Factory Serverless SaaS – Reference Solution では、テナントアイデンティティはカスタム tenantId によって決定しますが、テナント内でのユーザーの役割は Cognito グループを使用して指定されています。このリファレンスソリューションにおいて、テナントアイデンティティ属性はテナント分離を提供し、グループは特定のテナント内で適用される個々のユーザーの役割とアクセス権限を定義しています。 図2は、グループがユーザーに関連付けられ、その後 Lambda オーソライザーがそれぞれの認証済みユーザーがアクセスを許可されているバックエンドリソースとサービスを決定する方法を示しています。 図 2: グループベースのマルチテナンシー このモデルでは、グループはロールベースの制御を提供し、テナント ID などのカスタム属性はテナント分離を実施するために必要な情報を提供します。認可決定は、ユーザーのグループメンバーシップと属性値を評価することで、各テナントとユーザーに合わせた細かいアクセス制御を提供します。つまり、グループは直接的にロールベースのチェックを可能にし、カスタム属性はテナントの条件付きアクセスのための広範なコンテキストを提供します。両者を組み合わせることで、マルチテナントアプリケーションで細かい認可を実装するために必要なデータを提供できます。 グループベースのマルチテナンシーの長所: このモデルでは、複数テナントに対して単一の共有ユーザープールを使用するため、オンボーディングはユーザー属性の設定で済み、複数のプールを構成する必要がありません。 テナントは同じアプリケーションクライアントとプールを通して認証を行うため、SaaSクライアントの構成が簡素化されます。 グループベースのマルチテナンシーの短所: 1 つのプールを共有するため、パスワードポリシーや MFA などの設定は統一され、テナントごとのカスタマイズは不可となります。 ユーザープールあたり最大10,000グループの制限があります。 パターン 4: テナントごとに専用のユーザープールを用意する (サイロモデル) Cognito でのマルチテナントアイデンティティのもう1つのよくある方法は、各テナントに対して個別のユーザープールをプロビジョニングすることです。Cognito のユーザープールはユーザーディレクトリなので、個別のプールを使用することで最大の分離が可能になります。ただし、この方法ではアプリケーション側でテナントのルーティングロジックを実装し、ユーザーのテナントに基づいて認証対象のユーザープールを決定する必要があります。 テナントルーティング テナントごとに個別のユーザープール (または後で説明するアプリケーションクライアント) を使用する場合、アプリケーションには各ユーザーを適切なプール (またはクライアント) にルーティングするロジックが必要です。このアプローチでは、次のようなオプションを使用できます: URL にサブドメインを使用してテナントにマッピングします。たとえば、tenant1.myapp.com は Tenant 1 のユーザープールにルーティングされます。これにはサブドメインをテナントプールにマッピングする必要があります。 テナントごとに一意のメールドメインを使用します。たとえば、@tenant1.com は Tenant 1 のプールに行きます。これにはメールドメインをプールにマッピングする必要があります。 ユーザーにテナントをドロップダウンリストから選択させます。これにはテナントの選択肢を設定する必要があります。 ユーザーにテナント ID コードを入力させます。これにはコードをプールにマッピングする必要があります。 選択したアプローチに関係なく、主な要件は次のとおりです: テナントを識別するデータポイント (サブドメイン、メール、選択、コードなど) ユーザーからテナント識別情報を取得し、対応するユーザープールを検索してルーティングするためのマッピングデータセット 適切なユーザープールにリダイレクトするためのルーティングロジック たとえば、 AWS SaaS Factory Serverless Reference Architecture では、図 3 に示すアプローチを使用しています。 図 3: テナントごとに専用のユーザープール ワークフローは次のとおりです: ユーザーはサインイン時にテナント名を入力します。 テナント名からユーザープール ID、アプリケーションクライアント ID、API URL などのテナント固有の情報を取得します。 テナント固有の情報が SaaS アプリに渡され、正しいユーザープールとアプリクライアントで認証を初期化し、認可コードフローを初期化するために使用されます。 アプリは Cognito のホストされた UI に認証のためにリダイレクトします。 ユーザー資格情報が検証され、Cognito から OAuth コードが発行されます。 OAuth コードが Cognito の JWT と交換されます。 JWT を使用してユーザーをマイクロサービスにアクセスするために認証します。 テナントごとにプールを 1 つずつ持つモデルの長所: ユーザーは単一のディレクトリに存在し、クロステナントでの可視性はありません。トークンはそのプールに固有の鍵で発行され、署名されます。 各プールでは、パスワードルールや MFA 要件などのセキュリティポリシーをテナントごとにカスタマイズできます。 プールは、データ保管の要件を満たすために異なる AWS リージョンでホストできます。 テナントごとにプールを 1 つずつ持つモデルの潜在的な短所: アカウントあたりのプール数に制限があります (デフォルトは 1,000 プール、最大は 10,000 プールです)。 複数のプール、特にカスタマイズされた設定のプールを作成するには、追加の自動化が必要です。 アプリケーションは、認証リクエストを正しいユーザープールに向けるためのテナントルーティングを実装する必要があります。 各プールの設定が個別に管理され、テナントルーティング機能が追加されるため、トラブルシューティングが難しくなる可能性があります。 まとめると、個別のユーザープールはテナントの分離を最大化しますが、より複雑なプロビジョニングとルーティングが必要になります。大規模なマルチテナントデプロイメントの場合は、プール数の制限も考慮する必要があるかもしれません。 パターン 5: テナントごとのアプリケーションクライアント (ブリッジモデル) グループとカスタム属性を使用する以外に、単一のユーザープールでテナントごとに個別のアプリケーションクライアントを使用することでも、テナントの分離を実現できます。アプリケーションクライアントの Cognito 設定 (OAuth スコープ、ホストされた UI のカスタマイズ、セキュリティポリシーなど) は、テナントごとに固有のものにできます。また、アプリケーションクライアントを使用すれば、テナントごとに外部 IdP のフェデレーションも可能です。ただし、パスワードポリシーなどのユーザープールレベルの設定は共有されたままです。 図 4 は、単一のユーザープールに複数のアプリケーションクライアントを設定する方法を示しています。それぞれのアプリケーションクライアントは、各テナントに割り当てられています。ただし、このアプローチでは、アプリケーション内でテナントをどのアプリケーションクライアントにマッピングするかを判断するためのロジックを実装する必要があります (共有ユーザープールの場合と同様のアプローチです)。ユーザーが認証されると、Amazon API Gateway に Lambda オーソライザー関数を設定して ID トークンの署名を検証できます。その後、Lambda オーソライザー関数は、認証されたユーザーがアクセスを許可されているバックエンドリソースとサービスを判断できます。 図 4: アプリケーションクライアントベースのマルチテナンシー SAML または OpenID Connect フェデレーションを使って独自の IdP を利用したいテナントの場合は、ユーザーをテナントの連携 IdP にリダイレクトして認証する専用のアプリケーションクライアントを作成できます。これには以下のような主なメリットがあります: アプリケーションクライアントに単一の外部 IdP が有効化されている場合、ホストされた UI は自動的にユーザーをリダイレクトし、Cognito のサインイン画面を表示しません。これにより、テナントにとっては馴染みのあるサインイン体験が提供され、テナント IdP にセッションが既にある場合は、シームレスな体験になります。 ユーザーの追加や離脱、パスワードの管理など、ユーザーアクティビティの管理は、テナント側の IdP で完全に処理されます。SaaS プロバイダーはこれらのプロセスに関与する必要がありません。 重要なのは、フェデレーションを使用する場合でも、Cognito は外部認証が成功すると引き続きトークンを発行することです。つまり、SaaS プロバイダーは、IdP に関係なく、認可時に Cognito から発行される一貫したトークンを検証できます。 属性マッピング 外部 IdP と連携する場合、Amazon Cognito は発行するトークンに属性を動的にマッピングできます。これにより、IdP で作成されたグループ、メールアドレス、ロールなどの属性が認証時に Cognito に渡され、トークンに追加されます。 マッピングは、サインイン時に毎回行われ、既存のマッピング済み属性を上書きして IdP の最新の値と同期します。したがって、マッピング済み属性に関連する外部 IdP での変更は、サインイン後に Cognito に反映されます。メールアドレスのようにサインインに必要なマッピング済み属性がある場合、IdP に同等の属性があってマッピングする必要があります。Cognito の対象属性は変更可能に設定する必要があります。作成後は不変の属性はマッピングによっても上書きできません。 重要 : SaaS アイデンティティの場合、テナント属性は外部 IdP からマッピングするのではなく、Cognito で定義する必要があります。これにより、テナントが値を改ざんするのを防ぎ、分離を維持できます。ただし、グループやロールなどのユーザー属性は、テナントの IdP からマッピングしてアクセス許可を管理できます。これにより、テナントは独自の IdP グループを使用してアプリケーションのロールを設定できます。 ブリッジモデルの長所: このモデルでは、OAuth スコープ、UI、IdP などのテナント固有の設定が可能です。 テナントユーザーは外部 IdP を通じて馴染みのあるワークフローにアクセスでき、外部 IdP を使用する場合、テナントユーザー管理は外部で行われます。 カスタムクレームマッピングは必要ありませんが、オプションで使用できます。 Cognito はトークンを発行して認可を行えます。 ブリッジモデルの短所: ユーザーをテナントごとの正しいアプリクライアントにルーティングする必要があります。 ユーザープールごとのアプリクライアント数に制限があります。 パスワードポリシーなどの一部のユーザープール設定は共有されたままです。 動的なグループクレームの変更はできません。 まとめ このブログ記事では、 Amazon Cognito ユーザープールが SaaS ソリューションのマルチテナント ID をどのように有効にできるかについて、さまざまな方法を探りました。単一の共有ユーザープールは管理を簡素化しますが、ユーザープールレベルのポリシーをカスタマイズするオプションが制限されます。一方、個別のプールは分離と構成の柔軟性を最大化しますが、複雑さが増します。複数のアプリケーションクライアントを使用すると、外部 IdP や OAuth スコープなどのカスタマイズされたオプションと、ユーザープールの集中管理ポリシーとのバランスを取ることができます。カスタムクレームマッピングは柔軟性がありますが、追加のロジックが必要です。 これら 2 つのアプローチを組み合わせることもできます。たとえば、一部の上位層のテナントには専用のユーザープールを用意し、他のテナントはマルチテナントプールを共有するなどです。最適な選択は、特定のテナントのニーズと必要なカスタマイズ次第です。 このブログ記事では主に静的なアプローチについて説明しましたが、 トークン生成前の Lambda トリガー を使用してトークンを動的に変更し、クレームを追加、変更、削除することもできます。このトリガーは、ID トークンとアクセストークンの両方でグループメンバーシップを上書きすることもできます (訳者注: アクセストークンのカスタマイズには、Cognito の高度なセキュリティ機能を有効化する必要があります)。その他のクレーム変更は ID トークンにのみ適用されます。このトリガーの一般的な使用例は、テナント属性をトークンに動的に注入することです。 SaaS アーキテクチャとテナントの要件に対して、それぞれのアプローチの長所と短所を評価してください。ハイブリッドモデルが最適な場合が多くあります。Cognito のユーザープール、IdP、トリガーなどの構成要素を使用すると、テナント全体で認証と認可を細かく調整できます。 これらのトピックの詳細については、Cognito 開発者ガイドの 一般的な Amazon Cognito シナリオ と関連ブログ記事 How to Use Cognito Pre-Token Generation trigger to Customize Claims in ID Tokens を参照してください。   Shubhankar Sumar Shubhankar はAWSのシニアソリューションアーキテクトで、英国の企業ソフトウェアや SaaS のお客様と協力して、セキュアで拡張性があり、効率的で費用対効果の高いシステムを設計するのを支援しています。彼は多くの SaaS ソリューションを構築してきた経験豊富なソフトウェアエンジニアです。Shubhankar の専門分野は、クラウド上でマルチテナントプラットフォームを構築することです。また、顧客とも密接に連携して、SaaS アプリケーションに GenAI 機能を導入することにも取り組んでいます。 Owen Hawkins Owen は20年以上の情報セキュリティの経験を持ち、AWS のプリンシパル・ソリューション・アーキテクトとして深い専門知識を持っています。彼はデジタルバンキングのセキュリティに関する豊富な経験を活かして、ISV の顧客に密接に協力しています。Owen は SaaS およびマルチテナントアーキテクチャに特化しています。彼は企業がクラウドを安全に活用できるようにすることに情熱を持っています。複雑な課題を解決することは Owen にとって大きな喜びであり、AWS でアプリケーションを保護し実行するための革新的な方法を見つけることにやりがいを感じています。 翻訳はソリューションアーキテクト 中山 七美 が担当しました。原文は こちら です。

この記事は、 Tenant portability: Move tenants across tiers in a SaaS application を翻訳したものです。 今日の急速に変化する Software as a Service (SaaS) 環境において、テナントのポータビリティは、競争力を維持しようとする SaaS プロバイダーにとって重要な機能です。テナントのティア間の円滑な移動を可能にするポータビリティにより、企業は変化するニーズに適応できます。しかし、ティア移動のリクエストに手動で対応することは大きなボトルネックとなり、スケーラビリティを阻害し、多大なリソースを必要とします。テナントの数とポータビリティのリクエストが増加するにつれ、このアプローチはサステナブルではなくなり、より効率的な解決策を実装することが不可欠になります。 このブログ記事では、テナントのポータビリティの重要性を掘り下げ、 SaaS サーバーレスリファレンスアーキテクチャ へのシームレスな統合にフォーカスしながら、実装に不可欠なステップを概説します。次の図はティア移動のプロセスを示しており、テナントと管理者の役割、およびアーキテクチャ内の新規および既存サービスにおける影響が強調されています。次のセクションでは、この図に示されたイベントの順序を詳しく説明します。 図1. SaaS サーバーレスリファレンスアーキテクチャ内でテナントのポータビリティを組み込む なぜテナントのポータビリティが必要なのか? * 柔軟性: テナントによるティアのアップグレードまたはダウングレードの場合、ティアの移動は変化するテナントの需要、選択、予算、ビジネス戦略に合わせて行われます。これらのティア変更は、通常、テナントと SaaS プロバイダー間のサービス契約の変更を伴います。 * サービス品質: SaaS 管理者によるテナント移行は、セキュリティ違反や、テナントがサービス制限に達した際の対応として行われます。これらのインシデントでは、サービスレベル契約 (SLA) を維持するためにテナントの移行が必要になる可能性があります。 大まかなポータビリティフロー テナントのポータビリティは、通常、ティア間の移行をシームレスに行うために適切にオーケストレーションされたプロセスを通じて実現されます。このプロセスは以下のステップで構成されています: 図2. テナントポータビリティの大まかなフロー アイデンティティストアの移行 : テナントのアイデンティティストアをターゲットのティアに移行する必要があるかどうかを評価します。既存のアイデンティティストアがターゲットティアと互換性がない場合は、移行先ティアのアイデンティティストアと管理者ユーザーをプロビジョニングする必要があります。 テナント設定の更新 : SaaS アプリケーションは、テナント ID やティアなど、運用に必要なテナント設定情報を保存しています。 リソース管理 : ターゲットのティアにリソースをプロビジョニングし、インフラストラクチャとテナントのマッピングテーブルを更新するためのデプロイメントパイプラインを開始します。 データ移行 : テナントのデータを古いティアからターゲットティアの新しくプロビジョニングされたインフラストラクチャに移行します。 カットオーバー : テナントのトラフィックを新しいインフラストラクチャにリダイレクトし、更新されたリソースをダウンタイムなく利用できるようにします。 検討事項のウォークスルー ここでは、ポータビリティのワークフローにおける各ステップを詳しく見ていき、実装における重要な検討事項を強調します。 1. アイデンティティストアの移行 アイデンティティの移行における主な検討事項は、パスワードのリセットやユーザー ID の変更を必要とせずに、一貫したエンドユーザーエクスペリエンスを維持しながら、ユーザーの ID を移行することです。 フロントエンドが使用できる新しい ID ストアと関連するアプリケーションクライアントを作成した後、ユーザーを移行するメカニズムが必要になります。Amazon Cognito を使用した リファレンスアーキテクチャ では、各テナントが独自のユーザープールを持つことを「サイロ」と呼び、複数のテナントが ユーザーグループ を通じてユーザープールを共有することを「プール」と呼んでいます。 スムーズな移行プロセスを確保するため、ユーザーとコミュニケーションを取り、パスワードのリセットを回避するオプションを提供することが重要です。1 つのアプローチとして、期限までにログインするようユーザーに通知し、パスワードのリセットを回避することができます。ログイン時に ジャストインタイムマイグレーション を採用し、既存のパスワードを維持することで、ユーザーエクスペリエンスを阻害せずにパスワードを保持できます。 ただし、これにはすべてのユーザーが移行するまで待つ必要があり、移行期間が長期化する可能性があります。補完的な対策として、期限後に残りのユーザーを 一括インポート を使用して移行することができます。これにより、パスワードのリセットが強制されますが、一定の期間内で一貫した移行を確実に行えます。ただし、一部のユーザーには不便をかけることになります。 2. テナント設定の更新 SaaS プロバイダーは、すべてのテナント関連の設定を保持するためにメタデータストアを利用しています。移行プロセス中にテナントメタデータを更新する際は、慎重に行う必要があります。新しいティアのためにテナント設定を更新する際は、次の 2 つの重要な側面を考慮する必要があります。 移行プロセス全体を通して テナント ID を保持する ことで、移行後のテナントのログ、メトリクス、コスト請求について円滑に統合でき、イベントの継続的な記録が可能になります。 新しいティアに合わせて、テナントの使用量の上限を高めるための 新しい API キー とスロットリングメカニズムを確立します。 SaaS リファレンスアーキテクチャに新しいテナントポータビリティサービスを導入することで、この処理を行います。このサービスは、ティア変更のリクエストに基づいてテナントに異なる AWS API Gateway の使用量プランを割り当て、後続サービスの呼び出しを調整します。その後、既存のテナント管理サービスを拡張し、リクエストに基づいてテナントメタデータ (ティア、ユーザープール ID、アプリクライアント ID) を更新する必要があります。 3. リソース管理 インフラストラクチャのプロビジョニングにおけるポータビリティの成功は、以下の 2 つの重要な側面に依存します。 移行プロセス中の テナント分離 構成を尊重 し、クロステナントのアクセスを防ぎます。ロールベースのアクセス制御 (RBAC) または 属性ベースのアクセス制御 (ABAC) を使用して、これを確実にすることができます。前のステップでテナント ID が保持されている場合、ABAC 分離が移行中でも管理しやすいものとなります。 新しいティアで 計装とメトリクス収集 が正しく設定されていことを確認します。SaaS 運用の監視可視性を確保するために、同一の メトリクスフィルター を再作成します。 リファレンスアーキテクチャにおいて、インフラストラクチャのプロビジョニングとデプロビジョニングを処理するには、テナントプロビジョニングサービスを拡張します。 テナントスタックのマッピングテーブルを更新して、移行したテナントスタックの詳細を記録します。 必要に応じてインフラストラクチャのプロビジョニングまたは削除のパイプラインを開始します (例えば、データ移行とユーザーカットオーバーの手順の後に不要なインフラストラクチャを削除するパイプラインを実行します）。 最後に、関連するセキュリティ設定を適用し、 コンプライアンス に準拠したアプリケーションのバージョンをデプロイすることで、新しいリソースが必要なコンプライアンス基準を満たすことを確認します。 これらの事項に対処することで、SaaS プロバイダーはテナント分離と運用の継続性を維持しながら、シームレスな移行を確実にすることができます。 4. データ移行 データ移行戦略は、ストレージエンジンや分離アプローチなどのアーキテクチャに大きく影響されます。移行中のユーザーのダウンタイムを最小限に抑えるには、移行プロセスの加速、サービスの可用性維持、増分更新のためのレプリケーションチャネルの設定に重点を置く必要があります。さらに、プールモデルに移行する際のデータ整合性を確保し、データ損失を回避するために、サイロモデルでテナントが行ったスキーマ変更に対処することが重要です。 リファレンスアーキテクチャを拡張し、新しいデータ移行サービスを導入することで、異なるティア間での Amazon DynamoDB データ移行を可能にできます。DynamoDB パーティション移行には、 AWS Glue 、 カスタムスクリプト 、 DynamoDB テーブルの複製 、 パーティションの一括削除 などの複数のアプローチがあります。ゼロダウンタイムの移行を実現するには、 ハイブリッドアプローチ をお勧めします。このソリューションは、DynamoDB のスキーマがティアを越えて一貫している場合にのみ適用されます。スキーマが変更されている場合は、データ移行に カスタムソリューション が必要です。 5. カットオーバー カットオーバーフェーズでは、ユーザーを新しいインフラストラクチャに切り替え、継続的なデータレプリケーションを無効化し、 コンプライアンス要件 が満たされていることを確認します。これには、高い機密性が求められるサイロへの移行時には特に、テスト実行や監査や認証の取得を含むことになります。カットオーバーが成功した後、一時的なインフラストラクチャの削除や、以前のティアからの不要なテナントデータ履歴の削除など、クリーンアップ活動が必要です。ただし、データを削除する前に、監査証跡が規制要件に準拠して保存されており、データ削除が組織のポリシーに沿っていることを確認してください。 まとめ ポータビリティはマルチテナント SaaS にとって重要な機能です。テナントはデータと構成情報をティア間で移行でき、上記のようにリファレンスアーキテクチャに組み込むことで移行を簡便に実施できます。主な考慮事項は、一貫したアイデンティティを維持すること、コンプライアンスを維持すること、ダウンタイムを減らすこと、プロセスを自動化することです。   Aman Lal Aman Lal は、SaaS の開発、コンテナ技術、プラットフォームエンジニアリングを専門とする AWS のクラウドアーキテクトです。イノベーションへの情熱を持ち、AWS のお客様の多様なニーズに合わせたクリエイティブなソリューションを考案することに秀でています。Aman は Amazon のエンジニアリングプラクティスを゙使って、お客様に対してスケーラブルなプロダクトの構築とクラウドインフラの最適化をリードし、ビジネス価値を生み出しています。 Varun Saxena Varun は、ソフトウェアエンジニアとビルダーとしての16年以上の経験を持つAWSのクラウドアーキテクトです。彼は、AI を含む最先端のテクノロジーを活用して、クラウドネイティブのアプリケーションを設計・構築することに特化しています。これにより、世界中のフォーチュン企業のデジタルトランスフォーメーションと事業の成功を推進しています。より迅速かつ効率的なソリューションを提供することに専念している Varun は、テクノロジーを活用して複雑なビジネス上の課題を解決し、全体的な効率性と収益性を高めるために、クライアントが望む成果を達成するのを支援しています。彼は、正しいものを構築し、かつ正しく構築することの確固たる支持者です。 翻訳はソリューションアーキテクト 中山 七美 が担当しました。原文は こちら です。

この記事は、Deltek の Kevin Plexico と Shakun Vohra が共同で執筆した How Deltek uses Amazon Bedrock for question and answering on government solicitation documents を翻訳したものです。翻訳は Solutions Architect の宮口直樹が担当しました。 文書を使用した質疑応答 (Q&A) は、カスタマーサポートチャット、法律調査アシスタント、ヘルスケアアドバイザーなど、さまざまなユースケースで一般的に使用されるアプリケーションです。 Retrieval Augmented Generation (RAG) は、大規模言語モデル（LLM）の力を活用して自然言語で文書とやり取りするための主要な方法として登場しました。 このブログ記事では、 AWS Generative AI Innovation Center (GenAIIC) が Deltek 向けに開発したカスタムソリューションの概要を紹介します。 Deltek は政府契約およびプロフェッショナルサービスの両分野におけるプロジェクトベースのビジネスで世界的な標準として認められた企業です。Deltek は 30,000 を超えるクライアントに業界特化型のソフトウェアと情報ソリューションを提供しています。 この共同プロジェクトでは、AWS GenAIIC チームは Deltek 向けに、単一および複数の政府調達文書に対する Q&A を可能にする RAG ベースのソリューション作成しました。このソリューションでは、 Amazon Textract 、 Amazon OpenSearch Service 、 Amazon Bedrock などの AWS サービスを利用しています。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要な AI 企業から、高性能な基盤モデル (FM) と LLM を単一の API で選択して利用できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するための機能を提供します。 Deltek は、PDF 以外のファイル形式のサポートやデータ取り込みパイプラインのよりコスト効率の高いアプローチの実装など、特定の要件により適合させるために、このソリューションの強化に継続的に取り組んでいます。 RAG とは何か？ RAG は、LLM が応答を生成する前に、学習データソース以外の信頼できる知識ベースを参照できるようにすることで、LLM の出力を最適化するプロセスです。このアプローチは、誤った情報、古い情報、一般的すぎる情報を提示したり、用語の混同により不正確な応答を生成したりするなど、LLM に関連する課題を対処します。RAG により、LLM は組織内部のナレッジや特定の分野を参照することで、モデルを再学習する必要なく、より関連性が高く、正確で、コンテキストに即した応答を生成できます。これによって組織は生成されるテキスト出力をより制御できるようになり、ユーザーは LLM がどのように応答を生成したかについての洞察を得ることができます。RAG はさまざまな状況で LLM の性能を改善するための費用対効果の高いアプローチとなります。 主な課題 単一の文書に対して Q&A で RAG を適用するのは簡単ですが、複数の関連文書に同じことを適用するには、いくつかの特殊な課題が生じます。例えば、時間の経過とともに変化する文書に対して Q&A を行う場合、質問が時間とともに変化する概念に関するものであれば、文書の時系列順序を考慮することが必要です。順序を考慮しないと、過去のある時点では正確だったが、時系列に沿って整理された文書群の中のより最新の情報に基づくと、現在では古くなっている回答を提供してしまう可能性があります。時間的側面を適切に扱うことは、単一の文書から、時間の経過とともに変化する相互にリンクした文書群への質問応答を拡張する際の重要な課題です。 ソリューションの概要 ユースケースの例として、時系列の関係にある 2 つの文書に対する Q&A について説明します。1 つは長い提案依頼書（RFP）の草案文書、もう 1 つは関連する後続の情報提供依頼書（RFI）への政府の回答で、追加および改訂された情報が提供されています。 このソリューションは、2 つのステップで RAG アプローチを展開しています。 最初のステップはデータ取り込みで、以下の図に示す通りです。これには、PDF 文書の一回限りの処理が含まれます。ここでのアプリケーションコンポーネントは、テキストの分割やバックグラウンドでのサービス呼び出しなどの簡単な処理を行うユーザーインターフェイスです。手順は以下の通りです。 ユーザーが文書をアプリケーションにアップロードします。 アプリケーションは Amazon Textract を使用して、入力文書からテキストと表を取得します。 テキスト埋め込みモデルがテキストチャンクを処理し、各テキストチャンクの埋め込みベクトルを生成します。 テキストチャンクの埋め込み表現と関連するメタデータが OpenSearch Service にインデックス化されます。 2 番目のステップは以下の図に示す通り Q&A です。このステップでは、ユーザーが取り込まれた文書に関する質問をし、自然言語での回答を期待します。ここでのアプリケーションコンポーネントは、バックグラウンドで別のサービスを呼び出すなどの簡単な処理を行うユーザーインターフェースです。手順は以下の通りです。 ユーザーが文書に関する質問をします。 アプリケーションは、入力された質問の 埋め込みベクトル を取得します。 アプリケーションは、OpenSearch Service から取得したデータと質問を Amazon Bedrock に渡して、回答を生成します。モデルはセマンティック検索を実行し、文書から関連するテキストチャンク（コンテキスト）を見つけ出します。埋め込みベクトルは、質問をテキストから数値表現の空間にマッピングします。 質問とコンテキストが組み合わされ、LLM へのプロンプトとして入力されます。言語モデルは、ユーザーの質問に対する自然言語の回答を生成します。 我々のソリューションでは、PDF、PNG、JPEG、TIFF をテキストデータに変換できる Amazon Textract を使用しました。また、表などの複雑なレイアウトも分析しやすい形式に整形します。次のセクションでは、Amazon Textract の機能を示す例を紹介します。 OpenSearch は、Elasticsearch から派生したオープンソースの分散検索および分析スイートです。大量のデータを効率的に保存し、クエリを実行するためにベクトルデータベース構造を使用しています。OpenSearch Service には現在、数万のアクティブユーザーがいて、数十万のクラスターを管理し、月間数百兆のリクエストを処理しています。私たちは OpenSearch Service とその基盤となるベクトルデータベースを使用して、以下のことを行いました。 文書をベクトル空間にインデックス化し、関連項目を近接して配置することで関連性を向上させる Q&A のステップで、ベクトル間の近似最近傍探索を使用して、関連する文書チャンクを迅速に取得する OpenSearch Service 内のベクトルデータベースにより、関連データチャンクを効率的に保存し、迅速に取得することができ、これが質問応答システムの基盤となりました。文書をベクトルとしてモデル化することで、明示的なキーワード一致がなくても関連する段落を見つけられるようになりました。 テキスト埋め込みモデルは、テキストからの単語やフレーズを密なベクトル表現にマッピングする機械学習 (ML) モデルです。テキスト埋め込みは、RAG のような情報検索システムで以下の目的でよく使用されます。 ドキュメント埋め込み – 埋め込みモデルを使用して、文書の内容をエンコードし、埋め込み空間にマッピングします。通常、文書を段落、セクション、または固定サイズのチャンクなどの小さな単位に分割することが一般的です。 クエリ埋め込み – ユーザーのクエリをベクトルに埋め込みし、セマンティック検索を実行して文書チャンクと照合できるようにします。 この記事では、最大 8,000 トークンを受け取り、1,536 次元の数値ベクトルを出力するモデルである Amazon Titan Embeddings G1 – Text v1.2 を使用しました。このモデルは Amazon Bedrock 経由で利用可能なモデルです。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの有力な AI 企業から、すぐに使用できる基盤モデルを提供しています。プライバシーとセキュリティを維持しながら、これらのモデルにアクセスし、生成AIアプリケーションを構築するための単一のインターフェースを提供します。我々は、Amazon Bedrock の Anthropic Claude v2 を使用して、質問とコンテキストに基づいた自然言語の回答を生成しました。 以下のセクションでは、このソリューションの 2 つのステップをより詳しく見ていきます。 データ取り込み まず、RFP および RFI の回答文書の下書きが、Q&A の時に使用できるように処理されます。データ取り込みには、以下のステップが含まれます。 文書は Amazon Textract に渡され、テキストに変換されます。 言語モデルが表に関する質問に適切に答えられるようにするため、Amazon Textract の出力から表を CSV 形式に変換するパーサーを作成しました。表を CSV に変換することで、モデルの理解力が向上します。たとえば、以下の図は PDF 形式の RFI 回答書の一部と、対応する抽出されたテキストを示しています。抽出されたテキストでは、表が CSV 形式に変換され、他のテキストの中に配置されています。 長い文書の場合、抽出されたテキストが LLM の入力サイズ制限を超える可能性があります。そのような場合、テキストを小さなオーバーラップ部分を含む複数のチャンクに分割できます。チャンクのサイズとオーバーラップの割合は、ユースケースによって異なる場合があります。セクション単位のチャンク分割（各文書セクションごとに独立してチャンク分割を行う）を適用しており、後述のユースケースにて説明します。 一部の文書クラスは、標準的なレイアウトや形式に従っている場合があります。例えば、RFP には、定義されたセクションを含む特定のレイアウトがあることが多いです。このレイアウトを使用すれば、各文書セクションを独立して処理できます。また、目次が存在しても関連性がない場合は、削除される可能性があります。このブログ記事の後半で、文書構造の検出と利用のデモンストレーションを行います。 各テキストチャンクの埋め込みベクトルは、埋め込みモデルから取得されます。 最後のステップで、埋め込みベクトルが OpenSearch Service データベースにインデックス化されます。埋め込みベクトルに加えて、文書名、文書セクション名、公開日などのメタデータも、テキストフィールドとしてインデックスに追加されます。文書が時系列的に関連している場合、公開日は有用なメタデータで、LLM が最新の情報を特定できるようになります。次のコードスニペットは、インデックスの中身を示しています。 index_body = { "embedding_vector": <embedding vector of a text chunk>, "text_chunk": <text chunk>, "document_name": <name>, "section_name": <section name>, "release_date": <release date>, # 更なるメタデータを追加できます } Q&A Q&A フェーズでは、ユーザーは前のステップで取り込まれた RFP および RFI について自然言語で質問ができます。まず、セマンティック検索を実行し、ユーザーの質問に関連するテキストチャンクを取得します。次に、取得したコンテキストを使って質問を拡張してプロンプトを作成します。最後に、プロンプトを Amazon Bedrock に送信し、LLM が自然言語の回答を生成します。詳細な手順は以下の通りです。 入力された質問の埋め込みベクトルが、Amazon Bedrock の Amazon Titan 埋め込みモデルから取得されます。 質問の埋め込みベクトルを使用して、OpenSearch Service でセマンティック検索を実行し、関連性の高い上位 K 個のテキストチャンクを見つけます。以下は、OpenSearch Service に渡される検索クエリ本文の例です。検索クエリの構造化の詳細については、 OpenSearch のドキュメント を参照してください。 search_body = { "size": top_K, "query": { "script_score": { "query": { "match_all": {}, # skip full text search }, "script": { "lang": "knn", "source": "knn_score", "params": { "field": "embedding-vector", "query_value": question_embedding, "space_type": "cosinesimil" } } } } } 取得したメタデータ (セクション名や文書のリリース日付など) は、テキストのコンテキストを補強し、以下のように大規模な言語モデル (LLM) にさらに情報を提供するために使用されます。 def opensearch_result_to_context(os_res: dict) -> str: """ Convert OpenSearch result to context Args: os_res (dict): Amazon OpenSearch results Returns: context (str): Context to be included in LLM's prompt """ data = os_res["hits"]["hits"] context = [] for item in data: text = item["_source"]["text_chunk"] doc_name = item["_source"]["document_name"] section_name = item["_source"]["section_name"] release_date = item["_source"]["release_date"] context.append( f"<<Context>>: [Document name: {doc_name}, Section name: {section_name}, Release date: {release_date}] {text}" ) context = "\n \n ------ \n \n".join(context) return context 入力された質問は取得したコンテキストと組み合わされてプロンプトが作成されます。質問の複雑さや特殊性によっては、大規模な言語モデル (LLM) にさらなる説明とガイダンスを提供するために、初期プロンプトに追加で Chain-of-Thought (CoT) プロンプトを追加する必要があるかもしれません。CoT プロンプトは、質問を適切に理解し、回答を作成するために必要な論理的な推論と思考のプロセスを LLM に示すように設計されています。これは、LLM が質問に含まれる重要な情報を理解し、どのような回答が必要かを判断し、適切かつ正確な回答を構築するために従うべき一種の内部モノローグまたは認知的経路を示しています。本ユースケースでは、以下の CoT プロンプトを使用しています。 """ Context below includes a few paragraphs from draft RFP and RFI response documents: Context: {context} Question: {question} Think step by step: 1- Find all the paragraphs in the context that are relevant to the question. 2- Sort the paragraphs by release date. 3- Use the paragraphs to answer the question. Note: Pay attention to the updated information based on the release dates. """ プロンプトは、Amazon Bedrock の LLM に渡され、自然言語で回答が生成されます。Amazon Bedrock の Anthropic Claude V2 モデルでは、以下のような推論パラメータを使用しています。再現性を確保し、LLM のハルシネーションを防ぐために、Temperature パラメータは通常 0 に設定されます。一般的な RAG アプリケーションでは、 top_k と top_p はそれぞれ 250 と 1 に設定されます。 max_tokens_to_sample は、生成が期待される最大トークン数に設定します（英語の場合、1 トークンは約 3/4 語に相当します）。詳細については、 推論パラメータ を参照してください。 { "temperature": 0, "top_k": 250, "top_p": 1, "max_tokens_to_sample": 300, "stop_sequences": ["\n\nHuman:\n\n"] } 使用例 デモとして、関連する 2 つの文書に対する Q&A の例を説明します。1 つは 167 ページの PDF 形式の RFP 草案 、もう 1 つは後に公開された 6 ページの PDF 形式の RFI 回答書 で、RFP 案に対する追加情報と更新内容が含まれています。 以下は RFP 草案と RFI 回答書に基づいて、プロジェクトの規模要件が変更されたかどうかを尋ねる質問例です。 “Have the original scoring evaluations changed? if yes, what are the new project sizes?” 次の図は、回答が含まれている RFP 草案の関連セクションを示しています。 以下の図は、回答が含まれている RFI 回答書の関連セクションを示しています。 LLM が正しい応答を生成するためには、OpenSearch Service から取得したコンテキストに、前の図に示した表が含まれている必要があります。また、LLM は公開日などのメタデータからコンテンツの順序を整理し、自然言語で読みやすい回答を生成できる必要があります。 データ取り込みのステップは以下の通りです。 RFP 草案および RFI 回答書は、Amazon Textract にアップロードされ、テキストと表がコンテンツとして抽出されます。さらに、正規表現を使用して文書のセクションと目次を特定しました (それぞれ以下の図を参照)。このユースケースでは、目次に関連する情報がないため、削除できます。 各文書のセクションを独立して、オーバーラップを含む小さなチャンクに分割しました。本ユースケースでは、チャンクサイズを 500 トークン、オーバーラップを 100 トークンとしました（英語の場合、1 トークンは約 3/4 語に相当します）。 BPE トークナイザ を使用しており、各トークンは約 4 バイトに相当します。 Amazon Bedrock の Amazon Titan Embeddings G1 – Text v1.2 モデルを使用して、各テキストチャンクの埋め込みベクトルを取得します。 各テキストチャンクは、セクション名や文書公開日などのメタデータとともに、OpenSearch Service インデックスに格納します。 Q&A の手順は以下の通りです。 入力された質問は、まず埋め込みモデルを使って数値ベクトルに変換されます。このベクトル表現は、次のステップでのセマンティック検索と関連コンテキストの取得に使用されます。 上位 K 件の関連テキストチャンクとメタデータが OpenSearch Service から取得されます。 opensearch_result_to_context 関数と事前定義されたプロンプトテンプレートを使用して、入力の質問と取得したコンテキストに基づいてプロンプトが作成されます。 プロンプトは Amazon Bedrock 上の LLM に送信され、自然言語での回答が生成されます。以下は、Anthropic Claude v2 によって生成された応答で、 RFP 草案および RFI 回答書に示された情報と一致しています。質問は “Have the original scoring evaluations changed? If yes, what are the new project sizes?” でした。CoT プロンプトを使用することで、モデルは質問に正確に答えることができます。 主な機能 このソリューションは主に以下の機能を持ちます。 セクション単位のチャンク分割 – 文書のセクションを識別し、各セクションを独立して小さなチャンクに分割し、一部オーバーラップさせることでデータ取り込みを最適化します。 表から CSV への変換 – Amazon Textract で抽出された表を CSV 形式に変換し、言語モデルが表を理解し質問に答える能力を向上させます。 インデックスへのメタデータ追加 – セクション名や文書の公開日などのメタデータをテキストチャンクと共に OpenSearch Service インデックスに格納します。これにより、言語モデルが最新または関連性の高い情報を特定できるようになります。 CoT プロンプト – chain-of-thought プロンプトを設計し、質問を適切に理解し正確な回答を作成するために必要な論理的ステップについて、言語モデルにさらなる明確化とガイダンスを提供します。 これらの機能により、文書に関する質問への回答におけるソリューションの精度と能力が向上しました。実際、Deltek の専門家による LLM 生成レスポンスの評価では、このソリューションは全体で 96% の精度を達成しました。 結論 このブログ記事では、複数の政府調達文書に対する質問回答のための生成 AI アプリケーションについて概説しました。この記事で触れたソリューションは、AWS GenAIIC チームが Deltek と協力して開発したパイプラインを簡略化したものであり、時系列で個別に公開される長大な文書に対する Q&A を可能にするアプローチを説明しました。Amazon Bedrock と OpenSearch Service を使用することで、この RAG アーキテクチャはエンタープライズレベルの文書量に対応できます。さらに、CoT ロジックを使用してプロンプトテンプレートを紹介し、LLM がユーザーの質問に対して正確な応答を生成するのを支援しました。このブログ記事では、複雑な提案文書とその改訂版のレビューを合理化するための実世界の 生成 AI ソリューションの概要を提供することを目的としました。 Deltek はこのソリューションを固有のニーズに合わせて積極的に改良し最適化しています。この改良には、PDF 以外のファイル形式のサポート拡大や、データ取り込みパイプラインのためのコスト効率が良い手法の採用が含まれます。 プロンプトエンジニアリング と 生成 AI を活用した Q&A の詳細は、 Amazon Bedrock ハンズオン をご覧ください。技術サポートまたは AWS 生成 AI 専門家に連絡するには、 GenAIIC ウェブページ をご覧ください。 リソース Amazon Bedrock の詳細は、以下のリソースを参照してください。 Amazon Bedrock ワークショップ Amazon Bedrock ユーザーガイド OpenSearch Service の詳細は、以下のリソースを参照してください。 Amazon OpenSearch Service ドキュメント Amazon OpenSearch ワークショップ AWS の RAG リソースについては、以下のリンクを参照してください。 RAG (検索拡張生成) Amazon Bedrock のナレッジベース 著者について Kevin Plexico は、Deltek の情報ソリューション部の Senior Vice President で、政府請負業者および AEC 業界の顧客に対する調査、分析、仕様書作成を監督しています。 彼は 5,000 を超える顧客に不可欠な政府市場の情報を提供する GovWin IQ の提供を主導し、業界最大の規模の分析チームを管理しています。 Kevin はまた、Deltek の Specification Solutions 製品を統括しており、MasterSpec ®、SpecText などの建設仕様書コンテンツを作成しています。 Shakun Vohra は、20 年以上のソフトウェアエンジニアリング、AI/ML、ビジネスプロセスの改革、データ活用の専門知識を持つ傑出した技術リーダーです。 Deltek では、複数の大陸にまたがる多様な高パフォーマンスチームを率いて大きな成長を遂げました。 Shakun は、技術戦略と企業の目標を合わせ、経営陣と協力して組織の方向性を形作ることに長けています。 戦略的なビジョンとメンターシップで知られ、次世代のリーダーと変革的な技術ソリューションの育成に一貫して尽力してきました。 Amin Tajgardoon は、AWS Generative AI Innovation Center の Applied Scientist です。 コンピューターサイエンスと機械学習に関する幅広い経験を持っています。 特に Amin 氏は、ディープラーニングと予測、予測の説明手法、モデルドリフト検出、確率的生成モデル、そして医療分野における AI の応用に注力してきました。 Anila Joshi は、10 年以上にわたり AI ソリューションの構築に携わってきました。 AWS Generative AI Innovation Center の Applied Science Manager として、可能性の限界を押し広げる AI の革新的な応用を先導し、顧客が安全なジェネレーティブ AI ソリューションを構想、特定、実装するのを支援することで、顧客による AWS サービスの採用を加速させています。 Yash Shah と彼の率いるサイエンティスト、専門家、エンジニアのチームは、AWS Generative AI Innovation Center で、AWS の主要顧客と協力し、Generative AI の可能性を最大限に引き出し、ビジネス価値を生み出すことに取り組んでいます。 Yash は 7 年半以上 Amazon に在籍し、複数の地理的地域にわたり、ヘルスケア、スポーツ、製造業、ソフトウェア業界の顧客と協働してきました。 Jordan Cook は、AWS 分野で 20 年近くの実績を持つ Sr. Account Manager で、セールスとデータセンター戦略を専門としています。Jordan は、Amazon Web Services に関する広範な知識と、クラウドコンピューティングに対する深い理解を活かし、企業がクラウドインフラストラクチャを最適化し、運用効率を高め、イノベーションを促進できるよう、カスタマイズされたソリューションを提供しています。

本ブログは 2024 年 9 月 4 日に公開されたBlog ” Build a mobile driver’s license solution based on ISO/IEC 18013-5 using AWS Private CA and AWS KMS ” を翻訳したものです。 モバイル運転免許証 (mDL) は、モバイルデバイスに保存される物理的な運転免許証のデジタル版です。物理的な身分証明書には、紛失、盗難、偽造、破損、または古い情報が含まれる可能性があり、同意なしに個人を特定できる情報 ( PII ) を露出させる可能性があります。mDL は、身分証明書に比べて大幅な改善がされます。さまざまな組織が連携して、飛行機搭乗時の本人確認から年齢確認が必要な活動での情報提供まで、さまざまな状況で mDL を使用できるように取り組んでいます。 mDL システムにおける信頼は、公開鍵暗号方式に基づいています。mDL は発行機関によって秘密鍵で署名され、発行機関 (issuing authority) の公開鍵を使用して検証されます。 このブログでは、mDL 仕様 ISO/IEC 18013-5:2021 に従って、 AWS Private Certificate Authority (AWS Private CA) と AWS Key Management Service (AWS KMS) を使用して、 Amazon Web Services (AWS) で mDL 発行機関を構築する方法を紹介します。これらの AWS サービスは、ISO/IEC 18013-5 が発行機関に課す暗号化要件に適合しています。本ブログは mDL のユースケースに合わせて調整されていますが、AWS Private CA と AWS KMS を使用した署名と検証のメカニズムは、多様なデジタルアイデンティティ検証にも参考にできます。 ソリューションの概要 AWS Private CA は、独自のプライベート認証局（CA）を運用するための初期投資や継続的なメンテナンスコストなしに、高可用性のプライベート CA サービスを提供します。CA 管理者は、AWS Private CA を使用して、外部の CA に依存せずに、オンラインのルート CA や下位 CA を含む完全な CA 階層構造を作成できます。AWS Private CA を使用することで、組織内で信頼される証明書の発行、更新、失効を行うことができます。 AWS Private CA は、 ISO/IEC 18013-5 で規定されたフォーマットの証明書 を発行できます。ISO/IEC 18013-5 で発行機関認証局 (IACA: issuing authority certificate authority) と呼ばれる認証局 (CA) をAWS Private CA で 構築できます。本ブログでは、AWS Private CA を使用して IACA の自己署名ルート証明書と mDL 文書署名用証明書を作成します。 AWS KMS は、データを保護するために使用される暗号化キーを作成および管理するためのマネージドサービスです。AWS KMS は、FIPS 140-2 レベル 3 認証済みのハードウェアセキュリティモジュール (HSM) を使用して AWS KMS キーを保護します。これは、ISO/IEC 18013-5 で説明されている発行機関を構築する際の要件です。mDL 文書の署名と検証のために、AWS KMS で非対称キーペアを作成します。AWS KMS に保存された非対称キーペアによって署名された証明書署名要求 (CSR) をプログラムで作成します。CSR は AWS Private CA サービスに送信され、ISO/IEC 18013-5 で指定された証明書の証明書プロファイル要件に適合する mDL 文書署名用証明書を発行します。 AWS KMS で作成された KeyUsage 値が SIGN_VERIFY の非対称キーペアの秘密鍵を使用して、mDL 文書に署名します。署名された mDL 文書はモバイルデバイスに送信され、デジタルウォレットに保存され、mDL リーダーによる検証のために提示で使用されます。mDL リーダーには、さまざまな発行機関からの IACA 証明書が設定されており、それぞれの発行機関によって署名された mDL 文書を検証できます。発行機関の一例としては、運転免許証を発行する米国州政府機関などが挙げられます。 最小権限 本ブログのソリューションでは、AWS KMS と AWS Private CA サービスを使用します。ブログで説明する手順を実行する前に、選択した AWS Identity and Access Management (IAM) プリンシパルが最小特権の原則に従っており、必要最小限の権限のみが付与されていることを確認してください。詳細については、 IAM のセキュリティベストプラクティス をご覧ください。 ソリューションアーキテクチャ AWS で mDL 発行機関を構築するためのサンプルソリューションアーキテクチャを図 1 に示します。この図は、プライベート CA のセットアップから mDL 文書署名用証明書の発行、mDL の発行と検証までの段階的なプロセスを示しています。このアーキテクチャを使用して構築されるインフラストラクチャには、文書署名用証明書を発行するルート証明機関が含まれます。証明書の要件は、ISO/IEC 18013-5 のセクション B.1 証明書プロファイルで確認できます。 図 1 : AWS における mDL 発行機関のアーキテクチャとプロセスフロー このブログでは、 AWS Command Line Interface (AWS CLI) コマンドを使用しますが、必要に応じて AWS SDK API 呼び出しに置き換えることができます。AWS CLI の手順と併せて、AWS KMS を使用して mDL 文書署名用の CSR をプログラムで作成し署名するための GitHub サンプル も提供されています。 このソリューションで使用されているコマンドの詳細については、 AWS Private CA と AWS KMS の AWS CLI コマンドドキュメントをご覧ください。 ソリューションの詳細 mDL の署名と検証に必要なインフラストラクチャを作成する手順です。 ステップ 1: AWS Private CA での IACA CA の作成 このステップでは、信頼の起点となる IACA (発行機関 CA) を作成します。IACA ルート CA は、mDL の検証に使用される信頼の基点です。 以下の内容で、ローカルに ca_config.txt ファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルのセクション（付録 B ）から派生しています。必要に応じて、ファイル内の Country と CommonName の値を変更できます。 { "KeyAlgorithm": "EC_prime256v1", "SigningAlgorithm": "SHA256WITHECDSA", "Subject": { "Country": "US", "CommonName": "mDL IACA Root" } } IACA ルート証明書は、証明書失効リスト（ CRL ）とペアになります。CRL の設定に関する情報は、 証明書失効リスト（ CRL ）の設計 を参照してください。CRL を設定するために、以下の情報を含む revocation_config.txt というローカルファイルを作成します。 CustomCname と S3BucketName の値は例示です。AWS アカウント内で作成した値に更新してください。 ExpirationInDays は要件に合わせて更新してください。CRL を含む Amazon Simple Storage Service （ Amazon S3 ） バケットに暗号化を設定することをお勧めします。 { "CrlConfiguration": { "CustomCname": "example.com", "Enabled": true, "S3BucketName": "crlmdlbucket", "ExpirationInDays": 5000 } } AWS CLI コマンドを呼び出して、 プライベート認証局（ CA ）を作成 します。必要に応じて region パラメータを置き換えてください。以下のコマンドの file:// パスを、 ca_config.txt と revocation_config.txt ファイルを保存した場所に更新してください。 aws acm-pca create-certificate-authority \ --region us-west-1 \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revocation_config.txt \ --certificate-authority-type "ROOT" コマンドは以下の出力を生成するはずです。出力には作成された CA の Amazon リソースネーム (ARN) が含まれています。この ARN は後続のステップで必要になります。 { "CertificateAuthorityArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113" } ステップ 2: IACA ルート証明書の CSR の取得 IACA ルート証明書を作成します。この作成プロセスは CSR の取得から始まります。この手順で IACA ルート証明書の CSR を取得します。 certificate-authority-arn パラメータには、ステップ 1 で生成された CA ARN が含まれています。 次のコマンドは、 Privacy-Enhanced Mail （ PEM ）形式 の CSR を出力します。 aws acm-pca get-certificate-authority-csr \ --region us-west-1 \ --output text \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 出力される CSR の形式は以下の通りです： -----BEGIN CERTIFICATE REQUEST----- .. -----END CERTIFICATE REQUEST----- 出力されたテキストを IACA.csr というファイル名で保存してください。 ステップ 3: ルート証明書の生成 このステップでは、IACA ルート証明書を発行します。ISO/IEC 18013-5 の証明書プロファイルセクションから参照された以下の内容を使用して、 extensions.txt という名前のファイルを作成します。 KeyUsage 拡張機能の KeyCertSign と CRLSign を true に設定する必要があります。CRL 配布ポイントのカスタム拡張機能が設定され、証明書の有効期間は 9 年または 3285 日（次のステップで設定）に設定する必要があります。IACA ルート証明書は mDL の発行にのみ使用されるため、ISO/IEC 18013-5 の表 B.1 に示されているように、最大有効期間を 9 年とすれば十分です。さらに、CRL ディストリビューションポイント拡張機能が存在する必要があります。以下の例では、CDP 拡張機能でエンコードされた CRL URL は http://example.com/crl/0116z123-dv7a-59b1-x7be-1231v72571136.crl で、CA 作成時に適用された CA CRL 設定および CA ID の両方に合致しています。CDP 拡張機能の Base 64 エンコーディングについては、この Java サンプル を参照してください。 { "Extensions": { "KeyUsage": { "KeyCertSign": true, "CRLSign": true }, "CustomExtensions": [ { "ObjectIdentifier": "2.5.29.31", "Value": "MEgwRqBEoEKGQGh0dHA6Ly9leGFtcGxlLmNvbS9jcmwvMDExNnoxMjMtZHY3YS01OWIxLXg3YmUtMTIzMXY3MjU3MTEzNi5jcmw=" } ] } } 以下のコマンドを AWS Private CA に対して実行して、証明書を作成します。 aws acm-pca issue-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --template-arn "arn:aws:acm-pca:::template/BlankRootCACertificate_PathLen0_APIPassthrough/V1" \ --signing-algorithm "SHA256WITHECDSA" \ --csr fileb://IACA.csr \ --validity Value=3285,Type="DAYS" \ --api-passthrough file://extensions.txt このコマンドは、以下の出力を生成します： { "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318" } AWS Private CA で作成された IACA ルート CA には、デフォルトで CRL 配布ポイント (CDP) 拡張が含まれていないことに注意してください。しかし、これは ISO/IEC 18013-5 の IACA ルート証明書プロファイルによると必須の拡張機能です。これを実装するために、CDP 拡張を埋め込むカスタム拡張を API パススルー を使用して渡します。この拡張機能で指定される配布ポイントは、ステップ 1 で作成された CA ARN に含まれる CA ID である 0116z123-dv7a-59b1-x7be-1231v7257113 を使用して指定する必要があります。 ステップ 4: ルート証明書の取得 このステップでは、PEM 形式の IACA ルート証明書を取得します。 以下のコードを使用して IACA ルート証明書を取得します： aws acm-pca get-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/34a1dab03117f0e89c54b1234fe13318 \ --output text コマンドの出力は、以下のような PEM 形式の証明書となります： -----BEGIN CERTIFICATE----- .. -----END CERTIFICATE----- この出力されたテキストを IACA-Root-CA-Cert.pem という名前のファイルに保存します。 ステップ 5: ルート証明書のインポート 以下のコードを使用して、ルート証明書を AWS Private CA にインポートし、認証局をアクティブにして証明書を発行できる状態にします。 aws acm-pca import-certificate-authority-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate fileb://IACA-Root-CA-Cert.pem コマンドを実行すると、 success が表示されるはずです。 ステップ 6: AWS KMS での非対称キーの作成 この手順では、AWS KMS で非対称署名キーを作成します。このキーは、モバイル運転免許証（ mDL ）の文書に対する証明書署名要求（ CSR ）の署名に使用されます。 以下のコマンドを使用して非対称キーを作成します： aws kms create-key \ --region us-west-1 \ --key-spec ECC_NIST_P256 \ --key-usage SIGN_VERIFY コマンドを実行すると、以下のような出力が得られます： { "KeyMetadata": { "AWSAccountId": "123412345678", "KeyId": "3ab87971-1fe2-45d9-955a-5dc7f65558zf", "Arn": "arn:aws:kms:us-west-1:123412345678:key/3ab87971-1fe2-45d8-955c-5dc7f65558ef", "CreationDate": "2024-05-18T19:53:27.318000 + 00:00", "Enabled": true, "Description": "", "KeyUsage": "SIGN_VERIFY", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "ECC_NIST_P256", "KeySpec": "ECC_NIST_P256", "SigningAlgorithms": [ "ECDSA_SHA_256" ], "MultiRegion": false } } 出力から Arn の値をメモしてください。ステップ 7 で、mDL 文書署名用証明書の CSR 作成ユーティリティを構成する際に使用します。 ステップ 7: CSR 作成ユーティリティを使用した文書署名用証明書の CSR の生成 AWS の非対称キーで署名された CSR を作成するサンプルユーティリティを GitHub で公開しました。 GitHub リポジトリ をクローンし、リポジトリの README ファイルの指示に従って設定し、実行します。 このプログラムは、以下のような PEM 形式の CSR を出力します。 -----BEGIN CERTIFICATE REQUEST----- .. -----END CERTIFICATE REQUEST----- 出力をコピーし、 document-signing-kms.csr という名前のファイルに保存します。手順 8 で、この CSR に基づいて mDL 文書用の署名証明書を作成する際にこのファイルを使用します。 ステップ 8: mDL 文書署名用証明書の生成 このステップでは、AWS KMS の非対称キーを使用して署名された CSR から、 文書署名用証明書を発行します 。 以下の内容で extensionSigner.txt というファイルを作成します。このファイルの内容は、ISO/IEC 18013-5 の証明書プロファイルの節から派生しています。以下の JSON スニペットは、 DigitalSignature フィールドが true に設定された KeyUsage 拡張を含む拡張機能の構造を示しています。 { "Extensions": { "KeyUsage": { "DigitalSignature": true }, "ExtendedKeyUsage": [ { "ExtendedKeyUsageObjectIdentifier": "1.0.18013.5.1.2" } ] } } 以下の AWS CLI コマンドを使用して証明書を作成します。 aws acm-pca issue-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --template-arn "arn:aws:acm-pca:::template/BlankEndEntityCertificate_APIPassthrough/V1" \ --signing-algorithm "SHA256WITHECDSA" \ --csr fileb://document-signing-kms.csr \ --validity Value=1825,Type="DAYS" \ --api-passthrough file://extensionSigner.txt 出力： { "CertificateArn": "arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba" } 出力から CertificateArn を使用して、モバイル運転免許証（ mDL ）文書署名用証明書を取得します。 ステップ 9: mDL 文書署名用証明書の取得 このステップでは、AWS Private CA から PEM 形式の文書署名用証明書を取得します。 次のコマンドで文書署名用証明書を取得します： aws acm-pca get-certificate \ --region us-west-1 \ --certificate-authority-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113 \ --certificate-arn arn:aws:acm-pca:us-west-1:123412345678:certificate-authority/0116z123-dv7a-59b1-x7be-1231v7257113/certificate/d462fcd3b9h3beb45c7c312241d42fba \ --output text コマンドの出力を document_signing_cert.pem に保存します。 ISO/IEC 18013-5 で要求される Concise Binary Object Representation (CBOR) を用いて後ほどパッケージ化するために利用する mDL 文書署名用証明書を得ることができました。 ステップ 10: mDL リーダーによる発行機関の mDL 署名証明書チェーンの取り込み mDL リーダーは、ユーザーが提示した mDL を暗号学的に検証した後、その mDL を信頼することができます。この検証には、リーダーがユーザーに mDL を発行した発行機関の mDL 署名証明書チェーンを保持している必要があります。ISO/IEC 18013-5 で規定されている分散型公開鍵基盤 (PKI) 信頼モデルで要求されているように、mDL リーダーは発行機関の mDL 署名証明書チェーンを取得する必要があります。 ステップ 11: ユーザーによる発行機関への mDL 署名リクエスト ユーザーは発行機関に mDL への署名を要求します。 ステップ 12: 発行機関によるユーザーへの署名済み mDL の発行 発行機関はユーザーの身元を認証し、署名された mDL を発行します。発行機関は、モバイルセキュリティオブジェクト (MSO) として知られる CBOR エンコードされたオブジェクトとともに、mDL データをユーザーのデバイスに提供します。MSO には、ダイジェストアルゴリズム、個々の mDL データ要素のダイジェスト、および有効期間が含まれています。この MSO が ISO/IEC 18013-5:2021 のセクション 9.1.2.4 で要求されるように生成およびエンコードされた後、発行機関によって MSO に署名することができます。この署名は、以下のコマンドに示すように AWS KMS で生成できます。エンコードされた MSO の生成については、このブログでは扱いません。 sha256sum ユーティリティを使用して、エンコードされた MSO オブジェクトの SHA-256 ダイジェストを生成するには、次のコマンドを使用します。 sha256sum < EncodedMSO > EncodedMSODigest ステップ 6 で作成した AWS KMS の非対称キーを使用してダイジェストに署名します。 aws kms sign \ --region us-west-1 \ --key-id 3ab87971-1fe2-45d8-955c-5dc7f65558ef \ --message fileb://EncodedMSODigest \ --message-type DIGEST \ --signing-algorithm ECDSA_SHA_256 \ --output text \ --query Signature | base64 --decode この署名は、発行機関の証明書と MSO と組み合わされて、 CBOR Object Signing and Encryption (COSE) の署名付きメッセージを形成し、mDL データ要素とともにリーダーに提示されます。リーダーはこの署名を検証して、MSO の完全性を確認できます。 ステップ 13: ユーザーによる mDL リーダーへの mDL の提示 ユーザーは、空港などで本人確認のために mDL を mDL リーダーに提示します。このプロセスは、ISO/IEC 18013-5:2021 の 6.3.2.2 項で mDL 初期化と呼ばれています。mDL は、この初期化ステップでアクティブ化されます。 ステップ 14: mDL リーダーによるユーザーのモバイルデバイスからの mDL データのリクエスト mDL リーダーは、ユーザーのモバイルデバイスに mDL 取得リクエストを発行します。mDL の重要な特徴は、mDL 所有者が個人識別情報（ PII ）の一部を提示できることです。mDL リーダーは、氏名や生年月日などの特定の属性を要求し、mDL 所有者はこの情報の開示に同意する必要があります。mDL リーダーのリクエストには、mDL 所有者に共有を求める個人識別情報の項目リストが含まれています。 ステップ 15: ユーザーによる mDL データ共有の同意 ユーザーは、mDL 共有リクエストを通知するメッセージを受け取ります。このメッセージには、リクエストされている個人識別情報（ PII ）の項目リストが表示されます。ユーザーがリクエストに同意すると、MSO を含む mDL データがリーダーと共有されます。 ステップ 16: リーダーによる mDL の整合性の検証 リーダーは mDL データを受信し、その完全性を検証します。mDL データ要素に MSO を含めることで、mDL リーダーは受信したデータの完全性を検証するメカニズムを得られます。mDL リーダーは、デバイスから提示された個々の mDL データ要素をハッシュ化して検証できます。すべてのデータ要素が MSO の対応するエントリと一致する場合、mDL リーダーはデータが改ざんされていないことを確認できます。 例として、mDL に以下のデータ要素が含まれていると仮定します： 24(<< { "digestID": 0, "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1', "elementIdentifer": "given_name", "elementValue": "John" } >>), 24(<< { "digestID": 1, "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368', "elementIdentifer": "family_name", "elementValue": "Doe" } >>) さらに、データ要素のダイジェストを格納するモバイル セキュリティ オブジェクトはこちらです。 24(<< { "version": "1.0", "digestAlgorithm": "SHA-256", "valueDigests": { "org.iso.18013.5.1": { 0: h'D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E', 1: h'4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5' } } } >>) MSO の整合性チェックでは、まず MSO の有効期間 (図示されていません) が期限切れでないことを確認します。次に、発行機関の公開鍵を使用して署名 (図示されていません) を検証します。これらの確認が完了した後、各データ要素を検証する必要があります。各要素 ( digestID 、 random 、 elementIdentifier 、 elementValue ) の CBOR 表現はバイト列としてエンコードされ、SHA-256 を使用してハッシュ化されます。例えば、以下は D6AA81E454036313A9A681809151DDDBDF702289094F18286DDC591C41C6434E と等しくなるはずです。 SHA256(CBOR byte representation of 24(<< { "digestID": 0, "random": h'BBA394B98088CAE238D35979F7210E18DFAF70354524D86149CA20046E4321B1', "elementIdentifer": "given_name", "elementValue": "John" } >>)) ) 同様に、次の例は 4C3D83940CA8C5DE8060A23EB649C175E79B745B6A7D9939B4D16B3E46BB14D5 と等しくなるはずです。 SHA256(CBOR byte representation of 24(<< { "digestID": 1, "random": h'901F63FD880A15B30EDCEEFA857201C52FB9EAD1D39C15BB592829D16CB8A368', "elementIdentifer": "family_name", "elementValue": "Doe" } >>)) ) すべてのデータ要素がこのハッシュ検証チェックに合格すれば、mDL リーダーは提示された mDL の内容を信頼できるものとして扱うことができます。 まとめ このソリューションでご覧いただいたように、モバイル運転免許証 (mDL) は、個人のプライバシーを保護するために、セキュリティの向上と柔軟な同意管理を提供します。暗号化による署名と検証の原理は新しいものではなく、AWS KMS と AWS Private CA はどちらも、運転免許証やその他の種類の身分証明書など、デジタル ID アプリケーションのサポートに適しています。AWS KMS の非対称鍵と AWS Private CA の詳細については、 AWS KMS の非対称鍵機能を使用したデジタル署名 と AWS で完全なプライベート証明書インフラストラクチャをホストおよび管理する方法 をご覧ください。 本ブログに関するフィードバックがある場合は、以下のコメント欄にコメントを投稿してください。このブログに関する質問がある場合は、 AWS re:Post (AWS Certificate Manager) および AWS re:Post (AWS KMS) で新しいスレッドを立てるか、 AWS サポートにお問い合わせ ください。 Ram Ramani: Ram は AWS のプリンシパルセキュリティアーキテクトで、データ保護とプライバシーの重点分野をリードする責任を担っています。この役職以前は、様々な組織でソフトウェア開発者として応用数学と機械学習に焦点を当てて活動していました。 Raj Jain: Raj は Amazon FinTech 組織のシニアソフトウェアエンジニアで、AWS およびより広範な Amazon インフラストラクチャの基盤となるセキュリティとコンプライアンスサービスの開発を担当しています。Raj は Bell Labs Technical Journal に論文を発表し、IETF 標準の著者であり、AWS セキュリティブログを執筆し、12 件の特許を保有しています。 Kyle Schultheiss: Kyle は AWS Cryptography チームのシニアソフトウェアエンジニアです。2018 年の立ち上げ以来、AWS Private CA サービスに取り組んでいます。以前の役割では、Amazon Virtual Private Cloud、Amazon EC2、Amazon Route 53 などの他の AWS サービスにも貢献しました。 本ブログは Security Solutions Architect の 中島 章博が翻訳しました

VMware 仮想環境のモダナイゼーションに取り組む際には、信頼性が高くコスト効率の良いデータ保護が重要になります。一般にデータ保護ソリューションを評価する際には、ソフトウェア、ストレージ、運用にかかる複雑なコスト計算が必要でした。 AWS が提供する AWS Backup はそれらの課題を解決し、よりシンプルなデータ保護の選択肢を提供します。 AWS Backup は、ソフトウェアのライセンス費用を前払いする必要のない従量課金でポリシー型のマネージドサービスであり、データ保護にかかるコストをシンプル化します。 加えて、AWS Backup には VMware 仮想マシン（VM）を Amazon Elastic Compute Cloud （EC2） インスタンスとして直接リストアする機能も備えているため、ミッションクリティカルなデータ保護と同時に AWS へのシームレスな移行、将来的なクラウドネイティブ化にも役立ちます。 本記事では、オンプレミスまたはクラウドベースの VMware 仮想環境を運用している方々を主な対象に、AWS Backup の実利用コストを見積もるための有用なヒントを提供します。 AWS Backup 利用料金を理解する AWS Backup の基本となる利用料金は、下記のようにシンプルです。 「バックアップデータが消費するストレージ領域の量 (月平均 GB)」 × 「単価（$/GB）」 しかし、VMware VM を AWS Backup でバックアップする場合、「バックアップデータが消費するストレージ領域の量」は、対象 VM、データタイプ、フォーマットによって異なる場合があります。 例えば、とあるバックアップ対象 VM には 90 GB のディスク割り当てたものの、オペレーティングシステム（OS）は 10 GB のストレージ利用だけを認識しており、一方 VMware vSphere からは 20 GB の物理ストレージが実際に消費されているケースを想像してみましょう。考慮すべきパラメーターは複数ありそうです。 結論からお伝えすると、AWS Backup のバックアップデータが消費するストレージは、割り当てられたデータと削除されたデータの両方を含むディスク使用量に等しくなります。これは通常、VM の割り当てられたサイズよりも小さくなり、VM の OS レベルの使用量よりも大きくなります。また、AWS Backup サービスコンソールに表示されるバックアップサイズは「バックアップデータが消費するストレージ領域の量」を表していません。代わりに、VMware 仮想環境で割り当てられた (プロビジョニングされた) ディスクサイズを反映しています。 本記事では、AWS Backup を使用して VMware 仮想環境の VM をバックアップした際の 1 ヶ月間の利用料金から逆算することで、「バックアップデータが消費するストレージ領域」を確かめていきます。 VMware 仮想環境と AWS マネジメントコンソール の双方において ストレージ容量は GB として表記されますが、実際には GiB（ギビバイト）を示している ことに注意してください。AWS Backup もバックアップストレージ、リストア、データ転送の価格計算に GiB（ギビバイト）を単位として使用していることに注意してください。 参考までに、「1 GB = 1,000³ bytes」、「1 GiB = 1,024³ bytes」です。 前提条件 今回のテストは以下の条件で実施しています。 VMware 仮想環境について 次の表は、本テストで使用した VMware 仮想環境の構成をまとめています。 VMware vSphere バージョン 8.0 ホストサーバー Amazon EC2 i3.metal * 1 台 リージョン N.Virginia 備考 VMware 仮想環境として VMware Cloud on AWS を使用 作成する VM はすべてシンプロビジョニング バックアップ対象の Windows VM について 次の表は、AWS Backup を使用してイメージバックアップを取得した Windows VM の情報をまとめています。 OS Windows Server 2019 VM ハードウェアバージョン 19 割り当てディスク容量 (C ドライブのみ) 90 GiB VMware vSphere によって認識されたストレージ使用量 19.66 GiB 備考 対象 VM はシンプロビジョニングとして作成 C ドライブには約 10 GiB の追加ファイル（主に ISO ファイル）を保存 バックアップ中、対象 VM の電源はオフ 図 1 は、AWS Backup でバックアップする Windows VM が vSphere からどのように認識されているかを示しています。 　　　　　　　　　　　　　　　図 1. バックアップ対象の Windows VM 図 2 は、Windows OS レイヤでは割り当てディスクが 90 GiB であると認識していることを示しています。 96,630,589,440 bytes は約 90 GiB となります。 　　　　　　　　　　　　　　　図 2. Windows OS によって認識される割り当てられたディスクのサイズ AWS Backup について 次の表は、対象 Windows VM のイメージバックアップを初めて取得した際の AWS Backup の情報をまとめています。 バックアップ作成日 2023 年 11 月 18 日 バックアップ保持期間 2023 年 11 月 18 日 – 2024 年 1 月 20 日 ストレージ層 ウォーム (Warm) リージョン N.Virginia 備考 AWS Backup の利用コストは、対象 Windows VM の初回イメージバックアップのみを対象とする バックアップ保持期間中に増分バックアップ、追加バックアップ、またはコールドストレージへの移行は実施していない 図 3 は、AWS マネジメントコンソールから AWS Backup の取得バックアップ情報を示しています。 コンソール中ではストレージ容量は GB として表示されますが、実際には GiB（ギビバイト）を表しています。 　　　　　　　　　　　　　　　図 3. AWS マネジメントコンソールにおける AWS Backup の情報 以下は、 AWS CloudShell で AWS Command Line Interface (CLI) を実行して取得した詳細な値です。 　　　　　　　　　　　　　　　図 4：AWS CLI から取得した AWS Backup の詳細情報 図 4 では、「BackupSizeInBytes」は AWS Backup によって認識されているバックアップサイズを表しています。この情報によると AWS Backup によって認識されるバックアップサイズは 90 GiB となっています。 「96,636,764,160 bytes = 90 GiB」です。ただし、この値は AWS Backup でバックアップデータによって実際に消費されるストレージ容量を表していません。 実際に課金された AWS Backup 利用コスト 2023 年 12 月 1 日から 2023 年 12 月 31 日までの 1 ヶ月間（31 日間）の AWS Backup 利用料金は 0.95 ドルでした。これを 2023 年 12 月時点での N.Virginia AWS リージョン の AWS Backup ウォームストレージの単価 0.05 ドル /GiB で除算して、AWS Backup が課金したストレージ使用量を逆算します。計算結果は以下のようになります。図 5 でハイライトします。 AWS Backup が課金したストレージ使用量 0.95 （USD） ÷ 0.05 （USD/GiB） = 19.0 （GiB） 　　　　　　　　　　　　　　　図 5. 実際に課金された AWS Backup 利用料金 図 6 で示す通り、2023 年 11 月 18 日以前にはバックアップを実施していないため利用料金は発生していません。 　　　　　　　　　　　　　　　図 6. テスト以前の AWS Backup 利用料金 最後に、関連する値を以下の表にまとめます。 対象 VM に割り当てられたディスク容量（シンプロビジョニング） VMware vSphere が認識する使用済みストレージ容量 AWS CLI から取得したバックアップサイズ 課金された AWS Backup のストレージ消費量 90 GiB 19.66 GiB 90 GiB 19.0 GiB 上表のとおり、このテストケースにおいては AWS Backupによって保存および課金されたデータ量は VMware vSphereから確認できた実際のストレージ使用量とほぼ同じであることがわかります。 テストケースの確認結果 このテストケースが示すように、VMware VM のバックアップに対して AWS Backup が課金したデータ量は、対象 VM の論理的な割り当て容量（90 GiB）ではなく、VMware vSphere によって認識されるストレージ使用量（19.66 GiB）とほぼ同じサイズ（19.0 GiB）でした。実際の VMware VM が VMDK ファイルであることを考慮すると、AWS Backup が課金するストレージ消費量は VMware vSphere が認識する使用済みストレージ容量と同等になります。 AWS Backup は保存されたバックアップデータを圧縮あるいは重複排除しません。 これを念頭に入れると、AWS Backup が課金するストレージ消費量は、VMware vSphere が認識する使用済みストレージ容量にほぼ一致することが理解できます。 念のため Linux VM でも追加のテストを行いましたが、結果は同様でした。シンプロビジョニング構成の VMware 仮想環境では、AWS Backup で課金されるストレージ消費量は、対象 VM に割り当てられたディスク容量ではなく、実際の使用済みストレージに等しくなります。 まとめ 本記事では、VMware 仮想環境における AWS Backup の利用料金に影響を与える主要な要素である バックアップストレージについてガイドしました。AWS Backup 利用料金のコア部分を理解することで、AWS Backup の予算をより正確に見積もることができます。 実際のバックアップコストは個々の使用パターンや要件に依存します。データ量、データ変更率、バックアップ頻度、保持期間など複数の要因も最終的な利用料金に影響を与えます。それらを踏まえつつも、今回ご紹介したガイドを AWS Backup の利用コストを予測するための出発点としてご活用ください。 参考情報 AWS Backup の料金 AWS Backup の VMware サポート AWS Backup が Amazon EC2 への VMware ワークロードの復元をサポート開始 AWS Backup でバックアップした VMware 仮想マシンを Amazon EC2 としてリストアする AWS Backup と VMware Cloud on AWS を活用した VMware ワークロードのデータ保護シンプル化 著者について 武田 紘一 VMware ワークロードのスペシャリストソリューションアーキテクトです。AWS への入社以前は通信業界と製造業界でインフラエンジニアおよびプロジェクトリーダーとして、VMware ならびにクラウドサービス技術に関する専門知識を活かしてきました。2022 年からは VMware vExpert として VMware User Group （VMUG） にも参画しています。 原文は こちら です。

この投稿はネットアップ合同会社 瀧山 毅 氏、松田 紘典 氏にサイバーレジリエンスにおけるデータリストアの解説と AWS における実装ポイントについて寄稿いただいたものです。 同シリーズの第 1 回「 サイバーレジリエンスとはなにか？ 」、第 2 回「 Amazon FSx for NetApp ONTAP イミュータブルバックアップの利用でランサムウェア対策の強化 」も併せてご覧ください。 こちらは、サイバーレジリエンスブログシリーズの第 3 回です。今回まで組織にとって重要な資産「データ」の観点から、サイバーレジリエンスの基本を解説してきました。 シリーズの最終回となる今回は、「バックアップとリストアの重要性」と「ランサムウェア被害を想定したリストアシナリオ」についてご紹介します。 今取得しているバックアップ大丈夫ですか？ ランサムウェアの被害が年々拡大および複雑化する中、バックアップの取得はランサムウェア対策の手段の 1 つとして現在多くの人に認知されています。NetApp はデータを蓄積・保護するストレージを扱う企業としてバックアップの重要性を理解しているため、たびたび  ”今取得しているバックアップ大丈夫ですか？” とお客様に聞くことがあります。その中で ”うちは問題なく取得できているはず” 、”どこどこのバックアップソフトを使用しているので大丈夫” という風に回答いただくことがありました。 併せて取得したバックアップのリストア実績について尋ねると ”ファイルレベルではあるけど、大規模な形での復元はない” 、”バックアップ成功しているってログがあるから特に気にしていない” という回答も少なからず聞く機会がありました。このようなコメントをいただいた中、今取得しているバックアップが有事の際に本当に使えると胸を張って言える企業が何社いるのだろうかという疑問を感じることがあります。 実際に警察庁が広報資料としてまとめている ”令和５年におけるサイバー空間をめぐる脅威の情勢等について” にてランサムウェア被害企業・団体のバックアップ取得・活動状況がレポートされており、バックアップ取得の有無に関しては有効回答数 140 件中 ８ 件 (6%) が取得していない状況で、リストアに関しては 126 件中被害直前の水準まで復元できた企業・団体が 21 件 (17％) のみで 105 件 (83％) の企業・団体が被害直前の水準まで復元できなかったという結果になっています。 図 1: バックアップの取得・活用状況 *1 (*1) 警視庁Webサイト,“令和５年におけるサイバー空間をめぐる脅威の情勢等について”, https://www.npa.go.jp/publications/statistics/cybersecurity/data/R5/R05_cyber_jousei.pdf, (2024/08/20 閲覧) レポートのようにファイルが元の水準で復元できず、そのためシステムや業務を長期間停止せざるを得ない事態になった場合、後日多くの労力とお金を費やしてシステムの改善等する必要に迫られると推測されます。このようなことを避けるため一度バックアップに求められる要素について考えてみたいと思います。 バックアップに求められる要素って何だろうか？ よく情報セキュリティで聞かれる項目として機密性 (Confidentiality)、完全性 (Integrity)、可用性  (Availability) がありますが、バックアップをこの項目に当てはめてざっくりと考えると以下のような内容になると考えています。 機密性:バックアップデータの改ざん/削除防止がされていること 完全性:データを完全な状態に復元可能な状態であること 可用性:どこから／どこにでも復元可能な状態であること 上記の項目を考慮して具体的にランサムウェア対策としてのバックアップに必要な要素としては以下のようなことが挙げられると思います。 RPO を顧慮した細かいバックアップの取得（可用性） 3-2-1 ルールを考慮したバックアップ（可用性） バックアップデータの保護/改ざん防止対策（機密性） 業務可能な状態でのデータ復旧のためのプロセス策定（完全性） 可用性と機密性に関してはバックアップの方式や取得方法のため、バックアップ取得後の完全性を考慮したデータ復旧にフォーカスしたお話をしたいと思います。完全性を考慮したバックアップを実施するということは “バックアップ成功しました。はい、終わり。” ではなく、取得したバックアップデータが業務に耐えうる水準でリストアできるかを確認するまでを実施することが理想であり、ランサムウェア攻撃等の有事に備えた有効な復旧プロセスの確立も含めて考慮する必要があります。ただし確認のため策定した復旧プロセスを経てリストアテストを実施するということになると、システムの規模によりますがリストアのためのストレージの空き容量や既存システムへの影響度合いも考慮する必要があるため簡単且つ定期的に実施できないというのが現状となります。 前置きは長くなりましたが、実は Amazon FSx for NetApp ONTAP (以降 FSx for ONTAP と記載します) 環境ですと簡単に復旧プロセスを含めたリストアテストが実施できます。 ※もちろんオンプレミスの ONTAP も同様に可能です。 次に FSx for ONTAP 環境でどのようにして簡単にリストアテストが実行できるか理由を記載します。 なぜ Amazon FSx for NetApp ONTAP ではリストアが簡単なのか サービス利用者が FSx for ONTAP に保管したデータについて、NetApp ONTAP のファイルシステム内では、データの保存場所を示すポインタ情報とデータブロックに分けて管理しています。Snapshot 作成を実行すると、前回作成した Snapshot とポインタ情報を比較し、ポインタ情報の更新部分を Snapshot 差分量として扱うことで、データブロックを動かさず Snapshot を作成することができます。この動作はリストアを行う際にも利用しており、データブロックを動かさないためバックアップデータを高速にリストアやクローンすることが可能となっています。 一般的なリストアテストでは、Snapshot をテスト領域にリストアしファイルが復旧するか確認するかと思います。リストアテストしたいデータが例えば 100TB 存在する場合、どのような影響が考えられるでしょうか。100TB をコピーする時間やコピー中ストレージにかかる負荷が本番サービスに影響を与えないか確認する必要があり、データ量が多ければ多いほどリストアテストを実施することが難しくなっていきます。NetApp ONTAP のファイルシステムでデータ管理を行なっている場合は、データブロックとポインタ情報を賢く扱うため、バックアップ・リストア・クローンが簡単に行えるようになります。 完全性を持ったバックアップを取得する方法については、関連する記事「 Amazon FSx for NetApp ONTAPイミュータブルバックアップの利用でランサムウェア対策の強化 」にて、改ざんできないバックアップ (Tamperproof Snapshot) 機能を紹介しています。 ランサムウェア攻撃を受けた際のデータリストアシナリオ ランサムウェア攻撃を受けファイルサーバ内のデータが改ざんされてしまった場合、どのような復旧操作が必要となるでしょうか。被害のないバックアップデータからリストアする操作を行いますが、被害を受けたファイルサーバはどのような攻撃を受けたか調査を行う必要があるため上書きリストアすることはできません。 この状況下でファイルサーバを復旧するには、バックアップデータを新たな領域にコピーし復旧する操作が必要となってきます。NetApp ONTAP では Snapshot から高速でボリュームを複製する FlexClone 機能があります。 この FlexClone 機能を使いデータリストアテストを行ってみましょう。 Amazon FSx for NetApp ONTAP にてデータリストアテスト 攻撃を受けファイルが改ざんされた共有データ data2 があります。 図 2: クライアントのエクスプローラーでの共有データ data2 の確認 FSx for ONTAP ファイルシステムの管理エンドポイントに ssh でログインします。取得済みの Snapshot 一覧を表示し被害を受ける前の Snapshot データがあることを確認します。 ::> snapshot show 図 3: Snapshot の確認 data2 の Snapshot を指定し FlexClone を data3 として作成します。 ::> volume clone create -flexclone <Clone Volume Name> -type RW -parent-vserver <SVM Name> -parent -volume <Origin Volume Name> -parent-snapshot <Snapshot Name> -junction-active ture -junction-path /<junction-path> 図 4: volume clone の作成 data3 を参照すると改ざんされる前のファイルがリストアできていることが確認できます。 図 5: クライアントのエクスプローラーでの共有データ data2 のリストア確認 復旧した data3 を恒久的に利用する場合は親ボリュームと切り離し (split) 通常のボリュームにすることができます。Split 操作を行う場合、Split 操作にて追加で必要となる容量を確認します。 ::> volume clone show -estimate -vserver <SVM Name> flexclone <Clone Volume Name> 図 6: volume clone の確認 FSx for ONTAP の空き容量を確認します。 ::> storage aggregate show 図 7: FSx for ONTAP のファイルシステム容量の確認 ボリュームを Split します。 ::> volume clone split start -flexclone <Clone Volume Name> 図 8: volume の split の設定 リストアテストが終了し、複製したデータが不要となった場合は以下の手順でクリーンナップすることができます。テストで使用した data3 ボリュームをオフラインにし、ボリュームを削除します。 ::> volume offline <Clone Volume Name> ::> volume delete <Clone Volume Name> ::> volume show 図 9: volume のオフライン作業、削除、削除されたことの確認 まとめ バックアップはランサムウェア攻撃を含む多くの有事に対する最後のかなめとして重要な位置づけにある中、意外とユーザが望む水準の状態まで復元できなかった企業が多いことがわかりました。NetApp としてはバックアップに関し一つ踏み込んだ形で、定期的にリストアまでのプロセスを含んだ一連の流れを実施することを推奨しています。その中で FSx for ONTAP 環境で出来るバックアップ・リストアについて Snapshot/FlexClone で実施する方法をご紹介させていただきました。 定期的に防災訓練のようにデータ復旧の一連の流れを実施することにより、バックアップの質のみならず有事の際の対応も早くなりランサムウェア攻撃等の被害を最小限にすることが可能と考えておりますのでぜひ実践下さい。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 AWSでは日本のお客様向けに「 日本の生成AI活用を支援 」というポータルサイトを設けています。週刊生成AI with AWSのブログシリーズはその週のニュースをサクッと確認していただくことを目指して書いていますが、こちらのポータルサイトは生成AIに取り組む際に有益な情報を集約しています。コンテンツを随時拡充していますので、ぜひチェックしてみてください。 先週、イベントを企画していますということを書きましたが、その第一弾のWebサイトが公開されました。「 AWS AI Day 」というイベントで、10/31に対面形式となります。生成AIの最新動向やユースケースを学べるようにコンテンツをくんでいますので、みなさんのご参加をお待ちしています。また、「 AWSジャパン生成AI実用化推進プログラム 」も引き続き参加者募集中です。こちらのほうも、よろしくお願いいたします。 それでは、9 月 2 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: KDDIアジャイル開発センター様、生成AIによる営業活動サポートの効果を確認 KDDIアジャイル開発センター株式会社 様は、生成AIを活用した社内外の課題解決に取り組んでいます。その取り組みのひとつが営業支援プロダクト「議事録パックン」です。営業活動を通じた知見の集積には、個々人の日報が重要です。ですが日報作成の時間確保や、その情報を有効活用する仕組みが上手くいっていないという課題がありました。これを解決するためにAmazon Bedrockを活用し、会議の録画・録音データや書き起こしテキストから、議事録を出力しそれに基づいて顧客に対する提案の骨子を出力する仕組みを構築しました。これによって議事録と提案書の作成時間を1時間短縮するという効果を確認しています。 ブログ記事「IBC2024でのAWSの見どころは生成AIとクラウドの進歩」を公開 年に一度開催されるIBC(International Broadcasting Convention)にむけて、AWSは生成AIからクラウドを利用したライブ制作ソリューションまで、メディア&エンターテインメント業界向けの最新技術をご紹介する準備を進めており、この記事ではその見どころをダイジェスト形式で紹介しています。 サービスアップデート Amazon BedrockでStability AIの画像生成モデル3種が利用可能に Amazon Bedrockで、Stability AIが提供する最新の画像生成モデル(テキストから画像を生成するモデル)がご利用頂けるようになりました。今回利用可能になったのは、Stable Image Ultra, Stable Diffusion 3 Large, Stable Image Coreの3種類です。それぞれのモデルは生成される画像の品質と生成スピードのバランスが異なっており、用途に応じたものを選択頂けるようになっています。 ブログ記事 や 製品webページ もご覧ください。現時点ではオレゴンリージョンでご利用頂けます。 Agents for Amazon BedrockがAnthropicのClaude 3.5 Sonnetをサポート 組織内に蓄えられた情報を利用したり、複雑なステップを要するタスクを実行する生成AIアプリケーションの開発を容易にするAgents for Amazon BedrockがAnthropic Claude 3.5 Sonnetをサポートしました。この機能は東京リージョンでもご利用頂けます。 Amazon SageMakerのオブジェクト指向SDK、sagemaker-coreを発表 Amazon SageMakerの操作を容易にするPython向けSDK、sagemaker-coreを発表しました。sagemaker-coreはリソースオブジェクトをパラメータとして渡すことができ、複雑なパラメータを手動で指定する手間を削減します。またリソースの状態やポーリングロジックなどを抽象化する仕組みをもっており、開発者がよりモデルの構築・デプロイに集中できるようになっています。 ドキュメント はこちらです。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

Gartner は 2024 年 8 月 19 日に、 Amazon Web Services (AWS) が含まれる Gartner 初の Magic Quadrant for AI Code Assistants を公開しました。 Amazon Q Developer は、2024 年 4 月 30 日に 一般提供 が開始されたことから審査対象要件を満たしており、AWS はその実行能力とビジョンの完全性からリーダーとしてランク付けされました。 私たちは、このリーダーとしての位置付けが、エンタープライズグレードのアクセスコントロールとセキュリティを用いてソフトウェア開発ライフサイクル全体を容易にし、開発者の生産性を向上させる、AWS の 急ペースのイノベーション を反映していると考えています。 Gartner のマジッククアドラントは、実行能力とビジョンの完全性に基づいて 12 の AI コードアシスタントを評価しています。Gartner の「 How Markets and Vendors Are Evaluated in Gartner Magic Quadrants 」レポートによると、実行能力は製品とサービスを効果的に提供するベンダーの能力を測定し、ビジョンの完全性はベンダーによる市場の理解と将来的な成長に向けた戦略を評価するものです。 以下は、2024 年 Gartner Magic Quadrant for AI Code Assistants のグラフです。 以下は、Gartner のレポートからの引用です。 Amazon Web Services (AWS) は、本マジッククアドラントのリーダーです。その製品である Amazon Q Developer (旧 CodeWhisperer) は、AI を使用して開発者のタスクを支援し、自動化することに重点を置いています。例えば、Amazon Q Developer はコードの提案と変換、テストとセキュリティ、および機能開発を支援します。その運用は地理的多様性を備え、あらゆる規模のクライアントを対象としています。AWS は、ソフトウェア開発ライフサイクル (SDLC) を強化する AI 主導型ソリューションの提供、複雑なタスクの自動化、パフォーマンスの最適化、セキュリティの確保、およびイノベーションの促進を重視しています。 私のチームは、 Amazon Q Developer Center と Community.aws で、ソフトウェア開発者のジョブ理論 (Jobs-To-Be-Done) を直接サポートし、生成 AI によって実現および強化される、Amazon Q Developer 関連のコンテンツを作成することに焦点を当てています。 私は、お客様と会話して、Amazon Q Developer を選ぶ理由をたずねる機会を得ました。お客様は、コーディング、テスト、アップグレードから、トラブルシューティング、セキュリティスキャンと修正の実行、AWS リソースの最適化、そしてデータエンジニアリングパイプラインの作成におよぶ、一般的な AI コードアシスタントをはるかに超えた SDLC 全体でのタスクの加速と完了に利用できることだと答えています。 以下は、お客様がより頻繁に言及した重要点です。 必要に応じてどこからでも利用可能 – Amazon Q Developer は、 Visual Studio Code 、 JetBrains IDEs 、 AWS Toolkit with Amazon Q 、 JupyterLab 、 Amazon EMR Studio 、 Amazon SageMaker Studio 、または AWS Glue Studio などの任意の統合開発環境 (IDE) で使用できます。Amazon Q Developer は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS ドキュメント 、 AWS サポート 、 AWS コンソールモバイルアプリケーション 、 Amazon CodeCatalyst で使用したり、 AWS Chatbot が設定された Slack および Microsoft Teams 経由で使用したりすることもできます。Safe Software は、「Amazon Q は AWS が提供する多数のツールの活用方法をすべて理解しています。より多くの事柄を達成できるようになったため、私たちは自動化を他の AWS サービスに拡張し、Amazon Q を活用して、目標の実現に役立てることができるでしょう」と話しています。 詳細については、 Amazon Q Developer の機能 と Amazon Q Developer のお客様 をご覧ください。 コード推奨のカスタマイズ – 社内のコードベースに基づいたコード推奨を取得できます。Amazon Q Developer は、社内のライブラリ、API、ベストプラクティス、アーキテクチャパターンを認識させることによって、新しいコードベースへのオンボーディングを迅速化し、より関連性の高いインラインコード推奨とチャット応答 (プレビュー中) を生成します。組織の管理者は、社内のコードベースに Amazon Q Developer をセキュアに接続して、複数のカスタマイゼーションを作成できます。 National Australia Bank (NAB) によると、NAB はそのコーディング標準に合わせてカスタマイズされた、Amazon Q のカスタマイゼーション機能を使用する固有の提案を追加しました。カスタマイゼーションにより、NAB では受け入れ率が 60% 向上しています。詳細については、AWS ドキュメントの「 Customizing suggestions 」を参照してください。 Java アプリケーションのアップグレード – Amazon Q Developer Agent for Code Transformation は、レガシー Java アプリケーションをアップグレードして変換するプロセスを自動化します。 Amazon の社内調査 によると、Amazon は Amazon Q Developer による支援を使用して、何万もの本番環境アプリケーションを Java 8 または 11 から Java 17 に移行しました。これは、1,000 人を超える開発者の 4,500 年を超える開発作業時間の節約 (手動アップグレードと比較した場合) と、年間コスト削減額 2 億 6,000 万 USD に相当するパフォーマンス向上に値します。Windows からクロスプラットフォーム .NET への変換も間もなく開始される予定です! 詳細については、AWS ドキュメントの「 Upgrading language versions with the Amazon Q Developer Agent for code transformation 」を参照してください。 詳細については、 2024 年 Gartner Magic Quadrant for AI Code Assistants レポート 全文をお読みください。 – Channy 原文は こちら です。 Gartner Magic Quadrant for AI Code Assistants (アナリスト: Arun Batchu、Philip Walsh、Matt Brasier、Haritha Khandabattu)、2024 年 8 月 19 日。 Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価やその他認定を受けたベンダーのみを選択するようテクノロジーユーザーに勧告するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、商品性または特定目的適合性に関するいかなる保証も含め、この調査に関する明示黙示の如何を問わず、あらゆる保証の適用を排除します。 GARTNER は、Gartner の登録商標およびサービスマークです。Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。All rights reserved.

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 関東は、秋めいた日も増えたように感じますが皆さんの地域はいかがでしょうか？ この時期になるとre:Inventが楽しみな気持ちもありつつ、その前にもいくつかイベントが予定されています。 その一つが10月31日に開催されるAWS AI Dayです。本日からオンサイト参加の登録サイトがオープンしました。 “AWS のテクノロジーで加速する生成 AI のプロダクション活用”について学べる機会ですので、ぜひご活用ください。 2024年10月31日 14:00-18:00 – AWS AI DAY 〜AWS のテクノロジーで加速する生成 AI のプロダクション活用〜 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年8月12日週の主要なアップデート 9/2(月) 米国祝日のためこの日の発表はありませんでした。 9/3(火) Amazon DynamoDB announces support for Attribute-Based Access Control Amazon DynamoDBがテーブルとインデックスの属性ベースのアクセス制御(Attribute-Based Access Control, ABAC)をサポートしました。この機能ではタグを使用してアクセス権とポリシーを設定が可能です。AWS ID およびアクセス管理 (IAM) プリンシパルのタグが Amazon DynamoDB テーブルのタグと一致する場合、タグベースのアクセス条件を使用して特定のアクションを許可または拒否できます。タグベースの条件を柔軟に使用できるようになったため、組織構造に基づいてより詳細なアクセス権限を設定できるようになりました。この機能は米国東部 (オハイオ)、米国東部 (バージニア)、および米国西部 (北カリフォルニア) の3つのリージョンでリミテッドプレビューとして利用可能です。リミテッドプレビューへのアクセスリクエストは こちらのページ をご確認ください。 Introducing sagemaker-core: A New Object-Oriented SDK for Amazon SageMaker SageMakerのリソースを操作するための新しいオブジェクト指向インターフェイスを提供するPython SDKであるsagemaker-coreが発表されました。sagemaker-coreはSageMaker APIと完全に同等のソリューションとして、すべてのSageMakerの機能を直接操作、活用することが可能です。また、sagemaker-coreはリソースの状態遷移やポーリングロジックなどの低レベル操作を抽象化しており、開発者の認知負荷を低減して複雑なパラメーター構造の管理を最小限に操作可能にします。詳細については サンプルノートブック や ドキュメント をご確認ください。 Amazon EBS direct APIs now supports IPv6 in AWS PrivateLink AWS PrivateLink経由でVPCからAmazon EBS direct APIを呼び出す際に、EBS direct APIがIPv6をサポートしました。EBS direct APIはAPI経由でEBSのスタップショット作成や読み取りを行うことができるAPIです。今回の対応により、IPv6ベースのオンプレミス・アプリケーションとの統合が可能になり、IPv4とIPv6間のアドレス変換を処理するための高価なネットワーク機器が不要になります。このアップデートはEBS direct APIが利用可能なすべてのAWSリージョンで利用可能です。 AWS Glue now provides job queuing AWS Glueにジョブのキューが追加されました。これまでアカウントレベルのクォータやリミットを意識する必要がありましたが、今回のアップデートにより、クォータやリミットを監視し、Glueが自動的にジョブをキューに入れ、再試行するようになります。これによりオペレーションが簡略化されます。この機能はマネジメントコンソールまたは API/CLI を使用して有効化が可能です。詳細については ドキュメント や ブログ をご確認ください。 AWS Network Load Balancer now supports configurable TCP idle timeout AWS Network Load Balancer (NLB)のTCPアイドルタイムアウトはこれまで350秒の固定値でしたが、60〜6000秒の値を柔軟に設定できるようになりました。これによりデータベースやERPなど存続時間の長いフローを使用するアプリケーションでの利用時に起きるトラフィックフローの中断を減らすことができます。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用可能です。詳細についてはこちらの ブログ もご確認ください。後述していますが、GWLBに関しても9/5に同様のアップデートがされています。 9/4(水) Bedrock Agents on Sonnet 3.5 生成AIと組み合わせた複雑なタスクの作成や社内のナレッジベースと連携したアプリケーションの作成を簡単に行えるAgents for Amazon Bedrockが、Claude 3.5 Sonnetに対応しました。東京、シンガポール、フランクフルト、オレゴン、バージニア北部の５つのリージョンで利用可能です。Bedrock Agentsについてや対応するモデル等の情報は ドキュメント をご確認ください。 Stability AI’s Top 3 Text-to-Image Models Now Available in Amazon Bedrock Stable Image Ultra, Stable Diffusion 3 Large (SD3 Large), and Stable Image Coreの３つのモデルが新たにAmazon Bedrockで一般提供されました。メディア、マーケティング、小売、ゲーム開発など、幅広い業種のお客様でこれまでにないスピードと精度で高品質のビジュアルを生成できるようになります。Stable Image Ultraは最高品質でフォトリアリスティックな出力、Stable Diffusion 3 Largeは生成速度と出力品質のバランス、Stable Image Core — 高速で手頃な価格の画像生成、に各々最適化されているいます。これらのモデルは、米国西部 (オレゴン) で利用可能です。 Use Apache Spark on Amazon EMR Serverless directly from Amazon Sagemaker Studio Amazon SageMaker Studio ノートブックから直接Amazon EMR サーバレスに接続できるようになりました。これによりEMR サーバレスで扱うペタバイト規模のデータにSpark SQL、Scala、Python を使用してインタラクティブにデータをクエリ、調査、視覚化したり、ノートブックからApache Spark ジョブを実行してデータを処理することができます。これらの機能は SageMaker ディストリビューション 1.10 以降で、SageMaker Studio が利用可能なすべてのAWSリージョンで利用可能です。詳細については、こちらの ブログ もご確認ください。 9/5(木) Announcing Storage Browser for Amazon S3 for your web applications (alpha release) Storage Browser for S3がアルファ版としてリリースされました。Storage Browser for S3はオープンソースのUIコンポーネントで、エンドユーザーがS3上のデータにアクセスするためのシンプルなインターフェースを提供します。リクエストを自動的に最適化して高スループットのデータ転送を実現する他、エンドユーザーのIDに基づくデータへのアクセス制御が可能です。現時点ではAWS Amplify JavaScript および React クライアントライブラリに対応しています。詳細は Github をご確認ください。 Amazon RDS Custom for SQL Server supports Cross-region Snapshot Copying Amazon RDS Custom for SQL Serverがスナップショットのクロスリージョンコピーに対応しました。これによりディザスターリカバリーを必要とするミッションクリティカルなサービスでもこれまでよりも簡単にAmazon RDS Custom for SQL Serverを活用いただくことが可能になります。この機能は、Amazon RDS Custom for SQL Serverが提供されているすべての商用 AWS リージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 AWS Gateway Load Balancer now supports configurable TCP idle timeout AWS Gateway Load Balancer (GWLB) のTCPアイドルタイムアウトはこれまで350秒の固定値でしたが、60〜6000秒の値を柔軟に設定できるようになりました。これによりデータベースやERPなど存続時間の長いフローを使用するアプリケーションでの利用時に起きるトラフィックフローの中断を減らすことができます。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用可能です。詳細はこちらの Blog もご確認ください。 Amazon WorkSpaces Pools now allows you to bring your Windows 10 or 11 licenses Amazon WorkSpaces プールがMicrosoft Windows 10及び11のBYOLに対応しました。これにより対象となる企業向けMicrosoft 365 Appsをサポートされるため、オンプレミスデスクトップと仮想デスクトップを切り替えた場合でも、一貫した体験が可能になります。このオプションを利用するには、マイクロソフトのライセンス要件を満たしている必要と、特定のAWS リージョンで毎月最低数の WorkSpacesの利用のコミットが必要です。詳細については「 AWS リージョン WorkSpaces プールの とアベイラビリティーゾーン 」とドキュメントの BYOLに関する項目 をご確認ください。 Amazon RDS for Oracle now supports OEM and OLS options with Multitenant configuration Amazon RDS for Oracleがマルチテナント設定でOracle エンタープライズマネージャー (OEM) と Oracle ラベルセキュリティ (OLS) オプションをサポートするようになりました。OEMは、Oracle インフラストラクチャを 1 つのコンソールから監視および管理できる機能で、OLSは個々のテーブルまたは行へのアクセスをきめ細かく制御するポリシーベースの管理機能です。各々、OEMの有効化に関してはこちらの ドキュメント を、OLSの有効化に関してはこちらの ドキュメント をご確認ください。 9/6(金) Amazon ECS now supports AWS Graviton-based Spot compute with AWS Fargate Amazon ECSでAWS Fargate Spotを利用時にAWS Gravitonを選択できるようになりました。AWS GravitonはAmazonが開発するARMベースのプロセッサで、Intel等他のCPU対比で電力効率やコストパフォーマンスが高いCPUです。これまでもFargateでGravitonを使うことは可能でしたが、Fargate SpotではIntel等他のCPUのみ利用可能だったためARM用にビルドしたコンテナでFargate spotを使うことはできませんでした。今回の対応によりARMベースのアプリケーションもFargate Spotで実行可能になり、中断や再開が許容できるアプリケーションはFargateと比較し最大70％割引でコンテナ実行が可能になります。この機能は、すべての商用リージョンと AWS GovCloud (米国) リージョンの AWS Fargate プラットフォームバージョン 1.4.0 以降で実行されている Amazon ECS タスクで利用可能です。詳細に関しては ドキュメント をご確認ください。 Amazon RDS Custom for SQL Server is now available in 3 additional AWS Regions Amazon RDS Custom for SQL Serverが大阪、パリ、北カリフォルニアの3つのリージョンで別時間になりました。Amazon RDS Custom for SQL Serverはマネージド型サービスでありつつ、通常のRDSでは操作できない特権アクセスを必要とする機能や設定変更に対応したサービスです。詳細については ドキュメント をご確認ください。 CloudWatch Application Signals now supports request based Service Level Objectives (SLOs) CloudWatch Application Signalsはメトリクス、トレース、ログのテレメトリとアプリケーションを関連づけ、可視化やSLOの管理を行うことができるサービスです。今回、CloudWatch Application SignalsがリクエストベースのSLOをサポートしました。例えば 200 ミリ秒未満のレイテンシーを満たすことをSLOとして定義する場合、リクエスト全体のうち満たしたリクエストの数を把握、監視が可能になります。詳細についてはこちらの ドキュメント をご確認ください。 それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

Sansan株式会社（以降 Sansan と記載）は、名刺や企業情報、営業履歴を一元管理して全社で共有できるようにすることで、売上拡大とコスト削減を同時に実現する営業 DX サービス「 Sansan 」を展開しています。その他にも、インボイス管理サービスとして「 Bill One 」を展開しており、郵送やメール添付などあらゆる形式の請求書をオンラインで受け取り可能にし、正確なデータ化を通じて請求書業務の DX を促進するサービスとなっています。 Sansan では、Bill One の認証基盤を「 Auth0 」で実現していましたが、プロダクト原価のコスト増につながっており、認証基盤を独自構築することで、費用削減を狙うプロジェクトが発足しました。認証基盤の構築プロジェクトは、6カ月という短期間で開発を完了しており、AWS 上で実現されたワークロードとなります。この認証基盤では、データベースサービスとして、 Aurora Serverless v2 を使用しています。本ブログでは、Aurora Serverless v2 を導入した効果について、お客様の声をご紹介します。 Aurora Serverless v2 の導入経緯 Sansan ではマネージドな DB が選択肢としてあがることが多く、Sansan の代表的な名刺アプリ「Eight」 では Aurora を使っています。他部署でもAuroraを利用しており、一度 Aurora Serverless v2 が検討の俎上にのぼったことはありましたが、コスト的な観点でプロビジョンドのAurora が選択されました。 今回開発した認証基盤の要件は以下の通りです。 Bill One のサービスレベルを満たすため、障害時にも業務が継続できる高い可用性 深夜の利用は極端に少ないなど、時間帯や曜日で変動要素が大きいワークロード ユーザー数の増加や想定外のピーク特性を考慮しつつ、少ないメンバーでも運用できる低い運用負荷 上記の要件を満たすサービスを検討した結果、可用性の高い Aurora PostgreSQL を採用することに決めました。さらに、Aurora Serverless v2を利用することで、トラフィックの需要に合わせてリソースのスケールアップ/ダウンが可能になり、開発者の限られたリソースの中で運用負荷を最低限に抑えられると判断しました。 Aurora Serverless v2 の開発/運用フェーズ上のメリット 少人数の体制でも 6 カ月間という短い期間で開発を完了できました。短い期間で達成できた一つの要因として、Aurora Serverless v2 を採用したことがあります。これにより信頼性/性能設計やテストの工数を大幅に削減でき、実際に負荷テストの段階で大きな性能トラブルもなく予定通り 1 週間 で終えられました。 今までは、Bill One の特性上、月末/月初にサービスへの負荷が集中するため、ピーク時期に備えて事前にデータベースのスケールアップを実施する必要があり、夜間作業が発生していました。今回の認証基盤では、Aurora Serverless v2 を選択したことで夜間作業がゼロになり、本来やるべき改善作業にリソースを集中できています。また、従来のデータベースでは、スケールアップなどの運用作業の際にダウンタイムが発生し、ユーザーへの影響が懸念されていましたが、Aurora Serverless v2ではダウンタイムもなくスケールアップできることが大きなメリットです。 また、日々の監視作業も楽になりました。従来のプロビジョンドだと、ピーク時に想定以上のユーザートラフィックがあった場合に OS リソースが不足していないかなど、重点的に監視する作業が発生していました。Aurora Serverless v2 はトラフィックに応じて柔軟にスケールアップしてくれるため、現状のところ月末/月初にも特に大きなトラブルなく運用できています。また、トラフィックが少なくなるとスケールダウンもしてくれるため、コスト最適化にもつながっています。 Aurora Serverless v2 の運用上の留意点 先ほども述べたように Aurora Serverless v2 は、 ほったらかしても大きなトラブルなく稼働 してくれますが、最大 ACU を超えないように監視することが重要です。Bill One の認証基盤では、当初最大 ACU を 16 ACU に設定していました。ある月初のタイミングでリソースの使用状況を確認したところ、ユーザー数の増加により、近いうちに上限を超えてしまう兆候が見えたため、最大 ACU を 32 ACU に拡張しました。その際にも再起動が不要なので、ユーザーへの影響なくスケールアップできました。 一方で、処理負荷の高いクエリが実行されると、簡単にスケールアップしてしまい、コスト増加に直結する傾向があります。ユーザー体験の悪化は防げますが、コストが高止まりする懸念があるため、認証基盤の運用でも定期的に Performance Insights を監視し、処理負荷の高いクエリをチューニングしています。 例えば、Row-Level Security を利用しているテーブルをスキャンするクエリで関数インデックスがうまく使われず、フルスキャンが発生してしまうことがありました。インデックスが利用されるようにするため、関数インデックスで使っていた関数を生成列として作成し、そのカラムにインデックスを作成してチューニングを行いました。そのようなチューニングを行うことで、サービスレベルの向上につながり、最大で 87％ の ACU 削減（=コスト削減）に成功しました。このように、定期的にパフォーマンス状況を監視し、チューニングを行っていくことで、コストが高止まりしないような運用を継続していこうと考えています。 将来の展望 今回開発した認証基盤は、現在Bill Oneでのみ利用していますが、将来的には他のプロダクトでも利用する可能性があります。さらにBill One自体のユーザー数も年間で約 2 倍の伸びを見せています。よって今後、新規プロダクトがこの認証基盤を利用したり、Bill Oneのユーザー数が急激に増加したりした場合、これまで以上にダウンタイムが許容されなくなることが予想されます。また、予想していないようなアクセスパターンへの対応など、より堅牢なシステムに昇華させていく必要があると考えています。 仮にデータベースにプロビジョンドインスタンスを利用していて、新規プロダクトを追加する場合、システムを増強するためにユーザー調整や運用作業が発生すると考えられるため、無停止で拡張できるのは非常にありがたいです。 また、Bill Oneはサービスをグローバルに展開しています。現在はアジア圏が中心のため夜間帯がオフタイムになり、Aurora Serverless v2 のコストはそこまでシステム原価に影響していませんが、今後アジア圏以外でも利用が拡大すると、「Follow the Sun」にもあるようにオフタイムという概念がなくなる可能性があります。コスト低減の観点で、リザーブドインスタンス（RI）や Savings Plan による割引プランなどがでてくると、24/365 で稼働する他システムでも利用しやすくなると考えています。   ソフトウェアエンジニア 樋口 礼人 様 Auth0 のコスト削減するのが目的で、認証システムを開発しています。そのため、認証システムのコストは今後も注視していく必要がありますが、少ない人数である意味ほったらかした状態 でデータベースを運用することができています。 サービスが成長していく中で、 Aurora Serverless v2 を選択したことは、メリットがあったと感じています。 チーフアーキテクト 加藤 耕太 様 AWS のアカウントチームの方々には、アーキテクチャレビューなどさまざまなサポートをしていただきました。リリース後もTrusted Advisor による Resilience の向上やコスト最適化に寄与いただいて、非常に助かっています。 著者 藤川 貞信（ISV/SaaS Business ソリューションアーキテクト） 高橋 佑里子（ISV/SaaS Business ソリューションアーキテクト） 内山 義夫（シニアデータベーススペシャリスト） 曽根田 隆司（アカウントマネージャー）

本記事は 2024 年 7 月 2 日に公開された記事 “ Modernize your Java application with Amazon Q Developer “ を翻訳したものです。 多くの組織には、保守がますます困難となっている重要なレガシー Java アプリケーションがあります。これらのアプリケーションのモダナイゼーションは必要不可欠ですが、新しい価値や機能を生み出すことに重点を置かない、困難かつリスクの高い作業です。このモダナイゼーションには、ドキュメント化されていないコード、古いフレームワークやライブラリ、セキュリティの脆弱性、ロギングやエラー処理、入力値チェックの欠如が含まれます。 Amazon Q Developer は、既存の Java アプリケーションのモダナイゼーションを簡素化し、加速させます。具体的には、コードを分析して改善余地のある領域を浮き彫りにしたり、技術的負債の解消を支援したり、コードの最適化を提案したり、現在のフレームワークやライブラリへの移行を促進したりすることができます。 このブログ記事では、Amazon Q Developer を使用してレガシー Java アプリケーションをモダナイズする方法について説明します。 Amazon Elastic Compute Cloud (Amazon EC2) 上で動作する Java 8 を搭載した Java アプリケーションである Unicorn Store API の例を取り上げます。まず、基盤となるランタイムを Java 8 から Java 17 へ、そして Spring を含む一般的な技術スタックをアップグレードします。次に、モジュール構成とロギングを改善することで、コード内の技術的負債を減らします。最後に、モダンなコンピューティングオプションである AWS Fargate を使用して、このアプリケーションをコンテナイメージに再デプロイします。 Maven でビルドされている Unicorn Store API は、データベース内のレコードを管理するための CRUD 操作を提供します。以下の手順に沿って Amazon Q Developer を使用して、このアプリケーションをモダナイズし、Fargate へ移行します。 最新の機能を活用し、アプリケーションを Java 17 へアップグレードします。 コードベース上にある既存の技術的負債を減らします。 アプリケーションをクラウドネイティブ化して AWS にデプロイします。 このチュートリアルでは、IntelliJ IDEA の統合開発環境と Amazon Q Developer plugin for IntelliJ IDEA を使用しています。 Java 8 から Java 17 へのアップグレード 古いアプリケーションでは、セキュリティと安定性を維持するためにより多くの労力が必要です。開発者は、以前のアップグレードで発見されたフレームワークの変更や最適化について、継続的な再学習が求められます。アプリケーションのメンテナンスに労力が割かれるため、必要なアップグレードと新しい機能追加とのバランスを取ることが困難です。 Amazon Q Developer agent for code transformation を使用すると、わずか数ステップでアプリケーションを最新の状態に保ち続けることができます。これにより、サポートされていないバージョンにおける脆弱性が取り除かれ、パフォーマンスが向上し、新しい機能開発に集中できるようになります。Amazon Q Developer agent for code transformation によって、アプリケーションのメンテナンス、アップグレード、移行を迅速に行うことができます。開発者は差別化要因とならない作業の多くを排除することができ、古い言語バージョンからの移行に伴う作業を最大で数日から数か月分節約できます。 最新の機能で最適化するため Amazon Q Developer agent for code transformation を使用し、Unicorn Store API を Java 8 から Java 17 へアップグレードしてみましょう。IntelliJ IDE にて、Amazon Q チャットパネルに「/transform」と入力し、Amazon Q Developer がプロジェクトのアップグレードを開始するために必要な詳細情報を入力します。 Amazon Q Developer agent for code transformation は、既存のコードを自動的に分析し、変換計画を生成、計画に沿った変換タスクを完了します。その際、Spring、Spring Boot、JUnit、JakartaEE、Mockito、Hibernate、Log4j などの一般的なライブラリとフレームワークを、Java 17 と互換性のある最新のメジャーバージョンにアップグレードします。また、Java 17 の推奨事項に従って、廃止予定のコードコンポーネントを更新します。Amazon Q Developer agent によるコード変換を始めるには、 Amazon Q Developer Agent for code transformation による言語バージョンのアップグレード の手順を読み、それに従ってください。 変換が完了したら、変更を受け入れる前に、変換済みコードとビルド及びテスト結果を確認することができます。 コードベース上の技術的負債の削減 技術的負債は、時間の経過とともにどのコードベースにも蓄積されます。技術的負債の中には、期日を守るために受け入れざるを得ないものもありますが、後で返済するためにも追跡して優先順位を付けておく必要があります。管理されないままにしておくと技術的負債が重なり、より開発が遅くなり費用もかかります。技術的負債の削減は、チームの継続的な取り組みであるべきですが、他の優先事項によって後回しになることがよくあります。Amazon Q Developer は、技術的負債を特定して修正することで、レガシー Java コードのモダナイゼーションを効率化します。コードベース上の技術的負債の原因となる問題のリストを提供することで、コードの分析にかかる時間とリソースを削減します。これにより、ソフトウェア開発チームは技術的負債の項目に優先順位を付け、どの問題から最初に対処すべきかについて情報に基づいた決定を下すことができます。 Unicorn Store API で技術的負債のリストを見つけてみましょう。IntelliJ IDE では、Send to Prompt オプションを使用してハイライトされたコードを Amazon Q チャットパネルに送信し、すべての技術的負債のリストを提供するよう求めるプロンプトを表示します。Amazon Q Developer は、すべての技術的負債を詳細にリストします。 技術的負債を特定したら、次のステップはそれらを徐々に改善することです。Amazon Q Developer は、技術的負債を修復するためのコードの実装にかかる時間を短縮します。開発者は、IDE 内の Amazon Q Developer agent for software development とやり取りして、達成しようとしている特定のタスクに関するコードの提案について支援を受けることができます。プロジェクト全体のコードをコンテキストとして使用し、プロジェクト内のすべてのファイルに対して行う予定の実装計画を提供します。計画を確認し、内容に問題がなければ、Amazon Q Developer に提案された計画に基づいてコードを生成するよう依頼できます。これにより、手動更新と比べて開発者の労力を節約できます。 上記のステップで特定された Unicorn Store API の技術的負債について、Amazon Q Developer を使用してロギングの問題に対処してみましょう。IntelliJ IDE で Amazon Q のチャットパネルに「/dev」と入力し、ロギングの技術的負債の詳細を記入します。Amazon Q Developer は、プロジェクト全体のコンテキストに基づいて実装計画とログを追加するためのコードを生成します。Amazon Q Developer agent for software development の使用を開始するには、「 Amazon Q Developer agent for software development を使用してソフトウェアを開発する 」の手順を参照してください。 従来の Java コードをモダナイズするには、品質を段階的に向上させ、時間の経過とともに技術的負債が蓄積されないようにするための継続的なリファクタリングが必要です。Amazon Q Developer は、リファクタリング機能によってこの反復プロセスを簡素化します。選択したコードに対して、リファクタリングされたコードと各変更点、そのコーディング上の利点についての説明を提供してくれるため、変更点を理解するのに役立ちます。この機能の詳細については、「 Amazon Q Developer によるコードの説明と更新 」を参照してください。 この機能を活用して、Unicorn Store API プロジェクトの UnicornController クラスのメソッドを改良してみましょう。Amazon Q Developer は、更新後のレビューのために、可読性や効率性などの点でよりよいコードを生成します。 アプリケーションをクラウドネイティブ化して AWS にデプロイ モダナイゼーションの最終ステップは、アプリケーションをクラウドネイティブ化して AWS にデプロイすることです。クラウドネイティブとは、クラウドコンピューティング環境で最新のアプリケーションを構築、デプロイ、および管理するソフトウェアアプローチです。これらのテクノロジーは、サービス提供に影響を与えることなく、アプリケーションへの迅速かつ頻繁な変更をサポートし、企業に競争上の優位性をもたらします。Amazon Q Developer が Unicorn Store API プロジェクトのクラウドネイティブ化をどのように支援できるかを見てみましょう。 IntelliJ IDE で Amazon Q チャットを開き、プロジェクトをクラウドネイティブ化して AWS にデプロイするための推奨アプローチを提供するよう Amazon Q Developer に依頼します。 Amazon Q Developer がコードを分析し、このアプリケーションをクラウドネイティブ化する手順を詳しく説明します。詳細な手順には、アプリケーションのコンテナ化、 Amazon Elastic Container Service (Amazon ECS) などの AWS サービスへのコンテナアプリケーションのデプロイ、サーバーレス方式でコンテナを実行するための Fargate、コンテナイメージをプッシュするための Amazon Elastic Container Registry (Amazon ECR) 、 AWS Application Load Balancer (ALB) を介したアプリケーションへのアクセス、 モニタリング用の Amazon CloudWatch 、及び Amazon Virtual Private Cloud (VPC) やサブネットなどの関連サービスが含まれます。 Amazon Q Developer に、先程のチャットで会話した手順を実行するよう依頼しましょう。まず、Amazon Q Developer へアプリケーションをコンテナ化するための docker ファイルの作成を依頼してください。コンテナ化のプロセスでは、基盤となるハードウェアやその他の依存関係からソフトウェアを切り離すことで、アプリケーション開発を効率化します。このアプローチは、コンテナ化された環境内のさまざまなコンポーネントを分離することにより、開発スピード、効率、及びセキュリティを強化します。 コンテナベースのアプリケーションの開発に成功したら、Amazon Q Developer の機能を活用して AWS CloudFormation テンプレートを生成してみましょう。このテンプレートにより、コードとしてのインフラストラクチャ (IaC) を使用して必要なリソースを AWS にデプロイできるようになります。IaC を使うと、コンピューティングインフラストラクチャをプログラム的にプロビジョニングして管理できるため、手作業によるプロセスや設定が不要になります。手作業によるインフラストラクチャ管理は、特に大規模なアプリケーションを扱う場合、時間がかかり属人的な作業ミスも起こりやすくなります。 CloudFormation テンプレートを作成するために、これまでの会話から得た提案を見直し、AWS でプロビジョニングする必要があるリソースのリストをまとめましょう。このリストを作成したら、Amazon Q Developer にこれらのリソース要件に基づいて CloudFormation テンプレートを生成するよう依頼できます。 Amazon Q Developer は、コンテナを AWS へ安全で信頼性が高くスケーラブルな方法でデプロイするように、必要なすべてのリソースを含む CloudFormation テンプレートを生成できます。 CloudFormation テンプレートが用意できたので、Unicorn Store API のローカル docker イメージを Amazon ECR にプッシュし、AWS でアプリケーションを実行するために必要な Fargate タスクを開始しましょう。 このように Amazon Q Developer によって、クラウドにデプロイするステップを設計することでアプリケーションをクラウドネイティブ化したり、コンテナベースのソリューションに移行できるよう支援したり、アプリケーションを AWS にデプロイするための IaC のスクリプトを記述したりすることができます。 まとめ Amazon Q Developer を利用することで、開発者はレガシー Java アプリケーションのモダナイゼーションを簡素化および加速できます。また、開発者は古いアプリケーションを現在のフレームワークに適用し、クラウドネイティブな構成で AWS にデプロイできます。これによりプロセスが合理化され、必要な労力やリスクが軽減されます。開発者は時間とリソースを大幅に節約できるため、技術的負債を管理するよりも、新しい機能の構築とモダナイズされたアプリケーションの強化に集中できるようになります。 Amazon Q Developer の詳細については、以下のリソースを参照してください。 Amazon Q の使用を開始する Amazon Q Developer ユーザーガイド Amazon Q Developer agent for code transformation Amazon Q Developer agent for software development Amazon Q Developer の機能 Chetan Makvana Chetan Makvana は、アマゾンウェブサービスのシニアソリューションアーキテクトです。AWS のパートナーやお客様と協力して、スケーラブルなアーキテクチャを構築し、AWS サービスの運用を促進する戦略を実装するためのアーキテクチャガイダンスを提供しています。彼はテクノロジー愛好家であり、生成 AI、サーバーレス、DevOps に関連する分野を中核とするビルダーでもあります。仕事以外では、ショーの鑑賞、旅行、音楽を楽しんでいます。 Venugopalan Vasudevan Venugopalan Vasudevan は、アマゾンウェブサービスのシニアスペシャリストソリューションアーキテクトで、生成 AI サービスを専門としています。彼の専門は、お客様が Amazon Q や Amazon Bedrock などの最先端のサービスを活用して、開発プロセスを合理化し、イノベーションを加速し、デジタル変革を推進できるよう支援することです。Venugopalan は生成 AI をワークフローに統合することで、開発者がより効率的かつ創造的に作業できるよう、次世代の開発者体験を向上させることに専念しています。 Surabhi Tandon Surabhi Tandon は、アマゾンウェブサービスのシニアテクニカルアカウントマネージャーです。彼女は戦略的な技術ガイダンスを提供することで、お客様が優れたオペレーションを実現できるようサポートし、AWS へのクラウド移行を支援しています。Surabhi は生成 AI、自動化、DevOps に関心を持つビルダーです。仕事以外では、ハイキング、読書、家族や友人との時間を楽しんでいます。 この記事は、ソリューションアーキテクトの戸巻 健が翻訳を担当しました。

本稿は、2024 年 2 月 26 日に AWS Security Blog で公開された “ How to use Regional AWS STS endpoints ” を翻訳したものです。 このブログ記事では、グローバル (レガシー) AWS Security Token Service (AWS STS) エンドポイントで、可用性が担保できない場合の回復力の向上に役立つ推奨事項を提供しています。グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com の可用性は高いですが、米国東部 (バージニア北部) という単一の AWS リージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。この投稿では、設定にリージョナル AWS STS エンドポイントを使用することで、ワークロードのパフォーマンスと耐障害性を向上させる方法を紹介します。 認証には、認証情報の不注意による開示、共有、盗難などのリスクを減らすために、長期間の認証情報の代わりに 一時的な認証情報 を使用するのが最善です。AWS STS を使用すると、信頼できるユーザーは、権限が制限された一時的な認証情報をリクエストして、 AWS リソースにアクセスできます 。 一時的な認証情報には、アクセスキーペアとセッショントークンが含まれます。アクセスキーペアは、アクセスキー ID とシークレットキーで構成されています。AWS STS は一時的な認証情報を動的に生成し、要求に応じてユーザーに提供します。これにより、長期間の保管が不要になります。一時的な認証情報には有効期間が限られているため、管理したりローテーションしたりする必要はありません。 これらの認証情報を取得するには、いくつかの方法があります。 ロール、ユーザー、サービスなどの AWS プリンシパル 外部 ID プロバイダー の SAML を使用したフェデレーション OAuth 2.0 や OpenID Connect (OIDC) アプリケーションによって提供されるようなウェブトークン 図 1: AWS STS に認証情報をリクエストする方法 グローバル (レガシー) とリージョナル AWS STS エンドポイント AWS のサービスにプログラムから接続するには、エンドポイントを使用します。 エンドポイント は、AWS STS のエントリポイントの URL です。 AWS STS は、すべてのリージョンにリージョナル AWS STS エンドポイントを提供します。AWS は当初、米国東部 (バージニア北部) リージョン ( us-east-1 ) でホストされているグローバル AWS STS エンドポイント (現在はレガシー) https://sts.amazonaws.com を使用して AWS STS を構築しました。リージョナル AWS STS エンドポイントは、AWS アカウントの中で デフォルトで有効になっているリージョン では、デフォルトで有効になっています。たとえば、 https://sts.ap-northeast-1.amazonaws.com はアジアパシフィック (東京) のリージョナル AWS STS エンドポイントです。デフォルトでは、AWS サービスはリージョナル AWS STS エンドポイントを使用します。たとえば、 IAM Roles Anywhere は、 トラストアンカー に対応するリージョナル AWS STS エンドポイントを使用します。各リージョンの AWS STS エンドポイントの完全なリストについては、「 AWS Security Token Service エンドポイントとクォータ 」を参照してください。リージョンが無効になっている場合は、AWS STS エンドポイントをアクティブ化することはできません。デフォルトでアクティブ化される AWS STS エンドポイントと、アクティブ化または非アクティブ化できるエンドポイントの詳細については、「 リージョンとエンドポイント 」を参照してください。 前述のように、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com は、米国東部 (バージニア北部) という単一のリージョンでホストされており、他のエンドポイントと同様に、他のリージョンのエンドポイントへの自動フェイルオーバーは提供されていません。AWS または AWS 外のワークロードがグローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com を使用するように設定されている場合は、米国東部 (バージニア北部) という単一のリージョンに依存することになります。万が一、そのリージョンでエンドポイントが使用できなくなったり、リソースとそのリージョンの間の接続が失われたりした場合、ワークロードは AWS STS を使用して一時的な認証情報を取得できなくなり、ワークロードに可用性のリスクが生じます。 AWS では、グローバル (レガシー) AWS STS エンドポイントではなく、リージョナル AWS STS エンドポイント ( https://sts. <リージョン名> .amazonaws.com ) を使用することを推奨しています。 回復力の向上に加えて、リージョナル AWS STS エンドポイントには他の利点もあります。 隔離と封じ込め — ワークロードと同じリージョンのリージョナル AWS STS エンドポイントにリクエストを送信することで、リージョン間の依存関係を最小限に抑え、リソースの範囲を一時的な認証情報の範囲に合わせて、可用性とセキュリティ上の懸念に対処できます。たとえば、ワークロードがアジアパシフィック (東京) リージョンで実行されている場合、アジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントをターゲットにして、他のリージョンへの依存関係を削除できます。 パフォーマンス — サービスやアプリケーションに近いエンドポイントにAWS STS リクエストを送信することで、より低いレイテンシーと短い応答時間で AWS STS にアクセスできます。 図2は、一時的な認証情報のセットを返すAWS STS AssumeRole API を呼び出すことで、AWS のプリンシパルが AWS Identity and Access Management (IAM) ロールを引き受けるプロセスを示しています。 図2: リージョナル AWS STS エンドポイントを使用して API を呼び出し、IAM ロールを引き受ける 同じリージョン内のリージョナル AWS STS への呼び出し 特定のリージョン内のワークロードを、そのリージョンのリージョナル AWS STS エンドポイントのみを使用するように設定する必要があります。リージョナル AWS STS エンドポイントを使用すると、ワークロードと同じリージョンで AWS STS を使用でき、リージョン間の依存関係がなくなります。たとえば、アジアパシフィック (東京) リージョンのワークロードは、リージョナルエンドポイント https://sts.ap-northeast-1.amazonaws.com のみを使用して AWS STS を呼び出す必要があります。リージョナル AWS STS エンドポイントにアクセスできなくなった場合、ワークロードは運用リージョン外のリージョナル AWS STS エンドポイントを呼び出すべきではありません。ワークロードにマルチリージョンの耐障害性要件がある場合、他のアクティブリージョンまたはスタンバイリージョンは、 そのリージョンのリージョナルAWS STSエンドポイントを使用 し、リージョンに障害が発生してもアプリケーションが機能するようにデプロイする必要があります。STSへのトラフィックは、 他のリージョンから隔離された独立した 同じリージョン内のリージョナル STS エンドポイントに送り、グローバル (レガシー) AWS STS エンドポイントへの依存関係を削除する必要があります。 AWS の外部から AWS STS への呼び出し AWS 外のワークロードは、AWS 外にあるワークロードのレイテンシーが最も低い適切なリージョナル AWS STS エンドポイントを呼び出すように設定する必要があります。ワークロードにマルチリージョンの耐障害性要件がある場合は、リージョナル AWS STS エンドポイントにアクセスできなくなった場合に備えて、他のリージョンのリージョナル AWS STS エンドポイントへのフェイルオーバーロジックを構築してください。リージョナル AWS STS エンドポイントから取得した一時的な認証情報は、デフォルトの セッション期間 、または指定した期間の間、 全てのリージョンで有効 です。 AWS CLI や SDK でリージョナル AWS STS エンドポイントを設定する方法 AWS STS API を呼び出すには、 AWS コマンドラインインターフェイス (CLI) または AWS SDK の最新のメジャー バージョン を使用することをお勧めします。 AWS CLI デフォルトでは、 AWS CLI バージョン 2 は、現在設定されているリージョンのリージョナル AWS STS エンドポイントに AWS STS API リクエストを送信します。AWS CLI v2 を使用している場合は、追加の変更を加える必要はありません。 AWS CLI v1 は、デフォルトでは AWS STS リクエストをグローバル (レガシー) AWS STS エンドポイントに送信します。使用している AWS CLI のバージョンを確認するには、次のコマンドを実行します。 $ aws --version AWS CLI コマンドを実行すると、AWS CLI は 特定の順序 で認証情報の設定を探します。最初はシェルの環境変数で、次にローカルの AWS 設定ファイル ( ~/.aws/config ) の設定を探します。 AWS SDK AWS SDK は、 さまざまなプログラミング言語 と環境で利用できます。2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。2022 年 7 月以降にリリースされた AWS SDK のメジャーバージョンを使用する場合は、追加の変更を加える必要はありません。 AWS SDKは、認証情報の設定値が見つかるまで、さまざまな 設定場所 を探します。たとえば、AWS SDK for Python ( Boto3 ) は、ソースを介して設定値を探す場合、次の探索順序に従います。 SDK のクライアント作成時に、AWS 設定パラメータとして渡される設定オブジェクト 環境変数 AWS 設定ファイル ~/.aws/config まだ AWS CLI v1 を使用している場合、または AWS SDK バージョンがデフォルトでリージョナル AWS STS エンドポイントに設定されていない場合は、以下のオプションでリージョナル AWS STS エンドポイントを設定できます。 オプション1 — 共有の AWS 設定ファイルを使用する AWS 設定ファイル は、LinuxまたはmacOSでは ~/.aws/config にあり、 Windows では C:\Users\USERNAME\.aws\config にあります。リージョナル AWS STS エンドポイントを使用するには、 sts_regional_endpoints パラメータを追加してください。 次の例は、AWS 設定ファイルのデフォルトプロファイルを使用して、アジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。 [default] region = ap-northeast-1 sts_regional_endpoints = regional AWS STS エンドポイントパラメータ ( sts_regional_endpoints ) の有効値は次のとおりです。 legacy — グローバル (レガシー) AWS STSエンドポイント sts.amazonaws.com を使用します。 regional — 現在設定されているリージョンのリージョナル AWS STS エンドポイント sts. <リージョン名> .amazonaws.com を使用します。 注: 2022 年 7 月以降、AWS SDK の主要な新バージョンはデフォルトでリージョナル AWS STS エンドポイントに設定され、現在設定されているリージョンに対応するエンドポイントを使用します。AWS CLI v1 を使用している場合、AWS STS エンドポイントパラメータを使用するにはバージョン 1.16.266 以降を使用する必要があります。 AWS CLI コマンドで --debug オプションを使用すると、デバッグログを受け取り、どの AWS STS エンドポイントが使用されたかを検証できます。 $ aws sts get-caller-identity \ > --region ap-northeast-1 \ > --debug デバッグログで useGlobalEndpoint を検索すると、 useGlobalEndpoint パラメータが False に設定されていることがわかります。共有 AWS 設定ファイルまたは環境変数でリージョナル AWS STS エンドポイントが設定されている場合は、リージョナル AWS STS エンドポイントプロバイダーの完全修飾ドメイン名 (FQDN) が表示されます。 2024-09-05 12:14:12,870 - MainThread - botocore.regions - DEBUG - Calling endpoint provider with parameters: {'Region': 'ap-northeast-1', 'UseDualStack': False, 'UseFIPS': False, 'UseGlobalEndpoint': False} 2024-09-05 12:14:12,871 - MainThread - botocore.regions - DEBUG - Endpoint provider result: https://sts.ap-northeast-1.amazonaws.com リージョナル AWS STS エンドポイントの共有 AWS 設定ファイル設定をサポートする AWS SDK のリストについては、「 AWS SDK との互換性 」を参照してください。 オプション2 — 環境変数を使用する 環境変数 は、認証情報の設定を指定する別の方法を提供します。環境変数は、シェルセッション内でグローバルに AWS サービスへの呼び出しに影響します。ほとんどの SDK は環境変数をサポートしています。環境変数を設定すると、SDK はシェルセッションが終了するまで、または変数を別の値に設定するまで、その値を使用します。変数を今後のセッションでも維持するには、シェルの起動スクリプトで変数を設定します。 次の例は、環境変数を使用してアジアパシフィック (東京) リージョン ( ap-northeast-1 ) のリージョナル AWS STS エンドポイントの値を設定する方法を示しています。 Linux または macOS $ export AWS_DEFAULT_REGION=ap-northeast-1 $ export AWS_STS_REGIONAL_ENDPOINTS=regional 以下のコマンドを実行して、環境変数を確認できます。 $ (echo $AWS_DEFAULT_REGION; echo $AWS_STS_REGIONAL_ENDPOINTS) 出力は次のようになります。 ap-northeast-1 regional Windows C:\> set AWS_DEFAULT_REGION=ap-northeast-1 C:\> set AWS_STS_REGIONAL_ENDPOINTS=regional 次の例は、環境変数を設定して、 AWS SDK for Python (Boto3) で STS クライアント がリージョナル AWS STS エンドポイントを使用するように設定する方法を示しています。 import boto3 import os os.environ["AWS_DEFAULT_REGION"] = "ap-northeast-1" os.environ["AWS_STS_REGIONAL_ENDPOINTS"] = "regional" メタデータ属性 sts_client.meta.endpoint_url を確認して、STS クライアントがどのように構成されているかを調べたり、検証したりできます。出力は次のようになります。 >>> sts_client = boto3.client("sts") >>> sts_client.meta.endpoint_url 'https://sts.ap-northeast-1.amazonaws.com' リージョナル AWS STS エンドポイントの環境変数設定をサポートする AWS SDKのリストについては、「 AWS SDK との互換性 」を参照してください。 オプション 3 — エンドポイント URL を指定する 特定のリージョナル AWS STS エンドポイントのエンドポイント URL を手動で指定することもできます。 次の例は、特定のエンドポイント URL を設定することで、AWS SDK for Python (Boto3) で STS クライアント がリージョナルの AWS STS エンドポイントを使用するように設定する方法を示しています。 import boto3 sts_client = boto3.client('sts', region_name='ap-northeast-1', endpoint_url='https://sts.ap-northeast-1.amazonaws.com') AWS STS で VPC エンドポイントを使用する Amazon VPC にデプロイしたリソースから、AWS STS へのプライベート接続を作成できます。AWS STS は、 インターフェイス VPC エンドポイント を使用して AWS PrivateLink と統合します。AWS PrivateLink の ネットワークトラフィック は、 グローバルAWSネットワークのバックボーン にとどまり、パブリックインターネットを経由しません。AWS STS の VPC エンドポイントを設定すると、リージョナル AWS STS エンドポイントのトラフィックはその VPC エンドポイントを使用して通信を行います。 デフォルトでは、VPC の DNS はリージョナル AWS STS エンドポイントのエントリを更新して、VPC 内の AWS STS の VPC エンドポイントのプライベート IP アドレスに解決します。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行した以下のコマンドの結果は、AWS STS エンドポイントの DNS 名が、AWS STS の VPC エンドポイントのプライベート IP アドレスに解決されることを示しています。 [ec2-user@ip-10-120-136-166 ~]$ nslookup sts.ap-northeast-1.amazonaws.com Server: 10.120.0.2 Address: 10.120.0.2#53 Non-authoritative answer: Name: sts.ap-northeast-1.amazonaws.com Address: 10.120.138.148 使用しているリージョンで AWS STS の インターフェイス VPC エンドポイントを作成 したら、同じリージョンの AWS STS にアクセスするために、環境変数を使用してそれぞれのリージョナル AWS STS エンドポイントの値を設定します。 次のログの出力は、リージョナル AWS STS エンドポイントに対して AWS STS 呼び出しが行われたことを示しています。 POST / content-type:application/x-www-form-urlencoded; charset=utf-8 host:sts.ap-northeast-1.amazonaws.com AWS STS リクエストのログ AWS CloudTrail イベントを使用して、 AWS STS に使用されたリクエストとエンドポイントに関する情報を取得できます 。この情報は、AWS STS のリクエストパターンを特定し、グローバル (レガシー) STS エンドポイントをまだ使用しているかどうかを確認するのに役立ちます。 CloudTrail のイベントは、AWS アカウントでのアクティビティの記録です。CloudTrail イベントは、 AWS マネジメントコンソール 、AWS SDK、コマンドラインツール、その他の AWS サービスを通じて行われた API と非 API の両方のアクティビティの履歴を提供します。 ログの場所 リージョナル AWS STS エンドポイント https://sts. <リージョン名> .amazonaws.com へのリクエストは、それぞれのリージョン内のCloudTrailに記録されます。 グローバル (レガシー) AWS STS エンドポイント sts.amazonaws.com へのリクエストは、米国東部 (バージニア北部) リージョン ( us-east-1 ) に記録されます。 ログフィールド リージョナル AWS STS エンドポイントとグローバル (レガシー) AWS STS エンドポイントへのリクエストは、CloudTrail の tlsDetails フィールドに記録されます。このフィールドを使用して、リクエストがリージョナル AWS STS エンドポイントに送信されたのか、グローバル (レガシー) AWS STS エンドポイントに対して行われたのかを判断できます。 VPC エンドポイントからのリクエストは、CloudTrail の vpcEndpointId フィールドに記録されます。 次の例は、VPC エンドポイントを持つリージョナル AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。 "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "vpcEndpointId": " vpce-021345abcdef6789" ", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.2", "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "clientProvidedHostHeader": " sts.ap-northeast-1.amazonaws.com " } 次の例は、グローバル (レガシー) AWS STS エンドポイントへの STS リクエストの CloudTrail イベントを示しています。 "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.2", "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256", "clientProvidedHostHeader": " sts.amazonaws.com " } AWS STSのログデータをインタラクティブに検索して分析するには、 Amazon CloudWatch Logs Insights または Amazon Athena を使用してください。 Amazon CloudWatch Logs Insights 次の例は、CloudWatch Logs Insightsクエリを実行して、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを探す方法を示しています。CloudTrail イベントをクエリする前に、 CloudWatch Logs にイベントを送信する ように CloudTrail の証跡を設定する必要があります。 filter eventSource="sts.amazonaws.com" and tlsDetails.clientProvidedHostHeader="sts.amazonaws.com" | fields eventTime, recipientAccountId, eventName, tlsDetails.clientProvidedHostHeader, sourceIPAddress, userIdentity.arn, @message | sort eventTime desc クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた AWS STS 呼び出しのイベントの詳細が表示されます。 図 3: CloudWatch Logs Insights のクエリを使用して STS API 呼び出しを検索します Amazon Athena 次の例は、Amazon Athena で CloudTrail イベントをクエリし、グローバル (レガシー) AWS STS エンドポイントに対して行われた API 呼び出しを検索する方法を示しています。 SELECT eventtime, recipientaccountid, eventname, tlsdetails.clientProvidedHostHeader, sourceipaddress, eventid, useridentity.arn FROM "cloudtrail_logs" WHERE eventsource = 'sts.amazonaws.com' AND tlsdetails.clientProvidedHostHeader = 'sts.amazonaws.com' ORDER BY eventtime DESC クエリ出力には、グローバル (レガシー) AWS STS エンドポイント https://sts.amazonaws.com に対して行われた STS 呼び出しが表示されます。 図 4: Athena を使用して STS API 呼び出しを検索し、STS エンドポイントを特定します まとめ この投稿では、リージョナル AWS STS エンドポイントを使用して、AWS で使用しているリージョンの回復力を高め、レイテンシーを減らし、セッショントークンの有用性を向上する方法を学びました。 環境内の AWS STS エンドポイントの設定と使用状況を確認し、CloudTrail ログで AWS STS のアクティビティを検証し、リージョナル AWS STS エンドポイントが使用されていることを確認することをおすすめします。 質問がある場合は、 セキュリティ、アイデンティティ、コンプライアンスの re:Post トピックに投稿するか、 AWS サポート に連絡してください。 著者について Darius Januskis は AWS の Senior Solutions Architect で、世界中の金融サービスを提供しているお客様のクラウドへの移行を支援しています。彼は情熱的なテクノロジー愛好家で、お客様と協力し、well-architected なソリューションを構築できるよう支援することを楽しんでいます。彼の関心事には、セキュリティ、DevOps、自動化、サーバーレステクノロジーが含まれます。   翻訳はクラウドサポートエンジニアの森永が担当し、大金がレビューしました。

年に 1 度の International Broadcasting Convention (IBC) が目前に迫る中、Amazon Web Services (AWS) は、人工知能 (AI) からライブクラウドプロダクションソリューションまでの最新のメディア & エンターテインメント (M&E) の革新を披露する準備を整えています。9 月 13 日から 16 日まで、RAI の Hall 5 にある二階建ての AWS ブース (5.C90) で会議やデモを行うだけでなく、NVIDIA と協力して Hall 14 の Innovation Village と IBC AI Tech Zone のスポンサーも務めます。 参加される方々は、9 月 14 日 (土) に Hall 8 で、業界をリードする識者による 1 日の啓発的なセッションにも参加できるほか、イベント期間中に AWS が協賛するその他のイベントにも参加できます。 IBC 期間中に AWS 専門家との会議をリクエストするには、 こちらからお問い合わせ ください。また、AWS のサービス、ソリューション、パートナーの出展場所については、以下のリストをご確認ください。 特別なイベント AWS Women in M&E Mixer : AWS は再び 9 月 13 日 (金) の 17:45 から 19:30 に、アムステルダムの Soho House で交流イベントを主催します。会話のテーマは、M&E 業界でのルールを書き換えていく女性リーダーについてです。まだ参加登録していない方は、 こちらからご登録 ください。 IBC Showcase Theater : AWS のセッションが、 9 月 14 日 (土) に Hall 8、スタンド A01 の IBC Showcase Theater の中央ステージで開催されます。 当日は 7 つのセッションが予定されており、生成 AI、収益化、ライブクラウドプロダクション、スポーツ、没入型の体験、ゲームなどをテーマとしています。NBCUniversal、Formula 1、Sky などのお客様にご参加いただきます。 IBC Keynote – Building a future-ready tech stack for an evolving media landscape :   9 月 14 日 (土) 10:00 から 11:00 に、Vice President of Prime Video & Amazon MGM Studios Technology の Girish Bajaj がカンファレンスルーム 1 でインサイトを交えた講演を行い、メディア・放送業界向けの適切な基盤テクノロジーの構築方法について解説します。 主な見どころ IBC 2024 では、AWS は 50 件のデモを展示し、AWS ブースで 60 社のパートナーを紹介します。デモでは、コンテンツの制作、配信、および収益化のための主要な M&E ワークロードをハイライトし、そのうち半分以上が AWS の生成 AI 技術を活用しています。ブースを訪れた方は、 Amazon Bedrock 、 Amazon Q 、 PartyRock アプリケーションを紹介する専用ポッドをご覧いただけます。 ブースに訪れた方は、制作現場の専門家に馴染みのある見た目、オーディオ、スクリーンを備えた実際の編集施設を模した、インタラクティブな編集およびカラーグレーディングスイートを探索することもできます。 拡大された Builder Zone では、参加者が AWS ソリューションを技術的に深く理解し、実験することができます。 AWS Elemental サービス、AWS ストレージサービス ( Amazon S3 、 Amazon S3 Glacier 、 Amazon FSx ) および Amazon GameLift 、さらには AWS の生成 AI サービスと Amazon Personalize を実際に体験できます。 IBC 全体に広がる生成 AI AWS は 5.C90 のブースで 29 の生成 AI デモを提供しているほか、NVIDIA とともに Hall 14 のブース A13 にイノベーションビレッジを出展しています。このビレッジでは、AWS 上の生成 AI サービスおよびソリューションを使用している共有パートナーとその実績が紹介されます。参加者はデモポッドを見て回ったり、AWS のお客様やパートナーによるシアター形式のプレゼンテーションを見ることができます。また、クラウドを使用して 8K や没入型のコンテンツをライブまたは事前に録画したものを制作できるワークフローも体験できます。会場では、対話型の AI を使用して絵を描く「Sir Martian」という名の動く人形ロボットとも会話できます。 さらに、AWS は Hall 14 の IBC の AI Tech Zone (AIA01 ブース) の共同スポンサーになっています。 この特設エリアでは、AI の有識者、ソリューションプロバイダー、クリエイターにスポットライトを当てます。 IBC で AWS とつながる IBC 2024 の日程を立てる際には、必ずブース番号 5.C90 を訪れ、M&E ワークフローのためのクラウド技術の最新のイノベーションをご覧ください。エキスパートとお話しいただき、放送ワークロードを最大限の俊敏性、弾力性、拡張性、信頼性をもって実行し、ダイレクト・トゥ・コンシューマーおよびストリーミングワークロードのためのイノベーションを加速させる新しい方法を見つけていただきたいと思います。 AWS チームは、広告収益の最大化、顧客エンゲージメントの促進、生成 AI の活用、高品質のコンテンツ配信を維持しつつコンテンツ配信コスト削減など、さまざまな点でガイダンスを提供できます。 最新情報については AWS IBC 2024 イベントページ をご覧ください。 AWS at IBC 参加者ガイド をダウンロードしたり、 LinkedIn の AWS for M&E をフォローしてください。 翻訳はソリューションアーキテクトの加藤・石井が担当しました。 原文は こちら をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先:  awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

メディア & エンターテインメント (M&E) 業界は、消費者の期待の変化、競合するストリーミングプラットフォームの台頭、データ駆動型のインサイトの重要性の高まりによって大きな変革を経験しています。コンテンツライブラリーが 継続的に拡大するつれ、多くのメディア企業は、貴重な既存コンテンツ資産をクラウドに移行する必要性を認識しています。そうすることで、持続可能なビジネス成長の機会、サプライチェーン業務の最適化、消費者エクスペリエンスの向上を実現できます。 IBC 2024 で Amazon Web Services (AWS) は、M&E 企業の業界変革を支援する 6 つの実例を紹介する予定です。コンテンツ移行と収益化にむけた自動化、クラウドベースのオーケストレーションワークフロー、高度なローカライゼーション機能など、業界が直面する最も重要な課題に対するソリューションのデモ展示を行います。 AWS メディアワークロードのデモは IBC 5.C90 ブースでご覧ください。 アーカイブの移行 ローコードでのワークフロー自動化 AWS 上のニュースルームとデイタイムクラウド制作 メディアのためのデータレイクとメタデータレイク インテリジェント QC とサステナビリティ コンテンツのローカライゼーションとアクセシビリティ Migrate to monetize : 収益化に向けた移行 メディアアーカイブには貴重な知的財産が含まれていますが、多くのメディア企業は、膨大なライブラリの動画、オーディオ、テキストベースのコンテンツを効果的に収益化することに苦慮しています。「Migrate to monetize：収益化に向けた移行」ではシームレスな移行から収益化までのクラウドベースのワークフローを実現するために、AWS のサービスとパートナーソリューションを統合したデモを実演予定です。 このワークフローは、コンテンツを AWS に移行することから始まります。ローコード/ノーコードのソリューションにより、オペレーションチームがオーケストレーションを修正可能です。移行したコンテンツ、メタデータは、複数の分散したビジネスユニットがアクセスできるアセット管理システムに格納されます。 Demonstration: Archive Migration: Unlock the hidden value in your content archives：アーカイブ移行: コンテンツアーカイブの隠された価値を解き放つ このデモンストレーションは、データをクラウドに移行するための Cloudfirst の archive migration as a service (AMaaS) からスタートします。AMaaS は、コンテンツを次世代のデジタルアーカイブに移行するための効率的で低リスクな方法です。次に、 PwC の AI 駆動のアノテーションソリューションが、AWS の大規模言語モデル (LLM) を活用して、権利契約から条件と規定を抽出することで、契約を digital intelligence に変換します。 Media2Cloud on AWS は、クラウドへのメディアアセットの移行プロセスを簡素化します。Media2Cloud で、コアメタデータの抽出を自動化し、インテリジェントな要約を生成することで、アーカイブされたメディアの収益化の可能性を引き出すことが可能になります。 Rightsline の包括的な権利プラットフォームにより、コンテンツライブラリの追跡、管理、収益化 が可能になります。Vidinet メディア管理エンジンは、 Vidispine から提供され、移行したアセットを制作およびディストリビューション用途に整理・インデックス化します。 Vubiquity の MetaVu は、メタデータ管理を簡素化し、さまざまな標準フォーマットと 2,000 を超えるディストリビューションエンドポイントをサポートし、コンテンツの検索性と業務効率を向上させます。 これらのソリューションを組み合わせることで、インテリジェントなメタデータ抽出、先進的なアナリティクス、ターゲットを絞ったコンテンツ配信を活用し、メディアアーカイブからの新たな収益機会を特定できます。 Demonstration:Low-Code Workflow Automation: Streamline content production and distribution：ローコード でのワークフロー自動化: コンテンツ制作とディストリビューションを合理化する このデモンストレーションでは、4 つのパートナーソリューションにわたるローコードによるワークフロー自動化を紹介します。 ローコード/ノーコード のプラットフォームにより、ユーザーは最小限のコーディングで独自のアプリケーションを構築・展開できるため、技術チーム以外のチームでもワークフローを最適化しやすくなります。 デモンストレーションでは、アセットのライフサイクルを案内し、制作済みのマスターファイルから始まります。インテリジェント品質管理 (QC) を活用して、ワークフローは高度な QC チェックを実行し、コンテンツが技術仕様と編集基準を満たしていることを確認できます。 Embrace Pulse-IT のローコードプラットフォームは、このワークフローのための高度な自動化、オーケストレーション、コラボレーション機能を提供し、 Codemill Accurate.Video プレーヤーを使用して QC の例外をタイムドメタデータを使用してレビューできます。 QC 分析が成功すると、コンテンツは C2PA 仕様で署名され、デジタルメディアの出所と整合性を認証します。 Veritone の Digital Media Hub は、AI 駆動のコンテンツ最適化、収益化、シンジケーション向けソリューションで、ビジネス間 (B2B) のコンテンツ取得ポータルで販売用にコンテンツをパッケージ化します。 ご来場いただくお客様には、制作からディストリビューションまでのエンドツーエンドのスケーラブルなワークフローをご確認いただけます。これにより、メディアチームは創造性とエディトリアルの取り組みに集中しつつ、オペレーションの効率化と出荷までの時間の短縮を実現できます。 Demonstration: Newsroom and Daytime Cloud Production on AWS: Enable cost-effective live and file-based workflows：AWS 上でのニュースルームとデイタイムクラウド制作: コストパフォーマンスの高いライブとファイルベースのワークフローの実現 ニュース放送局やメディア組織にとって、魅力的で、費用対効果の高いデイタイムのプログラムを提供することが、ますます重要になっています。AWS は、ライブクラウド拠点からファイナルプログラム配信までのニュースルームと制作のライフサイクル全体にわたる、エンドツーエンドのクラウドソリューションを紹介します。 ご来場いただくお客様には、 Amazon Elastic File System (Amazon EFS)、 Amazon FSx for Windows File Server、 Amazon Simple Storage Service (Amazon S3)、 Amazon Elastic Compute Cloud (Amazon EC2) などの AWS サービスが、シームレスで、クラウドによるデイタイムの番組やニュースルームの制作ワークフローを可能にするための AWS パートナーソリューションとどのように統合されているかご確認いただけます。主なパートナーには、Production Asset Management (PAM) に Mimir 、Newsroom Control System (NRCS) に Dina 、cloud-based editing に Cuttingroom 、CG と virtual studio integrationに Vizrt 、高度な編集ニーズに向けた Adobe Premiere が含まれます。 AWS のスケーラビリティ、信頼性、コストパフォーマンスを活用することで、メディア企業は、変化するコンテンツ需要や視聴者の好みに迅速に対応できる柔軟なクラウドベースの制作環境を構築できます。このデモンストレーションでは、ライブおよびファイルベースのワークフローを合理化し、オペレーションコストを削減、オンプレミスの容量制限を軽減しつつ、高品質のデイタイムおよびニュースルーム番組を配信する方法をご紹介いたします。 Media insights, search, and analysis：メディアのインサイト、検索、分析 現在のデータ駆動型なメディア業界において、包括的なコンテンツ戦略を構築するには、カスタムメタデータを統合、分析、実行可能なインサイトを抽出する必要があります。AWS は、そのサービスとパートナーソリューションを活用して、先進的なメディアインテリジェンス機能を実現し、コンテンツクリエイター、ディストリビューター、マーケッターの意思決定に役立つデータを活用できるようにしています。 Demonstration: Data Lake for Media and Metadata Lake: Unlock the power of consolidated data strategies: メディアとメタデータのデータレイク: 統合されたデータ戦略の力を引き出す このソリューションのコアは、ビジネスインテリジェンス機能を提供する Amazon QuickSight 、業界データフィードを提供する AWS Data Exchange 、リアルタイムデータストリーム処理を行う Amazon Kinesis 、データ統合および ETL に利用する AWS Glue 、メディア資産からのメタデータを自動抽出する Media2Cloud on AWS を統合したものです。 Twelve Labs や IMDb などの業界リーダーとのパートナーシップにより、AWS は、最先端の自然言語処理、コンピュータービジョン、マルチモーダル検索機能を活用して、コンテンツライブラリから豊富なインサイトを引き出す方法をデモします。ビジターは、制作からディストリビューションまでのメディアサプライチェーン全体で、シームレスなコンテンツ検索、メディアの重複排除、ターゲティングされたマーケティングキャンペーン、データ駆動の意思決定を可能にする、中央集約されたデータ戦略を設計する方法をご確認いただけます。 Localization, accessibility, and compliance：ローカライゼーション、アクセシビリティ、コンプライアンス メディアコンテンツを世界中の視聴者に届けるために、ローカライゼーション、アクセシビリティ、進化する規制への準拠を確保することが不可欠になっています。AWS は、従来の技術的な QC (Quality Control) を超えて、言語、アクセシビリティ、コンテンツ認証要件に対処するマルチベンダーの QC ワークフローを紹介します。 Demonstration: Intelligent QC & Sustainability: Comprehensive Global Content QC：インテリジェント QC とサステナビリティ: 包括的なグローバルコンテンツ QC コンテンツの品質、コンプライアンス、出所の保証は、コンテンツディストリビューターにとって非常に重要です。「インテリジェント QC」は、従来の技術的チェックを超えて、コンテンツ検証要件の複雑性の高まりに対応する包括的な QC ワークフローです。AWS サーバーレスサービスとパートナーソリューションを統合することで、このデモンストレーションは、メディア企業が QC プロセスをシームレスにスケールし、最高水準の QC とサステナビリティを維持する方法を示します。 ご来場いただくお客様には、ビデオ、言語、コンプライアンスなど、包括的なチェックを実行するための、Media2Cloud on AWS と Venera Quasar 、 Spherex AI などのパートナーソリューションを統合したマルチベンダーの QC ワークフローを紹介いたします。この QC ソリューションは、コンテンツの法令順守要件の高度化に対応するためにスケールすることができます。これには、地域の規制への準拠チェックや、European Corporate Sustainability Reporting Directive (CSRD) に基づく炭素排出の報告なども含まれます。 このワークフローの鍵は、Apptek の高度な言語 AI 機能を含む AWS パートナーテクノロジーの統合です。技術的 QC と、このようなコンテキストおよびコンプライアンスに重点を置いたチェックを組み合わせることで、メディア企業はコンテンツが世界中の視聴者と規制当局が期待する厳格な品質基準を満たしていることを確認できます。 Demonstration: Content Localization & Audience Accessibility: Ensure global reach and regulatory adherence: コンテンツのローカライゼーション & オーディエンスアクセシビリティ: グローバルな浸透と規制順守を確保する メディア企業がグローバルへ市場を広げるにつれ、国際市場向けのコンテンツのローカライズや、障害を持つ視聴者のアクセシビリティを改善することの重要性が高まっています。AWS は、コンテンツの長さ、レーティング、地域別の分類を特定するためのサービスとパートナーソリューションを提供しています。 このデモンストレーションでは、ローカル言語への翻訳や聴覚障害者向けの字幕、音声解説、視覚サインの生成など、コンテンツへのアクセシビリティを向上させるためのガイダンスをご紹介いたします。このガイダンスは、アクセシビリティ基準に対処するのに役立ちます。 ローカライゼーションとアクセシビリティのワークフローでは、 AWS Step Functions と AWS Lambda を使ってプロセスステップをオーケストレーションしています。 AudioShake Dialogue、Music、& Effects Separation によるオーディオトラックの分離、 DeepDub Go による AI 駆動のダビングと言語翻訳など、注目のパートナーが含まれています。AWS サービスと AWS パートナーソリューションを統合することで、メディア企業は、多様な世界中の視聴者の要件を満たし、アクセシビリティ規制に準拠しながら、コンテンツを効率的にグローバル展開できるようになります。 おわりに コンテンツアーカイブの隠れた価値を引き出したい、制作プロセスを合理化したい、世界中の視聴者にとってよりアクセスしやすくローカライズされたコンテンツを提供したい、などのニーズに対し、AWS は包括的なサービスとパートナーソリューションをご提供いたします。クラウドのスケーラビリティ、信頼性、コストパフォーマンスを活用することで、メディア企業は、変化する市場のニーズと視聴者の好みに迅速に対応できる柔軟なデータ駆動型のメディアサプライチェーンとアーカイブのエコシステムを構築可能です。 IBC 2024 の AWS スタンド 5.C90 で、これらのデモンストレーションを実際に体験してください。AWS メディアサプライチェーンとアーカイブチームとの 面談をスケジュール するか、AWS 担当者に連絡して詳細をご確認ください。一緒に、進化するメディア業界の中で、どのようにAWSがお客様の組織の成長を後押しするのかを探求しましょう。 アムステルダムでお会いできることを楽しみにしています! 翻訳はメディアソリューションアーキテクトの安司・石井が担当しました。 原文は こちら をご覧ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

こんにちは、Amazon Connect ソリューションアーキテクトの清水です。 2024 年 7 月のアップデート まとめはいかがでしたでしょうか。今後もコンタクトセンターや Amazon Connect に係わる方々へ気づきが得られる情報を発信したいと思いますので、記事を基に実際に皆様の環境でお試しいただき、是非フィードバックをお寄せ頂きたいと思います。 今月はアップデート以外に Amazon Connect のスキルアップに役立つトレーニングをお知らせいたします。 それでは今号も以下の内容をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートとトレーニングについて 2024 年 8 月のアップデート一覧 AWS Contact Center Blog のご紹介 1.注目のアップデートとトレーニングについて 注目#1 Amazon Connect Communications Specialist Learning Plan (Amazon Connect の新しい学習プランが公開) 従来より AWS は Amazon Connect に関するデジタルトレーニングを提供していましたが、製品にフォーカスしていたり、Amazon Connect の新機能の追加によりコンテンツが陳腐化するという課題がありました。新しい学習プランは、1 つのアプリケーションやサービスに関連するすべての概念を学ぶのではなく、自分の立場・役割に役立つ複数のアプリケーション、サービス、製品に関する特定の概念だけを学ぶことが可能になります。最初の学習プランではコンタクトセンターのエンジニア、通信エンジニア、IVR エンジニア、テレフォニー管理者を対象とした Amazon Connect Communications Specialist を公開しました。学習しやすいようにシリーズは 30 分～60 分で区切られており、テレフォニー、IVR、フロー、ルーティング、オムニチャネルデプロイ、および AWS サービスとの統合を学ぶことができます( 中でもAmazon Connect ソリューションアーキテクトが特におすすめするのは「 Amazon Connect Optimizing Routing Solutions 」です！ )。 このカリキュラムを修了し、ナレッジチェックを 80% 以上のスコアで合格すると Credly から Amazon Connect Communications Specialist バッジを獲得できます。これはクラウドスキルや経験を伝えるために役立てることができます。 このトレーニングは無償で利用可能で、現在は英語で提供しています。学習には AWS Skill Builder のアカウントが必要です。 注目#2 Amazon Connect provides new ways to configure callbacks (Amazon Connect でコールバックの新しい設定が追加) Amazon Connect では営業時間外の問い合わせやエージェントが対応できないため待ち時間が発生する状況に対しコールバックキューを利用して、エージェントが対応可能になり次第、順次顧客へのコールバックを行う機能があります。今回コールバックの設定でフローが設定可能になったことにより、例えば営業時間外にかかってきた問い合わせがコールバックキューに入った後、コールバック時にフローから顧客データを参照して、もし顧客が既にボットや FAQ によって問題を解決済みであればコールバックを中止し、エージェントと顧客の不要な通話を抑えることができます。 コールバックのフローは、「キューへ転送」ボックスの「オプションのパラメータ」－「作成フローを指定」で設定することができます。 2. 2024年8月のアップデート一覧 Amazon Connect provides new ways to configure callbacks (Amazon Connect でコールバックの新しい設定が追加) – 08/23/2024 Amazon Connect では、コールバックの作成前やキューにある間にアクションを実行するようにフローを設定できるようになりました。たとえば、コールバック前に SMS 経由で顧客に自動的に通知を送信したり、最新の顧客データに基づいてコールバック属性を更新したり、既に問題が解決された場合はコールバックを終了したりできるようになりました。また Customer Profiles やサードパーティアプリケーションからの顧客情報に基づいて、コールバックまでの時間がかかる場合に、コールバックの優先順位を動的に変更したり別のキューにコールバックを転送するフローを実行できるようになりました。 関連リンク 管理者ガイド Amazon Connect in-app, web, and video calling is now available in Africa (Cape Town) region (アプリ内通話、ウェブ通話、ビデオ通話がアフリカ(ケープタウン)リージョンをサポート) – 08/20/2024 Amazon Connect では、アフリカ (ケープタウン) リージョンでアプリ内通話、ウェブ通話、ビデオ通話機能が提供されるようになりました。これにより、ウェブサイトやモバイルアプリケーションで、よりパーソナライズされた音声およびビデオ通話を簡単に提供できるようになります。これらの音声およびビデオ機能により、顧客はウェブサイトやモバイルアプリケーションを切り替えることなく通話を開始することができます。この機能を使用してコンテキスト情報を Amazon Connect に渡すことができるため、顧客のプロフィール、認証ステータス、アプリ内で以前に実行されたアクションなどの属性に基づいて顧客体験をパーソナライズできます。 関連リンク 管理者ガイド Amazon Connect outbound campaigns now supports Mexico (Amazon Connect アウトバウンドキャンペーンがメキシコのサポートを開始) – 08/14/2024 Amazon Connect で米国東部 (バージニア) および米国西部 (オレゴン) リージョンにおけるメキシコへの outbound campaigns コールがサポートされるようになりました。これにより配達通知、マーケティングプロモーション、予約通知、債権回収などのユースケースで、音声、SMS、E メールによるコミュニケーションが容易になります。この機能には、ダイヤル状態の確認、時間帯、タイムゾーン、連絡先ごとの試行回数、留守番電話検出機能を備えたプレディクティブダイヤルなどの機能が含まれます。Amazon Pinpoint が提供するリスト管理機能を使用して、カスタマージャーニーやマルチチャネルのユーザーコンタクトエクスペリエンスを構築することもできます。 関連リンク Amazon Connect Telecoms Country Coverage Guide Amazon Connect Contact Lens generative AI-powered agent performance evaluations (preview) now available in 6 new regions (Amazon Connect Contact Lens の生成 AI を活用したエージェントのパフォーマンス評価機能 (プレビュー版) が 6 つの新しいリージョンで利用可能に) – 08/13/2024 Amazon Connect Contact Lens 生成 AI を活用したエージェントパフォーマンス評価 (プレビュー) が、ヨーロッパ (フランクフルト)、ヨーロッパ (ロンドン)、カナダ (中央)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、およびアジアパシフィック (シンガポール) の AWS リージョン で利用可能になりました。これにより管理者は、エージェントの行動に関する追加のインサイト(例：エージェントが悪い知らせを顧客に伝える際に共感を示したか)を得ることが可能になり、推奨された回答のコンテキストと正当性（回答を提供するために使用された文字起こしからの参照ポイント）を確認することで、より迅速かつ正確に評価を行うことができます。今回の提供開始により、Contact Lens 生成 AI を活用したエージェントパフォーマンス評価は、既存の米国東部（バージニア北部）、米国西部（オレゴン）リージョンを含む 8 つの AWS リージョンで利用できるようになりました。なお、評価対象の言語は現在英語をサポートしています。 関連リンク 管理者ガイド Amazon Connect now provides an API to update routing criteria on a queued contact (Amazon Connect にキュー内のコンタクトのルーティング条件を更新する API が提供) – 08/10/2024 Amazon Connect で、現在キューにあるコンタクトのルーティング条件を更新する API が提供されました。ルーティング条件を使用すると、特定の言語での習熟度などの属性に基づいて、特定の優先エージェントまたはエージェントのリストに対しコンタクトをターゲットにすることができます。この API を使用すると、キューに入っているコンタクトのルーティング条件を外部システムから直接更新できます。例えば、エージェントが顧客名などの属性に基づいて次にルーティングするコンタクトをキューから選択できるダッシュボードを構築し、この API を使用してルーティング指示をConnect に送信することができます。この機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Release Notes API Reference Amazon Connect now supports additional agent scheduling staffing rules (Amazon Connect が、追加のエージェントスケジューリング人員配置ルールのサポートを開始) – 08/06/2024 Amazon Connect で、労働、組合、その他の契約上のルールに従いながらエージェントを簡単にスケジュールできる追加のエージェントスケジューリングルールがサポートされました。これにより、Amazon Connect でエージェントのスケジューリングを行う際に、5 つの新しいルール (シフト間の最小休憩時間、1 週間あたりの最小休憩時間、連続勤務日数の上限、連続勤務日の上限) を設定できるようになりました。一度設定すると、これらのルールは新しいスケジュールが生成されたときだけでなく、既存のスケジュールを編集するときにも適用されます。これらの追加ルールにより、管理者はエージェントスケジュールに関する日々の管理が容易になります。この機能は、Amazon Connect スケジューリングが利用可能なすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now supports audio optimization for Amazon WorkSpaces cloud desktops (Amazon Connect が、Amazon WorkSpaces クラウドデスクトップに対するオーディオ最適化のサポートを開始) – 08/06/2024 Amazon Connect は、Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境で高品質の音声を簡単に提供可能になりました。Amazon Connect は、エージェントのローカルデスクトップから Connect にメディアをリダイレクトすることで音声を自動的に最適化し、エージェントの操作を簡素化し、ネットワークホップを減らすことで音質を向上させます。エージェントは、Windows デバイス、ウェブブラウザ、または Amazon WorkSpaces シンクライアント用の Amazon WorkSpaces クライアントアプリケーションにログインするだけで、Amazon Connect オープンソース JavaScript ライブラリの API を使用して、カスタムコンタクトコントロールパネルを使用した通話を開始できます。これらの新機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Release Notes Amazon Connect launches the ability to configure when whisper flows are used (Amazon Connect が、ウィスパーフローを使用するタイミングを設定する機能をリリース) – 08/03/2024 Amazon Connect では、フローのパフォーマンスを最適化するために、コンタクト中に ウィスパーフロー を使用するタイミングを設定する機能がサポートされました。ウィスパーフローは、お客様またはエージェントが音声またはチャットでお互いに接続されている間の体験を定義します。今回のリリースにより、ウィスパーフローをオフにできるようになったため、フローのパフォーマンスをさらに最適化し、コンタクト時間を短縮できます。たとえば、アウトバウンドまたはコールバックのシナリオではウィスパーフローをオフにして、エージェントとお客様が通話を開始するまでの時間を短縮できます。この機能は、Amazon Connect が提供されているすべての AWS リージョンで利用できます。 関連リンク 管理者ガイド Amazon Connect now enables agents to view pre-approved windows when scheduling time off (Amazon Connect で、エージェントが休暇をスケジュールする際に、事前に承認された期間を確認できるように) – 08/01/2024 Amazon Connect では、エージェントが自身のスタッフィンググループの事前に承認された休暇期間 (グループ許可) を確認できるようになりました。これにより、エージェントは休暇をリクエストするときに利用可能なオプションを簡単に特定できます。たとえば、午前 8 時から午後 12 時までの休暇申請を作成する場合、午前 8 時から午前 11 時までは利用可能なグループ許可があるが、午前 11 時から午後 12 時までの許可がないことを確認することができます。これに基づき、エージェントは提出前に休暇申請を変更したり、スーパーバイザーへ上書きをリクエストすることができます。今回の発表により、エージェントはリクエストを送信する前にどの日に必要な許可があるかを評価できるため、エージェントの休暇手続きが簡単になります。この機能は、Amazon Connect エージェントのスケジューリングが利用可能なすべての AWS リージョン で利用できます。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 2024 年の Amazon Connect の新機能 : カスタマーエクスペリエンスの変革に力を (日本語翻訳) 今日の急速に変化するビジネス環境において、優れた顧客体験を提供することは最重要課題です。顧客は、すべての接点で、シームレスでパーソナライズされたサポートを期待しており、これらの進化する要求に応えるため、企業は新しい方法を常に探し求めています。AI を活用したクラウドコンタクトセンターソリューションである Amazon Connect は、業界を問わず企業が最新の技術の進歩を活用し、エージェントを支援し、顧客データから洞察を抽出し、エンドユーザーを喜ばせるオムニチャネルサポートを提供できるよう支援しています。このブログでは、 Customer Contact Week (CCW) で発表されたものを含め Amazon Connect の最新の機能、そしてお客様サービスの提供を革新的に変えている先進的な企業の事例をご紹介します。 Manage cancelled callback to reduce agent handle time with Amazon Connect (英語記事) コールバックは、顧客が電話機を持ったまま待たせることなくキュー内の位置を予約できるため、コンタクトセンターでは重要な役割を果たします。これにより、待ち時間が短縮されてカスタマーサービスが強化されるだけでなく、電話のコストとエージェントの稼働率も最適化されます。コールバックが顧客によってリクエストされた場合、キャンセルされるか、顧客がエージェントに接続されるまでコールバックは キュー に残ります。このブログ記事では、すでにキューに入っているが不要となったコールバックを処理するさまざまな方法について説明します。さらに、顧客が以前にコールバックを要求したかどうかを確認し、複数のコールバックを設定できないようにする機能についても解説します。 CX Insights – Generative AI delivering results now (英語記事) 2023 年の夏、 生成 AI が正確で自動化された会話結果を顧客にいつ提供できるかという疑問が持たれていました。Gartner は 2023 年の Gartner® Market Trend Report において「2023 年にはバーチャルエージェントの投資が約 2％ だったが、2030 年までには人間のエージェントへの投資を上回るだろう」という戦略的計画の前提を置いています。現在はこのレポートから 1 年も経過していないことを考えると、バーチャルエージェントへの移行はさらに早く起こるかもしれません。生成 AI は、予想よりも早く企業規模の本番環境において、真の顧客体験（CX）の成果をもたらしつつあります。このブログ記事では、2023年の夏から実現可能性に関する疑問は何だったのか、そしてそれ以来どのような変化があったのかを解説します。 Enabling generative AI for better customer experience can be easy with Amazon Connect (英語記事) 生成 AI の話題は2024年になっても勢いは衰えることはありません。この注目すべきテクノロジーの新たなイノベーションと創造的なユースケースが日々登場しています。顧客体験 (CX) のユースケースにおける生成 AI の有望性は明確でエキサイティングです。ただし、新しいアイデアには、責任を持って安全に使用する方法と、結果を最大化する方法についての考慮事項があります。3 部構成となるブログシリーズの 第 1 部 では、生成 AI がコンタクトセンターの運営の 3 つの主要部分である、エージェント効率改善、分析と品質モニタリングの改善、顧客セルフサービスの改善にどのように影響するかについて説明しました。シリーズの 第 2 部 では、これら 3 つの領域、生成 AI の活用に伴う課題と、価値を最大化しながらリスクを軽減するためのアプローチ方法について詳しく説明しました。この第 3 部では、顧客サービスのユースケースで生成 AI を迅速かつ簡単に有効化する方法を紹介します。 Providing great customer experiences using real-time sentiment analysis with Amazon Connect (英語記事) コンタクトセンターのエージェントとスーパーバイザーは、顧客に対し常に優れたカスタマーサービスを提供するよう努めています。現代のコンタクトセンターでは、通常、自動音声応答 (IVR) システムが、サポートを求める顧客の最初の窓口となります。そのため顧客が IVR とやり取りしている間に、優れた顧客体験を提供することが重要です。しかしコンタクトセンターの運用チームは、顧客が IVR とやり取りしている間に顧客の意図を予測して適切なアクションを取るのに苦労することがよくあります。このような問題点があると、顧客は不満を抱き、問い合わせを適切に解決できないままコンタクトを切断してしまう可能性があります。このブログ記事では、 Amazon Connect を使用して組織が AI 主導の会話分析の力を活用し、発信者の感情を理解し、情報に基づいた意思決定をリアルタイムで下せるようにする方法を探ります。また、 Amazon Q in Connect がどのように生成 AI を使用してエージェントに顧客の質問への回答やアクションを提案し、より迅速な問題解決と顧客満足度の向上を実現するかについても説明します。 Elevating Amazon Connect digital enablement with learning plans and badges (英語記事) ペースの速いクラウドイノベーションの世界では、時代を先取りすることは困難な場合があります。 Amazon Connect では、お客様やパートナーに包括的で最新のトレーニングリソースを提供する必要性を認識しており、この度新しいデジタル支援戦略を再設計しました。学習プランは、AWS 教育を可能な限り最も効率的な方法で導くためのカスタマイズされたロードマップを提供します。1 つのアプリケーションやサービスに関連するすべての概念を学ぶのではなく、自分の役割を効果的に果たすのに役立つ複数のアプリケーション、サービス、製品に関する特定の概念だけを学ぶことになります。この学習アプローチは、目標とする役割に必要な分野のみに焦点を当てることにより、時間を節約します。 A repeatable approach to building contact centers with Amazon Connect (英語記事) 効果的なコンタクトセンターソリューションの導入は、特に独自の要件を持つ企業にとっては複雑です。このブログ記事では、発見、文書化、開発への標準化されたアプローチを含む基本的なプロセスの概要を説明しています。このアプローチに従うことで、企業は現在のニーズを満たし、長期にわたって簡単に維持および強化できる、信頼性が高くスケーラブルなコンタクトセンターを確立できます。 Standard Bank optimizes operational efficiency with Amazon Connect (英語記事) Standard Bank はアフリカ最大の銀行の 1 つで、5 万人以上の従業員を擁し、20 か国の 1,800 万人以上の顧客にサービスを提供しています。1862 年に設立された当行は、個人および企業向けバンキング、ウェルスマネジメント、アドバイザリーサービスなどを提供する大手ファイナンスサービス組織に成長しました。Standard Bank のコンタクトセンター業務は、多様な銀行ポートフォリオにわたるカスタマーサービスの提供を支えています。5,500 人以上のエージェントが年間 4,000 万件近くの顧客とのやり取りを処理しており、コンタクトセンターは重要なタッチポイントでした。しかし銀行が使用していたオンプレミスのコンタクトセンタープラットフォームがサポート終了を迎えたことにより、デジタルトランスフォーメーションの目標を達成する上で、大きなオペレーションリスクが生じました。このブログ記事では、Standard Bank が Amazon Connect を活用し、コンタクトセンターのモダナイズを実現し、顧客体験（CX）の向上やオペレーションの効率化など、様々な成果を上げた事例を紹介します。 Scale your contact center effectively with Amazon Connect and Service Quotas (英語記事) Amazon Connect のワークロードが増大するにつれて、お客様はスケーリングを効率的に管理し、デプロイの失敗やサービスの中断が制限を超えないようにするために、クォータを可視化する必要があります。Amazon Connect を サービスクォータ と統合することで、インスタンスのサービスクォータの管理が改善されます。サービスクォータは、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス （AWS CLI）のどちらを使用しても、クォータを効率的に管理および追跡するためのハブとして機能します。この統合により、Amazon Connect ではアカウントとリソースクォータ割り当てのナビゲートと最適化をより柔軟に制御できるようになります。サービスクォータを使用すると、Connect のクォータを 1 か所で管理できるため、複数のソースにアクセスする必要がなくなります。サポートされているクォータについては、 Amazon CloudWatch との統合により、設定可能なアラームによるプロアクティブな管理が可能になり、指定されたクォータに近づくとタイムリーにアラートが送信されます。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 Amazon Connect ソリューションアーキテクト 清水 幸典

本ブログは、KDDIアジャイル開発センター株式会社 プロダクトオーナーリード 佐々木 祥氏、同 エンジニア 大坪 悠氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 新谷 が共同で執筆しました。 KDDIアジャイル開発センター株式会社 （以下、KAG）は、サービスデザインとアジャイル開発手法によりビジネス創出からプロダクト開発を一貫してサポートするプロフェッショナル集団です。同社は Amazon Bedrock 統合の Slack チャットボット を開発する等、生成 AI を活用した社内外の課題解決に積極的に取り組んでいます。本ブログでは KAG の寄稿により、Amazon Bedrock を活用した営業支援プロダクト「議事録パックン」で、一連の営業活動を効率化し、営業知見の収集と利活用サイクルを構築した事例をご紹介します。実際に KDDI株式会社（以下、KDDI）の営業担当者が本プロダクトを利用し、議事録と提案書の作成時間を最大 1 時間短縮できるという効果が得られています。 導入背景 本事例は KDDI の営業社員が感じていた課題感を起点としています。営業活動は、過去のアプローチや商談結果に基づく知見を利活用して提案内容を検討することがありますが、この営業知見の原資となるのが個人の「日報」です。しかし、営業社員が忙しさから日報を書き残す時間を十分に取れなかったり、日報を収集して有効に利活用できるメカニズムを構築できていない点が課題でした。実際に、営業社員へのインタビューの中でも「議事録と日報作成の手間」や「情報共有が属人的」等の点に課題感を感じているという声が上がっています。そこで、KAG は日報の重要性とその作成負担を鑑み、日々の営業活動の自動収集・知見出力の自動化に取り組み、営業活動全体の業務フローを一気通貫で支援、改善できるプロダクトの開発を開始しました。 生成 AI で営業活動を一気通貫に支援「議事録パックン」 KAG は、営業活動の業務フローを生成 AI で一気通貫に支援するプロダクト「議事録パックン」を開発しました。日々の営業活動では ① 議事録作成を通じて活動履歴を残し ② 議事内容から商材検討の上顧客提案を行い ③ 日報・週報の作成通じて知見を利活用可能にする、というサイクルが重要です。各フェーズに対し「議事録パックン」は生成 AI を活用し ①’ 議事録生成機能 ②’ 提案骨子生成機能 ③‘ 日報・週報生成機能 を提供します。 1. 議事録生成機能 会議の録音・録画 ファイル、又は電話会議ツールの書き起こしテキストファイルをアップロードすることで、議事録を出力できる機能です。議事録は「参加者」「概要」「結論」「次回の議題」のように項目に沿って要点が提供されます。工夫した点として、一度出力された議事録に対しても、ユーザーが項目別に修正方針を入力し、再整形することが可能です。例えば「結論」の項目を「箇条書きにして」等と指示すると、指示に従って再整形した議事録を出力し直します。 2. 提案骨子生成機能 生成した議事録を活用し、提案骨子を出力できる機能です。ユーザーが案件名や対象とする議事録を入力すると、自動的に社内で保有している関連商材や他社の競合製品を検索し、比較表を生成します。このような流れで収集した情報に基づき、最終的には次回の顧客訪問に向けた提案骨子を生成します。 3. 日報・週報生成機能 日報・週報を出力できる機能です。ユーザーが期間を入力すると、案件毎にその期間で「議事録パックン」を通じて生成した情報に基づき活動履歴を要約し、日報・週報を生成します。 導入効果 実際に KDDI 営業担当にて本プロダクトを活用し評価を行なった結果、議事録と提案書の作成時間を最大 1 時間短縮することができました。また、生成された「議事録」「提案骨子」「日報」に対して「そのまま営業日報に使えるレベル」「部内の横展開もしやすく、業務品質は上がると思う」「提案材料を探す手間が減り、どう提案するかに力がさけるようになる」等のポジティブな声が多くあり、本プロダクトが営業活動を効率化し知見蓄積を促すために有効であることが確認できました。一方で、録音文化の醸成やファイルアップロードの待ち時間、具体的な知見の利活用などの観点での課題もフィードバックされており、これらの点は改善の余地があります。 アーキテクチャ 「議事録パックン」のプロジェクトは 企画から開発、評価に至るまで約 3 ヶ月で完了しました。そのうち、実際の開発期間は約 2 週間です。 Amazon Bedrock を中心に AWS マネージドサービスをフル活用したことで、短期間で生成 AI アプリケーションを開発することができました。そんな「議事録パックン」のアーキテクチャをご紹介します。 まず、議事録生成機能では、会議の音声データがアップロードされると、Amazon Elastic Container Service (ECS) で起動したコンテナが、Amazon Transcribe を呼び出して書き起こしテキストを取得します。このテキストを元に、 Amazon Bedrock の Claude 3 Opus に要約を指示して議事録を生成させます。議事録に対しユーザーから再整形を指示された際は、指示内容をプロンプトに付与して再度 Amazon Bedrock を呼び出します。提案骨子生成機能では、 LangChain の ReAct Agent を活用し、必要な社内外の情報を動的に取得しています。 Agent は、社内文書を格納している Amazon Bedrock Knowledge Bases から自社商材を検索する Tool や、他社製品や業界情報を取得するために Google 検索を行う Tool を使いながら、提案商材の検討・比較を行います。最終的には、取得した情報と議事録に基づき提案骨子を生成します。生成された情報は Amazon DynamoDB に蓄積し、日報・週報生成機能で利用しています。ユーザーに指定された期間の生成物を Amazon Bedrock に要約させることで、日報・週報を生成します。運用面では、 Langfuse を活用し、生成内容をトレースしながら評価やプロンプト管理ができるようにしました。 所感と今後の展望 Claude3 Opus の日本語生成精度が大変優秀だったため、当初時間を要すると思われた LLM のプロンプトやコンテキストの入れ方に関するチューニングがほぼ不要であった点が開発を一段と簡単にさせました。特に議事録生成機能は利用部門で好評となっており、営業メンバー本人が書く議事録と遜色がないレベルとのコメントも頂いております。プロダクト開発初期から Langfuse などのオブザーバビリティにも力をいれていた点も、開発速度向上に繋がりました。オブザーバビリティについては、より一層 Amazon Bedrock との親和性が高いマネージドサービスが出てくることを期待したいです。 （KDDIアジャイル開発センター株式会社 エンジニア 大坪 悠氏） 今回は議事録生成および議事内容から推測される次の打ち手の骨子程度の提案までにとどまりましたが、今後はさらにその先の、会社の戦略・ビジョンに関わる提案の支援や、プレゼン資料自体の作成等まで発展させ、利益創出の原動力となるプロダクトを目指したいです。その上でエージェント機能の進展は欠かせないと感じています。 AWS らしいカスタマイズ性は残しつつ、多岐にわたる知見の自律的活用が可能な AI 機能拡張に期待したいです。 （KDDIアジャイル開発センター株式会社 プロダクトオーナーリード 佐々木 祥氏） まとめ 本ブログでは、KDDIアジャイル開発センター株式会社の Amazon Bedrock 活用事例「議事録パックン」をご紹介しました。議事録や日報作成といった、日々の活動記録・レポートに上手く生成 AI の力を取り入れることで、営業活動全体を効率化しています。社内業務の課題を起点とした生成 AI ユースケースとして、皆様の参考になれば幸いです。 著者 佐々木 祥 KDDIアジャイル開発センター株式会社 ビジネスデザイン部 プロダクトオーナーリード 大坪 悠 KDDIアジャイル開発センター株式会社 開発5部 エンジニア 新谷 歩生 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ シニアソリューションアーキテクト

今日の変化の激しいデジタル環境においては、企業や開発者が Web アプリケーションを迅速かつ安全にデプロイする効率的な方法を常に求めています。 AWS Amplify Gen2 は、 GitLab の堅牢なバージョン管理システムと組み合わせることで、このチャレンジに対する効果的なソリューションを提供します。 AWS Amplify Hosting では様々な リポジトリの選択肢 をサポートしていますが、このブログでは GitLab をリポジトリとして使う AWS Amplify Hosting でのアプリケーションのデプロイ方法をご紹介します。 AWS Amplify Gen2 は、フロントエンド開発者が AWS 上でフルスタック アプリケーションを構築する方法を提供しています。TypeScript、ファイル規約、Git ブランチベースの環境を使用して、フロントエンドとバックエンドを定義できます。GitLab の強力なバージョン管理および継続的インテグレーションと継続的デプロイ (CI/CD) 機能と組み合わせることで、このソリューションは Web アプリケーションのシームレスで自動化されたデプロイを可能にし、一貫性を確保し、手動操作によるエラーのリスクを低減します。 このブログでは、GitLab をリポジトリとして使用し、AWS Amplify Hosting をデプロイプラットフォームとして使用して Web アプリケーションをデプロイするプロセスを説明します。このワークフローの簡素さと効率を活用する方法を学び、AWS Amplify Gen 2 がデプロイの複雑さを処理しながら、優れたアプリケーションの構築に集中できるようになります。 前提条件 はじめに必要な作業は次のとおりです。 GitLab アカウントと プロジェクト を作成する: GitLab に登録し、新しいプロジェクトを作成します。 IDE を開く: お好みの開発環境を起動します。 React TypeScript + Vite アプリと Amplify Gen 2 バックエンドをセットアップする: ターミナルでコマンド npm create vite@latest react-amplify-gen2 -- --template react-ts を使用して、Vite で TypeScript を使用する新しい React アプリを作成します。 コマンド cd react-amplify-gen2 で新しく作成したディレクトリに移動し、 npm install でプロジェクトの依存関係をインストールします。 npm create amplify@latest を実行して、GitLab リポジトリで Amplify Gen2 を設定します。このコマンドは、GitLab リポジトリで Amplify Gen2 の設定を検出するために不可欠です。 AWS アカウントを設定 し、Amplify で使用するために AWS プロファイルをローカルに設定します。 変更をコミットしてプッシュする セットアップが完了したら、 変更をすべてコミット し、GitLab リポジトリにプッシュします。 前提条件を完了した後、以下の手順を実行します。 AWS Amplify Hosting にホストするアプリケーションの作成 GitLab アカウントへの AWS Amplify のアクセスを承認 リポジトリとして GitLab を使用したサンプルアプリのデプロイ React アプリケーションを AWS Amplify Hosting にホスティングする方法 始めるには、 Amplify コンソール にサインインしてください。AWS Amplify のホームページから始める場合は、図 1 に示されているように、ページの上部にある Create new app を選択します。 図 1: AWS Amplify で新規のアプリケーション作成 すでに存在する Amplify アプリがある場合は、単に All apps タブから Create new app を選択します (図 2)。まず初めに、ソースコードプロバイダを選びましょう。図 3 に示すように、Choose source code provider ウィンドウで GitLab を選択してください。 図 2: AWS Amplify で新規のアプリケーションを追加 GitLab をソースコードプロバイダとして選択したら、下にスクロールして 次へ を選択してください。 まずはリポジトリブランチを追加しましょう。AWS Amplify は GitLab にサインインしてアクセス許可を得るためのポップアップウィンドウを開きます (図 4)。 前提条件の手順 1 「GitLab アカウントとプロジェクトを作成」で作成した資格情報を使って GitLab にサインインしてください。 図 3: AWS Amplify でソースコードプロバイダの選択 GitLab アカウントにサインインすると、認証ページにリダイレクトされます。 GitLab 認証ページで、図 5 で示すように Authorize を選択してください。 図 5: GitLab アカウントに AWS Amplify がアクセスできるように承認 注意 — Amplify コンソールを Bitbucket、GitLab、または AWS CodeCommit で認証すると、Amplify はリポジトリプロバイダからアクセストークンを取得しますが、そのトークンは AWS サーバーに保存されません。Amplify は特定のリポジトリにインストールされているデプロイキーを使用してリポジトリにアクセスします。 次に、 Add repository branch (図 6) でリポジトリとブランチを選択します。Amplify Gen 2 は、Nx や Yarn Workspaces などのモノレポツールを使用したフルスタックビルドのための monorepo ワークフローをサポートしていることに注目する価値があります。 図 6: AWS Amplify でリポジトリとブランチを選択 リポジトリブランチを追加するための必須項目を入力したら、 Next を選択してください。 アプリケーション設定を見直しましょう。AWS Amplify は自動的にアプリ名、フロントエンドのビルドコマンド、ビルド出力ディレクトリを設定し、必要なサービスロールを作成します。 また、必要に応じてアプリ名、フロントエンドのビルドコマンド、ビルド出力ディレクトリなど、Amplify が設定した項目を変更することもできます (図 7)。 図 7: AWS Amplify でアプリケーションの設定をレビュー AWS Amplify コンソールの Service role と Advanced settings  を確認してください。サービスロールは、ユーザーに代わってアクションを実行するために必要です。 また、高度な設定では、デフォルトのビルドコンテナを使用するか、 自身で作成したコンテナーイメージ を使用することもでき、環境変数を追加したり、アプリケーションのためのパッケージやツールのインストール済みバージョンを上書きすることができます。 終わったら、 Next  を選択してください。 アプリケーションの詳細を確認しましょう。アプリケーションをデプロイする前に設定ミスがある場合は、修正することができます。修正が必要なフィールドでは Edit を選択してください (図 8)。 図8: AWS Amplify 経由でデプロイする前のアプリの詳細と設定の確認 Save and deploy  を選択してください。 AWS Amplify が Web アプリケーションをデプロイするのに数分かかります。 図 9: ホスティングされたアプリへのアクセス アプリケーションをデプロイしたら、 Visit deployed URL を選択するか、 Domain の下に提供された URL にアクセスすることで、図 9 のように Web アプリケーションを表示できます！ アプリケーションコードの更新 (オプション) Amplify Hosting をコード リポジトリに接続すると、各コミットで、アプリケーションフロントエンドとバックエンドの両方をデプロイするワークフローが 1 つトリガーされます。この方法により、フロントエンドとバックエンドの不整合を防ぐために、Web アプリケーションは正常にデプロイされた後にのみ更新されます。 IDE で App.tsx ファイルに移動し、コンテンツを自分のコードで置き換えてください。アプリケーションコードを更新したら、変更をコミットしてプッシュしてください。 数分後、変更がデプロイされます。 クリーンアップ このブログで作成したリソース (含む GitLab プロジェクト ) を削除しないと、追加料金が発生する可能性があるので注意してください。 AWS Amplify コンソール に移動し、このブログで作成したアプリケーションについて View App  を選択します。 次に App settings に移動し、その後 General settings  を選択します。 最後に Delete app を選択して、アプリケーションと関連リソースを削除します (図 10)。 図 10: AWS Amplify アプリの削除 終わりに このブログ記事では、開発者が GitLab と AWS Amplify Hosting を使用して Web アプリをデプロイする方法を説明しました。GitLab のような Git プラットフォームと統合することで、AWS Amplify はデプロイメントを効率化し、効率的な CI/CD パイプラインの簡素化に重点を置きます。AWS Amplify Gen 2 は monorepo、ブランチデプロイ、カスタムパイプラインなど、さまざまなフルスタックワークフローをサポートしており、ウェブアプリを素早くデプロイできます。AWS Amplify Gen 2 の機能を活用し、デプロイプロセスを合理化するには、 AWS Amplify Gen 2 ドキュメント を参照し、実践的な AWS Amplify Gen 2 ワークショップ を試し、 AWS Amplify Hosting コンソール にアクセスして開始してください。 著者について Ben-Amin York Jr. Ben-Amin is a Solutions Architect at AWS, specializing in Frontend Web & Mobile technologies. He focuses on the impact of AI/GenAI/ML across industries and provides technical guidance to enterprise customers in the Automotive & Manufacturing sector to achieve their business goals. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。