TECH PLAY

AWS

AWS の技術ブログ

3138

この記事は Unlock data insights across multi-party datasets using AWS Entity Resolution on AWS Clean Rooms without sharing underlying data (記事公開日: 2024 年 7 月 25 日) を翻訳したものです。 マーケティングと広告テクノロジーの領域は、消費者のメディアや販売チャネルの分断化、新たなプライバシー規制、そして AI を活用した顧客エンゲージメントへの急速なシフトによって変革期を迎えています。様々な業界の企業がパーソナライズされた顧客体験と最適化された広告キャンペーンの提供を目指していますが、サイロ化されたデータ、重複データ、あるいはデータの欠如により、リアルタイムのユースケース実現に苦心しています。 Gartner の調査 によると、顧客の 360 度理解 (Customer 360) を実現するための統合された顧客プロファイルを持つ企業はわずか 14 %に留まっています。既存顧客の統合プロファイルを保有している企業であっても、広告パートナー (マーケター、パブリッシャー、代理店、ISV など) と連携した新規顧客獲得のプロセスは、上述の逆風に直面しています。 ファーストパーティデータのマッチングと連携の必要性は、業界専門家が「シンギュラリティ」と呼ぶ時期を推進しており、クラウドコンピューティング、最新のデータアーキテクチャ、人工知能 (AI) 、機械学習 (ML) のイノベーションに支えられ、マーケティングと広告テクノロジーの融合が進んでいます。この融合により、アイデンティティ解決とプライバシー強化技術 (データクリーンルームなど) が注目を集めています。これらは、2 者以上の参加者が合意した場合において、ファーストパーティデータを分析でき、かつデータアクセスの制限を確実に実施できる、安全な共同作業環境として機能します。 企業は Amazon Web Services (AWS) の支援を受けて、これらのトレンドに対応しながらイノベーションを進めています。 AWS Entity Resolution は、企業が複数のアプリケーション、チャネル、データストアにまたがる関連レコードのマッチング、リンク、拡張を容易に行えるようにし、データ品質を向上させることで、顧客をより深く理解し、効果的なエンゲージメントを実現することを支援します。 AWS Clean Rooms は、企業とそのパートナーが、お互いの基礎となるデータを共有またはコピーすることなく、より簡単かつ安全にデータセットの分析と共同作業を行うことを可能にします。AWS Clean Rooms を使用することで、数分で安全なデータクリーンルームを作成し、AWS を利用する他の企業と連携して、広告キャンペーン、投資判断、研究開発に関するユニークなインサイトを生成することができます。 本日、AWS Entity Resolution が AWS Clean Rooms にネイティブ統合されたことを 発表しました 。これにより、企業はルールベースまたはデータサービスプロバイダーベースのマッチング手法を使用して、AWS Clean Rooms のセキュアなコラボレーション環境内で、自社の顧客レコードとパートナー企業のレコードをマッチングすることが可能になります。数回のクリックだけで、企業とそのパートナーは関連レコードのマッチング、安全な分析、データセットの共同活用を行うことができ、オーディエンスの構築、キャンペーン計画の改善、キャンペーン効果の測定が可能になります —— これらすべてを生データを互いに共有することなく実現できます。 「消費者のプライバシー保護は、広告・マーケティング業界における最優先事項であり続けています。私たちは、AWS Entity Resolution と AWS Clean Rooms の革新的な統合を大変心強く感じています。この統合により、Affinity Solutions は購買データの連携が容易になり、プライバシーを保護しながらパートナーとのマッチ率を向上させることが可能になります。これにより、金融・小売業のお客様の新規顧客獲得とロイヤリティ向上につながる、より深いインサイトを得ることができます。」 Affinity Solutions, Vice President of Business Development, Logan Moore 氏 このブログ記事では、AWS Clean Rooms における AWS Entity Resolution 機能の利点について説明し、広告・マーケティング分野での主要なユースケースを紹介します。さらに、コラボレーターとのデータマッチングを向上させるための、データ準備とマッチングの開始方法の詳細についてご紹介します。 AWS Entity Resolution on AWS Clean Rooms AWS Clean Rooms への AWS Entity Resolution ネイティブ統合により、企業はコラボレーション内でルールベースまたはデータサービスプロバイダーベースのマッチング手法を利用できるようになりました。AWS Clean Rooms でデータがマッチングされる際、企業は、コラボレーター間のデータセットで一致したデータを含む ID マッピングテーブルに適用されるプライバシー強化ルールのメリットを享受できます。AWS Clean Rooms は各 ID マッピングテーブルを分析ルールで保護し、コラボレーションのメンバーがテーブルの内容を直接照会したり、確認したりすることを制限します。 ルールベースマッチングでは、コラボレーター間のデータセットを準備・マッチングするための、すぐに使用可能でカスタマイズ可能なルールを提供します。企業は、AWS Entity Resolution が提供するノーコードのルールベースマッチングエンジンをマッチングロジックに活用することができます。設定可能なマッチングルールで関連する識別子を結合してデータをマッチングすることで、時間を節約でき、マッチングロジックをより細かく制御することが可能になります。 データサービスプロバイダーベースのマッチングでは、LiveRamp などの信頼できるデータサービスプロバイダーのデータセットや ID を、AWS Clean Rooms のコラボレーション内で直接マッチングすることができます。これにより、企業はデータサービスプロバイダーからマッチング結果を生成し、それらをコラボレーションに関連付けるための ETL パイプラインを構築する必要がなくなります。 ユースケース Media Planning (メディアプランニング) : 広告主とパブリッシャーは重複するオーディエンスを分析することができ、広告計画と投資の最適化に役立ちます。 Audience Activation (オーディエンスアクティベーション) : 広告主はパートナーと協力して顧客の 360 度ビューを形成し、 AWS Clean Rooms ML を使用したオーディエンスモデリングのために、より正確なシードデータを作成できます。 Media Measurement (メディア測定) : 測定プロバイダーとパブリッシャーは広告の投資対効果を示すことができ、広告主とエージェンシーが特定のキャンペーン成果を理解することを支援します。広告主はメディア企業から提供されるコンバージョンやトランザクションイベントを分析することで、アトリビューションの追跡と理解を向上させることができます。 サービス概要 AWS Clean Rooms への AWS Entity Resolution ネイティブ統合により、企業は数分でデータコラボレーション環境を作成できます。コラボレーションメンバーは、自社のファーストパーティレコードを持ち込み、他のコラボレーターのファーストパーティレコードとマッチングすることができます。 例えば、広告主がアトリビューションを分析・理解するために、パブリッシャーが配信したインプレッションに対するコンバージョンやトランザクションイベントを分析したい場合があります。 パブリッシャー (下図の Company A) は、AWS Clean Rooms のコラボレーションを作成し、AWS Entity Resolution を使用してデータのインデックス作成と準備を開始します。これにより、データフォーマットの標準化、重複の削除を行い、マッチングと分析に適したデータセットを準備します。パブリッシャーは、このコラボレーションの作成前に AWS Entity Resolution を使用して既に準備を完了している場合を除き、パートナーとのマッチングの前にデータの準備を行う必要があります。 広告主 (下図の Company B) は、AWS Clean Rooms のコラボレーションに参加し、AWS Entity Resolution を使用してパブリッシャーとのレコードマッチングのワークフローを開始します。データマッチングの前に、広告主は必要に応じて AWS Entity Resolution を使用してデータの準備を行うことができます。 図 1 : AWS Clean Rooms における AWS Entity Resolution を活用した、パブリッシャーと広告主の連携フローの詳細図 ルールベースマッチング AWS Clean Rooms でのルールベースのエンティティマッチングは、以下の 5 つのステップで設定できます: コラボレーションの作成または参加 : 企業が AWS Clean Rooms のコラボレーションを作成し、メンバーを招待します。 ID ネームスペース の作成 : コラボレーションに参加する各企業は、AWS Clean Rooms から AWS Entity Resolution を使用して顧客データを関連付け、ID ネームスペースを作成する必要があります。 ID ネームスペースの関連付け : 各コラボレーションメンバーは、それぞれの ID ネームスペースを AWS Clean Rooms のコラボレーションに関連付けます。 ID マッピングテーブル の作成 : コラボレーションメンバーが AWS Clean Rooms でエンティティマッピングのワークフローを開始します。このワークフローの出力として、AWS Clean Rooms で利用可能な ID マッピングテーブルが作成されます。 AWS Clean Rooms でのクエリ実行 : すべてのメンバーで合意されたコラボレーション制約に基づき、参加者はプランニングや測定などの様々なユースケースのために AWS Clean Rooms でクエリを実行できます。ID マッピングテーブルは、コラボレーションメンバーによって追加された任意の分析ルールタイプ (リスト、集計、またはカスタム SQL) を含む設定済みテーブルと組み合わせて、クエリを実行することができます。 図 2 : ルールベースマッチングを選択した場合の 5 ステップのワークフローを示すアーキテクチャ図 データサービスプロバイダーベースマッチング AWS Clean Rooms でのデータサービスプロバイダーベースのマッチングは、以下の 5 つのステップで設定できます: コラボレーションの作成または参加 : 企業が AWS Clean Rooms のコラボレーションを作成し、メンバーを招待します。 ID ネームスペース の作成 : コラボレーションに参加する各企業は、AWS Clean Rooms から AWS Entity Resolution を使用して顧客データを関連付ける必要があります。AWS Entity Resolution において、企業はトランスコードしたい RampID のセットを指定するための ID ネームスペースを作成します。ID ネームスペースは、コラボレーションの各顧客が RampID のセットを参照し、トランスコードの方向に応じたロールを選択するために作成するリソースです。トランスコードを開始したい顧客は「ソース」を選択し、他のコラボレーターは「ターゲット」を選択します。 ID ネームスペースの関連付け : 各コラボレーションメンバーは、それぞれの ID ネームスペースを AWS Clean Rooms のコラボレーションに関連付けます。 ID マッピングテーブル の作成 : トランスコードを開始するコラボレーションメンバー (例:広告主) が ID マッピングテーブルを作成します。 AWS Clean Rooms でのクエリ実行 : コラボレーションメンバーは、ID マッピングテーブルを使用して、キャンペーンのプランニングや測定など、様々なユースケースのために AWS Clean Rooms でクエリを実行できます。この ID マッピングテーブルは、SQL JOIN ステートメントのみに分析を制限する、事前定義された不変の分析ルールセットを持つコラボレーションで使用されます。さらに、企業は AWS Clean Rooms ML と組み合わせて ID マッピングテーブルを使用し、類似オーディエンスモデリングのシードデータソースとして SQL クエリを受け入れることができます。 図 3 : データサービスプロバイダーベースのマッチングを選択した場合の 5 ステップのワークフローを示すアーキテクチャ図 まとめ 本記事では、企業が基礎データを互いに共有することなく、ルールベースおよびデータサービスプロバイダーベースのマッチング手法を使用し、広告キャンペーンのプランニング、類似モデリング、測定などのユースケースに向けて、コラボレーターのデータセットと容易にマッチングを行う方法をご紹介しました。 AWS Clean Rooms における AWS Entity Resolution の詳細については、当社の Web サイト をご覧いただくか、 プライバシー保護に配慮したデータ連携の専門家 にお問い合わせください。 関連資料 AWS Entity Resolution on AWS Clean Rooms pricing AWS Clean Rooms User Guide AWS Entity Resolution Web サイト 著者について Sid Patel Sid は、Amazon Web Services のプロダクトリードです。AWS Entity Resolution や AWS Clean Rooms を通じて、データコラボレーションとインサイトの分野でお客様を支援することに注力しています。 Archna Kulkarni Archna は、Amazon Web Services のシニアソリューションアーキテクトとして、金融サービスとデータ変革技術の分野で専門知識を有しています。AWS に入社する前は、フォーチュン 100 に選出される金融サービス組織でデジタルトランスフォーメーション責任者を務めていました。長年の業界経験とドメイン知識を活かし、お客様のデータ統合と変革の取り組みを支援しています。また、熱心なマラソンランナーでもあり、ニューヨークシティマラソンでの経験が最も思い出深いマラソン体験となっています。 Natasha Templeton Natasha は、Amazon Web Services の AWS Entity Resolution におけるビジネスデベロップメントリードです。 Shobhit Gupta Shobhit は、Amazon Web Services でプロダクト部門の統括責任者を務めています。ヘルスケア、小売、金融サービス、公共セクターなど、幅広い業界における機械学習向けデータ管理サービスの開発に精通しています。AWS では、AWS Clean Rooms、 Amazon Connect、 AWS Entity Resolution、 Amazon Personalize など、データと機械学習を融合したサービスの開発チームを率いています。モバイルアプリ、ビッグデータ、IoT 分野で複数の企業を成長させた 10 年以上の起業家経験を持ち、さらに経営コンサルタントとして公共機関、医療機関、小売企業への助言も行ってきました。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。
本記事は 2024年9月11日に公開された ” Migration to AWS Cloud WAN multi-Region inspection using service insertion ” を翻訳したものです。 はじめに AWS Cloud WAN はリリース以来、多くのお客様から関心を集め、数々の機能強化が行われてきました。2024年6月11日に発表された機能である Service Insertion は、一元化されたポリシー設定を使用して AWS およびサードパーティのネットワークおよびセキュリティサービスを AWS Cloud WAN に簡単に組み込むことができる新機能です。この機能を使用すれば、シンプルなポリシーステートメントを定義するか、UI で数回の操作を行うだけで、VPC 間、VPC とオンプレミス間、またはインターネットへのトラフィックをネットワークやセキュリティアプライアンスを経由するように簡単にルーティングできます。Service Insertion の詳細については、「 Simplify global security inspection with AWS Cloud WAN Service Insertion 」で説明されています。 現在、ほとんどのお客様は、各リージョンに集中型インスペクションを配置したマルチリージョン構成を採用しています。この記事では、以下の移行を段階的に行う方法ついて解説いたします。: Transit Gatewayで構成された集中型セキュリティインスペクションから、移行中の接続性を維持しダウンタイムを最小限に抑えた Service Insertion を使用した AWS Cloud WAN への移行。 Service Insertion を使用していない AWS Cloud WAN の構成から、Service Insertion を使用した構成への移行。 AWS Transit Gateway は、Amazon Web Services (AWS) のネットワーキングソリューションにおいて不可欠な存在であり、Virtual Private Cloud (VPC)、Virtual Private Network (VPN)、およびオンプレミスネットワーク間をスケーラブルかつ効率的に接続します。この記事は、ポリシーベースの管理、ワンクリックでのセグメンテーション、AWS ネイティブな自動化などの AWS Cloud WAN の特定の機能を利用したいと考えているお客様を対象としています。本記事では、AWS の環境内でこれらの機能を採用する際の洞察や考慮点を解説します。読者の皆様には、意思決定の前に、自社のネットワークへのニーズを評価し、利用可能なオプションを検討することをお勧めします。 ソリューション概要 AWS Cloud WAN Service Insertion は、ファイアウォールなどのネットワークサービスを通信経路に挿入する際の複雑さを解消します。これは、シンプルなインテントベースの ポリシーステートメント を設定するか、UI で数回のクリックを行うことで、トラフィックをインスペクション VPC にリダイレクトすることが可能です。 この機能では、インスペクション VPC アタッチメントを統合的に管理する Network Function Group (NFG) と呼ばれる新しい構成要素が導入されています。NFG は、ポリシーで定義された管理者の意図に基づいて、通信を目的のファイアウォールへリダイレクトするように制御します。これには、セグメント間およびセグメント内、VPC 間、リージョン間、オンプレミスと VPC 間、さらに VPC またはオンプレミスからインターネットへのトラフィックが含まれます。Service Insertion を使用することで、NFG と経路伝播が自動管理されるため各リージョンのインスペクションセグメントの設定やトラフィックリダイレクト用のスタティックルートの設定を管理する複雑さが解消されます。 Service Insertion の使用に対する追加料金は発生せず、通常の AWS Cloud WAN の料金 のみが適用されます。 前提条件 以下のセクションでは、AWS の基本的なネットワーク構成要素(Amazon VPC、AWS Transit Gateway、AWS Cloud WAN、AWS Network Firewall)について理解していることを前提としています。 初期構成及び各サービスのデプロイ手順の詳細には焦点を当てず、以下の構成をテスト環境にデプロイしていることを前提とします。そのため、初期構成として以下のサービスの事前デプロイが必要です。: シナリオ1:ワークロード用 VPC、AWS Network Firewall を含むインスペクション VPC、AWS Transit Gateway、および関連するルートテーブル、アタッチメント、ピアリングをデプロイして下さい。 シナリオ2:ワークロード用 VPC、AWS Network Firewall を含むインスペクション VPC、Service Insertion を含まない AWS Cloud WAN、および関連するセグメント、アタッチメント、ルーティングをデプロイして下さい。 移行のユースケース シナリオ1:Transit Gateway から Service Insertion を含む AWS Cloud WAN への移行 このシナリオでは、Transit Gateway と集中型インスペクションをベースとするアーキテクチャから、Service Insertion を利用する AWS Cloud WAN への移行について解説します。 現状構成(AWS Cloud WAN を使用していない) マルチリージョン環境において、一般的に採用されるアーキテクチャは、各リージョンにデプロイしたTransit Gatewayをピアリングアタッチメントで相互接続し、それぞれ集中型インスペクションを行う構成です。アーキテクチャは実績が豊富であり、動作が予測し易く、必要に応じてトラフィックをインスペクション VPC にリダイレクトできる利点があります。これはリージョン間トラフィックにおいて、ピアリング接続を経由するトラフィックは、セグメンテーションポリシーに準拠している場合のみファイアウォールで許可されます。ただし、このアーキテクチャでは多数のスタティックルートの管理が必要であり、多くの場合、二重のインスペクションにより追加コストが発生します。 アーキテクチャ図1は、2つのリージョンと、セグメント化された2つのワークロードを示しています。例として、本番環境と非本番環境のワークロードを使用していますが、他の種類のセグメンテーションでも問題ありません。これは多くのお客様が採用している構成のため、本記事ではこれを初期構成として使用します。 図1: Transit Gateway とセキュリティインスペクションを使用したマルチリージョン環境 フェーズ1: AWS Cloud WAN のデプロイと Transit Gateway ピアリングの確立 図2に示すように、最初のステップとして両方のリージョンに AWS Cloud WAN のコアネットワークをデプロイし、各リージョンの Transit Gateway とのピアリングを作成します。 図2: Transit Gateway ピアリングを使用した AWS Cloud WAN のデプロイ 「 Deploying hybrid networks using AWS Cloud WAN and AWS Direct Connect 」および「 Achieving traffic segmentation in multi-AWS Region environments using AWS Transit Gateway and AWS Cloud WAN 」では、フェーズ1(図2)に示されている設定の詳細について解説しています。 次のフェーズに進むにはポリシーの変更を適用する必要があります。ただし、この段階ではまだセグメント、アタッチメント、またはルーティングを設定していないため、既存のルーティングに変更はありません。リージョン間の通信は引き続き Transit Gateway のピアリングを経由します。 フェーズ2: セグメントの構成と Transit Gateway ルートテーブルアタッチメントの作成 次のステップは、2つのリージョンの Transit Gateway に構成された本番環境と非本番環境のルートテーブルを、AWS Cloud WAN 上に拡張することです。これにより、各リージョン内で定義されたセグメンテーションをコアネットワーク全体に拡張できます。この結果、リージョン間のセグメンテーションを維持するためにファイアウォールを通過させる必要がなくなります。ホップ数が減少することでパフォーマンスが向上し、同一セグメント内のトラフィックに関連するインスペクションと処理の料金も削減できます。 これを実現するには、AWS Cloud WAN でセグメントを作成し、両方のリージョンで関連するルートテーブルアタッチメントを設定する必要があります。この構成の詳細については、フェーズ1で紹介したブログ記事で解説されているため、本記事では解説しません。 図3: コアネットワーク全体への本番環境と非本番環境のセグメントの拡張 us-east-1 の Transit Gateway 上の本番環境のルートテーブルは、現在コアネットワーク経由で eu-west-2 の本番環境 VPC の経路を学習しており、その逆も同様です。これらは図3のルートテーブルで赤色で示されています。非本番環境のルートテーブルについても同様です。 これは、図3の紫色の矢印で示すように、 us-east-1 の本番環境 VPC から eu-west-2 の本番環境 VPC へのトラフィックが AWS Cloud WAN を経由することを意味します。これは、Transit Gateway のルートテーブルがより詳細な経路を学習した為であり、この経路は直接接続されていない VPC へのトラフィックをインスペクション VPC を経由するように初期設定したデフォルトルートよりも優先されます。 デフォルトルートの代わりにより詳細なスタティックルートを設定していた場合は、トラフィックを AWS Cloud WAN 経由で送信するためにこれらを削除する必要があります。これは、同じプレフィックスの場合、スタティックルートが動的に学習された経路よりも優先されるためです。非対称ルーティングを避けるため、両方のリージョンでルーティングを調整する必要があります。詳細については、Transit Gateway ドキュメントの ルート評価 のセクションを参照してください。 ただし、現時点では本番環境と非本番環境のワークロード間のトラフィックは引き続きデフォルトルートに一致します。リージョン間トラフィックについては、Transit Gateway に接続されたインスペクション VPC を経由し、Transit Gateway 間のピアリングを経由して転送されます。 以下は、本番環境と非本番環境の Transit Gateway ルートテーブルおよび VPC アタッチメントを、それぞれのAWS Cloud WAN セグメントに関連付けるために必要なコアネットワークポリシー設定の例です: Core networkコアネットワークポリシー "segments": [ { "name": "Production", "Isolated": "False" }, { "name": "Non-Production", "Isolated": "False" } ], "attachment-policies": [ { "rule-number": 100, "description": "Production VPCs", "conditions": [ { "type": "tag-exists", "key": "Segment", "operator": "equal-to", "value": "Production" } ], "action": { "add-to-segment": "Production" } }, { "rule-number": 200, "description": "Non-Production VPCs", "conditions": [ { "type": "tag-exists", "key": "Segment", "operator": "equal-to", "value": "NonProduction" } ], "action": { "add-to-segment": "NonProduction" } } ] Transit Gateway ルートテーブルアタッチメントの設定 本番環境と非本番環境の両方のルートテーブルに対して、Transit Gateway ルートテーブルアタッチメントを設定します。図4は、 us-east-1 の本番環境ルートテーブルに対する設定方法を示しています。残りのルートテーブルについても同様の設定を行ってください。アタッチメントのタグがコアネットワークポリシーで定義されたアタッチメントポリシーと一致することを確認してください。 アタッチメントを設定する前に、まずポリシーの変更を適用する必要があります。これによって既存のルーティングが変更されることはありません。ただし、アタッチメントを作成すると、新しい経路が伝播され、上記で解説したようにルートが変更されます。 図4:Transit Gateway ルートテーブルアタッチメントの設定 フェーズ3:NFG の設定とインスペクション VPC のアタッチ この段階では、AWS Cloud WAN で NFG を設定し、アタッチメントポリシーを使用して2つの新しいインスペクション VPC を NFG に追加します(図5)。ファイアウォールアプライアンス(図示されている AWS Network Firewall )の設定はこの記事の範囲外です。詳細については、ドキュメントの「 Getting started with AWS Network Firewall 」を参照してください。 図5:NFG の設定とインスペクション VPC のアタッチ 2つの新しいインスペクション VPC をデプロイする理由は、インスペクションを経由するセグメント間の通信を Transit Gateway から AWS Cloud WAN に移行する際にダウンタイムを最小限に抑えるためです。また、移行中は既存構成をそのまま残しておき、必要に応じてロールバックできるようにします。すべての VPC を AWS Cloud WAN に正常に移行した後は、AWS Cloud WAN 内のインスペクション VPC のみ残します。 NFG の作成とインスペクション VPC 用のアタッチメントポリシーの設定例を、以下の JSON ポリシーに示します: Core network policy "network-functions-group": [ { "name": "InspectionVpcs", "require-attachment-acceptance": false } ], "attachment-policies": [ { "rule-number": 500, "description": "Service Insertion Inspection VPCs", "conditions": [ { "type": "tag-exists", "key": "Network-Function-Group", "operator": "equal-to", "value": "InspectionVpcs" } ], "action": { "add-to-network-functions-group": "InspectionVpcs" } } ] インスペクション VPC アタッチメントの設定 図6に示すように、 us-east-1 と eu-west-1 リージョンの両方のインスペクション VPC を NFG にアタッチするよう設定します。アタッチメントのタグがコアネットワークポリシーで定義されたアタッチメントポリシーと一致することを確認し、 Appliance mode support が選択されていることを確認してください。 アタッチメントを設定する前に、まずポリシーの変更を適用する必要があります。アタッチメントを設定した後もこの段階ではルーティングは変更されません。 図6:NFG へのインスペクション VPC アタッチメントの設定 フェーズ4:リージョン間インスペクションを AWS Cloud WAN に移行 このフェーズでは、リージョン間のセグメント間トラフィックを AWS Cloud WAN 上の NFG を通るように転送します。図7のルートテーブルと紫色の矢印で示されているように、Service Insertion が新しいインスペクション VPC を通してトラフィックを送信します。 デフォルトでは、Service Insertion はリージョン間のすべてのトラフィックに対して単一のインスペクションポイントを選択します。この場合、デフォルトで選択されるインスペクション VPC は us-east-1 です(各リージョンペアに対してインスペクション VPC を指定することも可能です)。もう一方は、バックアップとして使用されます。単一のインスペクションポイントを使用することで、パフォーマンスが向上し、従来のデプロイメントで通常実装されていた二重インスペクションの必要性を排除することで、インスペクションと AWS Cloud WAN 処理の両方に関連するコストをさらに削減できます。 図7:Service Insertion を使用したリージョン間インスペクションの AWS Cloud WAN への移行 本番環境と非本番環境のセグメント間にインスペクションを挿入 Service Insertion を使用して、本番環境と非本番環境のセグメント間のトラフィックの通信経路にインスペクションポイントを挿入します。これは、以下の例に示すように、ポリシーに send-via ステートメントを追加することで実現できます。send via セグメントアクションの詳細については、 AWS Cloud WANのドキュメント を参照してください。 { "segment-actions": [ { "action": "send-via", "segment": "Production", "when-sent-to": { "segments": [ "Non-Production" ] }, "via": { "network-function-group": [ "InspectionVpcs" ] } } ] } 本番環境と非本番環境のセグメント間の双方向の通信を検査するには、単一の send-via セグメントアクションで十分です。非本番環境セグメントから本番環境へ向かうトラフィックに対して別のステートメントを設定する必要はありません。 図7の Transit Gateway ルートテーブルを確認し、赤で示された経路のように、本番環境のルートテーブルでコアネットワークから他のリージョンの非本番環境 VPC への経路を学習していることがわかります。同様に、非本番環境のルートテーブルも、他のリージョンの本番環境 VPC への経路をコアネットワークから学習しています。これは、Service Insertion と NFG セグメントが、先ほど定義したセグメントアクションの send-via ポリシーに基づいて、これらの経路を動的に伝播しているためです。 これらの経路は、初期構築で設定したリージョン間トラフィックを Transit Gateway にアタッチされたインスペクション VPC に送信するスタティックルートを上書きし、代わりに NFG にアタッチされたインスペクション VPC にトラフィックを送信します。ただし、同一リージョン内では、本番環境と非本番環境の VPC 間のトラフィックは、次のフェーズで解説するように、一方または両方のワークロード用 VPC が AWS Cloud WAN に移行されるまで、引き続き Transit Gateway にアタッチされたインスペクション VPC を経由します。 この段階でポリシーの変更を適用する必要があります。変更が適用されると、ルーティングの再収束と新しい経路の伝播が発生し、一部の通信において短時間中断する可能性があります。したがって、中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。 フェーズ5:VPC を Transit Gateway から AWS Cloud WAN に移行 この段階では、すべてのリージョン間トラフィックが AWS Cloud WAN 上を通過し、セグメント間のトラフィックの場合は NFG にアタッチされたインスペクション VPC を経由してルーティングされます。ここで、本番環境と非本番環境の VPC を Transit Gateway から AWS Cloud WAN の対応するセグメントに移行を開始します。万が一の設定ミスで多くのVPCに影響を与えるリスクを最小限に抑えるために、この移行は段階的に行うことを推奨します。 VPC を Transit Gateway から AWS Cloud WAN に移行する方法の詳細については、「 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns 」で解説されています。 図8は、非本番環境 VPC を Transit Gateway から AWS Cloud WAN へ移行し、更新されたルートテーブルと通信フローを示しています。 図8:VPC を AWS Transit Gateway から AWS Cloud WAN に移行 非本番環境 VPC が Transit Gateway から AWS Cloud WAN に移行されると、非本番環境セグメントはそれらの Classless Inter-Domain Routing(CIDR)を学習します。また、フェーズ2で設定したアタッチメントを通じて、これらの CIDR を Transit Gateway 上の非本番環境ルートテーブルに動的に伝播します。これにより、移行された VPC とまだ Transit Gateway 上にある VPC 間の到達可能性を維持しながら、段階的な移行が可能になります。 同様に、これらの経路は Service Insertion と NFG を介して AWS Cloud WAN 上の本番環境セグメントと Transit Gateway 上の本番環境ルートテーブルにも動的に伝播されます。Transit Gateway 上の本番環境ルートテーブルは、AWS Cloud WAN から学習した非本番環境 VPC 向けのより具体的な経路を持つようになるため、Transit Gateway にアタッチされたインスペクション VPC を指すデフォルトルートよりもこちらを優先します。したがって、トラフィックは AWS Cloud WAN を通じて NFG とそれにアタッチされたインスペクション VPC を経由し、非本番環境 VPC にルーティングされます。これは図8の青い矢印で示されており、紫の矢印はリージョン間のセグメント間通信を示しています。 VPC を Transit Gateway から AWS Cloud WAN に移行すると、ルーティングの再収束と新しい経路の伝播が必要となり、一部の通信が短時間中断する可能性があります。したがって、ここでも、中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。 フェーズ6:移行の完了 すべてのワークロード用 VPC が移行され、すべてのテストが正常に完了したら、図9の最終状態アーキテクチャに示されているように、古いインスペクション VPC と Transit Gateway を安全に削除できます。なお、NFG ルートテーブルはマネージドであり、Service Insertion ポリシーに基づいて自動的に経路設定されます。これらの経路は表示できますが、経路を追加、削除、または共有することはできません。 図9:最終構成と AWS Cloud WAN ルートテーブル シナリオ2:既存の AWS Cloud WAN のリージョン毎のインスペクションから Service Insertion への移行 このシナリオ(図10)では、スタティックルートを使用してリージョン毎のインスペクション VPC にトラフィックをリダイレクトする AWS Cloud WAN の構成から Service Insertion を使用する構成へ移行する方法について解説します。 図10:初期構成:リージョン毎のインスペクションセグメントを持つAWS Cloud WAN(Service Insertion なし) ステップ1:AWS Cloud WAN ネットワークポリシー UI でNFG を作成します(図11)(図12)。 図11:ポリシーの作成 – NFG 図12:NFG の作成 ステップ2:アタッチメントポリシーにルールを追加して、インスペクション装置(ファイアウォールなど)を含む1つ以上のアタッチメントを NFG にマッピングします。ここでは、Key: Network-Functions-Group、Value: InspectionVpcs を使用します。これは後で、インスペクション VPC をリージョン毎のインスペクションセグメントから新しく作成された NFG に移行する際に使用します。 図13:NFG 用の新しいアタッチメントポリシーの作成 ステップ3:シナリオ1で解説したように、本番環境と非本番環境のセグメント間の通信をインスペクション VPC にルーティングするには、これら2つのセグメントに対して Service Insertion ポリシーを作成する必要があります。図14と15は、UI での作成方法を示しています: 現在のポリシーバージョンを編集し、Service Insertion に移動して「作成」をクリックします Action で「Send via」を選択し、Mode で「Single hop」を選択します Segment form で「Production」を選択し、Segment To で「NonProduction」を選択します 「Send traffic via」で NFG を選択します このユースケースでは必要ないため、Edge overridesセクションは空のままにします 図14:Service Insertion の作成 図15:Service Insertionの設定 次に進むにはポリシーの変更を適用する必要があります。これによる既存のルーティングや通信への影響はありません。 ステップ4:Service Insertion が作成され、ポリシーが適用されたら、インスペクション VPC を NFG に移行します。そのためには、リージョン毎のインスペクションセグメントへの既存のアタッチメントを変更し、新しいタグを追加して古いタグを削除する必要があります。これにより、アタッチメントがリージョナルインスペクションセグメントから新しく設定された NFG に関連付けられるように変更されます。 図16:アタッチメントタグの更新 ステップ2で作成したアタッチメントポリシーに一致するタグ(Key: Network-Functions-Group、Value: InspectionVpcs)を追加し、リージョン毎のインスペクションセグメント用に割り当てていたタグ(Key:segment、Value: InspectionUSWest2)を削除します。 図17:新しいタグの追加と古いタグの削除 タグが更新されると、ルーティングの再収束と新しい経路の伝播が必要となり、一部の通信が短時間中断する可能性があります。そのため中断を最小限に抑えてスムーズに移行するために、これらの設定をスケジュールされたメンテナンスウィンドウ中に適用することがベストプラクティスです。 インスペクション VPC へのアタッチメントが NFG アタッチメントポリシーに変更され、「 Available 」になっていることを確認します。 図18:アタッチメントが更新されたことの確認 ステップ5:この段階で、トラフィックは Service Insertion と NFG を使用して動的にインスペクション VPC にルーティングされます。リージョン毎のインスペクションセグメントに関連する設定はもう使用しないため安全に削除できます。 まず、AWS Cloud WAN セグメントの設定から、これまでリリージョン毎のインスペクション VPC アタッチメントにトラフィックを送信していたスタティックルートを削除します。 図19:スタティックルートの削除 古いリージョン毎のインスペクションセグメント用のアタッチメントポリシーを削除します。 図20:リージョン毎のインスペクションセグメント用のアタッチメントポリシーの削除 リージョン毎のインスペクションセグメントを削除します。 図21:リージョン毎のインスペクションセグメントの削除 図22は、インスペクション用に NFG と Service Insertion が設定された最終状態を示しています。 図22:Service Insertion を使用した最終状態 考慮事項 この記事では Egress インスペクションについては扱っていません。Egress が East-West インスペクションと組み合わさる場合、send-to セグメントアクションを使用する等の追加の考慮事項が必要になります。 移行を開始する前に、すべてのファイアウォールに同じセキュリティポリシーが適用されていることを確認して下さい。 AWS Direct Connect を接続している場合など、一部のユースケースでは、Transit Gateway をそのまま維持する必要があります。※ 訳者注: 2024年11月25日より、AWS Cloud WAN は AWS Direct Connect ゲートウェイアタッチメントをネイティブでサポート しています。但し一部のリージョンは 2025年2月26日時点で未サポートですのでご注意下さい。サポートリージョンの情報は こちら をご参照ください。 ワークロード用 VPC を AWS Transit Gateway から AWS Cloud WAN に移行する際、VPC のルートテーブルのターゲットを Transit Gateway からコアネットワークに更新する必要があります。 この記事では、Transit Gateway の本番環境および非本番環境のルートテーブルでデフォルトルートを使用してトラフィックをインスペクション VPC にルーティングしている事を前提としています。代わりに VPC 固有のスタティックルートを使用している場合(例:リージョン間トラフィック)、トラフィックが AWS Cloud WAN 上を経由するには、これらを削除する必要があります。これは、同じプレフィックスに対して、スタティックルートが動的に学習された経路よりも優先されるためです。非対称ルーティングを避けるため、両方のリージョンでルーティングを調整する必要があります。 クリーンアップ このブログでデプロイしたリソースを削除するには、以下の手順に従ってください: 作成した Cloud WAN のアタッチメント、ピアリング、コアネットワークを削除します。 Cloud WAN アタッチメントの削除 Cloud WAN ピアリングの削除 AWS Cloud WAN コアネットワークの削除 AWS Cloud WAN グローバルネットワークの削除 作成した Transit Gateway とアタッチメントを削除します。 Transit Gateway への VPC アタッチメントの削除 Transit Gateway の削除 EC2 インスタンス、AWS Network Firewall、VPC を含む初期構成のリソースを削除します。 結論 ネットワークインスペクションは、クラウド実装において重要な役割を果たします。ポリシーベースの管理、ワンクリックのセグメンテーション、ネイティブな自動化など、AWS Cloud WAN の利点を活用しようとするお客様は、特にインスペクションポイントへのトラフィックのルーティングにおいて、安全かつ円滑に移行することへの課題を持つことがあります。 この記事では、Service Insertion がどのように移行をスムーズにし、中断を最小限に抑え、全体的な効率性を高めることができるかを解説しました。また、スムーズかつ安全に実装するための段階的な手順についても解説しました。 詳しい情報については、 AWS Cloud WAN Service Insertion をご覧ください。 翻訳は Technical Account Manager の米山 京佑が担当しました。原文は こちら です。
効果的なコンタクトセンターソリューションの導入は、特に独自の要件を持つ企業にとって複雑な場合があります。このブログ記事では、要求分析、文書化、開発に関する標準化されたアプローチを含む基本的なプロセスを概説します。このアプローチに従うことで、企業は現在のニーズを満たす信頼性が高く拡張可能なコンタクトセンターを確立でき、時間経過後も容易に保守および強化することができます。 要求の発見と要件定義 Amazon Connect によってコンタクトセンターを構築する最初のステップは、ユースケースの作成、つまり顧客のペルソナによって製品やサービスが潜在的に使用されうる具体的な状況を明らかにし、ビジネスニーズと要件を徹底的に調査することです。ビジネスアナリスト(BA)は、技術開発者のビジネスの仕組みの理解促進を支援する重要な役割を果たします。「エージェントはどのような種類の問い合わせ(音声、チャット、各種テキスト)を処理するか」、「エージェントは特定の問い合わせに対して特別なスキルを持っているか」、「営業時間や休日はどのようになっているか」といった運用上の疑問があります。技術変革の場面では、現在のソリューションのエージェント、その業務、運用時間について単に尋ね、最終的に知ったことを再現に陥りがちです。技術を変革する際、現行ソリューションのエージェント、その業務、運用時間について単純に調査し、その結果をそのまま再現してしまうことがあります。しかし、この機能的な同一性に基づくアプローチでは、コンタクトセンターの変革に対する、ビジネスリーダーが求めている目的を理解する機会を逃す可能性があります。例えばリーダーは、 生成 AI を活用したセルフサービスソリューションを実装して通話やクエリに対応 し、エージェントの作業負荷を軽減しながら、顧客とのやり取りにおける満足度を確保することを構想しているかもしれません。このような落とし穴を避けるためには、ビジネス要件と長期的な戦略的ビジョンをより深く掘り下げる、包括的なアプローチを取ることが重要です。 運用設計における標準化されたアプローチ この記事で紹介するアプローチの重要な要素は、シンプルで補完的かつ反復可能な標準化された開発運用サイクルです。このプロセスは、ビジネス、開発、品質の三位一体なしでは機能しません。ビジネスアナリストは Amazon Connect を使う開発者とペアを組み、ユースケース開発を中心とした発見フェーズを主導します。まず彼らは協力してビジネスの実用最小限の製品として要件を満たす設計を作成します。設計後、品質保証エンジニア(組織内から参画可能な場合は参画させることを強く推奨)は、テストケースを構築し、時として主観的なプロセスに客観的な声を提供するため、設計を深く掘り下げます。組織に品質管理チームがない場合、ビジネスアナリストの役割を担う誰かが代わりにこの重要なプロセスを行います。開発者がソリューションをテストした後、テストまたはユーザー受け入れ環境に展開されます。開発 – テスト – バグ修正 – 再テストのサイクルには特定の繰り返し回数はありません。設計で合意された実用最小限の製品の機能が完成するまで、このサイクルは必要な回数だけ継続します。いずれの環境でのテストも、エンドユーザーとしてソリューションを体験する機会であり、開発チームにフィードバックを提供して、彼らのバージョンのソリューションがビジネスニーズを満たしていることを確認します。ビジネス側の承認が得られたら、本番環境に向けてソリューションを準備し、必要に応じて再度サイクルを繰り返します。 発見(Discovery)、設計(Design)、開発(Development)、テスト(Test)、ユーザー受け入れ(User Acceptance)の大まかなで高レベルな概要を以下に示します : 発見 : BA は、ビジネスユニットのコンタクトフローなど業務要件を収集するために、既存のドキュメントを確認します 設計 : 開発者は、ビジネスユニットの要件を満たすソリューションを設計します 開発 : 開発者は、合意された設計に基づいてコンタクトフローを開発します テスト : QA テスターは、ソリューションが設計パラメータを満たしていることを確認するため、テストを実施します ユーザー受け入れ : BA は、ソリューションが彼らのニーズを満たしていることを検証するために、ビジネスユニットと ユーザー受け入れテスト(UAT)を実施します 組織変更の管理 Amazon Connect のようなクラウドベースのコンタクトセンタープラットフォームへの移行には、慎重な 組織の変更管理 が重要です。製品のサポートを受ける側から提供する側への移行は、オーナーシップの移行を意味します。責任あるオーナーシップには、組織内の人材、現在使用しているプロセス、そして目指す製品の責任の所在について内部的な検討が必要です。まずは「成功とは何か」という問いに答えるためのビジネス戦略の検討から始めることをお勧めします。AWS の オンラインドキュメント や ブログ を確認し、カンファレンスやワークショップに参加し、それらの経験を活かして製品ビジョンとサポート戦略を策定してください。適切な人材はいますか? 製品ロードマップはありますか? 製品ロードマップの完了まで予算は確保できていますか? 変更管理には、エグゼクティブスポンサー、プロジェクトマネージャー、そして専門知識を持つ機能/コンポーネントの所有者など、主要な関係者の役割と責任を明確に定義した階層構造の確立を推奨します。同様に重要なのは、従業員の懸念に対応し、賛同を得て、組織全体での導入を推進するための綿密なコミュニケーション計画です。 Amazon Connect のセンターオブエクセレンス Amazon Connect の実装の成功を持続させるために、 Amazon のクラウドセンターオブエクセレンス と同じ原則を用いた専門のセンターオブエクセレンス(CoE)を確立することをお勧めします。この中央集権的なガバナンスモデルは、ベストプラクティス、継続的なサポート、そして継続的な改善とイノベーションのためのフレームワークを提供します。CoE は、複数の技術部門とビジネス部門にわたる効率的な知識共有とコラボレーションを促進し、時間とともにコンタクトセンターを最適化できるようチームの能力を高めます。CoE には、以下のようなさまざまな専門的な役割とスキルセットを持つ人々を含める必要があります : コンタクトセンター業務のエキスパート : コンタクトセンターの運営、カスタマーエクスペリエンス戦略、人員管理について深い知識を持つ熟練の専門家です。全体的なビジョンとロードマップを導くための専門知識を提供します。 技術スペシャリスト: Amazon Connect 環境の設計、実装、保守を担当する開発者、アーキテクト、DevOps エンジニアです。技術基盤が堅牢で、スケーラブルで、ベストプラクティスに沿ったものであることを確保します。 変更管理とトレーニングのリーダー:ユーザー採用を推進し、抵抗に対処し、組織の能力を構築するための戦略を開発・実行する変更管理の専門家です。また、コンタクトセンターチームのスキル向上のためのトレーニングプログラムを監督します。 継続的改善と分析のエキスパート:パフォーマンスを継続的に監視し、最適化の機会を特定し、コンタクトセンターにデータ駆動型の改善を実装するデータアナリストとプロセス改善のスペシャリストです。 まとめ 企業は、この包括的で標準化されたアプローチに従うことで、 Amazon Connect を活用したコンタクトセンターをより効率的に、反復可能なステップで設置し、再利用可能な成果物を作成することができます。このフレームワークは、発見、設計、開発、組織変更における主要な課題に対応し、組織が独自の要件を満たす、カスタマイズされた効率的なコンタクトセンターソリューションを迅速に確立できるようにします。 コンタクトセンターの変革において、ほとんどの企業は使用するプラットフォームの決定や調査に時間とお金をかけています。Amazon は 豊富なコンタクトセンターリソース 、 顧客事例 、そして変革の支援サービスである AWS プロフェッショナルサービス を提供しています。Amazon Connect は業界をリードするコンタクトセンタープラットフォームです。特に特別な点は、実装、運用、利用に関わる人々です。彼らがクラウドへの移行を実現する推進者となります。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか? お問い合わせください。 筆者について Corey Miller は、AWS プロフェッショナルサービスのシニアエンゲージメントマネージャーです。彼の職務は、お客様向けの導入プランを策定し、AWS、AWS パートナー、お客様チーム間の相乗効果を生み出すことです。AWS に入社する前は、米空軍に 28 年間勤務していました。Corey は旅行、ゴルフ、そして妻と 2 人の娘と過ごす時間を楽しんでいます。 Ramesh Natarajan は 15 年の業界経験を持つ Amazon Connect コンサルタントです。彼は Amazon Connect 向けの最先端 AI/ML アプリケーションの構築を専門とし、生成 AI の変革的な可能性を活用できるコンタクトセンターソリューションの提供を担当しています。仕事以外では、ランニング、スポーツ、そして様々なガーデニングプロジェクトに取り組み、活動的に過ごしています。また、2 人の娘との時間を大切にしています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。
こんにちは!ソリューションアーキテクト(SA)の白石( @piko_san_0000 )です! 2025 年 1 月 30 日に「 2025クラウドガバナンスはこう変わる!マルチアカウント運用のre:Invent最新情報と活用例 」と題したイベントを開催しました、その開催報告と資料公開のお知らせです。 ( AWS Startup Loft Tokyo はスタートアップとデベロッパーのための施設で、定期的に様々なイベントを開催しています) 本イベントは、皆さんのクラウドの運用を楽にし、将来のビジネスの成長を阻害させないための「仕組みづくり」に役立つ情報をお届けすることを目的としています。 クラウドガバナンスとは、クラウド環境を「安全」かつ「効率的に管理したい」というニーズに応えるための領域です。AWS においては、このクラウドガバナンスを楽にするために AWS Organizations、 AWS Control Tower をはじめとしたマルチアカウント管理のための仕組みを提供していますが、各社が実際にどのように運用しているのかについての情報共有の場は多くはありませんでした。 本イベントのセッションでは、AWS アカウントの運用やセキュリティのエキスパートである各社にご登壇頂いた他、昨年の re:Invent 最新アップデート情報をお届けしました。 関連サービス・領域:AWS Organizations、AWS Control Tower、AWS Config、AWS Security Hub、マルチアカウント運用、セキュリティ アジェンダ ビジネス成長を阻害しないために新しく AWS アカウントを作成した人がやるべきこと  資料 re:Invent 2024 から見る AWS マルチアカウントガバナンスのこれまでとこれから  資料 【お客様登壇】少数精鋭で200+アカウントを支える!弥生の「CSGO活動(Cost、Security、Governance、Other)」とは  資料 【お客様登壇】AWS Organizations で実現する、マルチ AWS アカウントのルートユーザー管理からの脱却  資料 【お客様登壇】スタートアップとセキュリティ対策  資料 持続可能なクラウドガバナンス運用: スモールステップと生成AIで始める運用効率化  資料 セッションの紹介 「ビジネス成長を阻害しないために新しく AWS アカウントを作成した人がやるべきこと」 北川 友稀:AWS ソリューションアーキテクト 資料リンク (写真:AWS ソリューションアーキテクト 北川) 初めのセッションでは、SA 北川より、ビジネス成長を阻害させないための AWS アカウントのベストプラクティスについて解説しました。ビジネスが成長した後に、AWS アカウントの運用設計を見直すのは手間がかかります。少しの手間をかけて、AWS アカウント管理における「やっておけばよかった」を先行して解決しておくことで、将来のビジネス成長に備えることができます。マルチアカウントによる環境分離や、マルチアカウント管理を楽にする AWS Control Tower など、AWS アカウントの運用についてこれから考えたい方、悩まれている方は、ぜひ上記の資料リンクをご確認ください。 「re:Invent 2024 から見る AWS マルチアカウントガバナンスのこれまでとこれから」 大西 朔:AWS ソリューションアーキテクト 資料リンク (写真:AWS ソリューションアーキテクト 大西) SA 大西からは re:Invent 2024 のクラウドガバナンス関連のアップデートをご紹介しました。AWS Organizations・AWS Control Tower のこれまでのアップデートを振り返るとともに、今回のアップデートにより追加された新しいポリシー概念である「 RCPs(リソースコントロールポリシー) 」「 宣言型ポリシー(Declarative Policies) 」によって実現できること・ユースケースをお伝えしました。Organizations 上で従来の SCP(サービスコントロールポリシー)と同様、OU・アカウント単位にこれらの新しいポリシーを直接設定できる他、これらの新しいポリシーは AWS Control Tower の予防コントロールとしても設定できます。 「少数精鋭で 200+ アカウントを支える!弥生の「CSGO活動(Cost、Security、Governance、Other)」とは」 弥生株式会社 開発本部 サービスプラットフォーム部 商用インフラチーム 峯岸 純也 様、五十嵐 大旭樹 様、今泉 和馬 様 資料リンク (写真:弥生株式会社 峯岸 様) (写真:弥生株式会社 五十嵐 様) (写真:弥生株式会社 今泉 様) 弥生株式会社様では、2021 年 8 月よりシングルアカウント運用からマルチアカウント運用に切り替えられ、現在 222 アカウントを少数精鋭のチームで管理されています。「コスト最適化」「セキュリティ強化」「ガバナンス強化」「未来を実現するためのインフラ基盤整備」の4つの軸で、自動化やガイドライン整備、部を横断した施策の普及活動による効率化を進めてこられました。AWS Security Hub スコア向上のための自動修復、オートメーション機能による自動抑制、ガバナンス強化のための SIEM on Amazon OpenSearch Service によるログ収集や AWS IAM Identity Center での AWS アカウントへのアクセス許可の自動化や、アカウント利用チームへの Slack 自動通知など。これまで取り組まれてきた具体的な施策についてご紹介いただきました。 数百以上の AWS アカウントの運用を見据えている企業や担当者にとって必見となる Tips 集です。 (株式会社弥生様が以前投稿された「100アカウントを見据えたAWSマルチアカウント運用」の資料は こちら ) 「AWS Organizations で実現する、マルチ AWS アカウントのルートユーザー管理からの脱却」 STORES株式会社 テクノロジー部門 技術推進本部 エンジニア 浅野 大我 様 資料リンク (写真:STORES 株式会社 浅野 様) STORES 株式会社様からは、昨年発表された AWS Organizations 「ルートアクセスの一元管理」の機能を最速で活用された取り組みについて、お話頂きました。 IAM Identity Center のシングルサインオン機能によりユーザ管理が簡素化された一方で、ルートユーザの管理は依然として個別に管理する必要があり、煩雑だと感じられる方も多いはず。この解消といえる新機能 「ルートアクセスの一元管理(Root Access Management)」 が2024 年 11 月に登場 し、STORES 様では一早くこの新しい機能を活用し、本番運用に移行されました。ルートユーザのパスワード管理・MFA デバイスの管理が不要になり、アカウント払出しと管理コストの削減につながったお話は、ルートユーザの管理を簡素化したい皆様必見です。 (STORES様が以前投稿された Product Blog の記事は こちら ) 「スタートアップとセキュリティ対策」 SecureNavi株式会社 新規事業本部⻑ 川畑 秀和 様 資料リンク (写真:SecureNavi 株式会社 川畑 様) SecureNavi 株式会社様からは、IPO の準備をされているスタートアップや新規事業を始める方向けに、セキュリティ対策として何から着手するべきか、セキュリティの専門家の観点からお話いただきました。近年のセキュリティインシデントの傾向や、ISMS 認証やプライバシーマーク取得におけるプロセスや課題について、これからまさに取得を考える企業や担当者にとって知っておきたい要点をまとめてお伝えいただきました。 2025 年 1 月より、SecureNavi 様の SecureNavi サービスが AWS マーケットプレイス からも利用可能になっています。 ISMS 認証と P マークを効率よく取得・運用、または統合管理したいと考えているお客様向けのクラウドサービスです。 「持続可能なクラウドガバナンス運用: スモールステップと生成AIで始める運用効率化」 鈴木 陽三:AWS ソリューションアーキテクト 資料リンク (写真:AWS ソリューションアーキテクト 鈴木) AWS Security Hub や Amazon GuardDuty を有効化したものの、検知量の多さに疲弊してしまったり、運用に難しさを感じるケースもあるのではないでしょうか。 SA 鈴木からは、スモールスタートで始めるための考え方や生成 AI を用いた運用効率化のアイディアをお伝えしました。 AWS Security Hub、Amazon GuardDuty では重要度の高いものをフィルタリングして通知する他、生成 AI を用いてわかりやすいサマリー通知を行うためのプロンプトの例を挙げて解説しました。(Amazon GuardDuty では、 re:Invent 2024のアップデートにより、重要度別に検出結果をソートする機能や、最も重大な問題の概要を明示する機能が追加されており、このあたりの優先順位をつけた運用がやりやすくなる機能がアップデートされています) こちら、AWS Startup Loft Tokyo の会場の様子です。当日は多くのお客様にお越しいただきました。 イベントにご参加・ご協力いただいた全ての皆様、ありがとうございます。 クラウドガバナンスは、組織の成長を安全に支え、加速させるための仕組みです。 今後もこの領域における最新情報を発信する場を作っていきますので、またぜひご参加ください。 著者 白石 一乃(Ichino Shiraishi) Solutions Architect Amazon Web Services, Inc (X: @piko_san_0000 )
2 月 20 日に開催された AWS Developer Day 2025 では、責任ある生成 AI を開発ワークフローに統合する方法が紹介されました。このイベントでは、Director Generative AI Applications and Developer Experiences の Srini Iragavarapu 、Vice President of AWS Evangelism の Jeff Barr 、Director Open Source Marketing of AWS の David Nalley などの AWS リーダーのほか、 AWS ヒーロー やテクニカルコミュニティメンバーによる基調講演が行われました。 Developer Day 2025 のイベント録画全編をぜひご視聴ください。 今から 2025 年 3 月 6 日まで、2025 年の AWS Cloud Club Captain プログラム の 申請を受け付けています 。AWS Cloud Club は、18 歳以上の高等教育機関の学生および自主研究を行なっている学生を対象とした、学生主導のグループです。 Meetup ページ でお近くのクラブを検索してください。 2 月 17 日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amplify Hosting がサーバーサイドレンダリング (SSR) アプリケーションの IAM ロールのサポートを発表 – AWS Amplify ホスティング は、SSR アプリケーションの AWS Identity and Access Management (IAM) ロールのサポートを開始しました。これにより、認証情報を手動で管理することなく、AWS サービスに安全にアクセスできるようになりました。詳細については、「 AWS Amplify ホスティングを使用したサーバーサイドレンダリングの IAM コンピューティングロール 」ブログをご覧ください。 AWS WAF がデータ保護とログ記録機能を強化 – AWS WAF が データ保護 機能を拡張しました。これにより、ログが WAF サンプルログ、Amazon Security Lake、Amazon CloudWatch、またはその他のログ記録の宛先に送信される前に、ログ内の機密データを暗号化ハッシュ (‘ade099751d2ea9f3393f0f’ など) または事前定義された静的文字列 (‘REDACTED’) に置き換えられるようになりました。 AWS DMS Serverless の包括的な移行前評価の発表 – AWS Database Migration Service Serverless (AWS DMS Serverless) では、データベースの移行が始まる前に潜在的な問題を特定するために、レプリケーションの移行前評価のサポートを開始しました。このツールは、ソースデータベースとターゲットデータベースを分析し、最適な DMS 設定とベストプラクティスに関する推奨事項を提供します。 Amazon ECS が ECS タスクの CPU 制限を 192 vCPU に増加 – Amazon Elastic Container Service (Amazon ECS) は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにデプロイされた ECS タスクについて、以前の 10 vCPU から増加した最大 192 vCPU の CPU 制限のサポートを開始しました。この機能強化によって、お客様はより大規模な Amazon EC2 インスタンスのリソース割り当てを、より効果的に管理できるようになります。 AWS Network Firewall が自動ドメインリストとインサイトを導入 – AWS Network Firewall では、30 日間の HTTP/S トラフィックを分析することによる、自動ドメインリストとインサイトの提供を開始しました。これによって、追加費用なしで、許可リストポリシーをより効率的に作成および管理できます。 AWS が請求書のバックアップ支払い方法を発表 – AWS では、一次支払いが失敗した場合に、自動的に有効になるバックアップ支払い方法を設定できるようになりました。これにより、サービスの中断を防ぎ、請求書の支払いに手間をかける必要がなくなります。 「 AWS の新着情報 」ページで、AWS のすべての発表をご確認ください。 AWS のその他のニュース その他の注目すべき項目は次のとおりです。 AWS パートナーネットワーク: ISV パートナー向けの必須トレーニングリソース – AWS はソリューションの効果的な拡張をサポートできるように、 AWS Marketplace の基礎、 ファンデーショナルテクニカルレビュー (FTR) 、 APN カスタマーエンゲージメント (ACE) プログラムおよび 共同販売 、 パートナー資金調達 の機会という 4 つの主要分野に関する重要なトレーニングリソースを、ソフトウェアベンダー (ISV) パートナー向けに提供しています。 Formula 1®、生成 AI を使用してレース当日の問題解決を加速 – Formula 1® (F1) は、 Amazon Bedrock を使用してレース当日の問題解決を加速しています。根本原因を分析して修正を提案するチャットボットを通じて、トラブルシューティングにかかる時間を数週間から数分に短縮しました。 Amazon Bedrock ナレッジベースを使用した検証済みセマンティックキャッシュによる LLM エージェントのハルシネーションの削減 – このブログでは、 Amazon Bedrock ナレッジベース と Amazon Bedrock エージェント を使用して、新しい回答を生成する前に、クエリをキュレーション済みの回答と照合する検証済みセマンティックキャッシュを実装することで、大規模言語モデル (LLM) のハルシネーションを削減し、精度と応答時間を改善するソリューションをご紹介します。 Amazon Bedrock のツールを使用したインテリジェントな文書処理ワークフローのオーケストレーション – このブログでは、Amazon Bedrock ツールを使用したインテリジェントな文書処理ワークフローをご紹介します。このワークフローは、オーケストレーション用の Anthropic の Claude 3 Haiku と、分析用の Anthropic の Claude 3.5 Sonnet (v2) を組み合わせて、構造化、半構造化、非構造化の医療文書を効率的に処理します。 community.aws より community.aws から、私が個人的に気に入っている記事をご紹介します。 Amazon Bedrock エージェントのトレース – Randy D による、AWS X-Ray を使用して Amazon Bedrock エージェントのワークフローを追跡および分析し、オブザーバビリティを向上させる方法をご覧ください。 AWS FIS を使用した Amazon ECS ネットワーク耐障害性のテスト – この記事では、 Amazon Q Developer のガイダンスをもとに、AWS FIS を使用して、Amaon ECS のネットワーク耐障害性をテストする方法をご紹介します。Sunil Govindankutty のプロフィールページごとに、Amazon ECS でネットワーク耐障害性をテストする方法を、 Sunil Govindankutty がご説明します。 AWS Lambda 関数でのデフォルト引数の使用を停止 – 一般的な Python プログラミング手法が原因で AWS Lambda のコストが制御不能になる理由について、 Stuart Clark がご説明します。 AWS の Amazon Nova プロンプトエンジニアリング: Brooke によるフィールドガイド – Brooke Jamieson による、AWS でのプロンプトエンジニアリングパターンとベストプラクティスを網羅した、Amazon Novaモデルを使用するためのフィールドガイドをご覧ください。 Amazon Q を使用した EKS のデプロイ設定の作成 – Amazon Q Developer は、Kubernetes 設定のテンプレートとベストプラクティスを提供することで、EKS デプロイの作成を支援します。 Ricardo Tasso による記事をご覧ください。 Amazon Bedrock エージェントによる WhatsApp マルチメディアの処理: 画像、動画、ドキュメント – 私の最新のブログでは、Amazon Bedrock モデルと Amazon Nova モデルを使用して WhatsApp AI アシスタントを作成し、画像、動画、ドキュメント、音声などのマルチメディアコンテンツを処理する方法について説明しています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS GenAI Lofts – GenAI Lofts は、スタートアップや開発者にコラボレーションスペースと没入型の体験をご提供します。 Hands-on with Agentic Graph RAG Workshop (2 月 25 日)、 Unstructured Data Meetup SF (2 月 26〜27 日)、 AI Tinkerers – サンフランシスコ – February 2025 Demos + Science Fair (2 月 27〜28 日) などの実地の GenAI Loft サンフランシスコ イベントにご参加ください。 GenAI Loft ベルリン では、2 月 24 日から 3 月 7 日まで、見逃せないイベントやワークショップを開催しています。 AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーがリードする技術的なディスカッション、ワークショップ、ハンズオンラブなどが開催される、コミュニティ主導のカンファレンスにご参加ください: イタリア・ミラノ (4 月 2 日)、 ベイエリア – セキュリティエディション (4 月 4 日)、 ルーマニア・ティミショアラ (4 月 10 日)、 チェコ共和国・プラハ (4 月 29 日)。 AWS Innovate: 生成 AI + データ – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンスにご参加ください。このカンファレンスは、APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: パリ (4 月 9 日)、 アムステルダム (4 月 16 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)。 AWS re:Inforce – AWS re:Inforce (6 月 16~18 日) は、ペンシルバニア州フィラデルフィアで開催される、AWS クラウドセキュリティのすべてに焦点を当てた年次学習イベントです。登録は 3 月に開始されます。5,000 人を超えるセキュリティビルダーやリーダーとともにご参加ください。 AWS ビルダー ID を作成 し、エイリアスをご予約ください。ビルダー ID はユニバーサルログイン認証情報です。ユーザーは AWS マネジメントコンソールだけでなく、600 以上の無料トレーニングコース、コミュニティ機能、Amazon Q Developer をはじめとするデベロッパーツールなどの AWS ツールやリソースにアクセスできます。 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 2 月 24 日週はここまでです。3 月 3 日週の Weekly Roundup にもご期待ください! – Eli この記事は、 Weekly Roundup シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。
概要 Amazon Web Services (AWS) クラウドを使う大きな利点として、利用したサービスに対してのみ料金を支払うことができる、という点があります。このきめ細かな制御と弾力性のあるモデルにより、 オンプレミスのインフラと比較して大幅なコスト削減を実現 できます。投資から最大限の価値を引き出すための手法であり、 Well-Architected Framework の基本的な柱の 1 つが、コスト最適化です。 長い間、コスト最適化は財務チームが毎月月末に実施する遡及的な取り組みと考えられていましたが、その考え方はもはや当てはまりません。これは全員が継続的に共同で取り組む必要がある “共有責任” です。価値を最大限に引き出すためには、戦略的観点と戦術的観点の両方からコスト最適化を実施する必要があります。戦略的 (strategic) な観点とは、ベストプラクティス、クラウドネイティブサービスの使用、およびデータ主導型アプローチを組み合わせたものです。戦術的 (tactical) な観点とは、即時のコスト削減につながる具体的かつプロアクティブなアクションに関するものです。これらのアプローチを組み合わせつつ、さらに重要となるのは、最適なベースライン基準を自動的に確立および維持することで、ビジネス価値および AWS クラウドにおけるワークロードのコストパフォーマンスの効率を最大化できることです。 AWS Config は AWS、オンプレミス、およびその他のクラウド上のリソースの設定や関係を継続的に査定・監査・評価するサービスです。この投稿では、 AWS Config の適合パック という機能を利用して、コスト最適化のためのベストプラクティスのロジックに照らしてリソースを自動的に評価するソリューションを Organization 全体にデプロイすることで AWS Config サービスの価値を高める方法について紹介します。 適合パックとその利点とは? 適合パックは、AWS Config ルールと修復アクションの集まりであり、汎用のコンプライアンスフレームワークを提供します。これにより、戦略的なセキュリティや、運用もしくはコスト最適化のガバナンスチェックを単一のアカウントとリージョン、もしくは AWS Organization 全体にわたって大規模に体系化したりデプロイしたりすることができます。これらのルールはリソースを自動的に監視および評価し、各ルールで定義されたロジックに対するコンプライアンス体制を特定します。AWS Config には、事前定義済みのカスタマイズ可能なルールのリストである AWS Config マネージドルール のほか、 AWS Lambda 関数や policy-as-code 言語である AWS CloudFormation Guard を使用して独自のカスタムロジックを定義できる AWS Config カスタムルール が用意されています。 リソースがルールで定義されたロジックに準拠していない場合、そのリソースは “ 非準拠 (Noncompliant) ” としてマークされます。AWS のアプリケーションやリソースの運用ハブを提供するサービスである AWS Systems Manager Automation を使用して、戦術的な修復手順を手動もしくは自動で呼び出すことができます。このサービスは、非準拠のリソースを自動的に修復したり、チームにアクションを起こすよう警告するなどのイベント駆動型ワークフローをトリガーしたりする、事前定義済みのランブックを備えています。 ソリューションの概要 Cost Optimization Conformance Pack ソリューションは、コスト最適化ガバナンスを統合してサービス価値を高めることで、すでに AWS Config を利用しているお客様がサービスへの投資を最大化できるようにします。このカスタマイズ可能なソリューションには、ベストプラクティスのコスト最適化ロジックを含む 3 つのカスタムルール例が含まれています。これらのルールでは、リソースを監視および評価してコスト最適化のコンプライアンス体制を特定し、その結果を単一の「 委任管理者 」アカウントの AWS Config アグリゲータ に複製することで、管理と報告を簡素化します。以下のルールが含まれています。 ルール 1 : EBS gp2 ボリュームをチェックする ( 修復 : gp2 ボリュームを gp3 ボリュームに変換する) ルール 2 : EC2 インスタンスにアタッチされていない EBS ボリュームをチェックする ルール 3 : ライフサイクル設定ポリシーのない S3 バケットをチェックする リソースがルールで定義された基準のいずれも満たさない場合、リソース、Config ルール、および適合パックはすべて “ 非準拠 (Noncompliant) ” としてマークされます。ルール 1 には、手動または自動で呼び出すことのできる修復アクションも含まれています。これにより SSM Automation ランブックがトリガーされ、EBS ボリュームは gp2 から gp3 に変換されます。gp3 ボリュームを使用すると、ストレージサイズを増やすことなく IOPS とスループットを個別にプロビジョニングでき、gp2 ボリュームと比較して GB あたりのコストも最大 20% 低くなります。 注 : AWS Config は有料サービスです。まだ使用していない場合は、 料金例 を参照して、Organization 全体でサービスを有効にすることによるコストへの影響を理解してください。 このソリューションは、 AWS Control Tower が有効になっているかどうかに関係なく、AWS Organization 全体にデプロイできます。AWS Control Towerは、規範的なベストプラクティスに従って、AWS マルチアカウント環境のセットアップとガバナンスを簡素化するオーケストレーションソリューションです。図 1 は、AWS Control Tower が提供する、メンバーアカウントを含む OU 構造例全体への Cost Optimization Conformance Pack のデプロイを示しています。 図 1: Cost Optimization Conformance Pack のアーキテクチャ Security OU 内では監査アカウントを AWS Config と AWS CloudFormation の委任管理者として登録します。これにより、Cost Optimization Conformance Pack とCloudFormation スタックで定義されている関連リソースを Organization 内のアカウント全体にデプロイする権限が監査アカウントに付与されます。 CloudFormation スタックには Cost Optimization Conformance Pack のカスタムルールと共に、ルールによって参照される AWS Lambda 関数と AWS Systems Manager ドキュメントが含まれています。Lambda 関数と Systems Manager ドキュメントを実行できるように、 CloudFormation StackSets を使って 2 つのカスタム AWS Identity and Access Management (IAM) ロールが作成されます。これらのリソースとロールは一元化する監査アカウントから Organization 内のすべてのアカウントにデプロイされ、ソリューションの管理を簡素化します。 AWS Config では、定期的に、または環境内の設定変更に応じて、リソースが適合パックルールへ準拠しているかどうかをチェックできます。監査アカウントの AWS Config アグリゲータは、AWS Config によって各メンバーアカウントでキャプチャされたデータを照合して一元化し、リージョンごとにさらなる分析をできるようにします。 前提条件 この投稿では、OU 構造、監査アカウント、AWS Config アグリゲータをデプロイする AWS Organizations と AWS Control Tower が既に有効になっていること を前提としています。もし AWS Control Tower を使用する予定がないならば、先に進む前に「 AWS Organizations を使用した組織の作成 」および「 AWS Config のアグリゲータの作成 」に関するガイドを参照してください。 さらに、以下のことも必要になります: Cost Optimization Conformance Pack ソリューションのデプロイのために、Organization の管理アカウントと管理権限を委任している監査アカウントの両方にアクセスする権限。 AWS Organizations が有効化されている StackSets への信頼されたアクセス。これを確認する手順については「 AWS Organizations を使用してスタックセットのための信頼されたアクセスをアクティブ化する 」ドキュメントをご参照ください。 ソリューションがデプロイされているメンバーアカウントの AWS Config への AWS コンソールアクセス。 ウォークスルー この投稿では、以下の手順を実行する方法について説明します。 AWS Organizations と、AWS Config および AWS CloudFormation StackSets のサービスプリンシパルとの間に信頼関係を確立します。 監査アカウントに AWS Config および AWS CloudFormation の「委任管理者」権限を付与します。 Control Tower が有効になっていない場合は、AWS Config アグリゲータがデプロイされているアカウントを使用して「監査」アカウントを参照する手順を実行します。 Cost Optimization Conformance Pack をデプロイします。 CloudFormation を使用して、ソリューションに含まれる適合パック、Lambda 関数、IAM ロール、および Systems Manager ドキュメントをデプロイします。 ソリューションをテストします。 このウォークスルーでは、管理アカウント ID は 111111111111 、ソリューションのデプロイ元となる監査アカウントのアカウント ID は 222222222222 であるものとします。 ソリューションをデプロイする AWS Organizations と AWS CloudFormation のサービスプリンシパルの間の信頼関係を確立する AWS Organizations と AWS Config の間の信頼関係は、前提条件となる手順に従って既に部分的に確立されています。AWS Config ルールと AWS CloudFormation の信頼関係をさらに深めるには、Organization の管理アカウントで AWS CloudShell を使って以下の CLI コマンドを実行します。 信頼関係を作成して確認するには (コンソール) ※訳注:以下は管理アカウントでの操作です。 AWS コンソールを開きます。 Organization の管理アカウントに管理者 (administrator) としてログインします。 コンソールの検索バーに「 CloudShell 」と入力し、「 CloudShell 」を選択します。 画面下部のブラウザ内に CloudShell ターミナルウィンドウが起動します。 以下のコマンドを実行します。 aws organizations enable-aws-service-access --service-principal=config-multiaccountsetup.amazonaws.com および aws organizations enable-aws-service-access --service-principal=member.org.stacksets.cloudformation.amazonaws.com 以下のコマンドで、信頼関係が正しく確立されているかを確認します。 aws organizations list-aws-service-access-for-organization 出力には、図 2 に示す値が含まれているはずです。 図 2: AWS Organizations のサービスプリンシパルの信頼関係 AWS Config の「委任管理者」アカウントを有効化する この手順により、監査アカウントが AWS Config サービスおよび Config ルールの委任管理者として有効になります。委任管理者とは、追加の管理権限が付与された、特定の AWS Organization 内のアカウントです。この場合、その管理権限とは AWS Config サービスがアカウント間でルールをデプロイおよび管理するためのものになります。 AWS Config の委任管理者アカウントを設定するには (コンソール) ※訳注:以下は管理アカウントでの操作です。 手順を繰り返して CloudShell にログインします。 account-id を監査アカウントの ID に置き換えて以下のコマンドを実行します。 aws organizations register-delegated-administrator --account-id 222222222222 --service-principal config-multiaccountsetup.amazonaws.com account-id を監査アカウントの ID に置き換えて以下のコマンドを実行します。 aws organizations register-delegated-administrator --account-id 222222222222 --service-principal config.amazonaws.com 監査アカウントが AWS Config の委任管理者として正常に確立されたことを確認するために、以下のコマンドを実行します: aws organizations list-delegated-administrators --service-principal=config.amazonaws.com および aws organizations list-delegated-administrators --service-principal=config-multiaccountsetup.amazonaws.com 委任管理者アカウントのアカウント ID と共に、各コマンドに対して図 3 のような出力が表示されるはずです。 図 3: AWS Organizations の委任管理者 AWS CloudFormation の「委任管理者」アカウントを有効化する 委任管理者の権限を AWS CloudFormation の監査アカウントに付与するには、 AWS CloudFormation StackSets および AWS Organizations を使用する必要があります。この機能により、各メンバーアカウントに 必要な IAM ロールが作成され、Cost Optimization Conformance Pack のリソースを含む CloudFormation StackSet を Organization 全体にデプロイできるようになります。 AWS CloudFormation の委任管理者アカウントを設定するには (コンソール) ※訳注:以下は管理アカウントでの操作です。 手順を繰り返して CloudShell にログインします。 account-id を監査アカウントの ID に置き換えて以下のコマンドを実行します。 aws organizations register-delegated-administrator --service-principal=member.org.stacksets.cloudformation.amazonaws.com --account-id=222222222222 監査アカウントが AWS Config の委任管理者として正常に確立されたことを確認するために、以下のコマンドを実行します: aws organizations list-delegated-administrators --service-principal=member.org.stacksets.cloudformation.amazonaws.com 委任管理者アカウントのアカウント ID と共に、図 3 のような出力が表示されるはずです。 Cost Optimization Conformance Pack をデプロイする この手順では、 AWS Samples の Cost Optimization Conformance Pack GitHub リポジトリ からこの CloudFormation YAML テンプレート を使用して、適合パックを監査アカウントにダウンロードおよびデプロイします。CloudFormation StackSets は AWS リソースのデプロイや管理のプロセスを簡素化します。 (訳注:原文では https://github.com/aws-samples/aws-config-cost-optimization-conformance-pack/blob/main/template.yaml の YAML テンプレートがリンクされていますが、実際には https://github.com/aws-samples/aws-config-cost-optimization-conformance-pack/releases/ の最新リリースの YAML ファイルをダウンロードしてください。) このソリューションでは、以下がデプロイされます。 AWS Config Organization 適合パック – ベストプラクティスのコスト最適化ロジックに照らしてリソースを評価するために使用される、AWS Config カスタムルールの集まり。 この Organization 適合パックは、各メンバーアカウントに個別の Cost Optimization Conformance Pack をデプロイします。 AWS CloudFormation StackSet – AWS Organization 内のすべてのメンバーアカウントにデプロイされる CloudFormation StackSets の集まり。これらのスタックは以下をデプロイします。 AWS Lambda 関数 – AWS Config カスタムルールは、特定のリソースが上記で定義されたコストの最適化ベストプラクティスルールに 準拠 (Compliant) しているか 非準拠 (Noncompliant) かを評価するロジックを含む Lambda 関数を呼び出します。 IAM ロール – 2 つのカスタム IAM ロールがデプロイされます。1 つは Lambda 関数の呼び出しを可能にするもので、もう 1 つは AWS Systems Manager (SSM) が SSM ドキュメントで定義されている修復アクションを実行するために使われるものです。 AWS Systems Manager Automation ドキュメント – これは監査アカウントのみにデプロイされ、メンバーアカウントによって使用されます。 Cost Optimization Conformance Pack をダウンロードおよびデプロイするには (コンソール) ※訳注:以下は管理アカウントではなく監査アカウントでの操作です。 手順を繰り返して CloudShell にログインします。 CloudShell の「 アクション (Actions) 」メニューから「 ファイルのアップロード (Upload file) 」を選択し、ダウンロードした YAML ファイルを選択して CloudShell セッションに YAML ファイルをアップロードします。 以下のコマンドを実行します。 aws cloudformation deploy --template-file template.yaml --stack-name CostOptimizationConfPack --parameter-overrides DeployingInDelegatedAdminAccount=True --capabilities CAPABILITY_IAM CloudFormation StackSets が正常にデプロイされたことを確認するために、コンソールの検索バーに「 CloudFormation 」と入力し、「 CloudFormation 」を選択します。 左側のメニューで「スタック (Stack)」を選択します。出力には図 4 のようにデプロイされたスタックが CREATE_COMPLETE ステータスで表示されるはずです。 適合パックが正常にデプロイされたことを確認するには、コンソールの検索バーに「 AWS Config 」と入力し、「 AWS Config 」を選択します。 左側のメニューで「 適合パック (Conformance packs) 」を選択します。ダッシュボードは図 5 のようになるはずです。 図 4: CloudFormation スタックのデプロイステータス AWS Config 適合パックのダッシュボードには、正常にデプロイされ、コンプライアンススコアが報告されていることが表示されます。このスコアは、適合パックのルールに照らして評価されたリソースのコンプライアンスレベルをパーセンテージで示します。このダッシュボードでは、ルールが初めて評価されるまでは通常は「 不十分なデータ (INSUFFICIENT DATA) 」と表示されます。 図 5: 適合パックのデプロイステータス ソリューションのテスト Cost Optimization Conformance Pack のステータスを確認する 適合パックおよび関連するリソースがアカウント全体にデプロイされたので、AWS Config 適合パックダッシュボードを使用して適合パックルールのステータスを確認できます。図 6 に示すように、ルールに照らして評価されているリソースが既にあり、「 準拠 (Compliant) 」もしくは「 非準拠 (Noncompliant) 」と表示されているかもしれません。もしリソースが表示されていないようならば、以下の手順に従ってテスト用の非準拠の Amazon EBS ボリュームを作成します。 図 6: Cost Optimization Conformance Pack のステータス 非準拠リソースを使用して適合パックをテストするには (コンソール) ※訳注:いずれかのアカウントでの操作です。 AWS コンソールを開きます。 管理者 (administrator) として Organization のメンバーアカウントにログインします。 この手順 を使用して Amazon EBS ボリュームを作成します。 ボリュームタイプ としては「 gp2 」を選択します。 EBS ボリュームが作成されたら、AWS Config ダッシュボードに移動します。 「 適合パック (Conformance packs) 」を選択します。 名前に「 Cost-Optimization 」が含まれる適合パックを選択します。 図 6 のようなルールのリストが表示されます。 名前に「 CostOpt-Ebs 」が含まれるルールを選択し、ルールダッシュボードを表示します。 「 アクション (Actions) 」メニューを選択します。 「 再評価 (Re-evaluate) 」を選択すると、ルールをトリガーしてアカウント内のリソースを評価します。 評価が完了すると、非準拠の EBS ボリュームが図 7 のように表示されます。ボリューム ID をクリックすると、リソースに関する詳細情報が表示されます。 図 7: Config ルールのステータス 修復のテスト ルールに修復アクションが設定されている場合、図 7 に示すように AWS コンソールからそれを呼び出すことができます。EBS gp2 ルールの場合、監査アカウントの Systems Manager automation ランブックが呼び出され、ボリュームタイプが gp3 に変換されます。 修復ルールを呼び出すには (コンソール) ※訳注:以下は上記で gp2 ボリュームを作成したメンバーアカウントでの操作です。 図 7 の AWS Config ルールダッシュボードから「 対象範囲内のリソース (Resources in scope) 」までスクロールします。 「 非準拠 (Noncompliant) 」と表示されている EC2 ボリューム のラジオボタンを選択します。 「 修復 (Remediate) 」ボタンを選択します。 修復ルールがトリガーされると、「 ステータス (Status) 」列に「 アクションが正常に実行されました (Action executed successfully) 」と表示されます。EC2 サービスの Elastic Block Store に表示されているボリュームを確認することで、ボリュームタイプの変更が正常に完了したことを確認することもできます。図 8 は ボリュームタイプ が gp3 になったことを示しています。 図 8: EBS ボリュームのステータス 最後に、AWS Config はルールのステータスを更新し、gp3 に変換されたボリュームが 準拠 (Compliant) となっていることを表示します。 注 : このステータスの更新はリアルタイムではありません。 図 9: 準拠リソースを含む Config ルールのステータス クリーンアップ AWS コンソールまたは以下の CLI コマンドを使用して CloudFormation スタックを削除することで、Cost Optimization Conformance Pack ソリューションでデプロイされたすべてのリソースを削除することができます。 Cost Optimization Conformance Pack ソリューションを削除するには (CLI) ※訳注:以下は監査アカウントでの操作です。 手順を繰り返して CloudShell にログインします。 以下のコマンドを実行します。 aws cloudformation delete-stack --stack-name CostOptimizationConfPack account-id を監査アカウントの ID に置き換え、以下の CLI コマンドを実行することで、AWS Config および CloudFormation の委任管理者としての監査アカウントを Organization から登録解除することもできます。 ※訳注:以下は管理アカウントでの操作です。 以下のコマンドを実行します。 aws organizations deregister-delegated-administrator --account-id 123412341234 --service-principal config-multiaccountsetup.amazonaws.com および aws organizations deregister-delegated-administrator --account-id 123412341234 --service-principal config.amazonaws.com 訳注:修復ルールのテストのために作成した EBS ボリュームの削除も忘れないでください。 まとめ AWS Config の Cost Optimization Conformance Pack は、Organization 全体でコスト最適化標準を定義・自動化・管理するための強力かつシンプルな方法です。このソリューションには、コスト最適化ルールのベストプラクティスが組み込まれており、コンプライアンスに非準拠のリソースに対して修復手順を呼び出す機能により、一貫したコンプライアンス体制を確立および監視するのに役立ちます。 Cost Optimization Conformance Pack は AWS Samples GitHub リポジトリ から入手可能なオープンソースソリューションです。リポジトリにある README ガイド を使用して独自のコスト最適化ルールや修復方法を適合パックに組み込むことをお勧めします。ソリューションの機能をさらに拡張するには、 AWS Config カスタム Lambda ルール と AWS Systems Manager ドキュメント の詳細をご覧ください。 AWS Config の微調整に関する詳細については、「 AWS Control Tower 環境での AWS Config リソーストラッキングのカスタマイズ 」の投稿を参照してください。 Matt King は、ロンドンを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。20 年以上にわたるシニア IT リーダーとしての経験を活かして、半導体分野に特化してさまざまな業界のお客様をサポートしています。Matt は、AWS の革新的で持続可能なクラウドソリューションを通じてお客様の成功を促進することに尽力しています。 Dan Johns はシニアソリューションアーキテクトエンジニアで、お客様の AWS での構築とビジネス要件の実現をサポートしています。仕事以外では、本を読んだり、家族との時間を過ごしたり、家庭内のタスクを自動化したりすることが大好きです。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。
本記事は 2025 年 2 月 17 日に公開された “ Streamline Development with New Amazon Q Developer Agents ” を翻訳したものです。 ソフトウェア開発が急速に進化し続ける中で、開発者はワークフローの効率化、コード品質の向上、生産性の向上を支援するツールを常に求めています。Amazon Web Services (AWS) は、このニーズに応えるべく、 Amazon Q Developer に強力な新しい AI エージェントを導入しました。 AI を搭載したエージェント は、開発者のドキュメント作成、ユニットテスト、コードレビューのアプローチを変革します。エージェントとは、環境とやり取りし、データを収集し、そのデータを活用して独立したタスクを実行し、事前に定義された目標を達成する自律型のソフトウェアプログラムです。エージェントは合理的であり、取得した情報やデータに基づいて最適なパフォーマンスを実現するための意思決定をします。AI エージェントの活用により、生産性の向上、コスト削減、意思決定の改善、顧客体験の向上といったメリットを得ることができます。Amazon Q Developer には、新たに /doc 、 /test 、 /review の 3 つのエージェントが追加されました。本記事では、それぞれのエージェントについて詳しく説明し、日々の開発ワークフローにどのように組み込めるかを紹介します。 Amazon Q Developer に最初に 導入されたエージェント は、昨年リリースされたソフトウェア開発エージェントです。 /dev エージェントを使用すると、IDE 内で直接新しいコードを生成したり、コードの変更を行ったりすることができます。これにより、新機能の実装やプロジェクト内の問題修正が可能になります。達成したいタスクの説明を入力するだけで、Amazon Q Developer がコードベースの適切なコンテキストを分析し、必要なコード変更を生成します。Amazon Q Developer は、新しい AWS アプリケーションの構築や既存アプリケーションの更新を支援し、実施した変更のステップごとの概要を提供するため、開発者は提案された変更を簡単に受け入れたり拒否したりすることができます。 /dev の機能は、新しい API エンドポイントの作成やデータベースクエリの最適化など、シンプルな作業から複雑な開発タスクまで幅広く対応できる、開発者なら必ず試すべきツールです。 以降のセクションでは、アプリケーションのユースケースでこれらの新しいエージェントをどのように活用できるかを詳しく見ていきましょう。 前提条件 Amazon Q Developer の使用を開始するには、以下が必要です: AWS アカウント AWS Builder ID または組織が管理される AWS Identity Center のログイン Visual Studio Code またはサポート対象の JetBrains IDE Amazon Q Developer のセットアップ方法とチャットの使い方 注: Amazon Q Developer は Eclipse や Visual Studio Pro などの追加の IDE もサポートしていますが、エージェント機能が有効になっているものは上記に記載された IDE のみです。 アプリケーション概要 あなたはテクノロジー企業のソフトウェアエンジニアとして、以下のアプリケーションのドキュメント作成、ユニットテストの統合、セキュリティ強化を担当することになりました。 このアプリケーションは、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB を使用した サーバーレスアーキテクチャ を採用しており、Python で RESTful API を実装しています。 AWS では、Amazon Q Developer の新しいドキュメント作成、テスト、セキュリティスキャンのエージェントが、アプリケーションのソフトウェア開発ライフサイクル (Software Development LifeCycle: SDLC) を支援できることを学びました。SDLC は、計画と調査、コーディング、ドキュメント作成、テスト、ビルドとデプロイ、運用と保守などの複数のステージを持つフライホイールです。 新しい Amazon Q Developer エージェントを活用し、この SDLC においてどのように実際のアプリケーションに活用できるかを見ていきましょう。 ドキュメント生成 ( /doc ) アプリケーションのドキュメント作成と保守は、ソフトウェア開発の中で最も時間がかかり、頻繁に見過ごされがちな作業の 1 つです。しかし、詳細なドキュメントがあることで、チームメンバーやステークホルダーがコード、設計、アーキテクチャを理解しやすくなります。また、可読性の向上、新機能の迅速な開発、SDLC の効率化 にもつながります。 Amazon Q Developer に新しく導入された /doc エージェント を活用すれば、このプロセスを簡単かつ迅速に進めることができます。Amazon Q Developer は、プロジェクト内のフォルダを分析し、新しい README ファイルを自動生成できます。また、コード変更をレビューし、既存のドキュメントの更新を推奨することも可能です。さらに、自然言語でリクエストできるため、特定の変更やカスタム要約ができ、プロセス全体がより直感的でユーザーフレンドリーになります。これらの機能により、開発チームがアプリケーションを運用する際に、チームの負担を軽減しながら、正確で最新のプロジェクトドキュメントを維持できます。 本アプリケーションには詳細な README がないため、以下の例では、Amazon Q Developer の /doc エージェント を Visual Studio Code (VS Code) IDE で活用し、アプリケーションのコードベースに対する詳細なドキュメントを生成する方法を紹介します。 プロンプト: /doc Create a README (訳者注: README を作って) Amazon Q Developer /doc エージェントを使用する際のベストプラクティス 大規模なリポジトリの場合、特定のディレクトリをドキュメント化の対象として指定することを検討してください。 生成されるドキュメントの品質を向上させるために、適切な命名規則で十分にコメントが付けられた整理されたコードを維持してください。 README への変更を記述する際は具体的にしてください。 注意: /doc 機能は、.template ファイル、requirements.txt、package.json、tsconfig.json、Dockerfile など、さまざまなファイル形式をサポートしています。既存の README の最大サイズは 15 KB、コードプロジェクトのサイズ上限は非圧縮で 200 MB、圧縮時で 50 MB のクォータがあることに注意することが重要です。 ユニットテスト生成 ( /test ) テスト駆動開発は、一般的な SDLC のベストプラクティスの一つです。その一部であるユニットテストはコード品質を維持するための基盤となります。ユニットテストを実施することで、バグを早期に発見し、技術的負債を最小限に抑えることができます。しかし、包括的なテストを書く作業は、一般的に開発チームの多くの時間と労力が必要です。 Amazon Q Developer の新しい /test エージェントは、テストのプロセスを自動化し、開発者が新機能の開発や問題解決により注力できるよう支援します。このツールには、テストワークフローを効率化する強力な機能が備わっています。必要なテストケースを自動識別し、分離されたテストシナリオに適したモックやスタブの生成、識別されたケースに基づくテストコードの作成を行います。現在、Java と Python のプロジェクトの両方をサポートしており、VS Code や JetBrains IDE などの一般的な開発環境とシームレスに統合され、生産性を最大化しながらテスト実践を強化したいと考える現代の開発チームにとって貴重なアセットとなっています。 Amazon Q Developer /test エージェントを使用すると、クラス、関数、メソッドなど特定のコードセクションを指定してユニットテストを生成したり、IDE 内でコードをハイライトしてテストを作成したりできます。以下の例では、DynamoDB テーブルに新しいアイテムを追加する Python ファイル (add_item.py) に対して、/testエージェントを使用してユニットテストを生成する方法を示しています。 プロンプト: /test generate unit tests for the lambda_handler method that is adding items to dynamodb table (訳者注: DynamoDB テーブルにアイテムを追加する lambda_handler メソッドの、ユニットテストを生成して) ユニットテストの生成に Amazon Q Developer の /test エージェントを活用 Amazon Q Developer を使用して、IDE 内でコード選択からユニットテストを生成 注意: Amazon Q Developer のユニットテストエージェントは、VS Code および JetBrains IDEs で Java および Python のプロジェクトをサポートしています。ユニットテスト生成の言語およびフレームワークのサポートについては、「 /test によるユニットテスト生成の言語とフレームワークのサポート 」を参照してください。 /test 機能は、サポートされていない言語やフレームワーク、Java の非公開メソッド、月間使用制限の到達など、さまざまな特別なケースに対応しています。プロセス全体を通じて、スムーズなユーザー体験と適切なガイダンスを提供するよう設計されています。 コード品質とセキュリティの向上 ( /review ) コードレビューは、ソフトウェア開発の品質基準を維持するために不可欠なプロセスとなっており、Amazon Q Developer の新しい /review 機能は、AI を活用した強力なコード分析でこの重要なプロセスを変革します。この革新的なツールには包括的なコード分析機能があり、開発チームは潜在的な問題を早期に特定し、深刻な問題に発展する前に対処できるようになります。ユーザーは、コードを記述する際にシームレスに動作する継続的なコードスキャンを利用でき、明確な説明と具体的な改善策が含まれた詳細な問題レポートを受け取ることができます。さらに、この機能は一歩進んで、コード内で直接修正を適用できるため、必要な改善をこれまで以上に簡単に実施できます。 /review 機能のセキュリティ検出機能は、幅広い潜在的な問題をカバーし、複数の側面から包括的なコード分析を実施します。Amazon Q Developer /review 機能は、静的アプリケーションセキュリティテスト ( SAST ) を実行してセキュリティ脆弱性を特定し、機密情報の漏洩を防ぐためのシークレット検出を行い、 Infrastructure as Code (IaC) の潜在的な問題を分析します。これにより、SDLC のより早い段階でセキュリティ対策を講じることが可能となり、コードがリポジトリにコミットされる前に脆弱性を発見し、全体的なセキュリティ態勢とコード品質を向上させます。加えて、このツールは保守性や効率性に影響を与えるコード品質要素を評価し、デプロイ時の潜在的なリスクを分析し、サードパーティコードに対するソフトウェアコンポジション分析 (SCA) を実施します。この包括的なアプローチにより、開発チームは高品質でセキュアかつ効率的なコードベースを維持しながら、レビュー作業を大幅に効率化できます。 以下の例では、 /review 機能を活用し、アプリケーション全体のワークスペースをスキャンして Python のアプリケーションコードと Terraform のインフラコードを分析し、その後修正を適用する方法を示しています。オプションとして、IDE 内で開いているアクティブなファイルのみをスキャンすることもできます。 プロンプト: /review 注意: /review 機能には最適なパフォーマンスを維持するためのクォータが設定されており、自動レビューおよびプロジェクト全体のスキャンにおける入力アーティファクトのサイズやソースコードのサイズに制限があります。詳細については こちら を参照してください。 結論 Amazon Q Developer の革新的なエージェントである /doc 、 /test 、 /review は、ドキュメント管理からテスト、コードレビューまで、開発ライフサイクルにおける最も困難な時間のかかるプロセスを直接支援します。README の作成や更新、ユニットテストの生成、包括的なコード分析などの重要なタスクを自動化することで、開発チームはコード品質とセキュリティの水準を高く維持しながら、生産性を大幅に向上させることができます。潜在的な問題を早期に発見し、開発ライフサイクルを効率化できることで、チームはこれまで以上にスムーズかつ効果的に作業を進められます。ただし、これらの AI を活用した機能は、人間の専門知識に取って代わるのではなく、補完するように設計されていることを覚えておくことが重要です。これらの機能は開発者の能力を強化する知的なアシスタントとして機能しており、最適なプロジェクト成果を実現するためには開発者の専門的な判断が欠かせません。これらのツールは、AI を活用して従来の開発上の課題を克服し、開発チームが本当に重要なこと、つまり優れたソフトウェアの開発に集中できるようにする優れた例となっています。ぜひこれらの新機能を活用し、Amazon Q Developer で開発プロセスを次のレベルへと引き上げましょう。Amazon Q Developer の詳細や、ソフトウェア開発を加速するための活用方法については、 Amazon Q Developer のドキュメント を参照してください。これらのエージェントは Amazon Q Developer の無料枠の一部として利用可能で、今すぐ 使い始められます ! 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Ryan Yanchuleff Ryanは、生成AIのあらゆる分野に特化したワールドワイド・スペシャリスト組織のシニア・スペシャリスト・ソリューションアーキテクトです。スタートアップ企業が新しいソリューションを構築してアイデアを実現するのを支援することに情熱を注いでおり、自身も複数のスタートアップを立ち上げた経験があります。テクノロジーと向き合う以外の時間は、妻と2人の子供たちと過ごしたり、次の住宅リノベーションプロジェクトに取り組んだりすることを楽しんでいます。 Janardhan Molumuri Janardhan MolumuriはAWSのプリンシパル・テクニカルリーダーです。20年以上にわたるエンジニアリングリーダーとしての経験を持ち、クラウド導入戦略や生成AIを含む新興技術について顧客にアドバイスを提供してきました。スピーキングやライティングに情熱を持ち、大規模な問題解決のために技術トレンドを探求することを楽しんでいます。
みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 関東は寒い風の強い日が続きますが体調いかがでしょうか?花粉の飛散量予報はまだ多くなさそうに見えるのですが、私は先週から花粉症に似た症状が出ており・・・暖かくなるのに戦々恐々しております。 さて、日本時間の今朝、AnthropicのClaude 3.7 Sonnetがリリースされましたね。週刊AWSでも次週取り扱うと思いますがAmazon Bedrockでもサポートされているので、ぜひ試してみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年2月17日週の主要なアップデート 2/17(月) Amazon Aurora PostgreSQL zero-ETL integration with Amazon Redshift now available in 18 additional regions Amazon Aurora PostgreSQL互換とAmazon RedshiftへのZero-ETL機能が大阪を含む18のリージョンで新たにサポートされました。Zero-ETL機能は名前の通り複雑なETLパイプラインを構築することなく、RedshiftでAuroraのデータをほぼリアルタイムに利用できる機能で、ニアリアルタイム分析や機械学習(ML)などでご活用いただけます。Zero-ETLについては こちら もご確認ください。今回のリージョン追加でAmazon Redshiftがサポートされているすべての商用リージョンでこの機能が利用可能になりました。 AWS Price List API supports AWS PrivateLink AWS Price List APIがAWS PrivateLinkをサポートしました。AWS Price List APIはAWS サービスの製品と価格のカタログを提供するものです。PrivateLinkはオンプレミスやVPCからのアクセスを容易にする機能で、VPCエンドポイントとプライベートIPアドレス経由でプライベートネットワーク内からAPIを呼び出すことができます。この機能はAWS Price List APIが利用できるバージニア北部、ムンバイ、フランクフルト、中国 (寧夏)でご利用いただけます。 Dynamically update your running EMR cluster with reconfiguration for instance fleets Amazon EMR on EC2でインスタンスフリートのアプリケーション設定をリアルタイムに更新できるようになりました。これまで設定変更にはクラスターの終了や再起動が必要でした。今回の機能によりSparkのメモリ設定、YARNのリソース割り当て、HDFS設定などをデータ処理とパフォーマンス要件に合わせて動的に変更可能です。この機能はEMR 5.21以降でAWS GovCloud (米国) リージョンを含むすべての AWS リージョンで利用可能です。詳細は ドキュメント もご確認ください。 2/18(火) Amplify Hosting announces support for IAM roles for server-side rendered (SSR) applications AWS Amplify Hostingでサーバサイドレンダリング(SSR)アプリケーションから、AWS リソースにIAM ロールを使ってアクセスできるようになりました。RDSやDynamoDBへの接続、アプリケーション認証情報の管理など様々な場面で権限管理が容易になります。この機能は東京、大阪リージョンを含め、AWS Amplify Hostingが使える20リージョンすべてで利用可能です。詳細は ドキュメント のほか、 ブログ もご確認ください。 Amazon Timestream for InfluxDB Adds Read Replica support Amazon Timestream for InfluxDBがリードレプリカをサポートしました。これによりリアルタイム分析や監視ソリューションなど読み取りが多いワークロードにおいてパフォーマンスと可用性を向上させることができます。この機能は東京を含む14のリージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 AWS WAF enhances Data Protection and logging experience AWS WAFのデータ保護機能が拡張され、ログをAmazon Security LakeやCloudWatchなどに転送する前に選択したリクエストログフィールドを暗号化ハッシュもしくは事前定義された静的文字列に置き換えることができるようになりました。これによりデータ管理を簡素化し、ログデータから情報が参照できてしまう偶発的なデータ漏洩リスクを減らすことができます。また、このアップデートに合わせてログ設定の管理コンソール画面が簡素化されています。この機能はAWS WAFがサポートされるすべてのAWSリージョンとエンドポイントで利用可能です。詳細については ドキュメント をご確認ください。 2/19(水) AWS Network Firewall introduces automated domain lists and insights AWS Network Firewallで自動ドメインリストとインサイトの機能がサポートされました。この機能は過去30日間のHTTPおよびHTTPSトラフィックログを分析し、可視化するものです。ドメインリスト作成を自動化することで、アクセスがあるドメインの特定やニーズの変化を取得する労力を削減して、観測されたトラフィックパターンに基づいたルール作成・運用が可能です。この機能はAWS Network Firewallが利用可能なすべてのAWSリージョンでサポートされ、追加料金はかかりません。詳細は ドキュメント をご確認ください。 Amazon ECS increases the CPU limit for ECS tasks to 192 vCPUs Amazon ECSのタスクをAmazon EC2にデプロイする際にサポートされるCPU制限が、これまでの10vCPUから最大192vCPUと大幅に増加しました。CPU制限は1つのタスクが過剰にリソースを消費するのを防いでくれます。今回サポートコア数が増えたことで大規模なEC2インスタンスで複数のタスクを起動する際にもリソース競合を防ぎ、より効率的なタスク配置が可能になります。この機能はAmazon ECSを利用可能なすべてのリージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 2/20(木) Amazon Bedrock now available in Asia Pacific (Hyderabad) and Asia Pacific (Osaka) regions Amazon Bedrockが大阪およびハイデラバードの2つリージョンで新たに利用可能になりました。現時点ではクロスリージョン推論(Cross-region inference)機能でClaude 3.5 Sonnetが利用可能です。これにより大阪をメインに使うお客様がAmazon Bedrockを使うために東京リージョンで準備する必要性は減りましたが、現時点では両リージョンで使えるモデルや機能に差がある点はご注意ください。 AWS announces Backup Payment Methods for invoices AWS の支払い方法に関して、請求書での支払いに失敗した際のバックアップ方法を設定できるようになりました。これまでも手動で支払い方法の変更はできましたが、事前に設定可能になったことで支払い漏れや遅延のリスクがさらに軽減されます。設定方法等の詳細は ドキュメント をご確認ください。 AWS CodePipeline adds native Amazon EKS deployment support AWS CodePipelineにAmazon EKSにデプロイする新しいアクションが追加されました。今回のアップデートによりプライベートなVPCにあるEKS クラスターに対してもアクションからクラスター名を指定することで自動的に接続を確立し、簡単にデプロイが可能になります。詳細については ドキュメント をご確認ください。この機能はAWS GovCloud (米国) リージョンと中国リージョン以外のAWS CodePipelineがサポートされるすべてのリージョンで利用可能です。 Amazon Elastic Beanstalk now supports Windows Server 2025 and Windows Server Core 2025 environments AWS Elastic BeanstalkがWindows Server 2025とWindows Server Core 2025をサポートしました。これらの環境には.NET Framework 4.8.1に加え.NETの最新の長期サポート(LTS)である.NET 8.0も予めセットアップされています。このサポートはAWS GovCloud (米国) リージョンを含む Elastic Beanstalkがサポートされるすべての商用リージョンでご利用いただけます。 2/21(金) Certificate-Based Authentication is now available on Amazon AppStream 2.0 multi-session fleets Amazon AppStream 2.0が、Active Directoryに参加するWindows OSのマルチセッションフリートで証明書ベースの認証(CBA)をサポートしました。AppStream 2.0のマルチセッションフリートはインスタンスを最大50人の複数ユーザーでシェアして使う方法です。今回サポートされたCBAを使うとSAML 2.0 IdP等と連携して個別にパスワードを入力せずともAppStream 2.0 リソースにアクセスできるので、ユーザー体験を向上しつつ、コスト効率よくAppStream 2.0を利用できます。この機能は追加料金なしで、AppStream 2.0がサポートされるすべてのリージョンで利用可能ですが、2025年2月7日以降にリリースされたエージェントを利用するイメージ、もしくは2025年2月11日以降にリリースされたManaged AppStream 2.0 イメージアップデートを使用する必要があるのでご注意ください。 AWS CodePipeline adds native Amazon EC2 deployment support AWS CodePipelineに新しいアクションが追加され、ロードバランサーの後ろにあるEC2へのデプロイをネイティブにサポートしました。これまではEC2にパイプラインからデプロイする場合CodeDeploy経由で行う必要がありましたが、今回のアップデートでCodeDeployを使わずともデプロイできる様になりプロセスが簡素化されます。詳細については チュートリアル と ドキュメント をご確認ください。この機能はAWS GovCloud (米国) リージョンと中国リージョン以外のAWS CodePipelineがサポートされるすべてのリージョンで利用可能です。 Amazon MSK adds support for Apache Kafka version 3.8 Amazon MSKがApache Kafka version 3.8をサポートしました。Amazon MSKが利用可能なすべてのAWS リージョンで利用可能です。v3.8にはバグ修正のほか圧縮レベル設定のサポートなどが含まれていますが、詳細はApache Kafkaの リリースノート をご確認ください。 それでは、また来週! ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています!
みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 Amazon BedrockでAnthropic Claude 3.7 Sonnet がご利用いただけるようになりました。いつもの記事執筆サイクルだと来週ピックアップするのですが、注目されている方も多いでしょうから速報的に取り上げておきます。Claude 3.7 Sonnetは”extended thinking”モードと、”standard”モードが用意されており使い分けることができるのが特徴です。 AWS News Blogの記事 も出ていますのでこちらもぜひご覧ください。 それでは、2 月 17 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS でグラフと生成 AI を活用した製造デジタルスレッドを構築」を公開 この記事は製造業にフォーカスして、データを戦略資産として捉え、それに基づく意思決定を実現するにはどうすれば良いのかを解説する翻訳記事です。製造業ではPLM, ERP, MES, CRMなど様々なシステムがありますが、これらのデータはそれぞれのシステムに独立して保存されており、それを活用できていない企業が多いと言われています。この記事では、ナレッジグラフと生成AIを活用し各種システムのデータを統合する方法についてひとつのアイデアを紹介しています。 ブログ記事「エンタープライズにおける Amazon Bedrock による生成 AI のオペレーティングモデル」を公開 生成AIの導入が進むにつれて、そのオペレーションモデルを確立する必要が高まるという声をお客様から伺います。この構造自体は、クラウド利用に似ているところがあります。事業部門がその必要に応じて様々な取り組みを進め、中央にそれを支援・管理する組織が存在する構造です。クラウド利用についてはAWS Organizationsなどでガバナンスを確立するケースが多いのですが、生成AIに関してはどう取り組めば良いか?を考えるのがこの記事です。 サービスアップデート Amazon Bedrockが大阪とハイデラ バードのリージョンで利用可能に Amazon Bedrockが大阪リージョンと、インドに存在するハイデラバードのリージョンでご利用いただけるようになりました。現時点では、大阪リージョンではクロスリージョン推論(Cross-region inference)機能を介して、アジア太平洋地域のリージョンで稼働するClaude 3.5 Sonnetを利用できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。
アマゾン ウェブ サービス ジャパン(以下、AWS ジャパン)が 2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。基盤モデルの開発者向けと、既存モデルを活用する利用者向けの 2 つの枠組みを提供し、企業の目的や検討段階に応じた最適な支援を行っています。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC(Generative AI Accelerator Challenge)の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2025 年 2 月 7 日に開催されました。 2024 年 11 月 15 日に実施された第 1 回 に続き、今回が第 2 回となります。本記事では、そのイベントの模様をレポートします。 開会のご挨拶 イベント冒頭では、AWS ジャパンの代表執行役員社長である白幡 晶彦が、AWS の生成 AI 領域における活動をビデオメッセージで説明しました。 AWS は 2023 年 4 月の Amazon Bedrock の発表以降、生成 AI 技術の活用促進に向けた取り組みを続けています。例えば、日本では「 AWS LLM 開発支援プログラム 」を通じて企業と連携し、日本語モデルの開発や検証を進めてきました。また、GENIAC プロジェクトでは、13 社が AWS の計算リソースを活用し、AI 開発を加速させています。こうした取り組みを支える AWS のクラウドサービス はインフラ層からアプリケーション層まで包括的なソリューションを提供できます。その中でも、生成 AI の実用化を支援するために、特に注力しているのが、 高い費用対効果を実現する高性能なインフラ、基盤モデルを利用した生成 AI アプリケーションのビジネス実装に向けた、セキュアでスケーラブルなツール、生産性向上のためのアプリケーションの提供です。技術支援にも力を入れており、各種のプログラムを通じて実践的なノウハウの共有や具体的な開発・運用のアドバイスを行っています。最後に会場の方々に向けて「多種多様な方々が一堂に会し、対話をすることで、新たなソリューション創出につながることを期待しています」と呼びかけました。 AWS スピーカーによるセッション 次に、AWS ジャパンの AI / ML 事業開発マネージャーである井形 健太郎が、生成 AI の最新動向とビジネス価値を生み出すためのデータ活用について解説しました。 まず、2024 年の生成 AI のトレンドを振り返り、多くの企業が PoC(概念実証)から本番導入へと移行したことを強調。主なユースケースとして、「1. データ入力支援」「2. 営業支援」「3. コンテンツ作成」「4. 専門的な応対支援」「5. 検索体験の向上」「6. データレビュー」「7. システム開発支援」に分類できるとしました。2025 年の展望として、生成 AI からビジネス価値を創出する動きが加速すると予測。AI エージェント技術の発展や、業界ごとに最適化されたモデルがより重要になるとし、同時に規制やセキュリティ対策の強化も求められると述べました。 続いて、AWS の生成 AI 関連サービスの主要なアップデートを紹介しました。まず最初に、フルマネージドの生成 AI 基盤である Amazon Bedrock について説明。生成基盤モデル Amazon Nova をはじめとした新たなモデルが使用可能になり、利便性が向上しました。また、モデル蒸留やマルチエージェント・コラボレーションもサポートしています。次に Amazon Q についても説明がありました。Amazon Q はフルマネージドの AI アシスタントサービスで、 Amazon Q Business と Amazon Q Developer の2つが提供されています。Amazon Q Business は情報検索や RAG の機能を備え、企業のデータを活用した AI 検索が可能です。一方、Amazon Q Developer はエンジニア向けの開発支援機能を備え、コードの作成やセキュリティスキャン、デプロイ後の運用を通じ、ソフトウェアライフサイクル全体をサポートします。さらに、 Amazon QuickSight と Amazon Q Business の統合が発表され、BI ツールにおけるデータ分析の効率化が進みました。従来の BI ツールは数値やグラフの表示が主でしたが、生成 AI を活用することで、その背景や関連情報を文章として提示できるようになり、分析結果の活用が容易になります。また、AWS が開発する AI/ML 専用チップ AWS Inferentia と AWS Trainium にも触れ、次世代の AWS Trainium チップが大幅な性能向上を遂げたことを説明しました。特に、モデルの学習速度の向上や消費電力の削減が進んでおり、今後の AI 開発の基盤として期待されています。 生成 AI をビジネス価値に結びつけるためのデータ活用の重要性について触れました。生成 AI を活用するにはデータの整備が不可欠であり、データエンジニアやデータサイエンティストの役割が一層重要になると指摘。データのサイロ化を解消し、統合的に活用できる環境を整えることが重要になります。その課題を解決するためのプラットフォームとして、 Amazon SageMaker を推奨しました。「今後さらに生成 AI 関連の技術開発を進め、企業のデジタル変革を支援していきます」と述べ、セッションを締めくくりました。 プログラム参加者によるライトニングトーク 生成 AI 実用化推進プログラムに参加する 5 社の企業代表者が登壇し、AWS のサービス利用を軸にした取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長の小林 正人(写真右)と、AWS シニア 生成 AI スタートアップ ソリューションアーキテクトの針原 佳貴(写真左)がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社フィックスターズ SaaS&VAR 事業推進室 シニアディレクターの相澤 和宏 氏は、ハードウェアリソースを最適化し、学習や推論の処理速度を向上させることで、コスト効率の高い AI 開発と運用を実現する「Fixstars AI Booster」について解説しました。過去に実施した検証では、p4d.24xlarge(A100x4)上での Megatron-LM による Llama3 8B 継続事前学習を行い、15〜20% のパフォーマンス向上を達成しています。「この技術を活用し、みなさまの AI 開発の加速と効率化に貢献したい」と語りました。 ジェネシスヘルスケア株式会社 A.D.A.M. イノベーションセンター バックエンドエンジニアの小林 拓也 氏は、遺伝子検査サービスと生成 AI を活用した新機能について講演。肥満遺伝子検査サービスの結果をもとに、チャットボットを活用してパーソナライズドアドバイスをする機能の開発経緯を説明しました。アーキテクチャの選定では試行錯誤を重ねましたが、最終的に Amazon Bedrock エージェント を採用する方針を選んだといいます。「今後も進化する技術を活用しながら、サービスの精度向上を目指します」と締めくくりました。 株式会社フレイ・スリー 開発部 リードエンジニアの青木 諭 氏は、同社が提供する動画マーケティングサービス「1ROLL」を紹介しました。動画制作における課題として、原稿作成や字幕付けに時間がかかること、資料の動画化による視認性の低下、適切な動画選定の難しさなどが挙げられます。これらを解決するため同社では Amazon Bedrock を活用し、資料から動画を自動生成する機能や、長尺動画のダイジェスト作成機能、ナレーションやテロップの自動生成機能を導入しました。 株式会社Nint プロダクトDiv. ユニットリーダーの田 瀟逸 氏は、EC データ分析サービス「Nint ECommerce」における生成 AI 活用について説明しました。同社では、新規クライアントのオンボーディング時に BI ツールの習得に時間がかかることが課題でした。これを解決するため、Amazon Bedrock を活用して自然言語で検索・分析が可能な「Nint AI」を開発し、データに基づいた根拠ある回答を提供できる仕組みを構築しました。 開発者のモデルご紹介 株式会社Preferred Networks VP of PreferredAI Products の Adiyan Mujibiya 氏は、AI バリューチェーンの垂直統合を目指し、ソフトウェアとハードウェアを融合させた技術開発を進めていると説明しました。最近の取り組みとして、純国産の生成 AI 基盤モデル「PLaMo」を提供しています。今後は 100B トークン規模の高品質な学習データセットを構築し、推論コストを従来モデル比で 10 分の 1 以下に抑えた高性能モデルの開発を行う方針です。 Sparticle株式会社の新井 典孝 氏は、モデルの最適化の事例について話しました。この事例では、 Amazon EC2 P4d インスタンスを活用して、Llama3.1-405B、Llama3.3-70B、Qwen-72B の日本語化・量子化・コンテキストサイズ拡張を実施。その結果、精度を維持しつつ処理の効率化に成功し、コスト削減も実現しました。この LLM を GBase プライベートクラウド環境の専用 RAG で利用しています。 株式会社ユビタス シニア・ディレクター 中坪 知幸 氏は、観光産業向けの LLM 開発を進めていると説明しました。Llama3.1 の 405B をベースに、日本語・中国語・韓国語に強い言語モデルとしてオープンソース化を目指しています。また、マルチモーダル LLM や VLM の開発も進めており、AI キャラクター制作プラットフォーム「UbiOne」や画像生成ツール「UbiArt」などのプロダクトを展開しています。 クロージング 各セッションの終了後、AWS ジャパンよりいくつかのお知らせをしました。 GENIAC の最新情報 GENIAC の第 2 期は 2023 年 10 月に開始され、2025 年 4 月 22 日まで開発が続きます。さらに、第 3 期の 公募予告 が 2025 年 2 月 14 日に公開されました。公募期間は 3 月中旬から 5 月中旬、研究開発期間は 8 月上旬から 2026 年 2 月上旬(6 カ月間)の予定です。第 3 期ではモデル開発および社会実装支援が盛り込まれる予定です。 生成 AI 実用化推進プログラムの最新情報 今後の予定として、2025 年 3 月 31 日に現在のプログラムが終了しますが、4 月には新たな支援プログラムが発表されます。お申込みは3月31日まで可能です。4 月 16 日には第3回 Meetup イベントを開催する予定です。 参加者交流会の様子 交流会では、各セッションの登壇者を交えたディスカッションや、参加者同士の歓談が行われ、会場は終始活気に満ちていました。また、同じ課題や関心を持つ企業同士の交流も活発に行われ、新たな協業の可能性を模索する姿も見られました。登壇者・参加者のつながりが広がることで、生成 AI 活用のさらなる発展が期待されます。 おわりに 本イベントでは、参加者が各セッションに熱心に耳を傾け、登壇者とのディスカッションやネットワーキングを通じて活発に交流する姿が見られました。生成 AI の最新動向や活用事例が共有され、技術的な理解を深めるとともに、新たなビジネス機会の創出につながる場となりました。AWS ジャパンは、今後も「生成 AI 実用化推進プログラム」をはじめとするさまざまな取り組みを通じて、企業の生成 AI 活用を支援していく方針です。
本稿は、2025 年 2 月 18 日に AWS Blog で公開された “ AWS for VMware at re:Invent 2024 Playlist ” を翻訳したものです。 AWS re:Invent の興奮も冷めやらぬ中、VMware から AWS への移行に関するオンデマンドセッションのプレイリストを厳選しました。このプレイリストには、エキスパートによる教育的なブレイクアウトセッション、実際の顧客事例、AWS ソリューションの Deep Dive が含まれており、お客様が自信を持って IT 変革を進めることができるように支援します。AWS の新機能の活用方法、セキュリティの強化方法、インフラストラクチャコストの最適化方法について学ぶことができます。 まずはここから:AWS での移行パスのオプションを決定 MAM103 | The future of your VMware-based workloads with AWS | Level 100 VMware ベースのワークロードに適したクラウドの移行先を選択することは、ビジネスにとって極めて重要です。このセッションでは、AWS がどのようにお客様と協力してこのジャーニーをナビゲートするかを学びます。AWS は実績のある移行パスを提供しています。これには VMware Cloud Foundations (VCF) 環境の AWS への移行を簡素化する Amazon Elastic VMware Service (Amazon EVS) や、クラウドジャーニーを支援する規範的なガイダンスを提供する目的別サービスが含まれます。現在および将来のビジネス目標を達成するために、移行、モダナイゼーション、イノベーションの適切な組み合わせを実現するためのオプションとパスを探ります。AWS と AWS パートナーが VMware 環境をシームレスに変革するためにどのように支援するかをご覧ください。 クラウドジャーニーの新しいオファリングを理解し、AWS 移行パスを Deep Dive する MAM238-INT | Automating migration and modernization to accelerate transformation (Innovation talk) | Level 200 多くの組織が、既存のアプリケーションとその中に閉じ込められたデータから価値を引き出すことに苦労しています。このセッションでは、AWS が最も複雑な移行とモダナイゼーションのタスクをどのように簡素化し、レガシーシステムの変革とクラウドイノベーションを加速しているかを説明します。アプリケーションの最新アーキテクチャへのアップグレード、リプラットフォーム、リファクタリングにおいて、チーム横断的な移行とモダナイゼーションの機会の発見、計画、実行方法を一新する革新的な AWS サービスについてご紹介します。また、ミッションクリティカルアプリケーションとデータをクラウドへ効率的に移行・改善する方法を学ぶことで、運用コストとライセンス費用の削減、イノベーションの加速、そしてレガシーコードベースのメンテナンス遅延によるリスクを軽減する方法をご覧ください。 DOP224-New | Accelerate modernization of VMware workloads using Amazon Q Developer Amazon Q Developer の新しい変換機能が、VMware 環境の AWS へのモダナイゼーションと移行をどのように簡素化・自動化するかについて学びませんか?このセッションでは、Amazon Q Developer が VMware 環境の Amazon EC2 への移行における発見、計画、リプラットフォーム、デプロイメントをどのように加速するかを紹介します。生成 AI を活用した機能が、VMware の AWS への移行を数ヶ月で効率化することで、スケーラビリティとイノベーションを高める方法をご紹介します。モダナイゼーションチームが差別化されていない重労働を削減し、生産性を向上させ、ビジネス価値をより迅速に提供する方法について洞察を得ることができます。 MAM119-New | New Launch – Amazon Elastic VMware Service: Start your modernization journey | Level 100 Amazon Elastic VMware Service (Amazon EVS) は、既存のスキルと使い慣れたソフトウェアを使用しながら、VMware ベースのワークロードを AWS に移行して実行するためのシンプルな方法です。主要機能について学び、Amazon EVS の提供するシンプルさ、柔軟性、セキュリティ、制御から仮想マシンがどのようなメリットを得られるかをご覧ください。このソリューションを構築したチームと共に、既存の VMware Cloud Foundation (VCF) サブスクリプション、VMware への投資、お好みのツールを活用しながら、クラウドのメリットを享受する方法を理解します。AWS 上で VCF 環境をデプロイする方法と、Amazon EVS がお客様のニーズにどのように対応できるかをご紹介します。 HYB201 | AWS wherever you need it: From the cloud to the edge | Level 200 ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、デジタル主権のニーズにより、一部はオンプレミスまたはエッジに残るものもあります。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、AWS IoT などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像処理、スマート製造、データレジデンシー要件を持つ生成 AI アプリケーションなどのハイブリッドクラウドおよびエッジコンピューティングワークロードをどのようにサポートするかを学びます。 HYB308 | Migrating your VMware workloads with on-premises dependencies | Level 300 ほとんどの VMware ワークロードは簡単にクラウドに移行できますが、アプリケーションの相互依存性、データレジデンシー要件、またはタイムライン制約により、一部はオンプレミスに残す必要があります。このセッションでは、AWS Outposts や AWS Local Zones などの AWS ハイブリッドおよびエッジサービスが、その場での移行とお客様のペースでのモダナイゼーションをどのように可能にするかを学びます。Outposts を使用したさまざまな移行パスと、クラウドへの移行を簡素化・加速するために使用できる移行ツールやプログラムについて詳しく説明します。 KUB310 | Amazon EKS for edge and hybrid use cases | Level 300 製造、医療、通信、金融サービスなどの業界では特に、低レイテンシー、データ依存性、データ主権、その他の規制上の理由により、一部のワークロードをオンプレミス、エッジ、またはハイブリッドシナリオで実行する必要があります。データ依存のワークロードは、AWS サービスにデータが存在するまで完全な移行を待つ必要があるかもしれません。このセッションでは、Amazon EKS Anywhere と Amazon EKS Hybrid Nodes を使用してオンプレミスでコンテナワークロードを実行し、VMware ベースのワークロードのモダナイゼーションをサポートする本番環境対応のアーキテクチャを探ります。 顧客事例から学ぶ MAM104 | AWS for VMware migrations: Successes, roadmaps, & strategies | Level 100 オンプレミスの VMware 環境を AWS に移行しようとしており、適切なアプローチについてのガイダンスを求めていますか?このセッションでは、その経験を歩んできた移行の先駆者たちが集まります。さまざまなグローバル組織が計画から実行まで、どのようにしてクラウドジャーニーを加速したかを直接聞くことができます。講演者は、移行をスムーズにした信頼できるツール、戦略、教訓を共有し、お客様の移行の指針となる洞察を得られます。さらに、各社のモダナイゼーションロードマップとイノベーション戦略についても垣間見ることができます。クラウドへの移行を始めたばかりのお客様でも、ハードルを乗り越えているお客様でも、自社のクラウド変革を推進するための実用的な洞察を得ることができます。 MAM214 | Gilead Sciences’ AWS migration: From VMware to cloud transformation | Level 200 Gilead Sciences が AWS プロフェッショナルサービスとの協力を通じて、グローバルなデジタルトランスフォーメーションをどのように加速したかをご紹介します。オンプレミス VMware 環境から AWS ネイティブサービスへの 2,000 台以上のサーバーの移行と、1,400 台以上のシステムの廃止の事例について知ることができます。この取り組みを主導した Gilead のリーダーから、移行アプローチ、活用した AWS のツールとサービス、ワークロード選択と移行のベストプラクティスについて直接話を聞くことができます。AWS を活用することで、Gilead はモダナイゼーションとイノベーションを加速することができました。Gilead がどのようにデータを活用し、AI のような新しいテクノロジーを統合してビジネス目標を達成しているのか、洞察を得ることができます。 ライセンスの最適化方法を学ぶ XNT204 | Licensing commercial software on AWS | Level 200 AWS はエンタープライズワークロードのための様々な移行パスを提供していますが、すべてのライセンスオプションを把握するの困難です。このセッションでは、サポート終了を含む Microsoft ソフトウェアのライセンスオプション、Microsoft、VMware、Oracle ワークロードのための補完的な AWS 最適化およびライセンス評価(AWS OLA)、および VMware のような商用ハイパーバイザーの高コストへの対処方法について説明します。ソフトウェアライセンス製品やアプリケーションをオープンソースの代替製品やクラウド専用に構築された技術に置き換えることで、将来に備え、ライセンスコンプライアンスの業務から脱却しましょう。 チョークトークを振り返りたいですか?ここでスライドをご覧ください。 MAM102-R | An AWS guide for VMware administrators | Level 100 STG337 | Migrate any VMware workload from anywhere to improve your TCO | Level 300 MAM218 | Technical decisions for a seamless migration from VMware to AWS | Level 200 MAM237-NEW | New Launch – Deep dive into Amazon Elastic VMware Service | Level 200 次のステップ VMware の移行を AWS がどのように支援できるかの詳細については、 AWS for VMware をご覧ください。 ワークロードを評価し、クラウドへの最適なパスを決定する準備はできましたか?無料の AWS Optimization and Licensing Assessment を今すぐリクエストしてください。 この投稿の翻訳は Solutions Architect の澤が担当させていただきました。原文記事は こちら です。
コンタクトセンターにおける問い合わせ量とエージェントの数は、1 日の中で変動します。エージェントの対応可能数を上回る問い合わせがある場合、エージェントの応答待ちの問い合わせはキューで保持されます。すべての着信問い合わせを処理する単一のキューを構成すれば、サービスレベルを最大化でき、待ち時間を最小化できます。各エージェントがすべての種類の問い合わせを処理できるのであればこれは有効です。しかし、複雑な環境を想定すると、すべてのエージェントがすべての問い合わせを効果的に処理していくことは現実的ではありません。ですから、このような状況では、コンタクトセンターの管理者は着信問い合わせを複数のキューに分割するよう構成します。キューを分割する基準として、言語、事業部門、製品、機能、営業時間、顧客の優先順位付けなどが一般的に使用されます。 コンタクトセンターの新入エージェントは、数週間から数ヶ月にわたり研修を受け、着信問い合わせに対応するための複数のスキルを向上させます。企業は、エージェントが問い合わせ対応で活躍できるようになるまでの時間を短縮することと、新入社員にカリキュラムを修了させることとの間で苦心しています。つまり、運用管理者の観点からは、エージェントが研修期間中の早い段階でより簡単なタイプの問い合わせに対応できるよう、キューを細かく分ける必要があります。一方、過度に専門化されたキュー構成は、問い合わせタイプ間の量の変動によるルーティング制御と運用の非効率性をもたらすサイロ化された構造を作り出します。多数のキューは、IVR における問い合わせ分類のルールとロジックを複雑にします。これらのルールは時間とともに変化するので、誤った振り分けを引き起こし、結果コンタクトセンター内での不要な転送につながってしまいます。 Amazon Connect は、(コンタクトセンター単位の)キューと(エージェント単位の)習熟度を設定する機能を提供します。Amazon Connect では、キューは問い合わせのタイプに基づいてルーティング制御する方法を提供します。習熟度の設定により、そのキュー内の問い合わせに対するビジネスニーズに最も適合するスキルを持つエージェントへさらにルーティング制御します。このブログ記事では、ルーティング制御の要件と運用効率のバランスを取るための Amazon Connect におけるキューと習熟度の設計および設定のベストプラクティスを提供します。 概要 次の図は Amazon Connect のルーティングに関連するエンティティとその関係を示しています キューはエージェントが応答するまで問い合わせが保持される領域です。ビジネスに合わせた、サービスレベルのゴールや目標はキュー単位で設定されます ルーティングプロファイル は、エージェントが対応するように設定された問い合わせのキューのリストをまとめたものです エージェントは 1 つのルーティングプロファイルを持つことができます ルーティングプロファイル内の各キューには優先度(1 から 99)があり、このエージェントがキューに対応する順序を示します。例えば、エージェント A2 は、Tech Support キュー Q2 (優先度 3)の新しい問い合わせよりも、Billing キュー Q1(優先度 2)の古い問い合わせを優先して対応します 習熟度 は、特定の属性を持つ問い合わせに対するエージェントの専門性を示します。習熟度は、 事前定義された属性名 、その値、習熟レベルで構成されます。事前定義された属性を作成した後、エージェントに 1 つ以上の習熟度を割り当てることができます 事前定義された属性の各値について、エージェントはその習熟度における専門性のレベルである 習熟度レベル (1 から 5)を持ちます。エージェントは習熟度を得るために特定の学習パスを完了する必要があり、学習パスの進捗が習熟レベルに反映される可能性があります ルーティング条件 は、 1 つ以上の習熟度要件の組み合わせに基づいてエージェントを対象とするルールをまとめたものです エージェントに問い合わせをルーティングするためにはキューの使用が必要ですが、 習熟度 の使用はオプションです。エージェントの習熟度を使用したルーティングは、以下の 4 つのステップで設定します: ルーティングに関連する事前定義された属性を定義する エージェントに習熟度を割り当てる キュー内での問い合わせのルーティング方法を定義するために、コンタクトフローでルーティング条件を設定する キューに転送する ソリューションの構成 ビジネスプロセスアウトソーシング(BPO)企業の AnyCompany 社は、 1 つの Amazon Connect インスタンスで、 2 つの顧客をサポートしています。各顧客には異なるサービスレベル契約(SLA)があり、SLA を満たさない場合のペナルティが設定されています。彼らは世界中でより多くの顧客にサービスを提供するため、積極的な拡大計画を持っています。エージェントは規模による効率性を高めるために複数の顧客をサポートしています。彼らはエージェントに新しい言語のトレーニングを行わず、顧客対応に必要な言語スキル(または能力)を持つエージェントを雇用しています。また、エージェントは顧客が選択したチャネル(音声またはチャット)で対応します。他の BPO と同様に、AnyCompany はエージェントの離職率が高く、新しいエージェントのトレーニングと導入に多額の予算を費やしています。特に複雑な問い合わせタイプや重要顧客への対応に必要な高度な専門知識を身につけるためには時間がかかるため、顧客満足度が低くなっています。 両顧客(AnyManufacturer-1 と AnyManufacturer-2)は 4 種類のオーディオ機器(スピーカー、レシーバー、サウンドバー、ワイヤレス)を専門としています。各メーカーの問い合わせに対する生産性を上げるために、エージェントは各機器タイプに対して 4 日間のトレーニングと、各メーカーのサービス手順を知るための 4 日間のトレーニングを受けます。これにより、各メーカーの対応を行うためには、 4 週間のトレーニングが必要になります。 AnyManufacturer-1 への問い合わせは、北米の2つの国(米国とカナダ)の消費者からのもので、エージェントは 2 つの言語(英語とフランス語)のいずれかで対応する必要があります。BPO のエージェントは北米の営業時間中に AnyManufacturer-1 をサポートします。 AnyManufacturer-2 への問い合わせは、ヨーロッパの 3 つの国(イギリス、スペイン、フランス)のいずれかの消費者からで、エージェントは3つの言語(英語、スペイン語、フランス語)のいずれかで対応する必要があります。BPO エージェントはヨーロッパの営業時間中に AnyManufacturer-1 をサポートします。 エージェントの習熟度を使用した最適なルーティングソリューションは以下のようになります :  メーカー × 言語 × 機種の組み合わせに基づく 20 のキューにより、問い合わせをセグメント化 各キューに独自のサービスレベル(SL)目標と、リアルタイムおよび履歴の問い合わせ量の測定が存在 AnyManufacturer-1:2 つの言語 × 4 つの機器タイプ = 8 キュー AnyManufacturer-2:3 つの言語 × 4 つの機器タイプ = 12 キュー メーカー × 言語の組み合わせに基づく 5 つのルーティングプロファイルによるエージェントをセグメント化 AnyManufacturer-1 用の 2 つの言語と AnyManufacturer-2 用の 3 つの言語 = 5 つのルーティングプロファイル  この方法では、AnyCompany はエージェントが問い合わせ対応に参加する前に、各メーカーのすべての機器タイプについてトレーニングを行う必要があります。これによりエージェントが実際に本番の対応を行うまでの時間が長期化します 新しいメーカーの導入と追加言語のサポートという積極的な成長計画により、AnyCompany は将来的にさらに追加のキューとルーティングプロファイルが必要になります エージェントの習熟度を使用した最適なルーティングソリューションは以下のようになります : 習熟度は事前定義された属性と値を使用して構築されます 事前定義された属性は、専門的な習熟カテゴリー(言語など)を指し、値には対応可能な異なる言語のリスト(例:英語、スペイン語、フランス語)が含まれます エージェントには習熟度とそれぞれの習熟度レベルが割り当てられます。習熟度レベルは各習熟度におけるエージェントの専門性を示します(1 ~ 5 、5 が最高) エージェントが持っている能力や、業務を通じて学ぶ知識と専門性の分野である、言語と機器を習熟度として扱います 以下の表は AnyCompany で採用した習熟度を示しています : 事前定義された属性 値 種類 connect:Language (言語) connect:English, connect:Spanish, connect:French システム Manufacturer (メーカー) AnyManufacturer-1, AnyManufacturer-2 ユーザー EquipmentType (機器種別) speakers, receivers, sound bars, wireless ユーザー connect:Subtype connect:Chat, connect:SMS, connect: Telephony システム 次の図は、習熟度をどのように Amazon Connect コンソールで設定するかを示しています : 習熟度を導入することで、AnyCompany は以下の改善を実現できます : 新入社員は 1 つの機器タイプの研修を受けた後すぐに問い合わせ対応を開始できます。これにより、エージェントの業務開始までの時間を短縮し、オンボーディングプロセスの早い段階で理論を実践に移すことができます キューの詳細な分類の一部を習熟度で管理できます。問い合わせのセグメンテーションは、各メーカーに対して 2 つのキューに分かれ、AnyCompany は各顧客に対して個別のサービスレベルを維持し続けることができます。これにより、キューの数が 20 から 2 へと 10 分の 1 に削減されます エージェントのセグメンテーションは 1 つのルーティングプロファイルに集約されます。これはルーティングプロファイルの数が 5 分の 1 に削減されることを意味します。大規模で複雑な顧客の場合、これにより設定が簡素化され、管理のオーバーヘッドコストを削減できます 次に、AnyCompany におけるルーティングの 2 つのユースケースについて見ていきましょう。 ユースケース 1 アメリカから英語を話す顧客が AnyManufacturer-1 スピーカーの修理を依頼するために電話をかけてきました。まず顧客は、言語および製品について最高の習熟度を持つエージェントに転送されるべきです。最高の習熟度のエージェントにルーティングできなければ、次に、習熟度レベル 3 以上のエージェントが対象とされます。最後に、そのメーカーについて何らかの経験を持つすべてのエージェントが対象となります。 エージェントのターゲティング要件は、コンタクトフローの ルーティング条件の設定 (Set routing criteria)ブロックを使用して、以下のルーティング基準で実装できます。 ステップ 1 {connect:Language} connect:English >= 5 AND {connect:subType} connect:Telephony >= 5 AND {Manufacturer} AnyManufacturer-1 >= 5 AND {EquipmentType} speakers >= 5 Expire in 5 seconds ステップ 2 {connect:Language} connect:English >= 3 AND {connect:subType} connect:Telephony >= 3 AND {Manufacturer} AnyManufacturer-1 >= 3 AND {EquipmentType} speakers >= 3 Expire in 5 seconds ステップ 3 {connect:Language} connect:English >= 1 AND {connect:subType} connect:Telephony >= 1 AND {Manufacturer} AnyManufacturer-1 >= 1 このユースケースのルーティング条件は、ルーティング条件の設定ブロック内で設定されます。最後のステップ 3 にはタイマーがないため、ステップ 3 のルーティング条件が満たされるまで問い合わせは待機します。 ユースケース 2 スペインからスペイン語を話す顧客が、AnyManufacturer-2 のレシーバーのサービス状況を確認するためにチャットをしています。顧客はまず、各項目(AnyManufacturer-2、レシーバー、スペイン語)について最高の習熟度を持つエージェントにルーティングされるべきです。15秒後、レシーバーまたはスピーカーについて習熟度レベル 3 以上のエージェントが対象となります。さらに 20 秒後、任意のメーカーのチャットまたはSMSチャネルについて習熟度レベル 2 以上のすべてのエージェントが対象となります。さらに 30 秒後、このキュー内のすべてのエージェントが対象となります。 エージェントへのターゲッティング要件は、コンタクトフローの ルーティング条件の設定ブロック を使用して、以下のルーティング条件で実装できます。 ステップ 1 {Manufacturer} anyManufacturer-2>= 5 AND {EquipmentType} receivers >= 5 AND {Language} Spanish >= 5 Expire in 15 seconds ステップ 2 {EquipmentType} receivers >= 3 OR {EquipmentType} speakers >= 3 Expire in 20 seconds ステップ 3 {connect:subType} connect:Chat >= 2 OR {connect:subType} connect:SMS >= 2 Expire in 30 seconds Amazon Connect は AWS Lambda を使用して、外部からの動的なルーティング条件作成をサポートしています。Lambda 関数はルーティング条件をカプセル化した JSON オブジェクト を返します。前述の図は、外部の JSON オブジェクトにリンクする動的なルーティング条件の設定を示しています。前のユースケースとは異なり、このユースケースの最終ステップ 3 にはタイマーがあります。タイマーが終了すると、問い合わせは、ルーティングプロファイルにこのキューを持つ応答可能なすべてのエージェントに転送されます。より複雑なニーズを持つコンタクトセンターでは、ルーティング条件を実行時に生成することができます。ルーティングのルールは、エンタープライズルールエンジンやデータストアから出力できます。これらの条件は、Amazon Connect API から取得したコンタクトセンターのメトリクスのリアルタイム値に基づいて生成することもできます。 ベストプラクティス キューを使用する際のベストプラクティスは以下の通りです : サービスレベルの目標や運用時間など、固有の要件に対して新しいキューの設定を検討します 特定タイプの問い合わせのレポートを出力することのみを目的に、キューを作成しないでください キューを追加することによるキャパシティプランニング、スケジューリング、バックエンドでのレポート作成のコストを認識してください エージェントのグループ間で問い合わせの負荷分散を行うために、ルーティングプロファイルで優先順位と遅延を使用してください 習熟度を使用する際のベストプラクティスは以下の通りです : キュー内の特定のエージェントをターゲットにする追加制御を導入するために習熟度を使用します 同じ問い合わせタイプをサポートする際に、より高い専門知識を持つエージェントを優先し、その後他のエージェントにルーティングする必要がある場合、習熟度を使用します ルーティング基準のステップはタイマーを使用して設定できます。これにより段階的なエージェント選択アプローチが可能になります。最終ステップのタイマーはオプションです。最終ステップのタイマーが期限切れになると、このキューをルーティングプロファイルに持つすべてのエージェントがターゲットになります。最終ステップがタイマーなしで設定されている場合、ルーティング基準が満たされるまで問い合わせは待機します ルーティングの変更のために習熟度レベルを変更しないでください。習熟度は、エージェントの専門知識の増減の実態に沿って変更すべきです 習熟度は、エージェントが特定タイプの問い合わせを処理する経験を学び、発展させた能力を実証する方法です。エージェントのモチベーション向上や報償として、学習進度に基づいて習熟度を自動設定することを検討してください まとめ この記事では、架空の企業 AnyCompany の管理者が、単一の Amazon Connect インスタンス内で異なるルーティング要件を持つ 2 つの顧客向けにキュー、習熟度、ルーティング基準を設定する方法を説明しました。まず、習熟度を含まないキュー構造について詳しく説明しました。その後、設計に習熟度を導入し、習熟度によってキュー内の特定のエージェントをターゲットにする追加のコントロールが可能になることを説明しました。キューと習熟度を使用する際のメンタルモデルに関する考慮事項とベストプラクティスをいくつか挙げました。この記事を参考に、キュー設計を簡素化し、ルーティングエラーや誤送信を減らし、最適なエージェントへのルーティングとコンタクトセンターの効率性のバランスを取るエージェント選択アプローチを開発することができるでしょう。 Amazon Connect は、使用した分だけお支払いいただく従量料金を採用しています。前払い、長期契約、最低月額料金は必要ありません。設定にサポートが必要な場合は、 AWS プロフェッショナルサービス からサポートを受けることができます。また、世界中の Amazon Connect パートナー からもサポートを受けることができます。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか? お問い合わせください。 筆者について Parind Poi は、AWS プロフェッショナルサービスのシニアプラクティスリーダーです。AWS におけるカスタマーエクスペリエンス(CX)に関する深い専門知識を持つ専門チームを率いています。Parind は、クラウドによるカスタマーエンゲージメントに関するワークロードのモダナイゼーションの支援に情熱を注いでいます。 Prashant Desaiは、AWS プロフェッショナルサービスのプリンシパルコンサルタントで、大規模なコンタクトセンターのクラウドへの設計と移行の経験を持っています。従来型およびクラウド型のコンタクトセンターにおいて合計 25 年以上の経験を有し、顧客ワークロードの最新化と顧客体験の簡素化のための革新的な方法を常に追求しています。 Balkrishna Nadkarniは、Amazon Connectのプリンシパルテクニカルプロダクトマネージャーです。Amazon Connect の顧客の毎日をよりよくするため、Amazon Connectのルーティングソリューションの構築を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。
2 月 20 日の AWS Developer Day にぜひご参加ください! このバーチャルイベントは、開発者とチームが最先端でありながら責任ある 生成 AI を開発ライフサイクル全体に組み込み、イノベーションを加速できるようにすることを目的としています。 基調講演では、AWS Evangelism の Vice President である Jeff Barr が、生成 AI に基づく次世代のソフトウェア開発、この変化する環境で成功するために必要なスキル、今後どのように進化していくかに関する考えを語ります。 Amazon Q Developer 、 AWS Amplify 、 GitLab Duo with Amazon Q に関するエキサイティングな技術の詳細情報と製品アップデートをぜひご覧ください。 Christian Bonzelet 氏 (AWS コミュニティビルダー)、 Hazel Saenz 氏 (AWS サーバーレスヒーロー)、 Matt Lewis 氏 (AWS データヒーロー)、 Johannes Koch 氏 (AWS DevTools ヒーロー) による実際のユースケース、ライブコーディングデモ、インタラクティブセッション、コミュニティスポットライトセッションをご体験いただけます。今すぐ このイベントにサインアップ してください! 2 月 10 日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS STS の AWS SDK デフォルトの更新 – アプリケーションの耐障害性とパフォーマンスを向上させるための AWS Security Token Service (AWS STS) グローバルエンドポイントに対する 今後の変更 についてお知らせしたとおり、2025 年 7 月 31 日に AWS Software Development Kit (AWS SDK) と AWS コマンドラインインターフェイス (AWS CLI) の 2 つのデフォルトを更新します。デフォルトの AWS STS サービスはリージョナルに、デフォルトの再試行戦略はスタンダードに変更されます。更新後に予期しない事態が発生しないように、リリース前にアプリケーションをテストすることをお勧めします。 AWS トラストセンターの紹介 – Amazon Web Services (AWS) の CISO である Chris Betz が、クラウドでお客様のアセットを保護する方法を説明する新しいオンラインリソース、 AWS トラストセンター を紹介しました。このリソースは、当社のセキュリティ対策、コンプライアンスプログラム、データ保護統制についての窓口であり、お客様の信頼を得るために当社が日々どのように取り組んでいるかを示すものです。 VPC エンドポイントをログに記録するための AWS CloudTrail ネットワークアクティビティイベント – セキュリティ体制の強化、潜在的な脅威の検出、VPC ネットワークトラフィックに関するより深いインサイトの取得を行うことのできる、強力なツールを提供します。この機能は、AWS 環境を包括的に可視化して制御する必要のあるお客様の重要なニーズに対応します。 非 HTTP リソースの AWS Verified Access のサポート – AWS Verified Access は、HTTP アプリケーションだけでなく、 Amazon Relational Database Service (Amazon RDS) データベースなどの非 HTTP リソースへの VPN レスの安全なアクセスの提供を開始しました。これにより、ウェブアプリケーションとデータベース接続の両方のセキュリティが向上し、ユーザーエクスペリエンスが改善されます。詳細については、「 Verified Access エンドポイント 」ページと 動画チュートリアル をご覧ください。 Network Load Balancer (NLB) の新しいサブネット管理 – NLB は今まで、新しい アベイラビリティーゾーン でのサブネットの追加のみに制限されていましたが、 Application Load Balancer (ALB) の機能と同様、サブネットの削除を含む完全なサブネット管理をサポートするようになりました。この強化により、組織はネットワークアーキテクチャをより細かく制御できるようになり、AWS ロードバランシングサービスの一貫性が実現します。 Amaz o n SageMaker JumpStart の Meta SAM 2.1 と Falcon 3 モデル – 最先端の動画および画像セグメンテーション機能を備えた Meta の Segment Anything Model (SAM) 2.1 を 1 つのモデルで使用できます。また、科学、数学、コーディング機能の強化に重点を置いて、10 億から 100 億のパラメータにわたる 5 つのモデルを備えた Falcon 3 ファミリーを使用することもできます。詳細については、「 SageMaker JumpStart 事前トレーニング済みモデル 」と「 Amazon SageMaker JumpStart の開始方法 」をご覧ください。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 AWS ドキュメントの更新 – AWS ドキュメント、SDK、CLI チームのリーダーである Greg Wilson が、200 以上の AWS サービスの進捗状況、課題、技術ドキュメントの今後の予定について、洞察に満ちたブログ投稿を共有しました。この投稿では、特定のニーズに適したサービスの選択、コードサンプルを 2 倍にするなどの文書の読みやすさの最適化、ダークモードやトップグローバルナビゲーションコントロールによる自動候補表示などの使いやすさの向上に役立つ AWS 意思決定ガイド にも触れています。また、生成 AI を使用して技術文書を作成する方法についても学ぶことができます。 AWS Well-Architected for Enterprise – 大規模な AWS ソリューションを設計、構築、運用する技術専門家向けに設計された、新しい無料のデジタルコースです。この中級レベルのコースは、ビジネス目標に沿う形でクラウドアーキテクチャを最適化するのに役立ちます。このコースは修了までに約 1 時間かかります。最後には学習内容を強化するための知識チェックが含まれます。 AWS と .NET Aspire の統合 – AWS の .NET チームは、.NET アプリケーションを AWS リソースに接続するための統合に取り組んできました。クラウド対応アプリケーションを構築するオープンソースフレームワークである .NET Aspire 用 Aspire.hosting.AWS NuGet パッケージを使用して、AWS アプリケーションリソースを自動的にデプロイする方法をご覧ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Innovate: 生成 AI + データ – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンスにご参加ください。このカンファレンスは、APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: パリ (4 月 9 日)、 アムステルダム (4 月 16 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)。 AWS GenAI Lofts – GenAI Lofts は、スタートアップや開発者にコラボレーションスペースと没入型の体験をご提供します。 Built on Amazon Bedrock デモナイト (4 月 19 日)、 スタートアップ向け SageMaker Unified Studio デモ (4 月 21 日)、 Agentic Graph RAG を使用したハンズオンワークショップ (4 月 25 日) など、 GenAI Loft サンフランシスコ の実地イベントにご参加いただけます。 GenAI Loft ベルリン の Opening Day は 2 月 24 日で、3 月 7 日まで開催されます。 AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーがリードする技術的なディスカッション、ワークショップ、ハンズオンラブなどが開催される、コミュニティ主導のカンファレンスにご参加ください: パキスタン・カラチ (2 月 22 日)、 イタリア・ミラノ (4 月 2 日)、 ベイエリア – セキュリティエディション (4 月 4 日)、 ルーマニア・ティミショアラ (4 月 10 日)、 チェコ共和国・プラハ (4 月 29 日)。 AWS re:Inforce – カレンダーを確認して、ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 16~18 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。今すぐイベントの最新情報にサブスクライブしてください! 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 2 月 17 日週はここまでです。2 月 24 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。
2 月 13 日、 AWS CloudTrail の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントのネットワークアクティビティイベントの一般提供を発表できたことを嬉しく思います。この機能を使用すると、VPC エンドポイントを通過する AWS API アクティビティを記録および監視できるので、データ境界を強化し、より優れた発見的コントロールを実装するのに役立ちます。 以前は、潜在的なデータ漏洩を引き起こすための試みや、VPC エンドポイントを介したネットワーク内のリソースへの不正アクセスを検出することは困難でした。VPC エンドポイントポリシーを設定して外部アカウントからのアクセスを禁止することができますが、拒否されたアクションをログに記録したり、外部認証情報が VPC エンドポイントで使用されたことを検出したりする組み込みのメカニズムはありませんでした。TLS トラフィックを検査および分析するためのカスタムソリューションを構築するという選択肢もありましたが、運用面でのコストがかかり、暗号化された通信のメリットが損なわれる可能性がありました。 この新機能により、VPC エンドポイントを通過するすべての AWS API アクティビティをログに記録するようオプトインできるようになりました。CloudTrail はこれらのイベントをネットワークアクティビティイベントと呼ばれる新しいイベントタイプとして記録し、VPC エンドポイントを通過するコントロールプレーンとデータプレーンの両方のアクションをキャプチャします。 CloudTrail に記録されるネットワークアクティビティイベントには、次のような主なメリットを提供します。 包括的な可視性 – アクションを開始した AWS アカウントに関係なく、VPC エンドポイントを通過するすべての API アクティビティがログに記録されます。 外部認証情報の検出 – 組織外の認証情報を使用して VPC エンドポイントへのアクセスが行われたときを特定します。 データ漏洩の防止 – 不正なデータ移動の潜在的な試みを検出して調査できます。 セキュリティモニタリングの強化 – TLS トラフィックを復号化する必要なく、VPC エンドポイントでのすべての AWS API アクティビティのインサイトを取得できます。 規制へのコンプライアンスの可視性 – 通過するすべての API アクティビティを追跡することで、規制要件を満たす能力を向上させることができます。 ネットワークアクティビティイベントでの VPC エンドポイントログの開始方法 ネットワークアクティビティイベントを有効にするには、 AWS CloudTrail コンソールに移動し、ナビゲーションペインで [証跡] を選択します。 [証跡の作成] を選択して新しい証跡を作成します。 [証跡名] フィールドに名前を入力し、イベントログを保存する Amazon Simple Storage Service (Amazon S3) バケットを選択します。CloudTrail で証跡を作成するとき、既存の Amazon S3 バケットを指定するか、証跡のイベントログを保存する新しいバケットを作成することができます。 [ログファイルの SSE-KMS 暗号化] を [有効] に設定する場合、 [新規] を選択して新しい AWS Key Management Service (AWS KMS) キーを作成するか、 [既存] を選択して既存の KMS キーを選択します。 [新規] を選択する場合、 [AWS KMS エイリアス] フィールドにエイリアスを入力する必要があります。CloudTrail は、この KMS キーでログファイルを暗号化してポリシーを追加します。KMS キーと Amazon S3 は同じ AWS リージョンにある必要があります。この例では、既存の KMS キーを使用します。このデモでは、 [AWS KMS エイリアス] フィールドにエイリアスを入力し、残りの設定はデフォルトのままにします。 [次へ] を選択して次のステップに進みます。 [ログイベントの選択] ステップでは、 [イベント] で [ネットワークアクティビティイベント] を選択します。 [cloudtrail.amazonaws.com] 、 [ec2.amazonaws.com] 、 [kms.amazonaws.com] 、 [s3.amazonaws.com] 、 [secretsmanager.amazonaws.com] などの AWS のサービスのリストからイベントソースを選択します。このデモでは、2 つのネットワークアクティビティイベントソースを追加します。最初のソースには、 [ec2.amazonaws.com] オプションを選択します。 [ログセレクターテンプレート] では、一般的なユースケース用のテンプレートを使用するか、特定のシナリオ用にきめ細かいフィルターを作成することができます。例えば、VPC エンドポイントを通過するすべての API アクティビティをログに記録するには、 [すべてのイベントをログに記録する] テンプレートを選択できます。ここでは、 [ネットワークアクティビティアクセス拒否イベントをログに記録] テンプレートを選択して、アクセス拒否イベントのみをログに記録します。オプションで、 [セレクター名] フィールドにログセレクターテンプレートを識別する名前を入力できます (「 Amazon EC2 のネットワークアクティビティイベントを含める 」など)。 2 番目の例として、 [カスタム] を選択して [eventName] や [vpcEndpointId] などの複数のフィールドにカスタムフィルターを作成します。特定の VPC エンドポイント ID を指定するか、結果をフィルターして特定の条件に一致する VPC エンドポイントのみを含めることができます。 [高度なイベントセレクター] で、 [フィールド] から [vpcEndpointId] を選択し、 [次と等しい] を [オペレーター] として選択して VPC エンドポイント ID を入力します。JSON ビューを展開すると、指定したイベントセレクターが JSON ブロックとして表示されます。 [次へ] を選択し、選択内容を確認した後に [証跡の作成] を選択します。 設定が完了すると、CloudTrail は VPC エンドポイントのネットワークアクティビティイベントのログ記録を開始するので、このデータを分析して必要な対応を取ることができます。AWS CloudTrail ネットワークアクティビティイベントを分析するには、CloudTrail コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK を使用して関連するログを取得できます。 CloudTrail Lake を使用して、ネットワークアクティビティイベントをキャプチャ、保存、分析することもできます。Trails を使用している場合は、 Amazon Athena を使用して、特定の条件に基づいてこれらのイベントをクエリおよびフィルターできます。これらのイベントを定期的に分析することで、AWS でセキュリティを維持し、規制に準拠してネットワークインフラストラクチャを最適化することができます。 今すぐご利用いただけます VPC エンドポイントをログに記録するための CloudTrail ネットワークアクティビティイベントは、セキュリティ体制の強化、潜在的な脅威の検出、VPC ネットワークトラフィックのより深いインサイトの取得を行うことのできる強力なツールを提供します。この機能は、AWS 環境を包括的に可視化して制御する必要のあるお客様の重要なニーズに対応します。 VPC エンドポイントのネットワークアクティビティイベントは、すべての商用 AWS リージョンで利用できます。 詳細については、「 AWS CloudTrail の料金 」をご覧ください。 CloudTrail ネットワークアクティビティイベントの使用を開始するには、 AWS CloudTrail にアクセスしてください。CloudTrail とその機能の詳細については、 AWS CloudTrail のドキュメント を参照してください。 – Esra 原文は こちら です。
このブログは 2025 年 1 月 31 日に Emma Fu(Senior Technical Product Manager)と Matt Luttrell(Principal Solutions Architect)によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 Amazon Elastic Block Store( Amazon EBS )スナップショットを使用して、業務では新しいボリュームを作成する際のベースライン基準となるアプリケーションデータボリュームのポイントインタイムコピーを取得します。これにより、異なる AWS リージョン でアプリケーションのワークロードを迅速に起動したり、データ保護や災害復旧の要件を満たすことができます。ユーザーが異なる AWS リージョンやアカウント間で AWS ワークロードを移行する際、セキュリティと規制コンプライアンスは依然として最優先事項であり、きめ細かなアクセス制御を可能にする API コールのリソースレベルアクセス制御が求められます。 今回、Amazon EBS は CreateVolume アクションのリソースレベル権限を強化し、ボリューム作成時にソーススナップショットの AWS Identity and Access Management(IAM) ポリシーでリソースレベルの追加権限を指定できるようになりました。この機能強化によりユーザーは、どの AWS IAM 認証情報がソーススナップショットから Amazon EBS ボリュームを作成できる か制御したり、ソーススナップショットを Amazon EBSボリューム の作成に使用できる条件を定義することができます。 この記事では、リソースレベル権限における変更を説明し、その実装ユースケースを検討し、この改善された権限モデルを採用することの重要性について議論します。また、以前のリソースレベル権限モデルから移行するための計画も提供します。 何が変わったのでしょうか? ソーススナップショットからボリュームを作成または復元する場合、AWS IAM ポリシーを使用して、CreateVolume アクションを実行する権限を付与する必要があります。以前は、AWS IAM ポリシーの CreateVolume アクションには、作成されるボリュームの権限が必要であり、ソーススナップショットは AWS IAM ポリシーの CreateVolume アクションのリソースコンテキストに含まれていませんでした。今回のアップデートにより、作成されるボリュームとソーススナップショットの両方に対してリソースレベルの権限を強制できるようになりました。また、ソーススナップショットの特定の権限要件を満たすために、 Amazon Elastic Compute Cloud(Amazon EC2) 固有の5つの条件キー(ec2:Encrypted、ec2:VolumeSize、ec2:Owner、ec2:ParentVolume、ec2:SnapshotTime)も使用できます。さらに、AWS IAM ポリシーでソーススナップショットの グローバル条件キー を使用することもできます。作成するボリュームに Amazon Resource Name( ARN )を使用してリソースステートメントを既に追加している場合は、スナップショットのリソースステートメントも明示的に指定する必要があります。以下の例を見てみましょう。 以前のポリシー: ボリュームリソースの作成を許可するポリシーが必要でした。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } 今回のアップデート後に必要なポリシー: ボリュームとソーススナップショットの両方を許可するポリシーが必要になりました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:snapshot/*" } ] } ソーススナップショットのリソースレベルの追加権限で何ができますか? 新しいリソースレベル権限モデルへ移行すると、2 つのメリットがあります: 1/ アクセス制御の粒度が強化 ソーススナップショットのリソースレベルの権限は、ボリュームの作成に使用できるスナップショットをきめ細かく制御します。条件を指定することで、個々のスナップショットまたはカテゴライズされたスナップショットに対して、権限を設定できます。例えば、特定の AWS アカウントが所有する機密データを含むワークロードの定期的なバックアップとして Amazon EBS スナップショットを取得する場合、この新しい権限モデルを使用して、許可されたユーザーが所有するスナップショットだけにボリュームの作成を制限することができます。 ポリシーの例: 1. 自分の組織に所属するスナップショットからのボリュームの作成のみを許可します。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" ], "Condition": { "StringEquals": { "aws:ResourceOrgId": "&lt;your organization ID&gt;" } } } 2. 自分のアカウントに所属するスナップショットからのボリュームの作成のみを許可します。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "&lt;your account ID&gt;" } } } 3. 特定のタグを持つスナップショットからのみボリュームの作成を許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/classification": "not-sensitive", "aws:ResourceOrgId": "&lt;your organization ID&gt;" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 2/ リソースとコストの最適化 この追加された権限は、セキュリティとコンプライアンス要件を強化するだけでなく、リソースの優先順位付けとコスト最適化のための強力なツールにもなります。スナップショットの取得時期や暗号化の状態などの条件を指定することで、ボリュームを作成する際にどのスナップショットを優先するかを制御できます。例えば、より新しいスナップショットや暗号化されたスナップショットを、他のスナップショットよりも優先させることができます。これにより、リソースの使用をビジネスの優先順位に合わせながら、セカンダリリージョンのボリュームをリストアするなどのバックアップ戦略を合理化することができます。 ポリシーの例: 1. 暗号化されたスナップショットからのボリュームの作成のみを許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "Bool": { "ec2:Encrypted": "true" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 2. 2025-01-01 00:00:00 以降に取得したスナップショットからのボリュームの作成のみを許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "DateGreaterThan": { "ec2:SnapshotTime": "2025-01-01T00:00:00Z" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 今回のアップデートに対してどのような準備が必要ですか? ほとんどの AWS ユーザーは今回のアップデートの影響を受けません。今回のアップデートによる影響を受けるポリシーが適用されていることを検出した場合、電子メールと AWS Health ダッシュボードを利用してお知らせしています。影響を受けるアカウントは現在許可リストに登録されており、2025 年 2 月 17 日までは以前のポリシーが適用されます。2025 年 2 月 17 日から、AWS IAM ポリシーを更新したアカウントを AWS はその許可リストから除外し始めます。そして、2025 年 5 月 17 日がすべてのアカウントが新しい許可モデルに移行する最終期限となります。2025 年 5 月 17 日以降、AWS IAM ポリシーの更新を行わなかった場合、CreateVolume API の呼び出しが拒否される可能性があります。 タイムライン: 2025 年 2 月 17 日より、AWS IAM ポリシーを更新したアカウントから順に、AWS は許可リストから削除し始めます。 2025 年 5 月 17 日が、すべてのアカウントが新しい権限モデルに移行する最終期限となります。 影響を受けるポリシーを特定し、更新します: AWS CloudTrail のログを確認するか、IAM get-account-authorization-details CLI コマンドを実行して、CreateVolume アクションなどのすべての AWS IAM ポリシーを一覧表示し、関連するポリシーを特定することができます。一般的に、更新が必要なポリシーは以下の 2 つのカテゴリに分類されます。 カテゴリ 1: スナップショットリソースの許可ステートメントがありません。 ポリシーの Resource 要素でボリュームのみ許可している場合、スナップショットリソースも許可する必要があります。次のコード例を見てください。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } 更新後のコードブロックは次のようになります。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" } ] } 同様の AWS マネージドポリシーの例として、 AWSElasticDisasterRecoveryServiceRolePolicy があります。 カテゴリ2: Resource 要素でボリュームとスナップショットの両方が許可されていますが、Condition はボリュームにのみ適用されます。 ポリシーの Resource 要素にボリュームとスナップショットの両方に一致するワイルドカードが使用されており、特定のボリュームに関する Condition 要素が含まれている場合は、 Resource 要素をボリュームにのみ適用するように変更し、スナップショットを許可する新しいステートメントを追加する必要があります。 以下は以前のポリシーのうち、今回のアップデート後に機能しなくなる例です。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "*", "Condition": { "StringLike": { "aws:RequestTag/CSIVolumeName": "*" } } } ポリシーを機能させるには、以下のように変更します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*", "Condition": { "StringLike": { "aws:RequestTag/CSIVolumeName": "*" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" } ] } 同様の AWS マネージドポリシーの例として、 AmazonEBSCSIDriverPolicy があります。 DryRun モードを使用し更新を検証します AWS IAM ポリシーが正しいかどうかを検証する必要がある場合、DryRun モードを使用してテストします。DryRun モードでは、実際には許可リストに含まれ API が古い権限モデルに従う場合でも、新しい権限モデルでの認可結果を確認することができます。DryRun モードを使用するには、AWS Command Line Interface(AWS CLI)コマンドまたは Amazon EBS CreateVolume API コールで -dry-run パラメータを指定します。DryRun モードを使用する CreateVolume API コールは常に エラー を返します。DryRunOperation を伴うエラーが返された場合は、AWS IAM ポリシーが新しい権限モデルで動作することを意味します。UnauthorizedOperation を伴うエラーが返された場合には、AWS IAM ポリシーを更新する必要があります。DryRun モードの詳細については、 AWS CLI のドキュメント を参照してください。 まとめ リソースレベルの権限に関するアップデートは、セキュリティ、制御、および運用の柔軟性を強化します。現在、古いアクセス許可モデルを使用しており、引き続きそれを使用する必要がある場合は、AWS サポートに連絡してユースケースへの対応を求めることができます。2025 年 2 月 17 日までに新しい許可ポリシーに移行する準備ができている場合は、AWS サポートに許可リストから削除するように依頼することもできます。今回の変更は、CopySnapshot のような他のアクションでも同様の許可を可能にする、より広範な取り組みの一部です。 サポートされている条件キーの詳細については、 ドキュメント .を参照してください。この投稿に関するフィードバックがある場合は、コメント欄で送信するか、AWS サポートに連絡してください。Amazon EBS ボリュームとスナップショットの詳細については、 Amazon EBS ユーザーガイド を参照してください。 <!-- '"` --> TAGS: Amazon EBS , Amazon EC2 , Amazon Elastic Block Storage (Amazon EBS) , AWS Identity and Access Management (IAM) Emma Fu Emma Fu は Amazon EBS チームの Senior Technical Product Manager です。バックアップ、セキュリティ、AI における新たなユースケースの探求に情熱を注いでいます。仕事以外では、家族と過ごす時間、料理、ワインテイスティングを楽しんでいます。 Matt Luttrell Matt は AWS Identity Solutions チームの Principal Solutions Architect です。子供を追いかけまわしている時間以外は、スキー、サイクリング、そして、たまにビデオゲームも楽しんでいます。
お客様は常に AWS の支出をよりよく理解する方法を探しています。多くのお客様が、特定のチームがどのくらい支出をしているか、特定のアプリケーションの実行コストはどのくらいか、様々な組織的な取り組みにおける節約の機会はどのくらいあるかについて知りたがっています。リソースレベルのコストの透明性を提供できることは、AWS クラウドへの移行の大きなメリットです。このような詳細な可視化を実現するカギは、包括的かつ組織的なタグ付け戦略の実装と適用です。 コスト配分戦略を実装するためのツール この投稿では、組織のコスト意識を向上させるタグ付け戦略を定義・実装・適用するために使用できるツールと、その使用方法について紹介します。最初のツールは AWS Cost Explorer です。これは、組織の支出に関するより深い洞察をもたらす説得力のある可視化により、AWS のコストや使用状況の分析や管理を可能にしてくれます。Cost Explorer を使用すると、日次で更新される過去 12 か月間のコストデータを取得できます。日付範囲、アカウント、サービス、リージョンなど、様々なパラメーターでデータをフィルタリングできます。 コスト使用状況データを詳細にするために、リソースに「タグ」を適用することができます。タグはキーと値のペアで、AWS リソースにメタデータを追加したり、タグ値ごとにコスト使用状況データを要約したりすることができます。タグはキーと値のペアであるため、組織に合った名前 (キー) を作成したり、ビジネスにとって意味のある値を使ったりできるような柔軟性があります。たとえば、組織において “CostCenter” を使用してコストを追跡することができます。AWS では、CostCenter というキーのタグをリソースに割り当て、そこにそのリソースの課金先となる CostCenter を表す値 (例:CostCenter=12345) を割り当てることができます。 また、タグポリシーおよびサービスコントロールポリシーと呼ばれる、 AWS Organizations の 2 つの機能についても見ていきます。これらのポリシーは遡及的には機能しないため、過去に作成された “タグの付与されていないリソース” を識別しやすくするためには AWS Tag Editor (タグエディタ) を使用します。そして、 AWS Config は継続的な戦略のコンプライアンスをサポートします。 タグ付け分類の作成 タグを使用するとさらに詳細な情報を得られるため、組織レベルでのタグ付け戦略と、それを適用する方法を確立することが重要です。ベストプラクティスとしては、タグの分類を定義して、すべてのビジネスユニットに推奨されるタグを整理するところから始めるのがよいでしょう。タグは様々な目的でリソースに関連付けることができます。技術タグは識別情報を提供します。オートメーションタグは開始/停止時間をスケジュールしたり、リソースを自動的にバックアップする必要がある場合に役立ちます。ビジネスタグは所有者やビジネスコンテキストを追加し、セキュリティタグはデータセキュリティ上の懸念事項を定義するのに役立ちます。以下にこれらの例を示します。 図 1. タグの分類とタイプの例 すべてのビジネスユニットに適用されるタグ付け戦略を実装する際には、その戦略が適切にドキュメント化されているのを確認することが重要です。以下に組織で必須となるタグの詳細を記載したタグ分類ドキュメントの例を示します。 図 2. 必須タグ例のタグ分類 タグ付け戦略のアプローチ 組織は通常、タグ付け戦略を実装する際に 2 つの異なる方法に従います。すべてのポリシーをトップダウンで実装するか、子組織が自分でタグを定義できるようにするかのどちらかです。どちらにも長所と短所があります。トップダウン型のアプローチは、定義と設定に時間がかかりますが、組織全体のコストの可視性が向上する可能性があります。一方、子組織が自分でタグ付け要件を柔軟に決定できるようにすると、俊敏性は向上しますが、組織全体の AWS 支出を分析しようとする際に一貫性が失われる可能性があります。 これら 2 つの戦略を組み合わせることが、おそらく最も効果的なアプローチでしょう。たとえば、組織の最上位レベルでは、下の図に示すように、すべてのチームと組織ユニットが従うビジネスタグ付け戦略を適用できます。そのあとで、個々のユニットは自主性と柔軟性をもって追加となるビジネス固有のタグを実装することができます。 許容できるキー値を定義することで、タグ分類ドキュメント内のタグをさらに細かく指定できます。たとえば、今回の CostCenter タグの例では、ビジネスユニットまたは部門を表す “Two Digit Division (2 桁の部門)” を追加しました。また、コストを追跡するために、プロジェクト、アプリケーション、チーム、その他のグループを表す “Four Digit Code (4 桁のコード)” も追加しました。これにより、各ビジネスユニットは、リソースを適切に識別するための適切なタグ付け規則を明確に把握できます。タグ付け戦略を明確に定義してドキュメント化したら、適用に移ることができます。 図 3. CostCenter タグ例のタグドキュメント タグ付けポリシーの適用 タグ付け戦略が組織全体に浸透したら、AWS Organization 内で必須のタグの設定を開始できます。目標は、AWS リソースの作成時に、新たな標準化されたタグ付けポリシーを適用することです。ここでの例では、特定のタグに必須の ”事前定義済みの値“ がない場合、Amazon EC2 インスタンスの作成は拒否されます。今回は、カスタム CostCenter タグを使用します。 1. まず最初に、管理アカウントの AWS Organizations コンソールに移動し、[Policies (ポリシー)] を選択します。次に [Tag policies (タグポリシー)] をクリックします。 図 4. AWS Organizations ポリシーページのタグポリシー部分 2. 次に、上記の例で定義した値を使用して、CostCenter タグのタグポリシーを作成します。このポリシーを Amazon EC2 インスタンスに適用し、組織によって指定された値でなければ、CostCenter タグを使用してリソースを作成することを禁止するようにします。 画面上部のタグポリシーに名前を付けます。ポリシーの説明を追加することもできます。この画面の中央では、ポリシー自体にタグを追加して、誰がポリシーを作成したかを追跡できます (ポリシーが適用されるリソースではなく、ポリシー自体にタグを付けることに注意してください)。“Visual editor (ビジュアルエディタ)” タブ内でタグキーを定義できます。ここでの例ではそれを “CostCenter” としています。 CostCenter タグキーの下にある、大文字と小文字の区別を確認するボックスにもチェックを入れます。これにより、タグの大文字と小文字が区別される (case-sensitive) ため、タグキーフィールドで指定されたとおりに正確に入力する必要があります。 “Allowed values (許容される値)” セクションで、CostCenter タグキーに使用できる値を指定するボックスにチェックを入れます。次に、上記の例で定義した CostCenter 値のリストを追加します。 最後に、“Resource types enforcement” (リソースタイプの強制)” セクションで、”Prevent noncompliant operations for this tag (このタグの非準拠操作を防止します)” をクリックします。リストから “ec2:instance” を選択します。これにより、Amazon EC2 インスタンスに CostCenter タグが含まれていて、かつタグ付けポリシーに基づく有効な値がない場合には、Amazon EC2 インスタンスが起動されなくなります。 図 5. タグポリシー設定ページ 3. この新しく作成されたポリシーを組織全体で確実に適用するには、組織単位 (OU) にポリシーをアタッチする必要があります。そのためには、タグポリシーページに戻り、先ほど作成した “CostCenterTagPolicy” を選択します。次に “Actions (アクション)” を選択し、“Attach policy (ポリシーのアタッチ)” をクリックします。 図 6. 既存のタグポリシーページでのポリシーのアタッチ 4. 次の画面では、新しいタグポリシーが特定の組織単位 (OU) にアタッチされていることを選択して確認できます。 図 7. 組織単位 (OU) へのタグポリシーのアタッチ 5. それでは、Amazon EC2 コンソールに移動して、適切な CostCenter タグ値を指定せずに新しい Amazon EC2 インスタンスを起動してみましょう。 図 8. EC2 コンソールでのタグ付けポリシーのテスト 6. 必須のタグポリシー値を指定せずにこのインスタンスを起動しようとすると、エラーが表示されます。 図 9. 許可されていない CostCenter タグ値であることにより EC2 の起動に失敗 タグポリシーが設定されたため、タグポリシー内の CostCenter タグに設定した値パラメーターに従わないリソースを、組織が起動できなくなりました。ただし、これでは CostCenter タグキーそのものがない場合はリソースを起動できてしまいます。それを防ぐためには、サービスコントロールポリシー (SCP) を利用します。 タグの適用の強化 ユーザーが特定のタグを含めていない場合はリソースを起動できないようにするなど、タグ付けの適用に関するより厳しいポリシーが必要な場合は、 サービスコントロールポリシー (SCP) を使用できます。SCP により、組織内のすべてのアカウントで使用可能な最大権限を一元的に制御できます。SCP を使用すると、CostCenter タグなどの特定のタグが含まれていない場合に特定のアクションを拒否できます。 このタイプの SCP の例を以下に示します。作成すると、先程作成したタグ付けポリシーをアタッチしたのと同じように、特定の組織単位 (OU) にアタッチできます。 SCP を定義する には、管理アカウントの AWS Organizations ページに移動し、“ポリシー (Policies)” をクリックしてから “サービスコントロールポリシー (Service Control Policies)” をクリックします。 図 10. CostCenter タグを必要とするサービスコントロールポリシー (SCP) の例 注: SCP の使用は完全にオプションであり、特にタグコンプライアンスに関するガバナンスのレベルを高めることができます。ただし、SCP の使用は慎重に行うべきです。SCP の設定は既存のリソースに影響を与える可能性があります。たとえば、必須である CostCenter キーが設定されていないリソースのオートスケーリングプランでは、SCP がスケーリング動作を妨げる可能性があります。既存のリソースを持つ組織に SCP を導入する場合は、この点を必ず考慮してください。 タグコンプライアンスの理解 この新しいタグ付けポリシーのコンプライアンスを継続的に検証するには、AWS Config を使用できます。AWS Config には、AWS アカウントの AWS リソースの設定の詳細が表示されます。AWS Config ルール、特に “required-tags” ルールを使用すると、リソースに必要なタグがあるかどうかをチェックできます (つまり、Amazon EC2 インスタンスに、先程作成した CostCenter タグが付いていることを確認できます)。 タグコンプライアンスをモニタリングするには、AWS Config コンソールページに移動し、左側のナビゲーションメニューから “ルール (Rules)” を選択します。 図 11. AWS Config ルールセクション画面 新しいルールを追加する方法の詳細はこのブログの範囲外ですが、required-tags 組み込み設定ルールの使用方法の詳細は AWS Config ドキュメント に記載されています。AWS Config と SCP により、組織全体にタグ付けポリシーをさらに適用し、長期的なコンプライアンスを検証できます。 しかし、新しいタグ付けポリシーに準拠していない可能性のある既存のリソースについてはどうでしょうか?これらのリソースをコンプライアンスに準拠させるにはどうすればよいでしょうか? タグエディタによるタグなしリソースの識別 タグ付けポリシー実装の最後のステップは、過去にタグなしでプロビジョニングされたリソースに対処することです。これはタグエディタを使うことで実行できます。 タグエディタを使用するには、AWS マネジメントコンソールに移動し、“Resource Groups &amp; Tag Editor” を検索してクリックします。 次に、左側のナビゲーションにある “タグ付け (Tagging)” の下にある “タグエディタ (Tag Editor)” をクリックします。 タグエディタページで、まずリソースを検索したいリージョンを選択します。この例では “All regions” を検索します。 次に、検索するリソースタイプを設定します。この例では、Amazon EC2 インスタンスを検索します。 最後に、検索するタグを入力します。ここでは、CostCenter タグが付いていないすべての Amazon EC2 インスタンスを検索します。 条件を満たすリソースのリスト、つまり CostCenter タグのついていない、すべてのリージョンのすべての Amazon EC2 インスタンスのリストが表示されます。結果を CSV にエクスポートし、組織内の従業員に通知して対応を依頼できます。 図 12. タグエディタの設定画面 注: タグエディタは単一のアカウントでのみ実行でき、組織レベルでは実行できません。組織内の各アカウントでタグが付いていないリソースを識別するには、各アカウントでタグエディタを使用する必要があります。 コスト配分タグを有効化する 新しく実装したタグ付け戦略を使って Cost Explorer でのコスト分析を開始する前に、コストと使用状況に関するレポート作成用にタグを有効化する必要があります。“請求とコスト管理” コンソールを開いて “コスト配分タグ (Cost Allocation Tags)” を選択し、新しく作成した CostCenter タグを有効化します。リソースにタグを付けてタグを有効化するまで、AWS Cost Explorer にはこれらのタグを適用した結果は表示されません。 図 13. ”請求とコスト管理“ コンソールでのコスト配分タグの有効化 AWS Cost Explorer での支出の可視化と分析 タグ付け戦略を実装し、“請求とコスト管理” コンソールでタグを有効化すると、AWS Cost Explorer を使用して個々のコストセンターのコストを分析できます。この例では、個々のコストセンターの支出をサービスごとに表示できます。 図 14. Cost Explorer レポート (フィルターなし) Cost Explorer を使用してコストを確認する際、タグ付けされているはずなのに以前の期間のコストには反映されておらず混乱してしまうことがあるかもしれません。タグ付けは遡って適用されることはなく、(タグ付け以降の) 将来のコストと使用状況のレポートにのみ正確に反映されます。 Cost Explorer を使用すると、適切な CostCenter タグが関連付けられていないアカウントのうち、最も支出が多いアカウントを分析できます。これを行うには、ディメンションを “連結アカウント (Linked Account)”、タグのフィルターを “CostCenter”、およびタグ値を “タグキーがありません :CostCenter (No tag key: CostCenter)” に設定した Cost Explorer レポートを作成します。 図 15. Cost Explorer レポート (“タグキーがありません :CostCenter” フィルターを適用した場合) このようなレポートを使用すると、組織はこれらの (タグ付けされていないリソースのある) 特定のアカウントが新しいタグ付け戦略を実装できるよう支援できます。時間が経過とともに、コストセンター別に組織の AWS 支出の詳細な内訳を示す追加の Cost Explorer レポートを作成できるようになります。 図16. Cost Explorer レポート (ディメンションを “CostCenter” タグにした場合) まとめ このブログでは、AWS アカウント内のタグ付けされていないリソースの識別を含む、組織のタグ付け戦略の定義・実装・適用に役立つプロセスの概要を説明しました。これが完了すると、Cost Explorer を使用して、これらのタグを使用して AWS のコストと使用状況を可視化・理解・管理・レポートすることができます。その結果、組織のコストに対する可視性と認識が高まるだけでなく、個々のビジネスユニットのコストの結果責任が促進され、クラウドコストの最適化とビジネス価値の実現にプラスの影響を与えることができます。 TAGS: AWS Billing Console , AWS Cost Explorer , AWS Organizations , Tagging Policies , Track and Allocate Ryan Doty Ryan Doty は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。革新的でスケーラブルなソリューションを設計するためのアーキテクチャガイドラインを提供することで、米国北東部のエンタープライズカスタマーが AWS クラウドの採用を加速できるよう支援しています。ソフトウェア開発とセールスエンジニアリングのバックグラウンドを持つ彼は、クラウドが世界にもたらす可能性にワクワクしています。仕事以外では、コンピューターゲームをしたり、リバプール FC を応援したりすることが大好きです。 Bert Zahniser, CISSP, CCSP Bert Zahniser は、フィラデルフィア地域を拠点とする AWS のシニアソリューションアーキテクトです。IT インフラストラクチャで 30 年以上の経験があり、情報セキュリティに重点を置いています。彼はクラウド採用の強力な提唱者であり、クラウド移行中のお客様がセキュリティとガバナンスを念頭に置いて AWS でソリューションを設計および実装できるよう支援しています。仕事以外では、野球やアイスホッケーが好きで、ゴルフやクラフトビールの醸造所を訪れるのが大好きです。 Vishal Manan Vishal Manan は、シアトルを拠点とする AWS のスペシャリストソリューションアーキテクトです。お客様が Graviton プロセッサ (クラウドでは arm64) を使用して、費用対効果やパフォーマンスが高く、持続可能な EC2 コンピューティングインスタンスを採用できるよう支援しています。プラットフォームソフトウェア開発のスキルとコンサルティングのバックグラウンドを AWS クラウドに活かせることに興奮しています。仕事以外では、父親であること、料理をすること、ゴルフをすること、ハイキングをすることが大好きです。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。
この記事は、 Cost Optimized Vector Database: Introduction to Amazon OpenSearch Service quantization techniques を翻訳したものです。 生成 AI アプリケーションの台頭により、セマンティック検索と自然言語検索を実装する必要性が高まっています。これらの高度な検索機能は、企業のコンテンツリポジトリから概念的に関連する文書を検索し、生成 AI モデルのプロンプトとして取得するのに役立ちます。テキスト、画像、音声、動画などの様々なソースリポジトリ内の生データは、埋め込みモデルを使用して、セマンティック検索と自然言語検索を支える標準的な数値表現である ベクトル に変換されます。組織がより高度な大規模言語モデルと基盤モデルを活用して生成 AI アプリケーションを強化するにつれ、補助的な埋め込みモデルも大規模で高次元のベクトル埋め込みを処理できるように進化しています。ベクトル量が拡大するにつれ、メモリ使用量と計算要件が比例して増加し、運用コストが高くなります。この問題を軽減するために、メモリ使用量と計算効率を最適化するための様々な圧縮技術を使用できます。 量子化は、計算量とメモリ使用量を削減し、特に大規模データワークロードのコストを下げることを目的とした、非可逆圧縮技術です。データの種類と量に応じて、様々な圧縮手法があります。一般的な手法は、無限の値 (または比較的大きな有限値のリスト) をより小さな離散値にマッピングすることです。ベクトル圧縮には、主に直積量子化とスカラー量子化の 2 つの手法があります。直積量子化の手法では、元のベクトル次元の配列を複数のサブベクトルに分割し、それぞれのサブベクトルを固定ビット数でエンコードして元のベクトルを表現します。この方法では、元のベクトルではなく、エンコードされたサブベクトルのみを保存し、検索する必要があります。スカラー量子化では、入力ベクトルの各次元が、32 ビット浮動小数点表現からより小さなデータ型にマッピングされます。 Amazon OpenSearch Service は、ベクトルデータベースとして、スカラー量子化と直積量子化の手法をサポートし、メモリ使用量を最適化して運用コストを削減します。 ベクトルデータベースとしての OpenSearch OpenSearch は、分散型の検索および分析サービスです。OpenSearch の k 最近傍 (k-NN) プラグインを使用すると、ベクトルのインデックス作成、保存、検索できます。ベクトルは knn_vector 型の 32 ビット浮動小数点数配列として OpenSearch に保存され、1 ベクトルあたり最大 16,000 次元までサポートしています。 OpenSearch は、スケーラブルなベクトル検索を提供するために、近似最近傍検索を使用します。近似 k-NN アルゴリズムは、与えられたクエリベクトルに最も近いベクトルを推定して結果を取得します。近似 k-NN を実行する主な手法として、グラフベースの Hierarchical Navigable Small-World (HNSW) とクラスターベースの Inverted File (IVF) の 2 つがあります。これらのデータ構造は、最初のベクトル検索操作中に構築され、メモリにロードされます。ベクトルの量が増加すると、データ構造と検索処理に必要なメモリも比例して増加します。 例えば、32 ビットの浮動小数点データを使用する各 HNSW グラフは、約 1.1 * (4 * d + 8 * m) * num_vectors バイトのメモリを消費します。ここで、 num_vectors はインデックス化するベクトルの総数を表し、 d はベクトルを生成するために使用する埋め込みモデルによって決定される次元数、 m は HSNW グラフの辺の数で、パフォーマンスを調整するためのインデックスパラメータです。この式を使用すると、384 次元で m が 16 の構成におけるベクトル格納のメモリ要件は次のようになります。 100 万ベクトル: 1.830 GB (1.1 * (4 * 384 + 8 * 16) * 1,000,000 バイト) 10 億ベクトル: 1830 GB (1.1 * (4 * 384 + 8 * 16) * 1,000,000,000 バイト) 近似最近傍検索は、数十億ものベクトルを含む大規模データセットを効率的に処理するように最適化できますが、検索処理中に 32 ビットの完全な精度のベクトルをロードするためのメモリ要件が非常に高くなる可能性があります。この問題を緩和するために、OpenSearch Service では次の 4 つの量子化手法をサポートしています。 バイナリ量子化 バイト量子化 FP16 量子化 直積量子化 これらの手法は、前述のスカラー量子化とプロダクト量子化の広範なカテゴリに含まれます。この投稿では、OpenSearch Service でベクトルワークロードを最適化するための量子化手法について、メモリ削減とコスト効率に焦点を当てて説明します。メモリにロードせずにディスクに保存されたベクトルを効率的にクエリできる、新しいディスクベースのベクトル検索アプローチを紹介します。この手法は、 on_disk モードや compression_level パラメータなどの主要な設定を備え、量子化手法とシームレスに統合されています。これらの設定により、インデックス作成時に組み込みのスカラー量子化がすぐに利用できます。 バイナリ量子化 (最大 32 倍の圧縮) バイナリ量子化 (BQ) はスカラー量子化の一種です。OpenSearch は FAISS エンジンのバイナリ量子化を活用し、インデックス作成時に最大 32 倍の圧縮を可能にしています。この手法では、デフォルトの 32 ビット浮動小数点からベクトルを 0 と 1 に圧縮することで、ベクトル次元を 1 ビットのバイナリに削減します。OpenSearch はバイナリベクトルのインデックス作成、保存、検索をサポートしています。また、下の例に示すように、目的の圧縮率に応じて、各ベクトル次元を 1、2、または 4 ビットでエンコードすることもできます。圧縮率は bits 設定で調整できます。2 の値では 16 倍の圧縮、4 の値では 8 倍の圧縮になります。デフォルト設定は 1 です。バイナリ量子化では、インデックス作成時に自動的に学習が行われるため、追加の前処理ステップは不要です。 バイナリ量子化を実装するには、ベクトル型を knn_vector と定義し、 encoder を binary に指定して、エンコードするビット数 bits を指定します。encoder パラメータは、インデックスに格納する前にベクトルデータを圧縮する方法を指す点に注意してください。パフォーマンスを最適化するために、 space_type 、 m 、 ef_construction パラメータを使用します。近似 k-NN の基盤となる設定の詳細については、 OpenSearch のドキュメント を参照してください。 PUT my-vector-index { "settings": { "index.knn": true }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "method": { "name": "hnsw", "engine": "faiss", "space_type": "l2", "parameters": { "m": 16, "ef_construction": 512, "encoder": { "name": "binary", "parameters": { "bits": 1 } } } } } } } } FAISS-HNSW を使用したバイナリ量子化の実装におけるメモリ要件はこのようになります。 1.1 * (bits * (d/8)+ 8 * m) * num_vectors バイト 圧縮率 エンコードビット数 10 億ベクトルのメモリ要件 (d=384, m=16, GB単位) 32x 1 193.6 16x 2 246.4 8x 4 352.0 バイナリ量子化の詳細な実装手順については、 OpenSearch のドキュメント を参照してください。 バイト量子化 (4 倍の圧縮) バイト量子化は、32 ビットの浮動小数点次元を -128 から + 127 の範囲の 8 ビット整数に圧縮し、メモリ使用量を 75% 削減します。OpenSearch では、バイトベクトルのインデックス作成、格納、検索がサポートされており、取り込む前に 8 ビット形式に変換する必要があります。バイトベクトルを実装するには、インデックスマッピングで k-NN ベクトルフィールドの data_type を byte と指定します。この機能は Lucene エンジンと FAISS エンジンの両方と互換性があります。バイト量子化ベクトルのインデックスを作成する例を次に示します。 PUT /my-vector-index { "settings": { "index": { "knn": true, "knn.algo_param.ef_search": 100 } }, "mappings": { "properties": { "my_vector": { "type": "knn_vector", "dimension": 3, "data_type": "byte", "space_type": "l2", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "ef_construction": 100, "m": 16 } } } } } } この方法では、バイト量子化ベクトルを OpenSearch に取り込み、k-NN ベクトルフィールド (バイト型) に直接格納する必要があります。しかし、最近導入されたディスクベースのベクトル検索機能により、外部ベクトル量子化の必要がなくなりました。このブログの後半で、この機能について詳しく説明します。 FAISS-HNSW でバイト量子化を実装するためのメモリ要件はこのようになります。 1.1 * (1 * d + 8 * m) * num_vectors バイト 詳細な実装手順については、 OpenSearch のドキュメント を参照してください。精度、スループット、レイテンシーに関するパフォーマンスメトリクスについては、 OpenSearch のバイト量子化ベクトル を参照してください。 FAISS FP16 量子化 (2 倍の圧縮) FP16 量子化は、16 ビットの浮動小数点スカラー表現を使用する手法で、メモリ使用量を 50% 削減します。各ベクトル次元は 32 ビットから 16 ビットの浮動小数点に変換され、メモリ要件が実質的に半分になります。圧縮されたベクトル次元は [-65504.0、65504.0] の範囲内でなければなりません。FP16 量子化を実装するには、k-NN ベクトルフィールドでインデックスを作成し、以下を構成します。 k-NN ベクトルフィールドのメソッドを HNSW に、エンジンを FAISS に設定します。 エンコーダーパラメーターを定義し、 name を sq 、 type を fp16 に設定します。 32 ビット浮動小数点ベクトルを OpenSearch にアップロードすると、スカラー量子化 FP16 (SQfp16) が自動的に取り込み時にそれらを 16 ビット浮動小数点ベクトルに量子化し、ベクトルフィールドに格納します。次の例は、FP16 量子化ベクトルを量子化して格納するためのインデックス作成方法を示しています。 PUT /my-vector-index { "settings": { "index": { "knn": true, "knn.algo_param.ef_search": 100 } }, "mappings": { "properties": { "my_vector1": { "type": "knn_vector", "dimension": 3, "space_type": "l2", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "encoder": { "name": "sq", "parameters": { "type": "fp16", "clip": true } }, "ef_construction": 256, "m": 8 } } } } } } FAISS-HNSW を使用して FP16 量子化を実装するためのメモリ要件は以下のようになります。 (1.1 * (2 * d + 8 * m) * num_vectors) バイト 前述の FP16 の例では、 clip というオプショナルな Boolean パラメータが導入されています。これはデフォルトで false に設定されています。false の場合、範囲外の値 (-65504.0 から + 65504.0 の範囲外の値) を持つベクトルは拒否されます。clip を true に設定すると、範囲外のベクトル値がサポートされる範囲内に丸められます。実装手順の詳細については、 OpenSearch のドキュメント を参照してください。精度、スループット、レイテンシーに関するパフォーマンスメトリクスについては、 Optimizing OpenSearch with Faiss FP16 scalar quantization: Enhancing memory efficiency and cost-effectiveness を参照してください。 直積量子化 直積量子化 (PQ) は、圧縮レベルを大幅に高めることができる高度な次元削減手法です。従来のスカラー量子化手法は通常 32 倍までの圧縮しか実現できませんが、PQ では最大 64 倍の圧縮が可能なため、ストレージとコストの最適化においてより効率的なソリューションとなります。OpenSearch は、FAISS エンジンの IVF および HNSW の両方の手法で PQ をサポートしています。直積量子化は、ベクトルを m 個のサブベクトルに分割し、各サブベクトルをコードサイズで決まるビット数でエンコードします。結果として得られるベクトルのメモリ使用量は m * code_size ビットになります。 FAISS における直積量子化のプロセスは、以下の 3 つの主要なステップで構成されます。 PQ モデルを構築するためのトレーニングインデックスを作成し、データを投入して精度を最適化する。 トレーニングインデックスに対して _train API を実行し、量子化モデルを生成する。 ベクトルインデックスを作成し、kNN フィールドを準備した量子化モデルで構成する。 以下の例では、直積量子化のセットアップ手順を 3 つのステップで説明します。 ステップ 1: トレーニングインデックスを作成します。トレーニングインデックスの仕様と次元数が合うように、適切なデータセットでトレーニングインデックスを構築します。トレーニングインデックスには最低 256 件のドキュメントが必要であることに注意してください。 PUT /train-index { "settings": { "number_of_shards": 1, "number_of_replicas": 2 }, "mappings": { "properties": { "train-field": { "type": "knn_vector", "dimension": 4 } } } } ステップ 2: 先ほど作成したトレーニングインデックスに対して _train API を実行し、my-model という名前の量子化モデルを作成します。 name が pq と定義された encoder では、ネイティブのベクトル量子化が適用されます。エンコーダーの他のパラメーターには code_size と m があります。FAISS-HNSW では code_size を 8 に設定し、少なくとも 256 ( 2^code_size ) 件のドキュメントからなるトレーニングデータセットが必要です。パラメーターの詳細な仕様については、 PQ パラメータ を参照してください。 POST /_plugins/_knn/models/my-model/_train { "training_index": "train-index", "training_field": "train-field", "dimension": 4, "description": "My test model description", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "encoder": { "name": "pq", "parameters": { "code_size":8, "m":2 } }, "ef_construction": 256, "m": 8 } } } ステップ 3: ベクトルインデックスに量子化モデルをマッピングします。 PUT /my-vector-index { "settings": { "number_of_shards": 1, "number_of_replicas": 2, "index.knn": true }, "mappings": { "properties": { "target-field": { "type": "knn_vector", "model_id": "my-model" } } } } 新しく作成したインデックス my-vector-index にデータセット全体を取り込みます。エンコーダーは、受け取ったベクトルを自動的に処理し、量子化モデルの設定で指定された圧縮パラメータ( code_size と m )に基づいてエンコードおよび量子化を適用します。 FAISS-HNSW を使用した直積量子化を実装するためのメモリ要件はこのようになります。 1.1 * (((code_size / 8) * m + 24 + 8 * m) * num_vectors バイト ここで code_size と m はエンコーダーパラメータ内のパラメータ、 num_vectors はベクトルの総数です。 量子化処理では、各トレーニングベクトルは設定可能な値 m で定義された複数のサブベクトルまたはサブスペースに分割されます。各サブベクトルをエンコードするビット数は、パラメータ code_size によって決まります。次に、各サブベクトルは k-means クラスタリングを実行してそれぞれ圧縮・量子化されます。この際、クラスタの数 k は 2^code_size と定義されます。この手法では、ベクトルは約 m * code_size ビットで圧縮されます。 直積量子化の詳細な実装手順や設定可能なパラメータについては、 OpenSearch ドキュメント を参照してください。FAISS IVF を使用した PQ の精度、スループット、レイテンシーに関するパフォーマンス指標については、 OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定 を参照してください。 ディスクベースのベクトル検索 ディスクベースのベクトル検索は、圧縮されたベクトルをメモリ内で使用しながら、完全な精度のベクトルをディスク上に保持することで、クエリの効率を最適化します。このアプローチにより、OpenSearch は大規模なベクトルデータセットをメモリに完全に読み込む必要がなくなり、スケーラビリティとリソースの効率が向上します。この機能は、インデックス作成時に設定できる mode と compression level という 2 つの新しい構成オプションによって実装されます。OpenSearch 2.17 以降では、インデックス作成時に mode パラメータを in_memory または on_disk に設定できます。これまで説明した手法はデフォルトで in-memory モードになります。この構成では、ベクトルインデックスがグラフ (HNSW) またはバケット (IVF) 構造を使用して構築され、検索操作時にネイティブメモリにロードされます。この方法は優れた再現率を提供しますが、メモリ使用量に影響を与え、大量のベクトル処理に対するスケーラビリティが低下する可能性があります。 on_disk モードは、インデックス作成時にリアルタイムのネイティブ量子化を使用しながら、完全な精度のベクトルをディスクに保存することで、ベクトル検索の効率を最適化します。調整可能な圧縮レベルと組み合わせることで、圧縮されたベクトルのみをメモリにロードするため、メモリおよびリソースの利用効率が向上し、検索パフォーマンスが改善されます。以下の圧縮レベルは、前述の様々なスカラー量子化手法に対応しています。 32 倍: バイナリ量子化 (1 ビット次元) 4 倍: バイトおよび整数量子化 (8 ビット次元) 2 倍: FP16 量子化 (16 ビット次元) この手法は、in_memory モードでは利用できない 16x や 8x などの他の圧縮レベルもサポートしています。ディスクベースのベクトル検索を有効にするには、次の例のように mode を on_disk に設定してインデックスを作成します。 PUT /my-vector-index { "settings" : { "index": { "knn": true } }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "space_type": "innerproduct", "data_type": "float", "mode": "on_disk" } } } } モードを on_disk に設定するだけでは、デフォルトの構成が適用され、FAISS エンジンと HNSW メソッドが使用され、32 倍の圧縮レベル (1 ビット、バイナリ量子化) が使用されます。インデックス作成時の待ち時間を最適化する ef_construction のデフォルト値は 100 です。より細かい微調整を行う場合は、次の例のように、これらの k-NN パラメータを上書きできます。 PUT /my-vector-index { "settings" : { "index": { "knn": true } }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "space_type": "innerproduct", "data_type": "float", "mode": "on_disk", "compression_level": "16x", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "ef_construction": 512 } } } } } } 量子化は非可逆圧縮の手法なので、圧縮率が高くなるほど再現率が低下する傾向があります。量子化時の再現率を改善するには、次の例のように、検索時の設定パラメータ ef_search と oversample_factor を使って、ディスクベースのベクトル検索を 2 段階で実行するよう設定できます。 GET my-vector-index/_search { "query": { "knn": { "my_vector_field": { "vector": [1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5], "k": 5, "method_parameters": { "ef_search": 512 }, "rescore": { "oversample_factor": 10.0 } } } } } 最初の段階では、メモリ内の量子化ベクトルから oversample_factor * k 個の結果を取得し、スコアを近似計算します。次の段階では、その oversample_factor * k 個の結果の完全な精度ベクトルをディスクからメモリにロードし、完全な精度のクエリベクトルと比較してスコアを再計算します。その後、結果は上位 k 個に絞られます。 リスコア用の oversample_factor は、インデックス作成時に設定された次元数と圧縮レベルによって決まります。次元が 1,000 未満の場合、係数は 5 に固定されます。1,000 を超える次元の場合、デフォルトのファクターは圧縮レベルに基づいて変わり、次の表のようになります。 圧縮レベル リスコア用の oversample_factor のデフォルト値 32x (デフォルト) 3 16x 2 8x 2 4x デフォルトのリスコアリングなし 2x デフォルトのリスコアリングなし 前述のように、 oversample_factor は検索時に動的に調整できます。この値は、精度と検索効率の間の重要なトレードオフを表します。高い値を設定すると精度は向上しますが、メモリ使用量が比例して増加し、検索スループットが低下します。ディスクベースのベクトル検索と oversample_factor の適切な使用方法を理解するには、 OpenSearch のドキュメント を参照してください。 量子化手法のパフォーマンス評価: メモリ使用量、再現率、クエリレイテンシーの検証 OpenSearch の近似 k-NN 検索に関するドキュメント は、ベクトル類似度検索を実装する際の出発点となります。さらに、 OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定 では、本番環境で数十億規模のベクトルを扱うための効率的なベクトルワークロードの設計に関する貴重な洞察が得られます。この記事では、メモリ使用量を削減し、コストを抑える手法として、直積量子化技術を導入することを提案しています。 次の表は、さまざまな量子化手法を使用して 10 億ベクトルを保存および検索する際のメモリ要件を示しています。この表は、HNSW を使用した完全な精度ベクトルのデフォルトのメモリ消費量と、量子化されたベクトルのメモリ消費量を比較しています。この分析で使用されたモデルは sentence-transformers/all-MiniLM-L12-v2 で、384 次元で動作します。生のメタデータは 100GB 以下と想定されています。 量子化なし (GB 単位) 直積量子化 (GB 単位) スカラー量子化 (GB 単位) FP16 ベクトル バイトベクトル バイナリベクトル m 16 16 16 16 16 pq_m、code_size – 16, 8 – – – ネイティブメモリ消費量 (GB) 1830.4 184.8 985.6 563.2 193.6 合計ストレージ = 100 GB + ベクトル 1930.4 284.8 1085.6 663.2 293.6 前の表を見直すと、10 億ベクトルのデータセットに対して、32 ビットの完全な精度のベクトルを使用する HNSW グラフでは約 1830 GB のメモリが必要になることがわかります。直積量子化などの圧縮技術を使えば、これを 184.8 GB に削減できます。一方、スカラー量子化では、さまざまなレベルの圧縮が可能です。次の表は、圧縮手法とコスト削減、再現率、クエリレイテンシーなどの主要パフォーマンス指標への影響の相関関係をまとめたものです。この分析は、上記のメモリ使用量の評価に基づいており、要件を満たす圧縮手法を選択する際の助けとなります。 この表には、2 つの主要な検索メトリクスが示されています。90 パーセンタイル (p90) での検索レイテンシーと、上位 100 件における再現率です。 検索レイテンシー@p90 – 90% の検索クエリがその特定のレイテンシー時間以内に完了することを示します。 recall@100 – 上位 100 件の正解となる近傍点のうち、返された 100 件の結果に含まれる割合です。 量子化なし (GB 単位) 直積量子化 (GB 単位) スカラー量子化 (GB 単位) FP16 量子化 [mode=in_memory] バイト量子化 [mode=in_memory] バイナリ量子化 [mode=on_disk] 前提条件/データセット すべてのデータセットに適用可能 再現率は学習データの性質に依存 次元値が [-65536 から 65535] の範囲内で動作 次元値が [-128 から 127] の範囲内で動作 次元数 &gt;= 768 の場合に適している 前処理の必要性 なし あり (前処理/学習が必要) なし なし なし リスコアリング なし なし なし なし あり 再現率 @100 &gt;=0.99 &gt;0.7 &gt;=0.95 &gt;=0.95 &gt;=0.90 p90 クエリレイテンシー (ms) &lt;50 ms &lt;50 ms &lt;50 ms &lt;50 ms &lt;200 ms コスト (ベースライン $X) $X $0.1*X (最大 90% の削減) $0.5*X (最大 50% の削減) $0.25*X (最大 75% の削減) $0.15*X (最大 85% の削減) 10 億ベクトルのサンプルコスト $20,923.14 $2,092.31 $10,461.57 $5,230.79 $3,138.47 10 億ベクトルのサンプルコストの見積もりは、コストを最適化された構成に基づいています。ただし、実際の削減額は、ワークロードの要件と選択した構成のパラメータによって異なる可能性があることにご注意ください。特に表では、直積量子化を使用すると、ベースラインの HNSW グラフベースのベクトル検索コスト ($X) と比較して最大 90% のコスト削減が可能です。スカラー量子化も同様に、圧縮されたメモリ使用量に応じて 50% から 85% の比例的なコスト削減をもたらします。圧縮手法の選択には、コスト効率、精度、パフォーマンスのバランスが関係し、精度やレイテンシーに影響を与えます。 結論 OpenSearch の量子化手法を活用することで、組織はコスト効率、パフォーマンス、再現率のバランスを考慮した選択が可能になり、最適な結果を得るためにベクトルデータベースの操作を微調整できるようになります。これらの量子化手法は、メモリ要件を大幅に削減し、クエリの効率を向上させ、シームレスな圧縮のための組み込みエンコーダーを提供します。大規模なテキスト埋め込み、画像特徴量、その他の高次元データのいずれを扱う場合でも、OpenSearch の量子化手法はベクトル検索の要件に対する効率的なソリューションを提供し、コスト効率が高く、スケーラブルで高性能なシステムの開発を可能にします。 ベクトルデータベースプロジェクトを進める際は、以下のことをお勧めします。 OpenSearch の圧縮手法を詳しく検討する。 特定のユースケースに適した手法の適用可能性を評価する。 再現率と検索レイテンシーの要件に基づいて適切な圧縮レベルを決定する。 精度、スループット、レイテンシーに基づいてコスト削減効果を測定し比較する。 この分野は急速に進化しているため、最新の技術動向を常に把握し、さまざまな量子化技術を試すことで、コスト・パフォーマンス・精度の最適なバランスを見つけることが重要です。
この記事は、 OpenSearch Vector Engine is now disk-optimized for low cost, accurate vector search を翻訳したものです。 OpenSearch ベクトルエンジンは、OpenSearch 2.17 以降のドメインで、従来の 3 分の 1 のコストでベクトル検索を実行できるようになりました。k-NN (ベクトル) インデックスをディスクモードで実行するように設定し、メモリに制約のある環境に最適化することで、数百ミリ秒単位で応答する低コストで正確なベクトル検索が可能になりました。ディスクモードは、 一桁ミリ秒に近いレイテンシー を求めない場合、従来のメモリモードの経済的な代替手段となります。 本記事では、この新機能の利点、基本的な仕組み、お客様の成功事例、そして始め方についてご紹介します。 ベクトル検索と OpenSearch ベクトルエンジンの概要 ベクトル検索は、機械学習 (ML) モデルによってベクトル (数値エンコーディング) にエンコードされたコンテンツに対して類似性検索を実行することで、検索の精度を向上させる手法です。これによりセマンティック検索のようなユースケースが可能になり、キーワードだけでなくコンテキストや意図も考慮した、より関連性の高い検索結果を提供できます。 OpenSearch ベクトルエンジンは、ベクトル化されたコンテンツに対してインデックスを作成することで、数十億のベクトルを超えるリアルタイムのベクトル検索を可能にします。これにより、質問、キーワード、または ML モデルによってエンコードされた画像・音声クリップ・テキストなどのコンテンツに対して、最も類似する上位 K 件のドキュメントを検索できます。 OpenSearch ベクトルエンジンのチューニング 検索アプリケーションには、速度、品質、コストに関してさまざまな要件があります。例えば、e コマースのカタログでは、購買体験を向上させるために、できるだけ短い応答時間と高品質な検索が求められます。しかし、検索の品質とパフォーマンスを最適化するには、追加のメモリやコンピューティングリソースが必要となり、コストが発生します。 速度、品質、コストの適切なバランスは、ユースケースとお客様の期待することによって異なります。OpenSearch ベクトルエンジンには包括的なチューニングオプションが用意されているため、独自の要件に応じた最適な結果を得るためのトレードオフのバランスを柔軟に調整できます。 以下のチューニングオプションを利用できます。 アルゴリズムとパラメータ – 以下が含まれます。 Hierarchical Navigable Small World (HNSW) アルゴリズムと、 ef_search 、 ef_construct 、 m などのパラメータ Inverted File Index (IVF) アルゴリズムと、 nlist 、 nprobes などのパラメータ Exact k-nearest neighbors (k-NN)、別名 brute-force k-NN (BFKNN) アルゴリズム エンジン – Facebook AI Similarity Search (FAISS)、Lucene、Non-metric Space Library (NMSLIB) 圧縮手法 – スカラー (バイト、半精度など)、バイナリ、直積量子化 類似度 (距離) 指標 – 内積、コサイン類似度、L1 距離、L2 距離、ハミング距離 ベクトル埋め込みタイプ – 可変次元の密ベクトルと疎 (スパース) ベクトル ランキングとスコアリング手法 – ベクトル検索、ハイブリッド検索 (ベクトルと Best Match 25 (BM25) スコアの組み合わせ)、マルチステージランキング (Cross-encoder や Personalizer など) これらのチューニングオプションを適切に組み合わせることで、ニーズに最適化された速度、品質、コストのバランスを実現できます。以下の図では、サンプル構成の大まかなパフォーマンスプロファイルを示しています。 ディスク最適化のチューニング OpenSearch 2.17 以降では、k-NN インデックスをディスクモードで実行できるようになり、インメモリのパフォーマンスと引き換えにレイテンシを高めることで、高品質かつ低コストなベクトル検索を実現できます。ユースケースの要件が 90 パーセンタイル (P90) のレイテンシー 100 〜 200 ミリ秒の範囲で満たされる場合、ディスクモードはコスト削減を実現しながら高い検索品質を維持するのに最適なオプションです。次の図は、さまざまなエンジン構成の中でのディスクモードのパフォーマンス特性を示しています。 ディスクモードは、すぐに利用できるように設計されており、メモリモードと比較して メモリ要件を 97% 削減 しながら高い検索品質を提供します。ただし、圧縮率とサンプリング率を調整することで、速度、品質、コストを調整できます。 以下の表は、ディスクモードのデフォルト設定におけるパフォーマンスベンチマークを示しています。最初の 3 つのテストには OpenSearch Benchmark (OSB) を使用し、最後の 2 つのテストには VectorDBBench (VDBB) を使用しました。最適な結果を得るために、 パフォーマンスチューニング のベストプラクティスを適用しています。小規模テスト (Tasb-1M と Marco-1M) は、1 つのレプリカを持つ単一の r7gd.large データノードで実行しました。その他のテストは、1 つのレプリカを持つ 2 つの r7gd.2xlarge データノードで実行しました。コスト削減率は、デフォルト設定と同等の適切なサイズのインメモリモードでのデプロイメントと比較して計算されています。 データセット Recall@100 (検索精度) p90 レイテンシー (ms) 次元数 ベクトル数 (百万) コスト削減率 モデル ソース Cohere TREC-RAG 0.94 104 1024 113 67% Cohere Embed V3 前処理済み Tasb-1M 0.96 7 768 1 83% msmacro-distilbert-base-tas-b 未処理 Marco-1M 0.99 7 768 1 67% msmarco-distilbert 未処理 OpenAI 5M 0.98 62 1536 5 67% text-embedding-ada-002 生成済み LAION 100M 0.93 169 768 100 67% CLIP 生成済み これらのテストは、ディスクモードが様々なデータセットとモデルで 32 倍の圧縮を実現し、目標レイテンシー (P90 200 ミリ秒未満) を維持しながら高い検索品質を提供できることを示すために設計されています。なお、これらのベンチマークは ML モデルの評価を目的としたものではありません。モデルが検索品質に与える影響は、データセットを含む複数の要因によって変わります。 ディスクモード最適化の仕組み ディスクモード で k-NN インデックスを実行するように構成すると、OpenSearch は自動的に量子化手法を適用し、ベクトルを圧縮しながらロードして圧縮インデックスを構築します。デフォルトでは、ディスクモードは、数百から数千の次元からなる完全な精度のベクトル (各次元が 32 ビット数値として格納されている) を、各次元を 1 ビットで表すバイナリベクトルに変換します。この変換により、32 倍の圧縮率が得られ、完全な精度のベクトルで構成されるインデックスと比較して 97% 小さいインデックスを構築できます。適切なサイズのクラスターであれば、この圧縮されたインデックスをメモリ内に保持できます。 圧縮によってベクトルエンジンのメモリ要件が削減されるため、コストは低くなりますが、その代償として精度が低下します。ディスクモードは、精度と検索品質を維持するために、2 段階の検索プロセスを使用しています。クエリ実行の最初の段階では、メモリ内の圧縮インデックスを効率的に走査して、候補となるベクトルを検索します。2 番目の段階では、これらの候補をもとに、対応する完全な精度のベクトルをオーバーサンプリングします。これらの完全な精度のベクトルは、I/O を削減し、ディスク検索の速度と効率を最適化するように設計されたフォーマットでディスクに格納されています。その後、この完全な精度のベクトルのサンプルを使用して、フェーズ 1 の検索結果を補強し、再スコアリング ( exact k-NN を使用) を行うことで、圧縮による検索品質の低下を防ぎます。ディスクモードのレイテンシがインメモリモードよりも高くなるのは、この再スコアリング処理によるものです。このプロセスでは、ディスクアクセスと追加の計算が必要となるため、相対的に処理時間が長くなります。 初期のお客様の成功事例 ベクトルエンジンのディスクモードは、すでに多くの企業で導入されています。ここでは、初期導入企業の事例を紹介します。 Asana は、OpenSearch のベクトルエンジンを通じてセマンティック検索機能を段階的に導入することで、ワークマネジメントプラットフォームにおける検索品質を向上させています。当初は 直積量子化 を使用してインデックスを 16 倍に圧縮することでデプロイを最適化しましたが、ディスク最適化構成に切り替えることで、検索品質とレイテンシーの目標を維持しながら、さらに 33% のコスト削減が可能になりました。このコスト構造の改善により、Asana は数十億ものベクトルにスケールし、プラットフォーム全体でセマンティック検索を民主化することが可能になりました。 DevRev は、顧客対応チームと開発者を直接つなぐことで、ソフトウェア企業の根本的なギャップを解消します。AI 中心のプラットフォームとして、顧客からのフィードバックから製品開発への直接的な経路を作り、1,000 社以上の企業が正確な検索、高速な分析、カスタマイズ可能なワークフローを活用して成長を加速できるようサポートしています。大規模言語モデル (LLM) と OpenSearch のベクトルエンジン上で実行される Retrieval Augmented Generation (RAG) フローに基づいて構築された DevRev は、インテリジェントな会話体験を実現します。 「OpenSearch のディスク最適化されたベクトルエンジンを使用することで、16 倍の圧縮を実現しつつ、検索品質とレイテンシーの目標を達成しました。OpenSearch は、当社の数十億ベクトル規模の検索において、スケーラブルで経済的な選択肢を提供してくれます。」 – Anshu Avinash, Head of AI and Search, DevRev OpenSearch ベクトルエンジンのディスクモードを利用開始する まず、インデックスをホストするために必要なリソースを決定する必要があります。デフォルトの 32 倍の圧縮率を使用したディスク最適化 k-NN インデックスをサポートするために必要なメモリを、次の式を使って見積もります。 必要なメモリ (バイト) = 1.1 x ((ベクトル次元数)/8 + 8 x m) x (ベクトル数) 例えば、 Amazon Titan Text V2 のデフォルト設定を使用する場合、ベクトルの次元数は 1024 になります。ディスクモードでは HNSW アルゴリズムを使用してインデックスを構築するため、「m」はアルゴリズムのパラメータの 1 つで、デフォルトは 16 です。10 億個のベクトルを持つコーパスを Amazon Titan Text でエンコードしてインデックスを作成する場合、必要なメモリは 282 GB となります。 高スループットのワークロードを扱う場合は、ドメインに十分な IOPS と CPU が確保されているかを確認する必要があります。デプロイのベストプラクティスに従えば、インスタンスストアとストレージ最適化インスタンスタイプを利用でき、一般的には十分な IOPS が得られます。高スループットワークロードの場合は必ず負荷テストを実施し、IOPS や CPU の要件を考慮して初期見積もりを調整してください。 今すぐ、ニーズに合わせて適切なサイズに設定された OpenSearch 2.17 + ドメインをデプロイできます。 k-NN インデックスを作成 する際に、 mode パラメータを on_disk に設定してから、 データを取り込んで ください。すでにデフォルトの in_memory モードで k-NN インデックスを実行している場合は、モードを on_disk に切り替えた後、 reindex 処理を実行することで変換できます。インデックスの再構築が完了したら、それに応じてドメインのサイズを調整してください。 結論 この記事では、OpenSearch ベクトルエンジンをディスクモードで実行することのメリット、お客様の成功事例、および導入の手順について説明しました。これで、従来のコストの 3 分の 1 まで抑えながら OpenSearch ベクトルを運用できる準備が整いました。 詳細は、 ドキュメント を参照してください。
今日、 AWS Amplify Hosting は、AWS Amplify アプリケーションの IAM Compute Roles を導入しました。これにより、コンピュート実行時から AWS サービスへの安全なアクセスを可能にし、サーバーサイドレンダリング機能を拡張できるようになりました。IAM Compute Roles を使えば、開発者はサーバーサイドレンダリングアプリに特定の権限を付与でき、Amplify が他の AWS サービスへの承認された呼び出しを行えるようになります。この新機能により、セキュリティのベストプラクティスを維持しながら、開発プロセスを加速できます。 主な機能 IAM Compute Roles を使えば、以下のことができるようになりました。 Next.js API ルートから AWS Secrets Manager と AWS Systems Manager Parameter Store を使用して、ランタイムで機密設定データにアクセスできます。 SSR アプリを Amazon RDS 、 Amazon DynamoDB などの AWS データベースに直接接続できます。 AWS Identity and Access Management (IAM) ポリシーを使用して、コンピューティング環境に細かい権限を定義できます。 サーバーサイドコードから任意の AWS サービスに対して、安全な認証済みの呼び出しができます。 チュートリアル 始める前に、IAM コンピューティング ロールを作成し、それを Amplify Next.js アプリケーションに関連付ける次の手順に従ってください。 前提条件 始める前に、以下がインストールされていることを確認してください。 Node.js (v18.x 以降) npm または npx (v10.x 以降) git (v2.39.5 以降) AWS CLI IAM Compute Roles の作成 Amplify Hosting の SSR コンピューティングサービスが、ロールの権限と信頼関係に基づいて、AWS リソースに安全にアクセスできるように、IAM ロールを作成しましょう。この例では、Amazon Simple Storage Service (Amazon S3) バケットに安全にアクセスします。 AWS マネジメントコンソールにサインインし、 IAM コンソール に移動します Access Management タブの下で、Roles を選択し、 Create role を選びます Custom trust policy を選択し、Amplify がこのロールを引き受けることができるように、以下のポリシーを入力します: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "amplify.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } AWS 管理の AmazonS3ReadOnlyAccess 権限ポリシーをロールに追加し、 Next を選択します ロールに amplify-compute-role という名前を付け、 Create Role を選択します Amplify が他の AWS サービスに接続するために引き受けることができるコンピュートロールを正常に作成しました。 セキュリティのベストプラクティス : 最小特権の原則を実施し、特定のユースケースに必要な権限のみを付与してください。 Amazon S3 バケットの作成 Next.js アプリが IAM Compute Roles を使用して安全にアクセスできる、プライベートの Amazon S3 バケットを設定します。Amazon S3 オブジェクトを公開したり、アクセスキーを管理するのではなく、Amplify Hosting の IAM Compute Roles を使って Amazon S3 からプライベートコンテンツを安全に取得します。 AWS マネジメントコンソールにサインインし、 Amazon S3 コンソール に移動します Create bucket &nbsp;を選択し、一意のバケット名を入力します ACL を無効 にし、 Block all public access を有効にしたままにします。 デフォルトの設定のままで、 Create bucket &nbsp;を選択します。 バケットへ移動し、 Upload &nbsp;を選択します。 画像 (例: amplify-logo.png) をアップロードします。 セキュリティの検証 : S3 バケットが完全にロックダウンされていることを確認するには、次の get-public-access-block AWS CLI コマンドを実行してください: // Note: Replace amplify-compute-role-demo with your specific bucket name aws s3api get-public-access-block --bucket amplify-compute-role-demo 出力結果は次のようになるはずです。 { "PublicAccessBlockConfiguration": { "BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true } } これらの設定は以下を保証します。 パブリック ACL の作成はできません 既存のパブリック ACL は無視されます パブリックバケットポリシーはブロックされます バケットへのパブリックアクセスが制限されます Next.js アプリの作成 次に、API ルートを使用して Amazon S3 バケットからプライベートコンテンツの画像にセキュアにアクセスできる Next.js アプリを作成します。 新しい Next.js 15 アプリを TypeScript と Tailwind CSS で作成します。 npx create-next-app@latest compute-role-demo --typescript --tailwind --eslint cd compute-role-demo JavaScript 用の AWS SDK の S3 Client パッケージをインストールします。 npm install @aws-sdk/client-s3 Amazon S3 Image API のルートを作成します。Amplify Hosting へのアプリケーションのデプロイ // app/api/image/route.ts import { S3Client, GetObjectCommand, S3ServiceException } from "@aws-sdk/client-s3"; import { NextResponse } from 'next/server'; const s3Client = new S3Client({}); const BUCKET_NAME = 'amplify-compute-role-demo'; const IMAGE_KEY = 'amplify-logo.png'; export async function GET() { console.log(`[S3 Image Request] Starting - Bucket: ${BUCKET_NAME}, Key: ${IMAGE_KEY}`); try { console.log('[S3 Image Request] Creating GetObjectCommand...'); const command = new GetObjectCommand({ Bucket: BUCKET_NAME, Key: IMAGE_KEY }); console.log('[S3 Image Request] Sending request to S3...'); const response = await s3Client.send(command); console.log('[S3 Image Request] Received S3 response:', { contentType: response.ContentType, contentLength: response.ContentLength, metadata: response.Metadata }); console.log('[S3 Image Request] Converting response to byte array...'); const buffer = await response.Body?.transformToByteArray(); if (!buffer) { console.error('[S3 Image Request] No buffer received from S3'); throw new Error('No image data received from S3'); } console.log('[S3 Image Request] Successfully processed image:', { bufferSize: buffer.length, contentType: response.ContentType }); return new NextResponse(buffer, { headers: { 'Content-Type': response.ContentType || 'image/png', 'Cache-Control': 'public, max-age=31536000, immutable' } }); } catch (error) { if (error instanceof S3ServiceException) { console.error('[S3 Image Request] AWS S3 Error:', { message: error.message, code: error.name, requestId: error.$metadata?.requestId, statusCode: error.$metadata?.httpStatusCode }); } else { console.error('[S3 Image Request] Unexpected error:', error); } return NextResponse.json({ success: false, error: 'Failed to load content' }, { status: 500 }); } finally { console.log('[S3 Image Request] Request completed'); } } クライアントコンポーネントを作成します。 // app/components/S3Component.tsx 'use client'; import { useState } from 'react'; import Image from 'next/image'; export default function S3Component() { const [imageError, setImageError] = useState(false); const [isRevealed, setIsRevealed] = useState(false); return ( &lt;div className="absolute inset-0 top-[88px] flex items-center justify-center"&gt; &lt;div className="w-full max-w-2xl rounded-2xl mx-4"&gt; &lt;div className="flex flex-col items-center justify-center min-h-[400px] p-8"&gt; {!isRevealed ? ( &lt;button onClick={() =&gt; setIsRevealed(true)} className="px-8 py-4 bg-[rgb(117,81,194)] text-white text-lg rounded-xl hover:bg-[rgb(107,71,184)] transition-colors" &gt; &lt;span className="flex items-center gap-2"&gt; Access Private S3 Bucket &lt;span className="text-xl"&gt;⚡&lt;/span&gt; &lt;/span&gt; &lt;/button&gt; ) : ( &lt;div className="space-y-8 w-full"&gt; {!imageError &amp;&amp; ( &lt;div className="relative h-64 w-full"&gt; &lt;Image src="/api/image" alt="Amplify Logo" fill unoptimized priority onError={() =&gt; setImageError(true)} className="object-contain" sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" /&gt; &lt;/div&gt; )} &lt;div className="text-center"&gt; &lt;p className="text-gray-400 text-sm"&gt; This content is securely served from S3 using an IAM Compute Role. &lt;/p&gt; &lt;/div&gt; &lt;/div&gt; )} &lt;/div&gt; &lt;/div&gt; &lt;/div&gt; ); } ホームページを更新して、クライアントコンポーネントをレンダリングします。 import S3Component from './components/S3Component'; export default function HomePage() { return ( &lt;div className="relative min-h-screen bg-[rgb(0,0,0)]"&gt; &lt;h1 className="text-2xl font-bold text-white py-8 text-center relative z-10"&gt; Amplify Hosting Compute Role Demo &lt;/h1&gt; &lt;S3Component /&gt; &lt;/div&gt; ); } 変更を git リポジトリにプッシュします。 新しい GitHub リポジトリを作成します 変更内容を Git ブランチに追加してコミットします リモート オリジンを追加し、変更内容をアップストリームにプッシュします git add . git commit -m "initial commit" git remote add origin https://github.com/&lt;OWNER&gt;/amplify-compute-role-demo.git git push -u origin main Amplify Hosting へのアプリケーションのデプロイ AWS マネジメントコンソールにサインインし、 Amplify コンソール に移動します。 Create new app を選び、リポジトリソースとして GitHub を選択します。 Amplify が GitHub アカウントにアクセスできるように認証します。 作成したリポジトリとブランチを選択します。 アプリの設定を確認し、 Next を選択します。 全体の設定を確認し、 Save and Deploy を選択します。 IAM Compute Roles を Amplify アプリに割り当てる Amplify コンソールでアプリを選択し、「App settings &gt; IAM roles」に進みます コンピュート ロールのセクションで Edit &nbsp;を選択します ロールメニューから amplify-compute-role を選択し、 Save を選んでください ブランチごとに固有のコンピュートロールを使うようにブランチ上書きを設定することもできます。これは開発、ステージング、プロダクションなど、さまざまな Git 環境間で特に役立ちます。 Next.js アプリへのアクセス Amplify コンソールのアプリの Overview タブに移動し、ブラウザ上で Amplify が生成したデフォルトの URL を開いてください。 次に、 Access Private S3 ボタンを選択してください。Amazon S3 バケットにアップロードされた画像が表示されるはずです。 ホスティングコンピューティングのログのレビュー アプリのホームページから、[Hosting] &gt; [Monitoring] に移動し、 Hosting compute logs タブを選択してください。 Amazon CloudWatch の Log Streams URL に移動し、最新のログストリームを確認してください。ログには Amazon S3 からの画像リクエストが含まれるはずです: おめでとうございます! Amplify Hosting の Next.js SSR アプリケーションに、IAM Compute Roles を正常に作成して割り当てました。これで、プライベート Amazon S3 バケットからコンテンツを安全に取得できるようになりました! クリーンアップ AWS Amplify アプリを削除するには、[ アプリ設定 ] &gt; [ 全般設定 ] に移動し、[ アプリの削除 ] を選択します。 Amazon S3 バケットを削除するには、S3 コンソールから [ バケットを選択 ] &gt; [ 削除を選択 ] &gt; 削除を確認するためにバケット名を入力します。 IAM ロールを削除するには、IAM コンソールから [ ロールを選択 ] &gt; amplify-compute-role 名を探し &gt; [ 削除を選択 ] &gt; 削除を確認するためにロール名を入力します。 まとめ AWS Amplify Hosting は現在、サーバーサイドレンダリング (SSR) アプリケーションの IAM Compute Roles をサポートし、AWS サービスへのセキュアなアクセスの課題を解決しています。以前は、開発者が環境変数を介して手動で認証情報を管理していました。しかし、IAM Compute Roles を使えば、開発者は SSR アプリに直接 IAM アクセス許可を割り当てられるため、サービスの統合が簡単になり、セキュリティが強化されます。 SSR アプリに IAM Compute Roles を追加するには今日、Amplify ドキュメント をご覧ください。 本記事は「 IAM Compute Roles for Server-Side Rendering with AWS Amplify Hosting 」を翻訳したものです。 著者について Jay Raval Jay Raval is a Solutions Architect on the AWS Amplify team. He’s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @ _Jay_Raval_ Matt Auerbach Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people’s lives easier. B night, however … well he does pretty much the same thing. You can find Matt on X @ mauerbac . He previously worked at Twitch, Optimizely &amp; Twilio. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。年明け 4 kg 太ったので、ダイエットに励んでいます。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。
PART3:Oracle DatabaseからAmazon&nbsp;Auroraへの移行 -運用編- PART1 では、農林中央金庫が Amazon Aurora の採用に至った経緯・評価点を解説しました。 PART2 では、農林中央金庫とNTT データで Amazon Aurora の採用に伴う非互換対応や性能試験に実施された内容を解説しました。PART3では、Amazon Aurora へ移行した後の実運用経験を踏まえ、これから Amazon Aurora へ移行検討されている方に向けて農林中央金庫・NTT データのコメントをご紹介させて頂きます。 Amazon Aurora で運用してみた感想 AWS および Amazon Auroraを活用することで、以下のような点で対応が楽になり、便利に感じられています: 基本的にパラメータはデフォルト設定で運用可能であり、特別なチューニングの必要性を感じていない テスト利用として、特にポイントインリカバリやバックアップ・リストア機能が便利 AWS 移行によってクラウド上の他システムとの接続・連携が格段に容易になり、データ活用につながっている 運用上アドホックなクエリを流すタイミングがあるが、SQL単位でのメモリ使用量をトラッキングする仕組みがなかった為、問題のあるアドホッククエリの特定が難しかった。 (※ Aurora PostgreSQL 15.4 以降の 15 バージョン、14.9 以降の 14 バージョンにて対応済 ) Amazon Aurora&nbsp;への移行を検討されている方へ 本プロジェクトを通じた気づきとして、Amazon Aurora への移行には大きなメリットがある一方で、注意点もいくつか明らかになりました。Amazon Aurora への移行をご検討される際は、以下の点に留意されることをおすすめします。 システム構成(特にAZを跨ぐ構成)について、その性能や可用性への影響を十分に見極めて設計する オンライン処理の性能確認は更改前の実測値を基準とし、準リアル処理においても実測値を基準としつつ、 本番の業務に相当するワークロードを仮想的に実行する仕組みを用意し、処理集中を意識した確認を行うことが必要 ※本プロジェクトでは、SQLの規約が整備されていたことで、想定外の事象が少なかったと考察 システム全体を見渡した上で、本番環境に近いトランザクション量での試験走行を実施することが重要 これらの点に留意しつつ、Amazon Auroraの大きなメリットを最大限に活かせるよう、移行検討を進めていただければと思います。 関連情報 本件の導入事例ページ https://aws.amazon.com/jp/solutions/case-studies/nochu-bank/ NTTデータの支援プログラムのページリンク あすぽす | デジタルテクノロジーディレクター® (ndigi.tech) &nbsp;