本ブログは 株式会社グレイプ様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの田中です。 2024 年は、非常に多くのお客様に、生成 AI の活用にチャレンジいただいた一年でした。生成 AI を活用した文書要約やチャットボットなど、社内の業務効率化に繋がる多くのユースケースが生まれました。さらに喜ばしいことに、生成 AI 活用をコアビジネスの価値向上や成長加速に繋がる事例も増えてきています。 今回ご紹介するのは、生成 AI の活用をコアビジネスの成長加速に繋げた、チャレンジングな取り組みです。月間 1.8億 PV を誇るウェブメディア「 grape（グレイプ） 」を運営する 株式会社グレイプ様 が、AWS の生成 AI サービスである Amazon Bedrock を活用して、メディアビジネスの根幹である高品質なコンテンツ制作を加速させた事例をご紹介します。 グレイプ様の状況と経緯 「 grape（グレイプ） 」は、「心に響く」をコンセプトに、読者の共感を呼ぶコンテンツを提供し続けているウェブメディアです。近年、ユーザーの情報収集手段はますますオンラインへとシフトし、従来型のマス広告だけでなく、個々のユーザーの興味や関心に寄り添ったコンテンツマーケティングの重要性が高まっています。グレイプ様は、長年培ってきたウェブメディア運営のノウハウを活かしながら、より多くの価値ある情報をユーザーに届けるためにチャレンジをし続けています。 グレイプ様が日々公開するコンテンツは、数十件にも及びます。その一つ一つに、読者の心に響く質の高さが求められます。プロのライターたちは、生成 AI には真似できないクリエイティビティを発揮されつつ、魅力的なコンテンツを多く生み出していますが、一方では課題を抱えていました。 一つは記事の校正に関する課題です。記事の品質を担保するため、各記事は二名体制での校正を行っています。校正作業は、誤字脱字のチェック、語彙のゆらぎのチェック、表現のチェックなどに加えて、HTML タグの確認など技術的な要素も含まれるケースがありました。そのため、経験が豊富なライターに頼らざるを得ない校正がいくつかあり、そのための作業に時間が費やされていました。 二つ目はタグ付けに関する課題です。記事の適切な分類と発信のためにタグは不可欠ですが、このタグはライターの経験と勘をもとに付与されていました。似たような記事でも人によってつけるタグが違ったり、経験が浅いライターにとっては効果的なタグがどれかわからないなど、適切なタグ付けが難しい状況にありました。 ソリューション／構成内容 これらの二つ課題に対して、グレイプ様は、ライターの方々に記事のライティング業務に集中してもらうため、校正作業に生成 AI の力を活用できないか、という発想からプロジェクトがスタートしました。検討の結果、Amazon Bedrock を活用したアプリケーションの構築を決定しました。コンテンツ制作はビジネスの核となる部分であるため、入力したデータが基盤モデルの学習に使用されない点が、重要な選定理由となりました。 様々な基盤モデルを比較検討した結果、 Anthropic Claude 3.5 Sonnet (v1) を採用することにしました。この基盤モデルを選んだ理由として、1) 日本語の校正に特に高い精度を示したこと、2) 簡単な文書作成においてライターから見ても自然な日本語表現ができており今後さらなる活用につながる見込みがあること、3) 応答時間とコストが現実的な範囲に収まったこと、の三点が挙げられます。 開発したアプリケーションのもつ主要機能は、以下の二つです。 1.校正支援機能 記事作成の加速を目指し、生成 AI を活用した校正支援の仕組みを構築しました。まず、ライターが作成したドラフト文書に対して、基盤モデルが誤字脱字のチェックを実施します。さらに、グレイプ様では独自の表記ルールを持っているため、このルールに沿っていない表現を見つけた場合、基盤モデルが適切な表現への置き換えを提案します。加えて、記事のドラフトに含まれる HTML タグについても、基盤モデルがチェックを行い、不適切な記述があれば正しい表記への修正を行います。 2.タグ推薦機能 基盤モデルに記事の内容をインプットとして与えると、アウトプットとして適切なタグを提案してくれる機能を実装しました。基盤モデルに対しては、記事の内容とともに、JSON 形式のタグ使用実績データも一緒に与えるようにアプリケーション内で実装しました。これによって、基盤モデルがよく利用されているタグから適切なタグを提案することができるようになり、タグに一貫性をもたせることを可能にしました。また、実際に付与するタグはライターが付与するので、その選別の手助けとなるよう、選別したタグの推薦理由も提案するようにしました。 （実際のアプリケーション画面） これらの機能開発は、記事校正ツールの開発 2 週間、タグ推薦ツールの開発はわずか 3 日間、という速さで行われました。主に開発を担当された柳本様は、それまで AWS のご経験はありませんでしたが、インフラ運用のご経験を活かし、まずはイメージがつきやすい Amazon Elastic Compute Cloud(Amazon EC2) をご自身で構築され、その上でアプリケーションの開発を進めました。 また、柳本様は生成 AI の活用も初めてのご経験でしたが、積極的にプロンプトエンジニアリングにも挑戦されました。開発中に期待する精度が得られないケースも発生しましたが、それらの問題解決にも時に生成 AI を活用しながら、一つ一つ解決していきました。 さらに、システムのテスト公開後は、ユーザーからのフィードバックを即座に取り込める体制を整えました。具体的には、実際に使用して期待する結果が得られなかった場合に、ユーザーがすぐに報告できるインターフェースを用意しました。この仕組みにより、ユーザーのフィードバックを元に追加開発を行う PDCA サイクルを素早く回すことができ、結果としてユーザーの積極的な利用に繋がりました。 導入効果 Amazon Bedrock を利用したアプリケーションの導入により、以下の効果が得られました。 記事の校正に関わる作業工数が 60 ％削減 記事のタグ選定に関わる作業工数が 20 %削減 数字では表せない定性的な効果もあがっています。例えば、校正作業の品質が均一化され、一定水準以上の質が保たれるようになりました。また、タグ付けにおいても、より適切で一貫性のある記事分類が可能になりました。 導入を担当された柳本様からは「AWS・AI 初学者でも生成 AI を使ってコードを作成し、実務対応レベルのツールが作れました。自分になんてと思わず生成 AI を活用して社内の課題にまずは挑戦するという気持ちが大切です。」とコメントをいただいています。 まとめ 本事例は、文章コンテンツをコアビジネスとする企業が、生成 AI を活用してビジネスの加速に繋げることができた好例です。人しか出せない価値について理解を深めていたからこそ、効果的な生成 AI の活用ができたのではないかと思います。また、短時間での構築を実現した点も注目です。AWS では、サーバーレスな API 形式で提供される生成 AI に加え、仮想サーバーやコンテナ、サーバーレスといったコンピューティングサービスなど、お客様のスキルセットやビジネス要件に合うサービスを選択して組み合わせることができます。これらをうまく活用することで、迅速なサービスリリースにつなげることができます。 グレイプ様では、さらなる進化を目指しています。具体的には、プロンプトの継続的な改善や、RAG（Retrieval Augmented Generation）の活用を通じて、コンテンツの品質向上に取り組んでいく予定です。 生成 AI を活用したビジネスの促進、業務の効率化、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社グレイプ : 技術開発部長 大槻 大作 様（中央右）、技術開発部 主任 柳澤 良介 様（中央左）、技術開発部 柳本 安利 様（中央） Amazon Web Services Japan : アカウントマネージャー 石井 美佑子（右端）、ソリューションアーキテクト 田中 里絵（左端） ソリューションアーキテクト 田中 里絵

本記事は 2024年11月25日に公開された「 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration 」 を翻訳したものです。 この投稿では、 AWS Cloud WAN の AWS Direct Connect アタッチメントを使用したハイブリッド接続アーキテクチャを構築する方法について解説します。また、オンプレミス環境とAWSクラウド間のシームレスな接続を実現するための、グローバルハイブリッドネットワークの設計におけるベストプラクティスや考慮事項についてご紹介します。 2024年11月25日より、AWS Cloud WAN は AWS Direct Connect ゲートウェイアタッチメントをネイティブでサポート しています。この統合により、中継点に AWS Transit Gateway を使用しなくても、グローバルなハイブリッドネットワークをより柔軟に設定できるようになります。AWS Direct Connect ゲートウェイが AWS Cloud WAN セグメントとオンプレミス環境間の経路を直接広報できるようにすることで、ルーティング管理を簡素化できます。 AWS Direct Connect ゲートウェイ を コアネットワーク に接続して、特定の AWS リージョン や Cloud WAN セグメントに応じたルーティング動作を実現できます。 この記事の最初のセクションでは、この新機能の仕組みについて解説するとともに、AWS Cloud WAN のグローバルネットワークに AWS Direct Connect を統合する際の代表的な3つの新規導入シナリオを紹介します。その後、現在 AWS Transit Gateway を介して AWS Cloud WAN と AWS Direct Connect を利用しているお客様向けに、推奨される移行方法を解説します。 前提条件 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Direct Connect、AWS Transit Gateway、AWS Cloud WANといった AWS のネットワーク構成要素に精通していることを前提としています。これらのサービスの詳細な説明は行わず、それぞれの機能や取り上げるルーティングシナリオでの活用方法について説明します。この記事で紹介する移行のベストプラクティスに関する背景情報として、Transit Gateway を含むハイブリッドルーティングアーキテクチャを取り上げた以前の記事「 Advanced hybrid routing scenarios with AWS Cloud WAN and AWS Direct Connect 」をご覧になることをお勧めします。なお、本記事では AWS Cloud WAN のセグメンテーション戦略やコアネットワークセグメントの作成や管理方法については詳しく扱いません。これらについては、AWS Cloud WAN の ドキュメント をご参照ください。 基本構成 簡素化のために、AWS クラウドリソースを 3つの AWS リージョン （ap-southeast-2、us-west-2、us-east-1）にまたがって展開する基本構成（図1）を使用します。コアネットワークの各 AWS リージョンで、AWS Cloud WAN はコアネットワークエッジ (CNE) をデプロイ及び管理します。ワークロード用に Production, Development, Hybrid の3つのセグメントを設定しました。本記事で紹介する構成は、セグメント数、アタッチメントタイプ、および AWS リージョン数が異なる環境にも適用可能です。テスト環境として図示されたような AWS Cloud WAN コアネットワークを作成したと仮定しています。 ドキュメント には、図1のアーキテクチャに類似したセグメントを持つコアネットワークのポリシー例が記載されています。           図 1: 3つの AWS リージョンにわたる AWS Cloud WAN コアネットワークを示す基本構成 AWS Cloud WAN の Direct Connect アタッチメントを設定する方法について、3つのシナリオを解説します。簡素化させるために、各シナリオでは Cloud WAN コアネットワーク上で個別のセグメントを使用します。 最初の 2 つのシナリオでは、2 つの異なる AWS Direct Connect ゲートウェイを Development セグメントとProductionセグメントにそれぞれ接続し、AWS 環境とオンプレミス環境間のエンドツーエンドのセグメンテーションを実現します。 3 番目のシナリオでは、Hybrid セグメントを使用し、2 つの新しい Direct Connect ゲートウェイを使用してグローバルルーティングセグメンテーションを設定します。この例では、ハイブリッドセグメントはオンプレミスからのパートナー接続専用であり、Production および Development セグメントとは直接通信しません。 仕組み 1 つ以上の Direct Connect ゲートウェイを、コアネットワークリージョンの全てまたは一部に AWS Cloud WAN コアネットワークにアタッチできます。Direct Connect ゲートウェイをコアネットワークの一部のリージョンにのみ関連付けた場合、そのゲートウェイは関連付けられたリージョン内のローカル経路のみを受け取ります。 この統合 により、オンプレミスのルーターは、コアネットワークが Direct Connect ゲートウェイを通じて広報した経路の完全な BGP AS_PATH 属性を受け取れるようになります。これにより、グローバルネットワーク全体のルーティングの可視性が向上し、オンプレミス環境できめ細かいルーティング制御が可能になります。 Cloud WAN と Direct Connect の統合設定を、ステップごとに確認していきましょう。まず基本構成から始め、新しいDirect Connect ゲートウェイを作成し、それを Cloud WAN の3つのリージョンすべてにまたがる Development セグメントに接続します。 ステップ 1: Direct Connect コンソール に移動し、「 Direct Connect ゲートウェイ 」を選択して、「 Direct Connect ゲートウェイを作成する 」をクリックします。図 2 に示すように、Direct Connect ゲートウェイの 名前 と 自律システム番号 (ASN) を設定します。Direct Connect ゲートウェイ ASN は一意でなければならず、コアネットワークの ASN 範囲またはオンプレミス環境と重複してはなりません。「 Direct Connect ゲートウェイを作成する 」をクリックします。 図 2: Direct Connect Gateway の作成 ステップ 2: AWS Network Manager コンソール に移動し、 グローバルネットワーク を選択します。 コアネットワーク に移動し「 アタッチメント 」 を選択します。「 アタッチメントの作成 」をクリックします。アタッチメントには、以下を設定します。 (オプション) 名前 : アタッチメントの名前を入力します。 アタッチメントタイプ : Direct Connect エッジロケーション : コアネットワークの AWS リージョンの全てまたは一部をアタッチ対象として選択します。この例では、コアネットワークが設定されているすべての AWS リージョンを選択します。後述の「知っておくべきこと」のセクションで、AWS リージョンを選択するためのベストプラクティスを紹介します。 Direct Connect ゲートウェイ : ステップ 1 で作成した Direct Connect ゲートウェイを選択します。 タグ : Cloud WAN アタッチメントポリシーに合わせて適切な Key と Value のペアを設定します。 図 3: Cloud WAN Development セグメントへの Direct Connect Gateway アタッチメントの設定 Cloud WAN ポリシーでセグメントに対して「 require-attachment-acceptance: true 」が指定されている場合は、アタッチメントを承認し、正しいセグメントへの関連付けを確認してください。アタッチメントの状態が「 Available 」になると、各 AWS リージョンのセグメントルートテーブルで Direct Connect ゲートウェイから受信した経路を確認できます。オンプレミスルーターでは、選択した特定の AWS リージョンのローカル経路を Cloud WAN セグメントから自動的に受信します。 本投稿では、Direct Connect 仮想インターフェイスの設定手順は説明しません。詳細については、AWS Direct Connect の ドキュメント を参照してください。 シナリオ1: 単一のオンプレミス拠点が AWS Cloud WAN グローバルネットワークの Development セグメントに接続される場合 図4は、前述の「仕組み」のセクションで説明した設定手順を実施した後のアーキテクチャを示しています。Direct Connect ゲートウェイを Development セグメントに接続し、3つの CNE すべてに関連付けました。このサンプルアーキテクチャでは、2つの Direct Connect トランジット仮想インターフェース（VIF）を使用しており、それぞれ2本の物理的な Direct Connect 接続に分散されています。1本目の物理接続にはプライマリトランジット VIF（VIF-1）を、2本目にはセカンダリトランジット VIF（VIF-2）を設定しました。また、 Direct Connect BGP コミュニティタグ を設定し、アクティブ/パッシブ構成を実現しています。 簡略化のため、この例では AWS Direct Connect に対して高い冗長性を持つアーキテクチャは使用していません。 AWS Direct Connect でのアクティブ/パッシブ BGP 接続の構築  や、 AWS Direct Connect の回復性に関する推奨事項 について詳細を確認することをお勧めします。 図 4: シナリオ 1 – 2 つの AWS Direct Connect 接続と 2 つのトランジット仮想インターフェイスを備えた単一のオンプレミスロケーション 1.オンプレミスから AWS への経路広報 図 5 は、オンプレミスから AWS に広報された BGP 経路を示しています。 図 5: シナリオ 1 – オンプレミスから AWS への経路広報 (A), (B) – オンプレミスのルーターは、両方のトランジット VIF を通じて Direct Connect ゲートウェイに IPv4 および IPv6 のプレフィックスを広報します。BGP コミュニティタグを使用して、Direct Connect ゲートウェイの BGP ローカルプリファレンスを調整し、2つの VIF 間でアクティブ/パッシブルーティングを実現しています。 (C) – Direct Connect ゲートウェイは、すべての経路に自身の ASN を AS_PATH に追加し、関連付けられた CNE にすべてのプレフィックスを広報します。Direct Connect ゲートウェイは BGP コミュニティをそのまま保持しますが、これらの BGP コミュニティは AWS Cloud WAN の動作には影響しません。各 CNE は、Development セグメント用に最適な経路をルートテーブルに登録し、ネクストホップとしてDirect Connect ゲートウェイ Development を設定します。 (D) – 各 CNE は、Direct Connect ゲートウェイから受信した IPv4 および IPv6 経路に自身の ASN を AS_PATH として追加し、それらをリモートリージョンの他のすべての CNE に広報します。ただし、 CNE は他の CNE から受信したオンプレミス経路を優先しません。これは、Direct Connect ゲートウェイから直接受信した経路と比較して、他の CNE から受信した経路は AS_PATH 属性が長くなるためです。 2. AWS からオンプレミスへの経路広報 図6は、Cloud WAN から Direct Connect ゲートウェイを通じてオンプレミスに伝播される経路を示しています。AWS Cloud WAN に組み込まれた Direct Connect アタッチメントにより、 許可されたプレフィックスリスト の設定を必要とせず、経路が双方向で動的に伝播されます。 図 6: シナリオ 1 — AWS からオンプレミスへの経路伝播 (A) – すべての VPC プレフィックス（IPv4 および IPv6）は、アタッチメントポリシーの設定に基づいて、対応するセグメント内の CNE に自動的に伝播されます。また、コアネットワークには、 Connect や AWS Site-to-Site VPN といった他のアタッチメントタイプを使用することもできます。 (B) – CNE はセグメント内のすべてのローカル経路を互いに、そして関連付けられた Direct Connect ゲートウェイに広報します。 (C) – Direct Connect ゲートウェイは、自身の ASN を AS_PATH に追加し、すべてのプレフィックスを関連付けられたすべてのトランジット VIF に広報します。オンプレミスのルーターでは、2つのトランジット VIF（VIF-1 および VIF-2）間でアクティブ/パッシブルーティング動作を実現するために、BGP 属性を設定する必要があります。 3.トラフィックフロー VPC とオンプレミス間のトラフィックフローを図 7 に示します。 図 7: シナリオ 1 — AWS とオンプレミス間のトラフィックフロー AWS からオンプレミスへのトラフィックフロー : VPC はトラフィックをローカルリージョン内の CNE に転送します。CNE はトラフィックをローカルの Direct Connect ゲートウェイアタッチメントに送ります。ただし、Direct Connect ゲートウェイがすべてのリージョンに関連付けられていない場合、CNE はランダムにリモートの CNE を選択してトラフィックを転送します。そのため、最適なルーティングを確保するために、アタッチされたセグメントが存在するすべての Cloud WAN リージョンに Direct Connect ゲートウェイを関連付けることを推奨します。Direct Connect ゲートウェイはトラフィックをプライマリトランジット VIF-1 に転送します。 オンプレミスから AWS へのトラフィックフロー : オンプレミスから AWS へのトラフィックは、同じ経路を通って対称的に転送されます。 シナリオ2: 複数のオンプレミス拠点がユニークなプレフィックスを AWS Cloud WAN コアネットワークの Production セグメントに広報する場合 このシナリオでは、複数のオンプレミス拠点が Cloud WAN コアネットワークの Production セグメントに接続されており、それぞれが AWS に対してユニークな IP プレフィックスを広報していることを前提としています。各拠点は独自の IPv4 および IPv6 プレフィックスでアドレス指定されているため、すべてのトランジット VIF と Cloud WAN コアネットワークエッジに対して単一の Direct Connect ゲートウェイが必要です。Direct Connect ゲートウェイは、関連するリージョンからのトラフィック転送において、ユニークな IPv4 および IPv6 プレフィックスの広報を基に適切なオンプレミス拠点を判断します。簡潔さを考慮し、このシナリオでは Direct Connect に高可用性のアーキテクチャを使用せず、Direct Connect の冗長性に関する推奨事項の確認を推奨します。 このアーキテクチャは図8に示されています。この構成は、2つ以上のグローバルに分散したオンプレミス拠点に拡張することが可能です。 図8: シナリオ2 – 各オンプレミス拠点がユニークな IPv4 および IPv6 プレフィックスをコアネットワークの Production セグメントに広報 1.オンプレミスから AWS への経路広報 図9は、オンプレミスの拠点から Production セグメントに広報される IPv4 および IPv6 プレフィックスを示しています。Direct Connect ゲートウェイ Production に Direct Connect アタッチメントを設定し、すべての CNE をこれに関連付けました。これにより、コアネットワーク内のすべての Cloud WAN CNE が、Direct Connect ゲートウェイを介してオンプレミス拠点から広報された BGP 経路を直接学習できるようになります。 図9: シナリオ2 – オンプレミスから AWS への BGP 経路広報 オンプレミスからの経路広報には BGP コミュニティを使用し、各プレフィックスに対する Direct Connect ゲートウェイのプライマリおよびバックアップパスを制御しています。経路は Direct Connect ゲートウェイから AWS Cloud WAN に伝播され、シナリオ1で説明したのと同じ経路伝播メカニズムが適用されます。 2. AWSからオンプレミスへの経路広報 AWS からオンプレミスへの経路広報は、前述のシナリオ1と同様に行われます。すべてのオンプレミス拠点は、コアネットワーク内のすべてのリージョンで Direct Connect ゲートウェイに関連付けられたセグメントから、AWS Cloud WAN のプレフィックスを学習します。 3.トラフィックフロー 図10は、VPC と特定のオンプレミス拠点間のトラフィックフローを示しています。 図 10: シナリオ 2 — AWS とオンプレミス間のトラフィックフロー AWS からオンプレミスへのトラフィックフロー : シナリオ1と同様に、図10では VPC からローカルリージョン内の CNE へトラフィックが流れ、次にローカル Direct Connect アタッチメントを介して Direct Connect ゲートウェイに送信される流れを示しています。Direct Connect ゲートウェイは、特定の広報された経路と BGP コミュニティに基づいて最終的なルーティング決定を行います。この場合、パケットの宛先 IP アドレスに基づき、プライマリトランジット VIF（VIF-1 または VIF-3）を通じて適切なオンプレミス拠点にトラフィックを送信します。 オンプレミスから AWS へのトラフィックフロー : トラフィックは同じパス (VIF-1 または VIF-3 > Direct Connect ゲートウェイ Production > CNE > VPC) をたどって対称的に転送されます。 シナリオ3: 同一プレフィックスを AWS Cloud WAN コアネットワークのハイブリッドセグメントに広報する複数のオンプレミス拠点 前述のシナリオ 2 で示したように、各オンプレミス拠点から特定のプレフィックスを広報することをお勧めします。しかし、複数のオンプレミス拠点から同じ集約プレフィックスを AWS に広報する必要がある場合、複数の Direct Connect ゲートウェイを使用して Cloud WAN のルーティングを制御できます。これにより、Direct Connect ゲートウェイが集約プレフィックスの送信先としてどのオンプレミス拠点を選択するかを制御できます。 このシナリオでは、2つの Direct Connect ゲートウェイを使用して、トラフィックが AWS からオンプレミスの宛先に向かう際、地理的に最も近い AWS Direct Connect のポイントオブプレゼンス（POP）を経由するようにルーティングを行います。2つの Direct Connect ゲートウェイを Hybrid セグメントに接続し、それぞれを特定のルーティング動作を必要とする CNE に関連付けます。図11は、このシナリオのアーキテクチャを示しています。 図11: シナリオ3 – 複数の Direct Connect ゲートウェイをCloud WAN のハイブリッドセグメントに接続し、それぞれを特定の CNE に関連付け 1. オンプレミスから AWS への経路広報 図12は、2つの Direct Connect ゲートウェイを通じてオンプレミスから AWS への経路広報を示しています。両方の Direct Connect ゲートウェイは、オンプレミスから同じ集約プレフィックスを学習し、それを関連付けられた CNE に広報します。各 CNE は関連付けられた Direct Connect ゲートウェイから学習した経路と、コアネットワーク内の他の CNE から AS_PATH がより長い経路を受信します。 図12: シナリオ3 – オンプレミスから AWS への経路広報 2. AWS からオンプレミスへの経路広報 コアネットワークセグメントに接続された Direct Connect ゲートウェイは、関連する CNE が各セグメントのローカルアタッチメントから学習した経路のみをオンプレミスに広報します。このシナリオでは: Direct Connect ゲートウェイ1は、ap-southeast-2 および us-west-2 のコアネットワークリージョン内でコアネットワークの Hybrid セグメントに接続された VPC からの IPv4 および IPv6 プレフィックスのみを、関連付けられたトランジット VIF に広報します。 Direct Connect ゲートウェイ2は、us-east-1 のコアネットワークリージョン内でコアネットワークの Hybrid セグメントに接続された VPC からの IPv4 および IPv6 プレフィックスのみを、関連付けられたトランジット VIF に広報します。 3.トラフィックフロー AWS からオンプレミスへのトラフィックフロー :このシナリオでは、US 西部のオンプレミス拠点に地理的に近い CNE を Direct Connect ゲートウェイ1に関連付け、US 東部のオンプレミス拠点に近い CNE を Direct Connect ゲートウェイ2に設定しました。これにより、集約プレフィックスに対してどのオンプレミス拠点を使用するかを制御できます。CNE は、直接関連付けられた Direct Connect ゲートウェイを経由する最短の AS_PATH を持つ経路を選択します。そのため、CNE はトラフィックを関連付けられた Direct Connect ゲートウェイに転送します。Direct Connect ゲートウェイは、設定された BGP コミュニティタグに基づいて適切なトランジット VIF にトラフィックを送信します。トラフィックがいずれかのオンプレミス拠点に到達すると、オンプレミスネットワーク上で拠点間のルーティングが可能です。 オンプレミスから AWS へのトラフィックフロー :オンプレミス側のルーターでは、それぞれの Direct Connect ゲートウェイに関連付けられたリージョン内のコアネットワークセグメントからの経路を受信します。トランジット VIF 1と2上で、ap-southeast-2 および us-west-2 にローカルな Hybrid セグメントからの経路を受信します。一方、トランジット VIF 3と4上で、us-east-1 にローカルな Hybrid セグメントからの経路を受信します。オンプレミス側のルーターで BGP のベストパス選択アルゴリズムを調整することで、AWS へのトラフィックがプライマリトランジット VIF（1および3）を経由するような対称的なルーティングを実現できます。 移行のベストプラクティス この記事の後半では、AWS Cloud WAN と AWS Direct Connect を Transit Gateway 経由で利用しているアーキテクチャから移行する際に、ダウンタイムを最小限に抑えるための移行戦略を説明します。もし AWS Cloud WAN への移行を検討しているが、現在の AWS リソース（例: VPC）がまだ Transit Gateway に接続されている場合は、「 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns 」に関するガイドラインに従うことをお勧めします。このガイドラインは、Transit Gateway を利用した Direct Connect によるハイブリッド接続を維持しつつ、AWS リソースを Transit Gateway から AWS Cloud WAN へ移行するのに役立ちます。その後、以下の手順に従って、Direct Connect を Transit Gateway から AWS Cloud WAN へ移行し、不要になった Transit Gateway を廃止することができます。 以下の移行におけるベストプラクティスを検討することをお勧めします。 Cloud WAN に接続するための新しい Direct Connect ゲートウェイを作成します。 Direct Connect ゲートウェイは無料で利用できます。新しいものを作成することでダウンタイムを最小限に抑え、移行やロールバックの手順を簡素化できます。 新しいトランジット VIF を作成し、新しい Direct Connect ゲートウェイに関連付けます。 これにより、トラフィックに影響を与えずに、既存の経路と新しい経路の広報を制御できます。この段階では、新しい BGP ピアがアクティブであることを確認しますが、まだオンプレミスからの経路を広報しないでください。 新しい Direct Connect ゲートウェイを、それぞれの AWS リージョンの AWS Cloud WAN の各セグメントにアタッチします。 このステップで、オンプレミスルーターは新しい Direct Connect ゲートウェイからコアネットワーク経路を自動的に受信します。これらの新しい経路の AS_PATH (AS_PATH = Direct Connect ゲートウェイ ASN、CNE ASN) は、古い Direct Connect ゲートウェイを経由する既存の経路 (AS_PATH = Direct Connect ゲートウェイ ASN) よりも長くなっています。この新しい Cloud WAN 統合では、Direct Connect ゲートウェイは自身の ASN で上書きする代わりに、AS_PATH 内のすべての ASN を保持します。このステップでは、オンプレミスルーターが AS_PATH の短い既存のトランジット VIF 経由で受信した経路を優先するため、ルーティングパスの変更は発生しません。 オンプレミスルーターが古い VIF と新しい VIF の両方から同じ経路を受信していることを確認します。 これにより、新しい経路設定が正しく構成されていることを確認できます。 新しい VIF 上でオンプレミスからテスト用の経路または一連の経路を広報します。 それらの経路が Cloud WAN で受信されていることを確認します。 新しい VIF 上で、古い VIF と同じオンプレミスのプレフィックスを広報します。同時に、オンプレミスルーターが新しい VIF 経由でトラフィックを優先的にルーティングするように設定します。これは、オンプレミスルーターで BGP ベストパス選択アルゴリズム（例: Local Preference の使用）を制御することで実現できます。 これにより、新しい Direct Connect ゲートウェイおよびトランジット VIF を介して、AWS Cloud WAN とオンプレミス環境間でトラフィックが対称的に流れるようになります。このステップで環境内でルーティングパスの変更が発生します。 これらの手順はすべて、計画されたメンテナンスウィンドウ中に実施することをお勧めします。ただし、既存のトラフィックフローに影響を与えるコアネットワーク内のルーティング変更が発生するのは、最後のステップのみです。ロールバックする場合は、新しい仮想インターフェイス上のオンプレミスから広報している経路を停止し、BGP のベストパス選択アルゴリズムを元に戻して古い VIF を優先するように設定します。これにより、Cloud WAN は Transit Gateway から受信したオンプレミス経路を再び優先するようになります。 知っておくべきこと Direct Connect ゲートウェイは1つの AWS Cloud WAN セグメントにしか関連付けることができません。ただし、同じセグメントに複数の Direct Connect ゲートウェイを関連付けることは可能です。また、異なる Cloud WAN セグメントに複数の Direct Connect ゲートウェイを関連付けることもできます。ただし、同じ Direct Connect ゲートウェイを複数のセグメントに関連付けることはできません。 Direct Connect アタッチメントを使用して Direct Connect ゲートウェイを AWS Cloud WAN セグメントに関連付ける際、Cloud WAN CNE 全体またはその一部を選択できます。シナリオ3で示されているような特定のルーティング要件がない限り、該当セグメントが設定されているすべての CNE にアタッチメントを関連付けることを推奨します。Direct Connect ゲートウェイアタッチメントを CNE の一部にのみ関連付けた場合、Direct Connect ゲートウェイは関連付けられた CNE のローカルアタッチメントからのみ経路を受信します。 Direct Connect BGP コミュニティタグ は Direct Connect ゲートウェイにのみ関連し、Cloud WAN コアネットワークのルーティング決定には影響しません。 Cloud WAN の経路評価アルゴリズムの詳細は こちら です。MED は AS 間を超えて伝播されないローカルな BGP 属性であるため、Direct Connect ゲートウェイは Cloud WAN に広報されるすべての経路で MED をリセットします。 AWS Cloud WAN の新しい Direct Connect アタッチメントでは、許可されたプレフィックスリストを使用する必要なく、経路を双方向に動的に伝播させることができます。ただし、Transit Gateway を Direct Connect ゲートウェイに関連付ける場合には、引き続き許可されたプレフィックスリストの使用が必要です。Direct Connect ゲートウェイを分離されたセグメントにアタッチした場合、VPC の経路はオンプレミスルーターに伝播されず、オンプレミス経路もコアネットワークセグメントには伝播されません。 ドキュメント に記載されている手順に従うことで、複数のアカウントから Direct Connect ゲートウェイを AWS Cloud WAN コアネットワークにアタッチすることができます。 コアネットワークセグメントから Direct Connect ゲートウェイアタッチメントに広報できる経路数、およびオンプレミス環境から Direct Connect 仮想インターフェイス上で広報できる経路数のクォータについては、 AWS Cloud WAN のドキュメント および AWS Direct Connect のドキュメント に詳しく記載されています。 まとめ この投稿では、 AWS Cloud WAN と AWS Direct Connect の統合機能 を活用して、ハイブリッド接続アーキテクチャを構築する方法について解説しました。AWS 上でグローバルなハイブリッドネットワークを設計し、オンプレミス環境と AWS クラウド間のシームレスな接続を可能にするためのベストプラクティスを解説しました。この統合により、中継点に AWS Transit Gateway を使用する必要がなく、グローバルなハイブリッドネットワークの構成においてより柔軟性が得られます。また、AWS Cloud WAN セグメントとオンプレミス環境間で経路を直接広報することで、ルーティング管理を簡素化できます。AWS Cloud WAN に関する詳細は、 ドキュメント をご確認ください。この投稿に関して質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 翻訳はテクニカルアカウントマネージャーの米山 京佑が担当しました。原文は こちら です。

このブログは、SAP の Senior Cyber Security Design Specialist である Amos Wendorff と共同で執筆されました。 はじめに: AWS では、お客様がクラウドサービスを安心して利用できるように、堅牢なセキュリティソリューションを提供することにコミットしています。 この記事では、SAP がお客様向けに AWS 上で実行している、安全で規制を遵守した RISE with SAP および SAP BTP (Business Technology Platform) 環境について説明し、AWS サービスを利用したセキュリティ監視およびアラート通知の自動化ソリューションの実装についても説明します。 RISE with SAP は、企業に ERP システムをトランスフォームしクラウドに移行する道筋を提供する包括的なオファリングです。SAP のインテリジェント エンタープライズ ソフトウェア、クラウド インフラストラクチャ、サービスを組み合わせることで、お客様は IT ランドスケープの簡素化、より速いイノベーション、デジタル トランスフォーメーションの推進が可能になります。RISE with SAP を採用することで、お客様は SAP S/4HANA など SAP アプリケーションのパワーを活用しながら、クラウドのスケーラビリティ、セキュリティ、コスト効率の恩恵も得られます。 背景: SAP が RISE with SAP と SAP BTP を急速に導入したことにより、SAP が使用する AWS アカウントの数が指数関数的に増加しました。SAP は現在 33 の AWS リージョンで運用しており、このブログ記事の執筆時点で 7,000 を超える AWS アカウントを管理しながら、新しいリージョンの立ち上げとともに展開地域を拡大しています。 これらの多数のアカウントを手動で監視およびセキュアに維持することは大変な課題となります。そこで SAP は、AWS の強力なセキュリティサービスを活用しながら、お客様のニーズに合わせてスケールできる、セキュアで自動化されたソリューションを必要としていました。 技術的な実装: SAP の Global Security & Cloud Compliance (SGSC) チームは、7,000 を超える AWS アカウントを対象に包括的なセキュリティを確保するため、AWS のサービスとサードパーティ製ツールを組み合わせた堅牢な「セキュアなデフォルト」フレームワークを構築しています。 このアーキテクチャの中核は、 Amazon GuardDuty です。 Amazon GuardDuty は、機械学習、異常検知、脅威インテリジェンスを活用して、AWS 環境における悪意のあるまたは不正な活動を継続的に監視し、リアルタイムの脅威検知を実現します。 すべての Amazon GuardDuty の検出結果とセキュリティログは、 Amazon S3 に集約されます。 Amazon S3 は、 AWS Organization 全体のログの中央リポジトリとして機能します。 このセットアップにより、SAP は膨大なクラウドインフラストラクチャの可視性と管理を維持できます。 大量のデータを処理するために、SAP は Splunk のような先進的な分析と可視化のための宛先へのルーティング前に、ログをフィルタリング、強化、正規化することで Cribl を使用します。これにより、セキュリティチームはデータを効率的に管理し分析して、脅威を迅速に特定し対応できます。さらに SAP は、アカウント所有者とセキュリティ対応者の連絡先情報を含むメタデータを保持する MasterData Cloud Database を維持しています。これにより、セキュリティ問題が検出された際に対象を絞った通知と対応が可能となり、明確な説明責任と迅速な対応能力を維持することが可能になります。 検出と分析に加えて、SAP は特定のセキュリティ上の問題を自動化して修正するための AWS Lambda 関数を利用しています。たとえば、GuardDuty がセキュリティポリシーに違反しているオープンポートを検知した場合、AWS Lambda 関数がトリガーされ、セキュリティグループルールの調整によってその問題を自動的に修正します。この自動化により、手動による介入の必要性を削減し、すべての AWS アカウントにおいてコンプライアンスを確実にします。RISE with SAP や SAP BTP のお客様の環境は SAP が運用しているため、この自動化アーキテクチャにより、クラウドリソースがこれらの厳格なセキュリティコントロールの下で継続的に監視・保護されるため、安心と継続的な運用が可能になります。 SAP のアプローチは、AWS ネイティブのセキュリティ機能を高度なデータ処理ツールと統合することで、AWS 上の SAP アプリケーションのニーズに特化した自動化、スケーラブル、かつセキュアなクラウド環境を実現しています。 セキュリティ制御の概要: SAP の「デフォルトで安全」な管理の対策には、AWS のネイティブなセキュリティ機能を利用して、安全なクラウド環境を確保するさまざまな対策が含まれています。その中には、すべてのアカウントを AWS の組織に組み入れてポリシーを統一的に適用すること、SAP Active Directory との統合、SAP ドメインユーザ以外のアクセスを防止すること、クラウド管理者に対する強制的な多要素認証の実施などがあります。 集中型のログ管理システムは、全アカウントを対象として、API の利用記録やストレージへのアクセス履歴を常時監視しています。これらのログデータは、セキュリティ分析基盤 (SIEM) に自動的に集約され、リアルタイムでセキュリティ監視と分析が行われる仕組みとなっています。このアプローチは、公開リソースや暗号化されていないデータなど一般的なクラウド設定のミスを防止するだけでなく、AWS の組織ガバナンス機能を活用して、特定のポートをブロックする高度なネットワーク管理や、安全な通信のための TLS 1.2 以上を強制するなどの対策を講じています。 デプロイメントリングを使ったフェーズドロールアウト: 新しい予防統制は、4 つのデプロイメントリングでロールアウトされます。 この段階的なアプローチにより、チームがポリシーをテストし、混乱を最小限に抑えることができます。 アカウントの所有者は、デプロイメントリングでのアカウントの配置を選択でき、ポリシーの施行の少なくとも 2 週間前に通知を受けることができます。 SAP は、潜在的な混乱を考慮し、特定の管理対象に対する例外または遅延を検討して、影響を最小限に抑えています。 通知と修復のプロセス: 自動化されたセキュリティ監視は、検出された管理違反の重大度に基づいて通知プロセスをトリガーします。 重大度の高い警告は、AWS Lambda を利用した SAP の自動化プロセスによって自動的に修復されます。 自動アカウントプロビジョニングとセキュリティ標準: SAP の自動アカウント プロビジョニング プロセスにより、新しい AWS アカウントはそのはじめから、予め定義されたセキュリティ標準とベストプラクティスを遵守することが保証されます。 これには、必要な IAM ロール、 AWS セキュリティツール の実装、および SGSC セキュリティポリシーへの準拠が含まれます。 このプロセスでは、高度な自動販売システムがアカウントのライフサイクルを自動的に管理します。セキュリティの第一層は、特定のアクションとリソースをブロックする Service Control Polices (SCP) によって実装されています。Amazon GuardDuty と AWS CloudTrail を使用して、検出メカニズムが導入されています。 Orca Security は、脆弱性、設定ミス、コンプライアンスリスクの自動化されたエージェントレススキャンと修復によって、SAP のクラウドセキュリティポスチャを強化します。 SAP は、SAP AWS 全組織にセキュリティを直接埋め込むことで、ライフサイクルの初期段階でリスクを特定し、軽減するプロアクティブなアプローチを採用しています。この統合により、お客様のワークロードに堅牢なセキュリティ基盤が確保され、攻撃対象領域を最小限に抑え、クラウドネイティブ環境のベストプラクティスに準拠します。 標準的なセキュリティ対策に加えて、SAP は RISE with SAP 環境のアカウントレベルのセキュリティを強化するために、AWS の複数の機能を活用しています: RISE with SAP のバックアップ用の EBS Snapshot Lock: クライアントのデータをより良く保護するため、SAP は Amazon Elastic Block Store (Amazon EBS) Snapshot Lock を採用しました。この機能は、1 日から約 100 年の範囲のロック期間を使用し、新規および既存の Amazon EBS Snapshot をロックします。これにより、保存されたデータが意図せず削除されるのを防ぎ、SAP のエンタープライズカスタマにより安心感を与えています。SAP は Amazon Data Lifecycle Manager を使用して、予め定義されたスケジュールと保持ガイドラインに基づいてスナップショットの作成、保持、削除を自動化します。そして、Amazon EBS Snapshot Lock を使って、これらのバックアップを厳格なコンプライアンス管理下に置きます。この機能のコンプライアンスモードでは、スナップショットが承認されたユーザによっても削除できないことを検証します。最大 72 時間のクーリングオフ期間を経た後は、スナップショットやロックはロック期間が切れるまで削除できず、モードも変更できません。SAP のお客様は、数週間から最大 2 年までの範囲で、スナップショットのロック期間をカスタマイズする選択肢もあります。 RISE with SAP での Bring Your Own Key (BYOK): お客様は、自身の AWS KMS customer master key (CMK) を使用して、RISE with SAP 環境のデータを暗号化することで、セキュリティを強化できます。お客様は同じリージョンで CMK を作成し、RISE with SAP AWS アカウントに権限を付与することで、EFS、データボリューム、バックアップ用の暗号化キーを利用できます。このアプローチでは、データ暗号化に対する制御を高め、キーアクセスの取り消しが可能であり、AWS KMS の 99.999 % の可用性サービスレベル SLA の恩恵を受けながら、暗号化要件を満たすことができます。 RISE with SAP 向け AWS WAF: AWS WAF (Web Application Firewall) は、RISE with SAP 環境の主要なセキュリティコンポーネントであり、Web アプリケーションと API を一般的な Web 攻撃やジオブロッキングによるリソース乱用から自動的に保護します。環境プロビジョニング時の自動デプロイと設定により、お客様の介入なく一貫した保護が確保されます。この設定により、RISE with SAP 環境の全体的なセキュリティポスチャにおいて、エンタープライズグレードの Web アプリケーションセキュリティが提供されます。 RISE with SAP 内の AWS ユーザ向け相互 TLS (mTLS) 検証: 相互 TLS (mTLS) 検証は、RISE with SAP 環境内の AWS のお客様向けの高度なセキュリティ機能です。この機能は、ネットワーク通信に対する認証とセキュリティの追加層を提供し、機密性の高いワークロードやアプリケーションに対するセキュリティ強化を図っています。mTLS の主な利点は、従来の TLS よりも強力な認証によるセキュリティ強化、許可されたクライアントのみがサービスに接続できるようクライアント検証、転送中のデータの機密性と整合性の維持による完全性の確保などです。さらに、mTLS は金融やヘルルスケアなどの業界における厳格な規制要件の遵守に役立ち、関連する基準を満たします。mTLS を導入することで、RISE with SAP のお客様は高度に安全で規制に準拠したクラウド環境の恩恵を受け、アプリケーションやワークロードの全体的なセキュリティポスチャを一層高めることができます。 RISE with SAP 向け SAP BTP Private Link Service: AWS PrivateLink に基づくサービスである SAP BTP Private Link Service は、SAP BTP と RISE with SAP 環境間の安全な プライベートネットワーク接続を確立し、トラフィックを AWS の内部ネットワークを介して送受信することで、パブリックインターネットへの公開を回避しながらも、低レイテンシーで高パフォーマンスな通信を実現します。 自動化ソリューションのメリット: 向上したセキュリティポスチャ: セキュリティ違反のリアルタイム検出と警告により、迅速な対処が可能になり、セキュリティインシデントを防ぐことができます。 スケーラビリティ: 数千の AWS アカウントにわたってセキュリティコントロールをスケーリングし、包括的な対応とセキュリティ保護を実現します。 自動化: セキュリティ監視の自動化により、手動での介入が不要になり、SAP のセキュリティ オペレーションの効率が向上します。 同様のアプローチを実装しようとしている企業にとって、重要な出発点は、クラウドネイティブのマインドセットを持ち、AWS 内蔵のセキュリティ機能を十分に活用することです。これには、AWS Organizations を使用して集中管理のためのアカウントを設定し、セキュリティガードレールとしてサービスコントロールポリシー (SCP) を適用することが含まれます。Amazon GuardDuty を利用した脅威検知、AWS CloudTrail を利用した監査ログ記録、AWS Key Management Service (KMS) を利用した安全な鍵管理など、クラウドネイティブツールを使うことで、組織はゼロトラストアーキテクチャを構築し、攻撃対象領域を大幅に削減し、全体的なセキュリティポスチャを強化することができます。暗号化基準を確保し、パスワードポリシーを施行し、すべてのアクセスポイントで多要素認証を有効にすることは実践すべき手順です。これらのセキュリティベストプラクティスの実装に関する包括的なガイダンスについては、組織は AWS Well-Architected Framework のセキュリティの柱の文書 を参照する必要があります。加えて、AWS Security Services と RISE with SAP の活用に関する具体的なガイダンスは、 AWS Security Considerations for RISE with SAP に記載されています。 結論: AWS の堅牢なセキュリティサービス、自動化機能、組織のポリシーエンジンを活用したクラウドネイティブのセキュリティ戦略を採用することで、SAP の「セキュア バイ デフォルト」ソリューションにより、AWS 上の RISE with SAP、SAP BTP、その他の SAP ソリューションを利用するお客様は、確かなセキュリティ態勢のもと、本来のビジネス目標に専念することができます。このアプローチには、ゼロトラストアーキテクチャ (ZTA) の原則が組み込まれており、ユーザーアクセスの継続的な検証、クラウドリソースの厳格な管理、そして AWS ネイティブツールによるコンプライアンスの徹底が最重要とされています。SAP は、リアルタイムの検知、アラート、自動修復を通じてリスクを最小限に抑えています。これにより、SAP のお客様は、AWS 上の包括的でスケーラブルなセキュリティフレームワークによって機密データとワークロードが確実に保護されているという安心感を持ちながら、クラウド投資の価値を最大限に引き出すことができます。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

本記事は、2024 年 11 月 22 日に公開された “ Build a Travel Planner with React Native, AWS Amplify, and Amazon Bedrock Knowledge Base ” を翻訳したものです。翻訳は Solutions Architect の 吉村 が担当しました。 Amplify AI kit の発表により、 カスタム UI コンポーネント 、 会話の履歴 、 会話の流れに外部データを追加 する方法を学びました。この記事では、React Native を使用してトラベルプランアプリケーションを構築する方法を学びます。このアプリケーションは、 Knowledge Base に基づいて、Retrieval Augmented Generation (RAG) および Large Language Models (LLM) を使用して応答を生成します。 大規模言語モデル (LLM) に最新の独自情報を付与するには、RAG という手法を使用できます。これは、企業のデータソースからデータを取得し、プロンプトを強化することで、より関連性が高く正確な応答を提供できるようになります。Amazon Bedrock Knowledge Bases を使えば、会社のプライベートデータソースから FM とエージェントにコンテキスト情報を提供し、RAG がより関連性があり、正確で、カスタマイズされた応答を提供できます。 この記事のバックエンドの構築、Knowledge Base の作成、RAG の部分は、どのウェブフレームワークでも使用できます。 ただし、このチュートリアルでは React Native でアプリケーションを構築することを想定しており、それに応じてフロントエンドのコードを説明します。 Amplify アプリの構築 Amplify アプリケーションを作成するには、アプリケーションのルートフォルダで create-amplify コマンドを実行する必要があります。 npm create amplify@latest -y これにより、AWS Amplify に対してプロジェクトに必要な依存関係がインストールされます。IDE でプロジェクトを開くと、新しい amplify フォルダが表示されます。 このフォルダには、メール認証付きのシンプルな ToDo アプリケーションが含まれています。関連するカテゴリのリソースは、それぞれ専用のフォルダの下に定義されています。たとえば、認証については auth/resource.ts ファイルを更新します。 ユーザーにパーソナライズされた体験のためのサインアップ認証フローを追加しましょう。まず auth/resource.ts ファイルを開き、次のように更新します。 import { defineAuth } from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: { verificationEmailSubject: "Welcome to Travel Advisor! Verify your email!", verificationEmailBody: (code) => `Here is your verification code: ${code()}`, verificationEmailStyle: "CODE", }, }, userAttributes: { preferredUsername: { mutable: true, required: true, }, }, }); これにより、ユーザー確認メールがカスタマイズされ、登録時にユーザー名の作成が求められます。次に、Amplify サンドボックスを介して、初期デプロイを行います。個人用のクラウドサンドボックス環境は、フルスタックアプリを迅速に構築、テストしていてレーションを回すことができる、分離された開発スペースを提供します。チームの各開発者は、クラウドリソースに接続された使い捨てのサンドボックス環境を使用できます。それでは最初のデプロイを行いましょう。その前に、 backend.ts を次のように更新してください。 import { defineBackend } from "@aws-amplify/backend"; import { auth } from "./auth/resource"; import { data } from "./data/resource"; /** * @see https://docs.amplify.aws/react/build-a-backend/ to add storage, functions, and more */ defineBackend({ auth, }); データリソースをコメントアウトしておくことで、データリソースをデプロイしないでおくこともできます。次のコマンドを実行して、認証用のサンドボックス環境を起動します。 npx ampx sandbox 次のステップはフロントエンドの実装です。これには、 Amplify UI コンポーネント を使用します。Amplify UI とは、アクセシビリティが高く、テーマ設定が可能で、高パフォーマンスなコンポーネントの集合体で、クラウドに直接接続することができます。わずか数行のコードで、複雑なタスクを些細なタスクに変えることができます。 まず、UI ライブラリを使うために必要なライブラリをインストールします。 npm install --force @aws-amplify/ui-react-native aws-amplify @aws-amplify/react-native react-native-safe-area-context @react-native-community/netinfo @react-native-async-storage/async-storage react-native-get-random-values React Native の最新バージョンと UI ライブラリが競合するため、forceフラグを追加しています。 iOS 向けに Pod をインストールして、ネイティブライブラリにライブラリをバインドします。 npx pod-install 次に、 App.tsx 内の App コンポーネントを次のように更新してください: import outputs from "./amplify_outputs.json"; Amplify.configure(outputs); const SignOutButton = () => { const { signOut } = useAuthenticator(); return ( <TouchableOpacity onPress={signOut}> <MaterialIcons name="exit-to-app" size={32} /> </TouchableOpacity> ); }; export default function App() { const [username, setUsername] = useState(""); useEffect(() => { const fetchUsername = async () => { const attributes = await fetchUserAttributes(); const username = attributes.preferred_username ?? ""; setUsername(username); }; fetchUsername(); }, []); return ( <Authenticator.Provider> <Authenticator> <SafeAreaView style={styles.container}> <KeyboardAvoidingView behavior={"height"} style={styles.container}> <View style={styles.header}> <Text style={styles.headerIcon}>✈</Text> <Text style={styles.headerText}>Travel Advisor</Text> <SignOutButton /> </View> </KeyboardAvoidingView> </SafeAreaView> </Authenticator> </Authenticator.Provider> ); } 以下は主な変更点です。 fetchUserAttributes を介して、定義した追加属性を取得しています。 useAuthenticator フックを使用して、signOut ボタンを呼び出しています。 Authenticator コンポーネントと Authenticator.Provider コンポーネントで、認証用の UI を作成し、認証フローを制御します。 認証フローはテストする準備ができました。次のステップは AI 機能を実装することです。 Amplify の新しい AI 機能により、生成 AI を使いやすくなりました。たとえばコンポーネントを生成する場合は、生成機能を使ってみると、どのようになるかを確認できます。 data/resource.ts ファイルを開き、次のように更新してください: import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ generateDestination: a .generation({ aiModel: a.ai.model("Claude 3.5 Sonnet"), systemPrompt: ` You are an advanced travel assistant with comprehensive knowledge about global destinations, including their geography, climate patterns, historical significance, tourist attractions, and cost of living. Your task is to analyze the following information: {{input}} Based solely on this input, determine the single best city on Earth for the user. Your response should be concise and definitive, presenting only the chosen city along with comprehensive information about their geography, climate patterns, historical significance, tourist attractions, and cost of living and why it's the ideal match. Do not ask for additional information or clarification. Provide your recommendation based exclusively on the given details. `, }) .arguments({ input: a.string().required(), }) .returns(a.string().required()) .authorization((allow) => [allow.authenticated()]), }); export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); このおかげで、質問に対する回答を生成できます。 App.tsx ファイルを開き、どこからでも以下のように generateDestination を呼び出せば、目的地を生成できるようになりました。 const { data, errors } = await client.generations.generateDestination({ input: inputText, }); Knowledge Base の作成 (LLM に与える) 情報は、プロンプトの強さに大きく左右されます。また、情報は AI モデルとその特性に関するものです。しかし、Amazon Bedrock Knowledge Base を使えば、プロンプトにさらに情報を与えることができます。 以下のような基本的な Knowledge Base を作成します。 都市 国 人口 説明 金融ハブ 首都？ ランキング 東京 日本 973 万人 東京は日本の首都です。超近代的な高層ビルと歴史的な寺院と庭園が共存しています。独自のポップカルチャー、先進的な技術、そして絶品の料理で知られています。世界最大の魚市場と最も混雑した横断歩道があります。 はい はい 1 イスタンブール トルコ 1,546 万人 イスタンブールはボスポラス海峡に跨っており、ヨーロッパとアジアの境目に位置しています。歴史に富み、ビザンティンとオスマンの建築物が見られます。バザール、ハンマーム、様々な料理で有名です。アヤソフィアとブルーモスクは象徴的な建造物です。 はい いいえ 5 ベルリン ドイツ 370 万人 ベルリンはドイツの首都で、活気ある芸術シーンと現代的な建築物、複雑な歴史で知られています。世界トップクラスの博物館、多様な地区、ベルリンの壁の残骸があります。テクノクラブ、ストリートアート、多文化な料理で有名です。 いいえ はい 2 ニューヨーク アメリカ 880 万人 ニューヨーク市は金融、芸術、文化の世界的ハブです。自由の女神像やエンパイアステートビルなど有名な観光スポットがあります。多様な地区、ブロードウェイの劇場、世界トップクラスの博物館、食の多様性で知られています。植民地時代から現代までの豊かな歴史があります。 はい いいえ 4 プラハ チェコ共和国 130 万人 プラハはチェコ共和国の首都で、「百塔の都市」として知られています。プラハ城やカレル橋など中世の建築物で有名です。ビール文化、クラシック音楽の遺産、よく保存された旧市街広場で名高いです。 いいえ はい 3 Amazon S3 コンソール に移動し、 Create bucket ボタンをクリックします。 バケットに一意の名前を選び、他はデフォルトの選択のままにします。次に、ファイルを S3 バケットにアップロードします。 それでは Knowledge Base を作成しましょう。まず AWS コンソールを開き、 Amazon Bedrock ページへ移動します。ページにアクセスしたら、左側のメニューから Knowledge bases を選択してください。 Create knowledge base ボタンをクリックしてください。すべてのデフォルト値のままにして (S3 が選択されていることを確認) 次へをクリックします。次のページで、S3 バケットからデータソースを選択してください。 データを変換するための埋め込みモデルを選択してください。 お客様に代わって Amazon が Vector Store を作成するか、以前作成したストアを選択して、Bedrock がデータの埋め込みを格納、更新、管理できるようにします。これで Knowledge Base を作成する準備が整いました。 Amazon Bedrock Knowledge Base のデフォルトのセットアップは OpenSearch Serverless で、これは使っていない間もデフォルトのコストがかかります。注意していないと AWS から請求が来るかもしれません。もしこれをテストするだけなら、終了後に必ず OpenSearch Serverless インスタンスをオフにしてください。 既にコンソール上で Knowledge Base をテストし、データが期待通りに動作するかどうかを確認できます。 Knowledge Base をアプリケーションで使用する時が来ました。 作成した Knowledge Base の利用 まず、いくつか片付けをしましょう。 Knowledge Base に対応した会話を作成し、そのデータベースと通信するための AppSync リゾルバーに接続する必要があります。 data/resource.ts ファイルを次のように更新してください。 import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ chat: a .conversation({ aiModel: a.ai.model("Claude 3 Haiku"), systemPrompt: `You are a helpful assistant.`, tools: [ a.ai.dataTool({ name: "DestinationKnowledgeBase", description: "A knowledge base to be checked about everything related to the cities.", query: a.ref("searchDestination"), }), ], }) .authorization((allow) => allow.owner()), searchDestination: a .query() .arguments({ input: a.string() }) .handler( a.handler.custom({ dataSource: "DestinationKnowledgeBaseDataSource", entry: "./bedrockresolver.js", }) ) .returns(a.string()) .authorization((allow) => [allow.authenticated()]), }); export type Schema = ClientSchema; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); これにより、先ほど作成した Knowledge Base がツールとして conversation に追加されます。description は、LLM が Knowledge Base とやり取りするための説明テキストになります。js リゾルバーを追加するには、bedrockresolver.js というファイルを作成し、次のコードを貼り付けてください。 export function request(ctx) { const { input } = ctx.args; return { resourcePath: "/knowledgebases/<knowledge-base-id>/retrieve", method: "POST", params: { headers: { "Content-Type": "application/json", }, body: JSON.stringify({ retrievalQuery: { text: input, }, }), }, }; } export function response(ctx) { return JSON.stringify(ctx.result.body); } これにより、AppSync を通じて会話のコンテキストに指定した ID の Knowledge Base が取得されます。最後に、 backend.ts ファイルの Lambda からデータソースへのポリシーを更新する必要があります。 import { defineBackend } from "@aws-amplify/backend"; import { auth } from "./auth/resource"; import { data } from "./data/resource"; import * as iam from "aws-cdk-lib/aws-iam"; const backend = defineBackend({ auth, data, }); const KnowledgeBaseDataSource = backend.data.resources.graphqlApi.addHttpDataSource( "DestinationKnowledgeBaseDataSource", "https://bedrock-agent-runtime.<region>.amazonaws.com", { authorizationConfig: { signingRegion: "<region>", signingServiceName: "bedrock", }, } ); KnowledgeBaseDataSource.grantPrincipal.addToPrincipalPolicy( new iam.PolicyStatement({ resources: [ "arn:aws:bedrock:<region>:<user-id>:knowledge-base/<knowledge-base-id>", ], actions: ["bedrock:Retrieve"], }) ); 最後に、UI を次のように更新してストリーミングを処理します。 import React, { useEffect, useState } from "react"; import { StyleSheet, Text, View, TextInput, TouchableOpacity, SafeAreaView, KeyboardAvoidingView, FlatList, ActivityIndicator, } from "react-native"; import MaterialIcons from "@expo/vector-icons/MaterialIcons"; import { Authenticator, useAuthenticator } from "@aws-amplify/ui-react-native"; import { fetchUserAttributes } from "aws-amplify/auth"; import { Amplify } from "aws-amplify"; import { Schema } from "./amplify/data/resource"; import { generateClient } from "aws-amplify/data"; import outputs from "./amplify_outputs.json"; import { createAIHooks } from "@aws-amplify/ui-react-ai"; Amplify.configure(outputs); const client = generateClient<Schema>(); const { useAIConversation } = createAIHooks(client); const HomePage = () => { const [username, setUsername] = useState(""); const [inputText, setInputText] = useState(""); const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation("chat"); const handleSend = () => { handleSendMessage({ content: [{ text: inputText }], }); setInputText(""); }; useEffect(() => { const fetchUsername = async () => { const attributes = await fetchUserAttributes(); const fetchedUsername = attributes.preferred_username ?? ""; setUsername(fetchedUsername); }; fetchUsername(); }, []); return ( <SafeAreaView style={styles.container}> <KeyboardAvoidingView behavior={"height"} style={styles.container}> <View style={styles.header}> <Text style={styles.headerIcon}>✈</Text> <Text style={styles.headerText}>Travel Advisor</Text> <TouchableOpacity onPress={() => { const { signOut } = useAuthenticator(); signOut(); }} > <MaterialIcons name="exit-to-app" size={32} /> </TouchableOpacity> </View> <FlatList data={messages} keyExtractor={(message) => message.id} renderItem={({ item }) => item.content .map((content) => content.text) .join("") .trim().length == 0 ? ( <View style={styles.loadingContainer}> <ActivityIndicator /> </View> ) : ( <ChatMessage text={item.content .map((content) => content.text) .join("") .trim()} isUser={item.role == "user"} userName={item.role == "user" ? username : "Travel Advisor"} /> ) } contentContainerStyle={styles.chatContainer} ListEmptyComponent={() => ( <View style={styles.emptyContainer}> <Text style={styles.emptyText}> Start a conversation by sending a message below! </Text> </View> )} /> <View style={styles.inputContainer}> <TextInput style={styles.input} value={inputText} onChangeText={setInputText} placeholder="Describe your dream travel..." multiline={true} numberOfLines={3} /> <TouchableOpacity style={[styles.sendButton, isLoading && styles.sendButtonDisabled]} onPress={handleSend} disabled={isLoading} > <Text style={styles.sendButtonText}>Send</Text> </TouchableOpacity> </View> </KeyboardAvoidingView> </SafeAreaView> ); }; interface Message { text: string; isUser: boolean; userName: string; } const ChatMessage = ({ text, isUser, userName }: Message) => ( <View> <View style={[ styles.messageBubble, isUser ? styles.userMessage : styles.aiMessage, ]} > <Text style={styles.messageText}>{text}</Text> </View> <Text style={[styles.nameText, isUser ? styles.userName : styles.aiName]}> {userName} </Text> </View> ); export default function App() { return ( <Authenticator.Provider> <Authenticator> <HomePage /> </Authenticator> </Authenticator.Provider> ); } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#FFFFFF", }, header: { flexDirection: "row", alignItems: "center", padding: 15, borderBottomWidth: 1, borderBottomColor: "#E0E0E0", }, headerIcon: { fontSize: 24, marginRight: 10, }, headerText: { fontSize: 20, fontWeight: "bold", flex: 1, }, signOutIcon: { fontSize: 24, }, chatContainer: { padding: 10, }, messageBubble: { maxWidth: "80%", padding: 10, borderRadius: 20, marginBottom: 5, }, aiMessage: { alignSelf: "flex-start", backgroundColor: "#F0F0F0", }, userMessage: { alignSelf: "flex-end", backgroundColor: "#DCF8C6", }, messageText: { fontSize: 16, }, nameText: { fontSize: 12, marginBottom: 10, }, userName: { alignSelf: "flex-end", color: "#4CAF50", }, aiName: { alignSelf: "flex-start", color: "#666666", }, inputContainer: { flexDirection: "row", padding: 10, borderTopWidth: 1, borderTopColor: "#E0E0E0", }, input: { flex: 1, backgroundColor: "#F0F0F0", borderRadius: 20, paddingHorizontal: 15, paddingVertical: 10, fontSize: 16, }, sendButton: { backgroundColor: "#4CAF50", paddingHorizontal: 12, borderRadius: 20, justifyContent: "center", alignItems: "center", marginLeft: 10, }, sendButtonDisabled: { backgroundColor: "#A5D6A7", }, sendButtonText: { color: "#FFFFFF", fontSize: 24, }, loadingContainer: { alignSelf: "flex-start", marginBottom: 10, }, loadingText: { fontSize: 24, color: "#666666", }, emptyContainer: { flex: 1, justifyContent: "center", alignItems: "center", height: 500, }, emptyText: { fontSize: 16, color: "#666666", textAlign: "center", }, }); 上記のコードで最も重要な部分は以下の通りです。 const { useAIConversation } = createAIHooks(client); 会話情報を取得し、メッセージを受信・送信するための React フックを作成します const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation("chat"); メッセージを受信し、メッセージを送信します 全体として、このアプリは取得した情報をリアルタイムに取得して、画面に表示します。 サンドボックスを再デプロイすると、アプリケーションが提供された情報を使用して Knowledge Base を呼び出すことがわかります。それではアプリケーションを実行して、その様子を確認しましょう。 クリーンアップ このブログ記事では、Amazon Bedrock Knowledge Base を通して LLM を呼び出す方法を学びました。最後に、次のコマンドを実行して Amplify サンドボックス内のリソースを削除することを忘れずに行ってください。 npx ampx sandbox delete -y また、ベクトルデータベースは高価な場合があるので、アプリケーションのテストが終わったら、必ず Amazon OpenSearch Serverless ダッシュボードからインスタンスを削除してください。 おわりに このブログ記事では、 Knowledge Base の作成方法とアプリケーションでの利用方法を学びました。さらに詳しく知りたい場合は、 AI 入門ガイド をご覧ください。Amplify AI kit の使い方について詳しく説明しています。

2024 年 11 月 29 日、私たちはフルスタックの開発者が会話型検索やチャット、要約などの AI 機能を備えたウェブアプリを構築する最も早い方法である、AWS Amplify AI Kit の一般提供を開始しました。Amplify AI Kit を使えば、クラウドアーキテクチャや機械学習の経験がなくても、フルスタックの生成 AI 機能を構築することができます。リソースのプロビジョニングやセキュアなフロントエンドへのアクセスを心配する必要はなく、すべてがサーバーレスなので迅速なイテレーションが可能で、使った分だけの料金を支払えば済みます。 AWS Amplify では TypeScript を全面採用しており、 Amplify Gen 2 の場合、アプリのクラウドバックエンドのすべての部分が TypeScript で定義されています。認証バックエンド、データバックエンド、ストレージバックエンド、生成 AI 、これら全てを TypeScript で定義することができるのです。 このブログでは、Amplify AI Kit の中身とそれが Amplify および Amazon Bedrock を使って安全なフルスタック AI アプリケーションを構築する作業をどのように簡素化するかについて説明します。すぐに始めたい場合は、 入門ガイド または サンプルリポジトリ をご覧ください。 セットアップ ローカル開発用に セットアップ済みの AWS アカウント が必要で、使用したい Amazon Bedrock の基盤モデルにアクセスできる権限が必要です。 Amazon Bedrock コンソール に移動してアクセス権を要求できます。 フロントエンドのプロジェクトがセットアップされていない場合は、Next.js または Vite を使ってセットアップできます。その後、プロジェクトディレクトリ内で create amplify スクリプトを実行してください。 npm create amplify@latest 次のコマンドを実行すると、TypeScript で書かれたバックエンド定義が含まれる amplify フォルダが作成されます。 npx ampx sandbox これにより、Amplify サンドボックスが起動し、実際の AWS リソースを使ってテストできるクラウド サンドボックス環境が用意されます。 AI 機能の追加 Amplify AI Kit に AI 機能を追加するには、データモデルやカスタムクエリと同様に、Amplify データスキーマに AI ルートを定義します。AI ルートは、バックエンドの AI 機能と対話するための API エンドポイントのようなものです。現在、AI ルートには 2 種類あります。 Conversation: Conversation ルートはリアルタイム、マルチターンの API です。会話とメッセージは自動的に DynamoDB に保存され、応答がリアルタイムにクライアントにストリーミングされます。チャットベースの AI エクスペリエンスや会話型 UI などがこれにあたります。 Generation: シンプルなリクエスト・レスポンス API です。Generation ルートは、定義に従って構造化データを生成する AWS AppSync クエリです。一般的な用途は、非構造化入力から構造化データを生成したり、要約することです。 Amplify のデータリソース定義では、スキーマ定義内で AI ルートを定義できます: import { a, defineData, type ClientSchema } from '@aws-amplify/backend'; const schema = a.schema({ // This will add a new conversation route to your Amplify Data backend. chat: a.conversation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant', }) .authorization((allow) => allow.owner()), // This adds a new generation route to your Amplify Data backend. generateRecipe: a.generation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant that generates recipes.', }) .arguments({ description: a.string(), }) .returns( a.customType({ name: a.string(), ingredients: a.string().array(), instructions: a.string(), }) ) .authorization((allow) => allow.authenticated()), }); export type Schema = ClientSchema; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); ここでは、2 つの AI ルートを作成しています。1 つは ‘chat’ という名前の Conversation ルート、もう 1 つは ‘generateRecipe’ という名前の Generation ルートです。コードを 1 ステップずつ見ていきましょう。 chat: a.conversation({ ここでは新しい「chat」という Conversation ルートを作成しています。ルートの名前は任意に付けられ、定義できる AI ルートの数の制限は、AWS AppSync スキーマのサイズの制限のみです。 aiModel: a.ai.model('Claude 3.5 Sonnet'), 次に、使用したい大規模言語モデル (LLM) を定義します。Amplify AI Kit は、ツール使用とストリーミングをサポートする Bedrock の任意の LLM をサポートしています。ここでは、Anthropic の Claude 3.5 Sonnet モデルを使用しています。 systemPrompt: 'You are a helpful assistant', システムプロンプトは、LLM に対して、その役割と応答の仕方を指示します。 .authorization((allow) => allow.owner()), Amplify Data には組み込みの認証方式があります。Conversation ルートの場合、特定の会話の所有者のみがアクセスできるようにしたいと思います。つまり、ユーザーは他のユーザーの会話履歴にアクセスできません。 generateRecipe: a.generation({ ここでは、generateRecipe と呼ばれる Generation ルートを作成しています。Generation は、入力に基づいて特定の型のデータを生成したい場合に使用する同期リクエスト/レスポンス API です。 .arguments({ description: a.string(), }) これにより、クライアントがレスポンスを受け取るためにどのような入力型を送る必要があるかを定義します。 .returns( a.customType({ name: a.string(), ingredients: a.string().array(), instructions: a.string(), }) ) これが生成したいデータの出力形式です。 Conversation と Generation のルートが定義できたので、Amplify クライアントライブラリで接続できます。 リアルタイム更新機能付きの型安全クライアント Amplify では、フルスタックアプリケーションのコードベースの中にある amplify フォルダにバックエンドリソースを定義します。これによって、データスキーマとフロントエンドクライアントが型を共有できるので、データスキーマと常に同期する型安全なクライアントを手に入れることができます。 import { generateClient } from "aws-amplify/api"; import type { Schema } from "../amplify/data/resource"; const client = generateClient(); // new generations / conversations namespace client.generations.generateRecipe({ }); // type-safe based on schema client.conversations.chat.create(); Amplify AI Kit には、React フックも含まれているので、ネットワーク要求や UI の状態を管理する心配はいりません。UI にフックするだけで、リアルタイム、セキュア、永続的な生成 AI との会話を利用できます。 import { generateClient } from "aws-amplify/api"; import { Schema } from "../amplify/data/resource"; import { createAIHooks } from "@aws-amplify/ui-react-ai"; const client = generateClient(); const { useAIGeneration, useAIConversation } = createAIHooks(client); function Chat() { const [ { data: { messages }, isLoading, hasError, }, sendMessage, ] = useAIConversation('chat'); //... } function RecipeGenerator() { const [ { data, isLoading }, handleGenerate] = useAIGeneration('generateRecipe'); //... } 生成 AI をデータとして活用 データに適切なアクセスができることは、意味のある生成 AI 機能を構築するために重要であり、私たちはデータを LLM に接続することをできるだけ簡単にしたいと考えました。Amplify では、データモデルを厳密に型付けされたスキーマで定義し、生成 AI 機能を追加することは、データモデルやカスタムクエリを追加するのと同じくらい簡単です。TypeScript でデータモデルとクエリの形状を定義しているため、Amplify AI Kit は、Bedrock の LLM がアクセスできるデータとそのアクセス方法を正確に知ることができるように、必要な部分をフックアップします。さらに、データスキーマで定義されたアクセス制御により、LLM はエンドユーザーがアクセスできるデータにのみアクセスできます。すべてのデータリクエストは、クライアントからのリクエストでも LLM からのデータリクエストでも、AWS AppSync を経由します。 「Post」というデータモデルを持つアプリケーションがあると仮定します。このデータにアクセスするには、Conversation ルートにツールを使用します。 import { a, defineData, type ClientSchema } from '@aws-amplify/backend'; const schema = a.schema({ Post: a.model({ title: a.string(), body: a.string() }) .authorization((allow) => allow.owner()), chat: a.conversation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant', // This allows the LLM to query for your data tools: [ a.ai.dataTool({ name: 'PostQuery', description: 'Searches for Post records', model: a.ref('Post'), modelOperation: 'list', }), ] }) .authorization((allow) => allow.owner()), //... }); このコードを分解しましょう。 tools: [ ツールは、LLM がデータを照会し、アクションを実行する手段です。Amplify AI Kit は、LLM へのリクエストでインプットを記述し、ツールの呼び出しと LLM への結果の送信を処理します。 a.ai.dataTool({ name: 'PostQuery', description: 'Searches for Post records', model: a.ref('Post'), modelOperation: 'list', }), LLM にスキーマで定義したデータモデルへのアクセスを提供できます。これにより、LLM はデータモデルの属性に基づいてレコードを照会できます。さらに所有者ベースの承認では、LLM はユーザーが作成したレコードにのみアクセスできます。LLM に カスタムクエリ の呼び出しも許可できます! サーバーレス AI アーキテクチャ Amplify AI スタックはフルマネージドのサーバーレスです。すばやくスピンアップでき、 Amplify サンドボックス を使えば、バックエンドのコードを反復しながら更新を実際のクラウド環境で確認できます。Amplify のサンドボックスを使うと、クラウドリソースにローカル開発環境を作れます。機能開発時にフロントエンドとバックエンドを同時に更新できるので、開発の分断なくエンドツーエンドの機能構築ができます。デプロイする準備ができたら、Amplify Hosting にブランチをプッシュすると、バックエンドとフロントエンドが同時にデプロイされます。 Amplify AI kit architecture AWS AppSync API: クライアントと安全にリアルタイム接続するための AI ゲートウェイ。AppSync API はハブとして機能し、すべてのデータリクエスト (クライアントまたは LLM からのリクエスト) が AppSync を通過します。 Lambda 関数: AppSync と Amazon Bedrock の間の橋渡し役。会話履歴を取得し、Bedrock のストリーミング会話 API を呼び出し、AppSync クエリに基づきツールの呼び出しをハンドリングします。 DynamoDB: 特定のアプリケーションユーザーに対する会話履歴とメッセージデータを保存します。 Generative UI の紹介 Amplify AI Kit でもう 1 つ行いたかったことは、生成 UI を構築することを簡単にすることでした。AI アシスタントが、テキストのみならず、カスタム UI コンポーネントで応答できるようにすることです。これにより、より豊かな体験が可能になり、会話型検索などの構築が可能になります。 Amplify AI Kit には、 <AIConversation /> React コンポーネントと useAIConversation React フックが用意されており、カスタマイズ可能なインターフェースを AI ルートで簡単に構築できます。このコンポーネントには、AI アシスタントが応答可能な responseComponents (コードで定義した React コンポーネント) を指定できます。コンポーネントの説明と props を定義すれば、Amplify AI Kit が残りの処理を行います。 function Chat() { const [ { data: { messages }, isLoading, }, sendMessage, ] = useAIConversation('chat'); return ( { return { city }; }, props: { city: { type: 'string', required: true, }, }, }, }} /> ); } 本番環境への移行 本番環境に移行する準備ができたら、Amplify コンソールで Git リポジトリを追加できます。ブランチにコードを push すると、フルスタックアプリケーション用の完全な継続的デプロイメントパイプラインが実行されます。アプリケーションが公開されると、アプリケーション内で会話データを確認できます。 クリーンアップ Amplify サンドボックスコマンドは ctrl + c で終了できます。その後、 npx ampx sandbox delete コマンドでクラウドサンドボックスリソースを削除できます。 まとめ 私たちは、Amplify AI Kit でみなさんが何を構築するのか非常に楽しみにしており、みなさんからのフィードバックを心待ちにしています。この 1 週間、毎日新しい記事を投稿し、Amplify AI Kit の異なる機能を紹介していきます。Amplify AI Kit の使用開始方法の詳細については、 docs.amplify.aws/ai をご覧ください。 問題がある場合は、 GitHub リポジトリ でお問い合わせいただくか、私たちのコミュニティ Discord で質問してください。 本記事は「 Build fullstack AI apps in minutes with the new Amplify AI Kit 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

フロントエンドの開発者は、アプリで永続的な会話型 AI チャット体験を開発するとき、しばしば複雑な API、複雑なリアルタイム UI の更新、設定が難しいアクセス許可を扱う必要があります。それに加えて、複雑なクラウド インフラストラクチャをセットアップしなければなりません。そういった理由から、私たちは AWS Amplify AI Kit とその会話型チャット体験をご紹介できて、大変嬉しいです。 わずか数行のコードで、TypeScript を使って会話型チャットを自分のフロントエンドアプリケーションに追加することができます。複雑なクラウド設定や追加の権限は必要ありません。作成したチャットには、さまざまな Amazon Bedrock モデルの 1 つを接続できます。それぞれのチャットに対して、お客様のユーザーアカウントに関連付けられた永続的な会話履歴が保持されます。また、アプリケーションのニーズに合わせてチャット体験をカスタマイズすることができます。 この機能は、バックエンドにルーティングする新しい conversation API によって動作します。Amazon Bedrock で動作する大規模言語モデル (LLM) を指定したり、お客様のニーズに合わせてカスタマイズしたシステムプロンプトを作成したりするオプションが用意されています。オプションとして、Amplify はツールの使用に対応しており、外部データや機能と対話して、必要に応じて正確に応答できるようになっています。 フロントエンドの Amplify では、 AIConversation コンポーネントと useAIConversation React フックを提供する新しい UI ライブラリがリリースされました。これらの API は、最小限の構成で React アプリケーションにドロップインすると、お客様が対話を開始できるチャット ウィンドウを表示できます。そのうえで、アプリケーションのルックアンドフィールに合わせてカスタマイズを行うこともできます。たとえば、アバター、表示テキスト、添付ファイルの許可、特定のレスポンス用コンポーネントの作成などができます。 このチュートリアルでは、アプリケーションに会話ルートを追加し、カスタマイズする方法を説明します。 前提条件 以下の手順を始める前に、アプリケーション内で AWS Amplify Gen 2 をセットアップする必要があります。これはアプリケーションのルートで create コマンドを実行するだけで簡単に行えます。 npm create amplify@latest これにより、プロジェクトのルートに新しい amplify フォルダが作成され、そこでバックエンドリソースを定義することができます。続行する前に、使用したい Amazon Bedrock モデル を有効にしてください。このチュートリアルでは、Claude 3 Haiku を使用します。さらに、必要に応じて、 ローカル開発用に AWS を設定する ことで、 クラウドサンドボックス環境 でローカルでテストができるようになります。 まだ Amplify AI Kit についてご覧になられていない方は 発表時のブログ記事 をご覧ください。この記事で紹介された機能のすべての使用例と、その他の例を見たい方は、 Amplify AI サンプルリポジトリ をご覧ください。 Conversation ルートの追加 Amplify AI Kit は、Amplify Data の規約に基づいています。この規約に従うことで、シンプルな TypeScript 対応の構文を使って、任意のデータソースに接続するためのデータモデルを作成できます。今回は、 data/resource.ts ファイルのスキーマ定義にある新しい a.conversation API を使用して、チャット会話のルートを構築します。 まず初めに、データリソースファイルに追加し、 chat という新しい会話を作成しましょう。 // data/resource.ts import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ chat: a.conversation({ aiModel: a.ai.model("Claude 3 Haiku"), systemPrompt: "You are a travel advisor app. You help travelers find locations.", }).authorization(allow => allow.owner()), }); export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); Conversation API を利用するユーザーは認証が必要です。これはデフォルトで変更できません。慣例として、AWS Amplify Gen 2 を設定する際には、 auth カテゴリ を介して Amazon Cognito User Pool が作成されます。自分でテストする場合は、フロントエンドを Authenticator コンポーネントでセットアップすることをお勧めします。このコンポーネントは Amplify auth カテゴリを利用し、数行のコードでサインイン/サインアウトの UI を提供します。 チャットをセットアップする上で最も重要な部分の 1 つは、 aiModel と systemPrompt を定義することです。 aiModel には Claude 3 Haiku を選択しました。これは最新の Anthropic Claude 3 モデルの 1 つで、ユーザーからの質問に対応するための LLM として機能します。Claude 3 Opus、Claude 3 Haiku、Cohere、LLama、Mistral など、選択可能な複数のモデルがローンチ時に提供されています。 システムプロンプトは、LLM に期待する動作を定義します。この記事では、プロンプトをシンプルにしていますが、使用ケースによっては、より簡潔なプロンプトを試してみる価値があるかもしれません。Few-Shot プロンプティングなどの他の プロンプト 戦略を検討することで、より良い結果が得られる可能性があります。 オプションで、モデルの token 、 temperature 、 top P を設定するための inferenceConfiguration を追加できます。別のオプションとしてツールを追加することができます。ツールの利用は、関数呼び出しとも呼ばれ、対応するモデルが外部の関数やデータと対話できるようにします。たとえば、Amazon Bedrock Knowledge Base で検索拡張生成 (RAG) を使用したい場合は、カスタムリゾルバーでリソースファイルに追加することができます。このような例については、今後の記事でご紹介します。 ルートにある amplify フォルダ内の backend.ts ファイルは、この Conversation API を追加するための他の追加設定は必要ありません。新規プロジェクトから開始する場合、 data が defineBackend 関数呼び出しにインポートされます。さらなる IAM ポリシーの更新は必要ありません。裏側では、AWS AppSync リゾルバを構築し、Amazon Bedrock と直接やり取りする AWS Lambda 関数を作成するための AWS Cloud Development Kit (CDK) コードが生成されます。Amplify は必要な IAM ポリシーも作成し、ユーザーアカウントごとに会話履歴を永続化するための Amazon DynamoDB のデータソースを設定します。 ローカルでのクラウドサンドボックステスト 同じようにコードを実行したい場合は、アプリケーションのルートで npx ampx sandbox コマンドを実行してローカルでテストできます。このコマンドは amplify フォルダを読み込み、テスト環境としてクラウドリソースをプロビジョニングします。 フロントエンドの更新 バックエンドの定義が完了したので、次にフロントエンドのコードを追加します。Vite または Next.js で React アプリケーションを使用していると仮定します。 npm i @aws-amplify/ui-react-ai この ライブラリには、Amplify の新しい AI コンポーネントを使用するために必要なすべてが含まれています。 新しい Chat.tsx コンポーネントを作成し、次のコードを追加してください。 import { Avatar, View } from "@aws-amplify/ui-react"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} avatars={{ user: { avatar: <Avatar src="erik.jpg" />, username: "Erik", }, ai: { avatar: <Avatar src="robot.jpg" />, username: "🤖", }, }} /> この新しいコンポーネントをアプリのエントリポイントファイルに追加します。テストする際は、ユーザーがすでにサインインしていることを確認してください。また、アプリケーションを Authenticator コンポーネントでラップすることをお勧めします。これにより、ユーザーがチャットにアクセスする前にサインインしてアカウントを作成する必要があります。 メインエントリをロードすると、使用可能なシンプルなチャットインターフェースが表示されます。 複数のチャット会話を追加する方法が気になるところでしょう。 useAIConversation フックを詳しく見て、オプションの id を追加しましょう。 const [ { data: { messages }, isLoading, }, sendMessage, ] = useAIConversation("chat", { id: "123" }); デフォルトでは、ユーザーは 1 つのチャットのみ持っています。 id を追加することで、その ID に基づいて、ユーザーごとに複数の個別のチャットを作成できます。各チャットは、システムにログインしているユーザーに紐付けられます。いつでも generateClient API を使用して、会話を取得、削除、あるいは更新できます。設定方法の完全な例については、 Amplify AI Examples リポジトリをご覧ください。 チャット体験のカスタマイズ AIConversation コンポーネントには、ユーザーへのチャット体験をカスタマイズするためのいくつかのプロパティがあります。ユーザー体験を向上させるためのいくつかのカスタマイズを見てみましょう。 アバターの更新 会話型チャットでは、ユーザーのアバターを表示することをしばしば求められますが、 avatars を設定することで設定できます。 import { Avatar, View } from "@aws-amplify/ui-react"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} avatars={{ user: { avatar: <Avatar src="erik.jpg" />, username: "Erik", }, ai: { avatar: <Avatar src="robot.jpg" />, username: "🤖", }, }} /> avatars は user と ai オブジェクトを取ります。チャットでそれぞれに表示されるアバターとユーザー名を定義できます。この例では、 @aws-amplify/ui-react ライブラリからの Avatar コンポーネントを使用して画像を表示しています。AI に関しては、名前を絵文字に変え、新しいアバターを指定しています。 レスポンスコンポーネント response component を使うと、開発者は LLM から返された応答メッセージに基づいてカスタム応答を作成できます。アプリ開発者はコンポーネントを作成し、 responseComponents プロップに追加することで、これらのメッセージの出力を定義できます。たとえば、ユーザが休暇地についての情報を求めた場合、チャットはカスタムの場所カードに名前と説明を表示できます。 以下のコードでは、ユーザー向けのカードを作成するために LocationCard コンポーネントが使用されています。 import { LocationCard } from './LocationCard.tsx'; ... <AIConversation messages={messages} handleSendMessage={sendMessage} responseComponents={{ LocationCard: { description: "Used to display a location to the user", component: LocationCard, props: { name: { type: "string", description: "The name of the location", }, description: { type: "string", description: "The description of the location", }, }, }, }} /> この例では、地名と説明を整えられたカードに表示しています。 responseComponents プロパティは、ツールを介して会話ルートに接続された外部 API でも動作します。 添付ファイルの許可 必要に応じて、チャットウィンドウ内に直接ファイルを添付できます。この機能を有効にするには、ファイルを受け付ける LLM を使用する必要があります。この機能を有効にするには、 allowAttachments を追加してください。 <AIConversation messages={messages} handleSendMessage={sendMessage} allowAttachments /> この allowAttachments を追加すると、チャットウィンドウの下部にファイルを添付するボタンが表示されるようになります。 アップロードした全ての画像は Amazon DynamoDB に保存されますので、ご注意ください。上限は 400KB なので、400KB 以下の画像のみ追加できます。画像を添付したら、その画像に関する質問をし、LLM による回答を得ることができます。 メッセージレンダラ message renderer プロパティはテキスト出力のフォーマットを指定します。たとえば、出力を Markdown で表示したい場合を想像してください。ほとんどの LLM がマークダウンをサポートしているので、会話のメッセージでマークダウンを利用できると便利です。これは、 react-markdown ライブラリをインストールし、 ReactMarkdown コンポーネントを使用して、全ての出力を適切にフォーマットできます。 import ReactMarkdown from "react-markdown"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} messageRenderer={{ text: ({ text }) => <ReactMarkdown>{text}</ReactMarkdown>, }} /> react-markdown を rehypeHighlight のような他のプラグインと組み合わせると、追加のコードハイライト機能が使えます。 これは、 messageRenderer でコードのテキストを表示するために、 rehypeHighlight プラグインを使用しているチャットの例です。 クリーンアップ サンドボックスを実行中の場合は、次のコマンドをターミナルで実行すると、サンドボックスとそれに作成された全てのバックエンドインフラストラクチャを削除できます。 npx ampx sandbox delete 次のステップ この記事では、Amplify AI Kit を使用してアプリケーションにセキュアな会話型チャットを追加する方法を見てきました。ユーザー向けにカスタムチャット体験を作成するために、新しい Amplify AI UI ライブラリを追加するのがいかに簡単かを確認しました。さらに、レスポンスコンポーネント、アバター、メッセージレンダラを使用してユーザー体験をさらに向上させることができることも確認しました。 詳しく学びたい方は、 AI のスタートガイド をご覧ください。Amplify AI Kit の使い方を詳しく説明しています。また Discord チャンネル に参加して、直接質問することもできます。 本記事は「 Create a Customized AI-Based Chat Interface With Your Application Data 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify Hosting は、開発者が Web アプリケーションを保護し、さらにセキュリティを強化できる新しいファイアウォール機能を発表しました。これは AWS WAF との直接統合であり、開発者は Amplify Hosting にホストされたアプリケーションに Web ACL を直接 追加することができます。Web アプリケーションファイアウォールは、一般的な Web 攻撃からアプリケーションを保護し、セキュリティを強化し、コンプライアンスを確保するためには必要不可欠です。IP の許可/ブロック、地理的制限、Bot からの保護などの機能があります。WAF を提供することで、Amplify のお客様はアプリケーションのセキュリティ保護を大幅に向上させ、リスクを軽減し、データとユーザーエクスペリエンスの完全性を維持できます。 AWS WAF は、Webアクセスコントロールリスト（Web ACL）と呼ばれる一連のルールを設定できるサービスであり、お客様が定義したカスタマイズ可能な Web セキュリティルールと条件に基づいて、Web リクエストを許可、ブロック、または監視（カウント）することができます。Amplify Hosting と AWS WAF を統合することで、トラフィックをさらに制御できるようになります。AWS WAF の詳細については、開発者ガイドの AWS WAF の動作方法 をご覧ください。 AWS WAF を初めて利用する場合でも Amplify Hosting では開発者が簡単に設定できるようになっています。 IP アドレス 許可/ブロック – 指定の IP アドレス範囲からのリクエストを許可または拒否することで、Web トラフィックを制限します 地理的制限 – 特定の国からのアクセスを許可または拒否します ファイアウォール保護 – Web アプリケーションで最も一般的に見られる脆弱性から保護するための一般的なファイアウォール保護、Amazon の内部の脅威インテリジェンスに基づく潜在的な脅威からの IP アドレスブロック、および悪意のあるアクターがアプリケーションの脆弱性を発見するのを防ぐ保護 Amplify URL の無効化 – デフォルトの Amplify で生成された amplifyapp.com ドメインへのアクセスを制限します (カスタムドメインを追加した後、Bot と検索エンジンがそのドメインをクロールするのを防ぐのに便利です) Amplify コンソールで有効化された保護は、お客様の AWS アカウント内の Web ACL に適用されます。細かいルールセットが必要な場合、開発者は WAF コンソールのルールビルダーを活用できます。 スタートガイド アプリに WAF を関連付ける手順については、 ドキュメント を参照してください。 可用性と価格 ファイアウォールのサポートは、Amplify Hosting が運用されているすべての AWS リージョンで、プレビュー版としてリリースされています ( オプトインリージョンを除く )。この統合は、CloudFront と同様のグローバルリソースの WAF に分類されます。Web ACL は複数の Amplify Hosting アプリにアタッチできますが、同じリージョン内に存在する必要があります。 プレビュー中は、AWS WAF の利用料金のみが発生します。AWS WAF は Web ACL ごとに $ 5/月、ルールごとに $ 1 を請求するほか、他の課金もあります。詳細は WAF の料金 をご覧ください。1 つの Web ACL と 2 つのルールを想定すると、この統合で最低でも $ 7 の課金が発生します。 さらに、Amplify ファイアウォール 機能を利用するには、新しい Amplify Hosting の上位プランへの加入が必要になります。この上位プランには、リリース時にほかの機能も含まれます。プレビュー期間中に Amplify ファイアウォールを有効にすると、この上位プランに自動的に加入しますが、Amplify ファイアウォール機能が一般提供されるまでは追加料金はかかりません。いつでも Amplify ファイアウォールを削除すれば、一般提供後も料金が請求されることはありません。この上位プランの具体的な価格は一般提供時にお知らせします。コミットメントも前払い投資も不要です。 次のステップ アプリにファイアウォール保護を設定するには、 AWS Amplify コンソール にアクセスしてください。 本記事は「 AWS Amplify Hosting Adds Web Application Firewall Protection – Public Preview 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。最近「 三菱電機グループエンジニアが作る新しい風 “Mitsubishi Electric AWS User Group (通称: MAWS-UG)” の軌跡 」を執筆しました。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

本記事は 2025 年 1 月 14 日に公開された “ Effortlessly execute AWS CLI commands using natural language with Amazon Q Developer ” を翻訳したものです。 CLI のつらみ コマンドラインツールは、インフラストラクチャや DevOps のワークフローを簡素化するためのものですが、実際には逆効果になることが多くあります。作業の効率化を図るはずが、膨大な数のコマンド、フラグ、構文により、CLI はまるでパズルのように感じられることがあります。生産性を向上させるためのツールのはずが、基本的なコマンドを見つけるためだけに、検索やフォーラム、ドキュメントをひたすら行き来する羽目になっています。 CLI の習得は、新しい言語を学ぶのと同様に、複雑で馴染みのない構文を理解する必要があります。現実世界ではコミュニケーションギャップを埋めるために翻訳者の助けを借りますが、これからは Amazon Q Developer があなたと CLI の翻訳者になってくれます！ この記事では、コマンドライン上での Amazon Q Developer のセットアップ方法を解説し、Amazon Q Developer が複雑なタスクをいかに簡単にしてくれるかをご紹介します。 はじめ方 スムーズに記事を読み進めるために、 AWS CLI がインストールされ、設定が完了している ことを確認してください。 CLI で Amazon Q Developer を使用するには、まず Amazon Q をインストール する必要があります。現在、Amazon Q の CLI 機能は macOS と Linux ユーザーのみが利用可能です。適切なプラットフォームを使用していることを確認してください。 Amazon Q Developer を使用するには、 AWS Builder ID を持っているか、 AWS IAM Identity Center インスタンスが設定された組織に所属している必要があります。 この記事では Amazon S3 と Amazon CloudFront を使用するため、AWS アカウントに必要な権限があることを確認してください: s3:CreateBucket s3:PutObject s3:PutBucketPolicy cloudfront:CreateDistribution cloudfront:CreateOriginAccessControl cloudfront:GetDistributionConfig cloudfront:UpdateDistribution ここまでの手順を完了すれば、Amazon Q Developer がどのようにして CLI ワークフローを簡素化できるのかを確認する準備が整います。それでは、始めていきましょう。 CLI 体験の変革 新しいターミナルウィンドウを開き、 q translate と入力し、続けて複雑なコマンドを実行するための自然言語プロンプトを入力します。Amazon Q Developer は入力を受け取り、Large Language Model (LLM) を通して処理し、対応する bash コマンドを生成します。 まずはシンプルで楽しい作業から始めてみましょう。ターミナルで10秒からカウントダウンしてみましょう: q translate "Count down from 10 second by second" (※Count down from 10 second by second : 訳者注: 10から1秒ずつカウントダウンして) コマンドを実行すると、Amazon Q が実行可能なシェルコマンドといくつかのアクション項目を提案します: Execute command: 提案されたコマンドをすぐに実行 Edit command: 提案されたコマンドを編集 Regenerate answer: 別のコマンドを提案 Ask another question: 新しいプロンプトを入力 Cancel: セッションを終了 ここではコマンドを実行して、その動作を確認してみましょう: AWS の CLI からウェブサイトを構築する 基本的な操作を理解したところで、実践的な作業に取り組んでみましょう。このチュートリアルでは、コマンドラインだけを使用して、AWS 上で静的ウェブサイトをホスティングする方法を説明します。 Step 1: ウェブサイトをホストする S3 バケットを作成する Amazon S3 は静的ウェブサイトのホスティングに最適です。まず、ウェブサイトのコンテンツファイルを保存する S3 バケットを作成する必要があります。Amazon Q Developer に「us-west-2 に ‘ai-generated-bucket’ という名前の S3 バケットを作成」するように指示するだけです: q translate "Create an S3 bucket called 'ai-generated-bucket' on us-west-2" (※Create an S3 bucket called ‘ai-generated-bucket’ on us-west-2 ：訳者注: ‘ai-generated-bucket’というS3バケットを us-west-2 に作って) 注：同じ名前のバケットがすでに存在する場合は、別の名前に変更してください。 Amazon Q Developer が正しくコマンドを生成したことが確認できます: aws s3 mb s3://ai-generated-bucket --region us-west-2 コマンドの内容が適切でない場合は、「Edit command」または「Regenerate answer」を試すことができます。ここでは、生成されたコマンドを実行し、 Amazon S3 コンソール で S3 バケットが実際に作成されたことを確認します。 Step 2: “Hello World” と書かれた HTML ファイルを作る 次に、基本的な HTML ファイルをバケットにアップロードする必要があります。手動で記述する代わりに、Amazon Q Developer に案内してもらいましょう。プロンプトはこちら: q translate "Create a simple index.html file with 'Hello World' message" (※Create a simple index.html file with ‘Hello World’ message：訳者注: ‘Hello World’ と書かれたシンプルな index.html ファイルを作って) Amazon Q Developer が提案した echo '<h1>Hello World</h1>' > index.html というコマンドは適切そうです。このコマンドを実行してみましょう。 Step 3: HTMLファイルを S3 にアップロードする では、 index.html ファイルを S3 バケットにアップロードしましょう: q translate "Upload index.html to the 'ai-generated-bucket' S3 bucket" (※Upload index.html to the ‘ai-generated-bucket’ S3 bucket：訳者注: index.html ファイルを ‘ai-generated-bucket’ にアップロードして) コマンドを実行したら、 Amazon S3 コンソール で index.html ファイルがバケットに正常にアップロードされたことを確認できます。 Step 4: CloudFront ディストリビューションを設定する デフォルトでは、Amazon S3 はアカウントとバケットへのパブリックアクセスをブロックします。本番環境での使用では、パブリックアクセスのブロックを有効にしたまま、 Amazon CloudFront を通じてサイトを安全に提供することをお勧めします。 Amazon CloudFront は、コンテンツを低レイテンシーと高速な転送速度で安全に配信するグローバルなコンテンツ配信ネットワーク（CDN）であり、静的ウェブサイトのホスティングに最適です。 Amazon Q Developer を使用して、 S3 バケット用の CloudFront ディストリビューションを作成しましょう: q translate "Create a CloudFront distribution for my S3 bucket 'ai-generated-bucket'" (※Create a CloudFront distribution for my S3 bucket ‘ai-generated-bucket’: 訳者注: ‘ai-generated-bucket’ のための CloudFront ディストリビューションを作って) うーん、これは正しくないようですね。 Amazon Q Developer は、指定されていない設定ファイルで --distribution-config を提供しようとしています。これを修正するには、CloudFront ディストリビューションの設定を手動で提供するか、Amazon Q Developer の力を最大限活用するかを選ぶことができます。 より適切な結果を得るために、 --distribution-config フラグを使用しないようにプロンプトを改善してみましょう: q translate "Create a CloudFront distribution for my S3 bucket 'ai-generated-bucket' without using the ‘—distribution-config' flag" (※Create a CloudFront distribution for my S3 bucket ‘ai-generated-bucket’ without using the ‘–distribution-config’ flag: 訳者注: ‘ai-generated-bucket’ のための CloudFront ディストリビューションを ‘—distribution-config’ のフラグを使わずに作って) ずっと良くなりました！ ‘X’ を実際のオリジンドメイン名に置き換える必要があるようです。この場合、S3 バケットのオリジンは以下の形式を使用します: bucket-name.s3.amazonaws.com CLI で「 Edit command 」オプションを選択し、 ‘X’ を置き換えてください。この場合、置き換える値は ai-generated-bucket.s3.amazonaws.com となります。コマンドを実行すると、成功時にコンソールに CloudFront の設定が表示されるはずです: 出力から “Id” をコピーしてください。次のステップで必要になります。 Step 5: パブリックアクセスの準備をする 作成した CloudFront ディストリビューションのデフォルトルートオブジェクトとして index.html を設定します。これにより、ユーザーがウェブサイトのルート URL にアクセスする際、URL で明示的に指定しなくても CloudFront が自動的に index.html ファイルを提供するようになります。 q translate "Update my CloudFront distribution CLOUDFRONT_ID to have 'index.html' as default root object without using the --distribution-config flag" (※Update my CloudFront distribution CLOUDFRONT_ID to have ‘index.html’ as default root object without using the —distribution-config flag: 訳者注: ‘—distribution-config’ フラグを使用せずに、 CloudFront ディストリビューション CLOUDFRONT_ID のデフォルトルートオブジェクトを ‘index.html’ に更新して) 前のステップで取得した Id で CLOUDFRONT_ID を置き換えることを忘れないでください。コマンドを実行すると、先ほどのステップと同様に、コンソールに CloudFront の設定が表示されるはずです。 次に、 HTML ファイルを安全に公開するために、以下の作業を行う必要があります: Origin Access Control (OAC) の設定 その OAC を CloudFront ディストリビューションに設定 S3 バケットポリシーの更新 まずは Amazon Q に OAC を生成してもらいましょう: q translate "Create an OAC named 'ai-generated-oac' for my CloudFront distribution CLOUDFRONT_ID" (※Create an OAC named ‘ai-generated-oac’ for my CloudFront distribution CLOUDFRONT_ID: 訳者注: CloudFront ディストリビューション CLOUDFRONT_ID 用に ‘ai-generated-oac’ という名前の OAC を作成して) コマンドを実行すると、以下のようなエラーが表示されます: An error occurred (MalformedXML) when calling the CreateOriginAccessControl operation: 1 validation error detected: Value 'origin-access-identity' at 'originAccessControlConfig.originAccessControlOriginType' failed to satisfy constraint: Member must satisfy enum value set: [s3, lambda, mediastore, mediapackagev2] このエラーメッセージをインターネットに頼らずにデバッグするのは難しいかもしれません。幸いなことに、Amazon Q Developer には q chat という、ターミナル上のチャットボットのような強力な機能があります。これを使ってトラブルシューティングを試してみましょう: q chat "@history An error occurred (MalformedXML) when calling the CreateOriginAccessControl operation: 1 validation error detected: Value 'origin-access-identity' at 'originAccessControlConfig.originAccessControlOriginType' failed to satisfy constraint: Member must satisfy enum value set: [s3, lambda, mediastore, mediapackagev2]. Help me resolve this error" (※ Help me resolve this error : 訳者注: このエラーの解決方法を教えて) プロンプトに @history を含めることで、シェルの履歴を Amazon Q に渡し、提供されたコンテキストに基づいて応答できるようになります。 ターミナル上で、ステップバイステップの手順と出典を含む詳細な AI 生成の応答が得られました！ @history タグを使用することで、 Amazon Q Developer はエラーメッセージを実行した正しいシェルコマンドに関連付けることができます（私たちが明示的に伝えなくても、 ai-generated-oac という名前で OAC を作成しようとしていることを理解しています）。 修正された bash コマンドを実行してみましょう: aws cloudfront create-origin-access-control \     --origin-access-control-config \     Name=ai-generated-oac,\     OriginAccessControlOriginType=s3,\     SigningBehavior=always,\     SigningProtocol=sigv4 今回は成功しました: Id フィールドをメモしておいてください。後で必要になります。 次に、生成された OAC を CloudFront ディストリビューションに設定する方法について、 q chat に尋ねてみましょう: q chat "@history Update my CloudFront distribution CLOUDFRONT_ID with the OAC we just generated, be specific" (※Update my CloudFront distribution CLOUDFRONT_ID with the OAC we just generated, be specific: 訳者注: 先ほど生成した OAC を使用して、CloudFront ディストリビューション CLOUDFRONT_ID を設定して、具体的に説明して) @history を使用することで、 Amazon Q が自動的に CLOUDFRONT_ID を補完してくれることに注目してください！ 指示に従って最後のステップを完了すれば、コンソールの出力に更新された CloudFront ディストリビューションが表示されるはずです: “Status” が “InProgress” と表示されています。次のステップに進むには、CloudFront のデプロイメントが完了するまで待つ必要があります。最新のステータスを取得する方法を Amazon Q Developer に尋ねてみましょう: q translate "Get the status of my CloudFront distribution with CLOUDFRONT_ID on us-west-2" (※Get the status of my CloudFront distribution with CLOUDFRONT_ID on us-west-2: 訳者注: us-west-2 で CLOUDFRONT_ID を持つ CloudFront ディストリビューションのステータスを取得して) $CLOUDFRONT_ID を実際のものに置き換えてコマンドを実行し、最新のステータスを確認しましょう。完了までに数分かかる可能性があるので、コーヒーを飲んだり、短い散歩に行ったりするのにちょうど良い時間です！ ステータスが Deployed になったら、 CloudFront ディストリビューションにパブリック読み取りアクセスを許可するように S3 バケットポリシーを更新できます: プロンプトはかなりあいまいなものを使用していますが、 @history のおかげで Amazon Q は役立つレスポンスを生成するのに十分なコンテキストを持つことができました。 指示に従うだけで、サイトにアクセスする準備が整います！ Step 6: サイトにアクセスする CloudFront ディストリビューションのパブリック URL を取得しましょう。 q translate "Get the public url of my CloudFront distribution CLOUDFRONT_ID" (※Get the public url of my CloudFront distribution CLOUDFRONT_ID: 訳者注: CloudFront ディストリビューション CLOUDFRONT_ID の Public URL を取得して) URL を取得したら、ブラウザで開いてください。「Hello World」が表示されるはずです！ まとめ この記事では、以下を実施しました: ウェブサイトファイルをホストするための S3 バケットの作成 「Hello World」メッセージを含む簡単な HTML ファイルの生成 HTML ファイルの S3 バケットへのアップロード ウェブサイトを安全に提供するための CloudFront ディストリビューションの作成 CloudFront ディストリビューション用の Origin Access Control (OAC) の設定 CloudFront からのアクセスを許可するための S3 バケットポリシーの更新 CloudFront URL を通じたウェブサイトへのアクセス これらすべてのステップは、 CLI 上の Amazon Q Developer を使用してターミナルで実行されました。 複雑な CLI コマンドを自然言語に変換できる手軽さを体験し、AWS がこれまで以上にアクセスしやすくなったことがお分かりいただけたと思います。しかし、これは始まりに過ぎません。ニーズが拡大するにつれて、Amazon Q もスケールし、より迅速なデプロイメント、生産性の向上、 AWS エコシステム全体へのシームレスなアクセスを提供します。 Amazon Q Developer が各ステップを簡素化してくれるので、まだ試していない AWS サービスもぜひ探索してみてください。ワークフローを効率化し、革新と成長のための新しい機会を開くことができます。 翻訳はApp Dev Consultantの宇賀神が担当しました。原文は こちら です。 著者について Xipu Li Xipu は AWS のソフトウェアエンジニアで、Amazon Q などの次世代開発ツールの開発に取り組んでいます。スタートアップ、スキー、ミームの作成に興味のある食通です。  

このブログは 2024 年 5 月 28 日に Alex Payne, Kartik Verma, Genta Watanabe によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2016 年に設立された トヨタコネクテッドノースアメリカ は、トヨタとレクサスの車両向けの高度な技術とデータサービスの開発と提供に注力しています。トヨタコネクテッドの使命は、モビリティをすべての人にとってより身近でエキサイティングな、人間中心の体験にすることです。この目的のために、トヨタコネクテッドはデータ接続を利用して、北米の 800 万を超える小売顧客、数百のディーラー、および車両会社にサービスを提供しています。 トヨタコネクテッドのリアルタイムデータプラットフォームは、コネクテッドカーの数が劇的に増加したため、わずか発売以来 5 年間で指数関数的な成長を遂げました。ビッグデータ分析プラットフォームの要件は、市場の状況に基づいており不確実です。製品サイクルにおける電動化の増加など、企業のビジネスイニシアチブを実現するためには迅速に進化する必要があります。したがって、これらのプラットフォームのデータストレージコストは、トヨタコネクテッドの全体的な予算に大きく直結しています。 この投稿では、トヨタコネクテッドノースアメリカが、 Amazon S3 Intelligent Tiering ストレージクラス 、 Amazon S3 ライフサイクル 、 Amazon Athena などのマネージドサービスと機能を活用して、データ量が 4 % 増加したにもかかわらず、ビジネスをサポートするためにどのように月間 40 % 以上の節約を実現したかについて説明します。 データ分析とストレージの課題 トヨタコネクテッドのリアルタイムデータプラットフォームは、複数のレイヤーで構成されています。 Ingest レイヤーは、車両の何百ものセンサーからデータを受信します。 Decode レイヤーは、バイナリデータを使用可能な形式に変換します。 Transform レイヤーは、データを変換し、テレメトリ、ドライバースコア、衝突通知、安全サービスなどの多数のデータサービスを顧客に公開します。 Analyze / Consume レイヤーはビッグデータ分析プラットフォームであり、車両データを処理し、機械学習 / 人工知能（ ML / AI ）を適用して研究開発のための洞察を提供し、トヨタ車の品質を向上させ顧客満足度を提供します。 車両台数の増加に伴うコスト上昇に対処するため、チームは当初、 S3 ライフサイクル設定を使用して S3 Standard ストレージクラス から S3 Glacier Flexible Retrieval ストレージクラス にデータを移動する保存ポリシーを実装しました。このアプローチは、クラウド全体のコストを削減するために望んでいた節約をもたらしましたが、これらの節約をさらに改善する必要がありました。 課題は保存ポリシーが静的であることでした。これらのほとんどは、 30 日後にデータをあるストレージ階層から別のストレージ階層に移動するなどの単純なルールを使用していました。2 つ目の課題は、ビッグデータ分析プラットフォームのデータ要件が市場の状況に基づいている事による不確実性でした。たとえば、 Prime プラグインハイブリッドや bZ4X 電気自動車に関連するデータは、電動化などの拡大するトヨタの取り組みをタイムリーにサポートするため、より迅速に取得できる必要があります。 欠けていたのは、アクセス頻度の低いデータとは対照的に、どのデータが頻繁に使用またはアクセスされたかを判断するためのインテリジェンスでした。こうしたアクセスパターンの変化に伴い、トヨタコネクテッドは必要に応じてデータを動的に利用できるようにする方法を必要としていました。さらに、アクセス頻度の低いデータを S3 Glacier Flexible Retrieval や S3 Glacier Deep Archive などの低コストのストレージクラスに移動した場合でも、ビジネスニーズの変化に応じて分析ワークロードからすぐにアクセスできるようにする必要がありました。たとえば、 2023 年のアースデイでは、トヨタコネクテッドは、ノーマルモードとエコモードで走行する車両から CAN データをすばやく取得して、特定の期間におけるトヨタ所有車の二酸化炭素排出量を比較する必要がありました。チームは、オペレーションオーバーヘッドを追加したり、既存のワークロードやアプリケーションを完全に再設計したりすることなく、これらの課題に対する無駄のないソリューションを探しました。 ソリューション トヨタと AWS は、さまざまなデータセット、そのアクセスパターン、データ量、オブジェクト数を分析するためのフォーカスグループを結成しました。この分析の結果、特定のストレージアプローチからメリットが得られる可能性のある分類されたデータセットと、それらのアプローチによる潜在的なコスト削減のリストが提供されました。 S3 Storage Lens と S3 ストレージクラス分析 が役に立ちました。S3 Storage Lens では、合計ストレージ、オブジェクト数、ストレージクラスまたは S3 バケットごとの平均オブジェクトサイズなど、オブジェクトストレージの使用状況とアクティビティの概要を確認できました。S3 ストレージクラス分析は、「アクセス頻度が低い」ストレージの量を特定するのに役立ちました。 最適化によって最も恩恵を受けるバケットについては、AWS からの提案に従いました。一般に、これらのバケットは、他のバケットよりも多くのデータを格納し、平均オブジェクトサイズが大きく、一時的ではない永続的なオブジェクトを含むバケットでした。AWS チームと協力して、分析した各バケットでどれだけのコスト削減が見込めるかを正確に見積もりました。その後、 3 つの戦略を策定しました。 S3 ライフサイクル設定 分析の結果、アクセスパターンが予測可能な場合では、少数のオブジェクトが何度もアクセスされるシナリオと、多数のオブジェクトが 1 回だけアクセスされるシナリオを区別することが重要であることがわかりました。後者の場合、S3 Intelligent Tiering による節約額は S3 ライフサイクル設定を使用する場合よりも少なくなります。これは、S3 Intelligent Tiering では、オブジェクトのアクセスパターンを監視するための 監視および自動化に毎月少額の料金 がかかり、 30 日間連続してアクセスされていないオブジェクトは S3 低頻度アクセス層に自動的に移行されるためです。アクセスパターンが予測可能なデータについては、よりカスタマイズされたルールを適用するために S3 ライフサイクル設定をこれらのバケットに残しました。 S3 Intelligent-Tiering 次に、アクセスパターンが予測できないバケットについて、S3 Intelligent Tiering の使用による影響を測定したいと考えました。チームは、インスタントアクセス階層からデータを取得する際にレイテンシーの課題がないことを確認するために、 Amazon Athena や Amazon EMR などのダウンストリームアプリケーションの検証を含む広範な分析を行いました。さらに、これらの AWS サービスを使用する日次ジョブを監視し、オペレーション効率に悪影響がないことを確認しました。 予測不可能なアクセスパターンデータを S3 Intelligent Tiering に移動した後、チームは AWS Cost Explorer を使用してコストを確認しました。2023 年 2 月に最初に確認された直接的な変化は、Amazon S3 の新しい階層へのオブジェクトの初期移行料金が原因の約 1 日のコスト急騰でした。その後、価格は予想通り通常に戻りました。切り替えから約 30 日後、データ量は前月比で 4 % 増加し、1 か月あたり 40 % のコスト削減が見られるようになりました。これは、S3 Intelligent Tiering が、アクセス頻度の低いオブジェクトをより低コストのストレージ階層に自動的に移動したためです。 重複データの回避 ビッグデータ分析プラットフォームでのデータ分析とクエリ処理に関して、トヨタコネクテッドは Amazon Athena を使用して Amazon S3 のデータをクエリしました。データセットには、S3 Standard と S3 Glacier の両方のストレージクラスのファイルが含まれていました。Amazon Athena は S3 Glacier Flexible Retrieval や S3 Glacier Deep Archive などの S3 Glacier アーカイブストレージクラスから復元されたデータを直接クエリすることはできませんでした。しかし、アドホックなビジネスニーズへの対応や技術的な課題のトラブルシューティングを行うために、アーカイブされたデータにアクセスすることが必要な場合があります。 この課題を緩和し、クエリをシームレスに実行するために、回避策を実装しました。これには、復元されたオブジェクトを複製して、Amazon Athena がクエリを実行できるように、復元されたオブジェクトのコピーを S3 Standard ストレージクラスに追加作成する必要がありました。しかし、このアプローチは、データストレージの増大によるコストの増加という形で、意図しない結果をもたらしました。この諸経費が、分析ニーズに Amazon Athena を活用する組織にとっての懸念事項となったため、製品に関するフィードバックを AWS チームと共有しました。 2023 年 6 月 29 日、Amazon Athena は、追加のコピーを必要とせずに、復元された S3 Glacier ストレージクラスのデータを直接クエリする 新機能 をリリースしました。これにより、プロセスが合理化され、コストが大幅に削減されました。この強化は、 Amazon Athena に依存するデータ分析ワークフローの最適化において極めて重要な瞬間となりました。これにより、経費を抑えながら、データの可能性を最大限に引き出すことができました。このブログ 記事 では、この新機能の詳細を紹介しています。 結論 この投稿では、ストレージコストを最適化するための 3 つの戦略について説明しました。S3 Intelligent Tiering を実装することで、リソースを効率的に割り当てることができ、パフォーマンスを低下させることなくコストを最適化できました。S3 Intelligent Tiering を最大限に活用するには、アクセス頻度の異なるデータを含むバケットを特定することが不可欠です。これは、月当たり 40 % の節約につながりました。一方、S3 ライフサイクル設定は、予測可能なアクセスパターンを持つデータを含むバケットに、よりカスタマイズされたルールを適用するのに役立ちます。さらに、Amazon Athena を使用して S3 Glacier Archive クラスから復元されたデータを直接クエリすることで、オペレーションオーバーヘッドがなくなり、ストレージコストをさらに節約できます。 こうした最適化の取り組みは、コネクテッドカーの数が増え続けることで指数関数的な成長を遂げてきた、トヨタコネクティッドのリアルデータプラットフォームの持続可能な事業成長を促進しました。また、電動化やアースデイの外部エンゲージメントイニシアチブなど、データ要件が不確実であったり、今後も不確実なデータ要件が続く新しい戦略的事業計画を支援しました。 <!-- '"` --> TAGS: Amazon S3 Glacier storage classes , Amazon S3 Intelligent-Tiering , Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage Alex Payne Alex Payne は、トヨタコネクテッドノースアメリカのCAN（コントローラー・エリア・ネットワーク）取り込みプラットフォームのテクニカル・リードで、トヨタ車からのCANデータの取り込みを担当しています。余暇には、チェスをしたり、ピアノを弾いたりするのが大好きです。 Kartik Verma Kartik Verma はトヨタコネクテッドノースアメリカのシニアデータエンジニアで、AWS サービスの最適化、大幅なコスト削減につながる自動化フレームワークの設計、モビリティグループの製品運用の推進に情熱を注いでいます。余暇には、家族と充実した時間を過ごしたり、アウトドアスポーツに参加したりしています。 Genta Watanabe Genta Watanabe は AWS のシニアテクニカルアカウントマネージャーです。彼は戦略的な自動車業界のお客様との仕事に時間を費やし、お客様がオペレーション・エクセレンスを達成できるよう支援しています。彼の関心分野は機械学習と人工知能です。余暇には、家族と充実した時間を過ごしたり、旅行を楽しんだりしています。

このブログは 2024 年 1 月 29 日に Ron Kolwitz (Senior Solutions Architect)、Robert Fountain (Sr. EUC Specialist Solutions Architect)、Roy Tokeshi (EUC Specialist Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 お客様は Amazon AppStream 2.0 を使用して、仮想化されたデスクトップとアプリケーションのフリートをエンドカスタマーにデプロイし、無数の永続的なストレージソリューションをサポートします。AppStream 2.0 は組織のユーザに複数の一般的なストレージオプションですぐに使用できる機能を提供します。例えば Amazon Simple Storage Service (S3) 、 Amazon WorkDocs 、Google Drive for G Suite、OneDrive for Business などです。これらのストレージソリューションで動作する場合、AppStream 2.0 はユーザーセッションの開始時にファイルをダウンロードし、セッションの終了時にストレージプロバイダーと同期します。これらのサービスはほとんどのデスクトップワークロードに最適化されており、典型的なシステム要件に対するデファクトのアプローチとなっています。 AppStream 2.0 のお客様の中には、大規模なデータセット、数百から数百万のファイル、バックエンドストレージプロバイダーとの継続的な同期など、強化されたストレージ機能を必要とする厳しい要求をお持ちのお客様もいます。たとえば、AppStream 2.0 フリートインスタンスで作業する大規模な開発チームは、大規模なソフトウェアアプリケーションを構築するために、数千のファイルを共同でコンパイルする必要がある場合があります。このようなユースケースでは、マネージドストレージオプションである Amazon FSx ファミリーなどの AWS ストレージサービスとフリートを統合できます。たとえば、 FSx for ONTAP と組み合わせると、VPC 内で実行されるカスタマイズ可能な IOPS、スループット、キャッシュ機能を備えた独自の NetApp ONTAP ストレージ機能を活用する堅牢なソリューションをフリートに提供できます。マネージドサービスである Amazon FSx は、可用性や耐久性、パッチ適用、可視性を維持し、お客様をご自身のストレージソリューションの管理から解放します。 このブログでは、高性能なストレージを提供するストレージ共有ドライブとして Amazon FSx ファミリーを使用し Amazon AppStream 2.0 Linux ベースのフリートをデプロイする方法を紹介します。このソリューションは、AWS ネットワークバックボーンで提供されるキャッシュ、パフォーマンス、拡張可能なストレージすべての機能を管理する Amazon FSx を必要とするチームに役立ちます。Windows ベースのユーザーに対しては、同様の Windows ソリューションをセットアップする方法として 以前のブログ がございます。 読了までの時間 10 分 完了までの時間 30 分 学習レベル 上級 (300) 完了までの費用 (推定) 割り当てられた FSx ストレージと最新のフリートを設定するための AppStream 2.0 イメージビルダーインスタンスの利用時間に対してのみ料金が発生します。詳細については、 Amazon AppStream 2.0 の料金 と Amazon FSx for NetApp ONTAP の料金 を参照してください。 利用したサービス Amazon AppStream 2.0 Amazon FSx for NetApp ONTAP 前提条件 次の前提条件が必要です。 AWS アカウント 必要な権限を持つ AWS IAM ロールとポリシー 2 つ以上のプライベートサブネットを持つ Amazon Virtual Private Cloud (VPC) AppStream 2.0 フリート、スタック、イメージビルダー – セットアップの詳細については Amazon AppStream 2.0 の開始方法 を参照してください。 Amazon FSx for NetApp ONTAP ファイルシステム – セットアップの詳細については Amazon FSx for NetApp ONTAP の開始方法 を参照してください。新しいファイルシステムの FSxN の共有ポイントを書き留めます。 例: &lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.com:/&lt;&lt;volume&gt;&gt; ソリューションの概要 Amazon AppStream 2.0 を Amazon FSx ストレージと一緒に使用するには、セッション開始時に FSx ストレージをマウントするようにイメージビルダーを設定する必要があります。このアプローチは、ホームフォルダーあるいは共通のファイル共有としてユーザーごとにストレージをマウントするために使用できます。 次の図は、さまざまな AppStream 2.0 および Amazon FSx for NetApp ONTAP コンポーネントとそのデプロイメントを示しています。 実装 カスタムイメージを作成するには、まずイメージビルダーインスタンスを作成します。 AppStream 2.0 管理コンソール AppStream 2.0 管理コンソールから、 Images を選択します。 Image builder タブを選択し、 Launch image builder を選択します。 フィルターを使用して利用可能な Linux イメージを検索し、Linux イメージを選択します。 イメージの名前を入力し、利用可能なインスタンスタイプを選択します。この例では、IAM ロールと VPC エンドポイントのセクションはそのままにしておきます。 Next を選択します。 VPC、利用可能なサブネット、セキュリティグループを選択します。注意: VPC セキュリティグループは、Amazon FSx ファイルシステムへのアクセスを許可する必要があります。 Launch Image builder を選択します。 次のオプションは、Amazon AppStream 2.0 Linux ベースのフリートと FSx for ONTAP 永続ストレージを組み合わせる方法を示しています。 オプション 1 ) すべてのユーザーに対するホームフォルダードライブの提供 Amazon FSx を使用して、ユーザーごとにアタッチされたフォルダーを提供することができます。このデータは、ネットワークファイルシステム (NFS) プロトコルを使用してマウントされ、ユーザーの AppStream 2.0 インスタンスに直接接続され、継続的に同期されたネットワークストレージを提供します。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 以前にメモした FSx 共有ボリュームを使用して、FSx ファイルシステムをイメージビルダーインスタンスにマウントし、各ユーザーのディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;" /fsx # repeat below for each user sudo mkdir /fsx/&lt;&lt;username&gt;&gt; sudo chown 1002:1004 /fsx/&lt;&lt;username&gt;&gt; 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 { &nbsp; &nbsp;"SessionStart": { &nbsp;&nbsp;&nbsp; "executables": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; …, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Context": "system", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Filename": "/opt/appstream/SessionScripts/system-start-fsx-user.sh", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Arguments": "", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "S3LogEnabled": true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp; "waitingTime": 60 &nbsp; }, &nbsp; … } ユーザーごとの FSx 共有をマウントするため、 /opt/appstream/SessionScripts/system-start-fsx-user.sh に新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有に更新します。このスクリプトは、 appstream_user_sh 環境変数の $AppStream_UserName を自動的に追加し、ボリューム上の Linux ユーザーのマウントディレクトリのみを一意にマウントします。 #!/bin/bash NFS_SHARE="&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;" HOMEFOLDER_BASE="$HOME/MyFiles/HomeFolder" # Load the appstream user variables if [ -f /etc/profile.d/appstream_user_vars.sh ]; then . /etc/profile.d/appstream_user_vars.sh fi&nbsp; # Mount FSX Storage for user session, create new directory if HomeFolder already exists (e.g. if S3 storage is already mounted) INDEX=”” while [ -d "$HOMEFOLDER_BASE$INDEX" ]; do &nbsp; ((INDEX++)) done HOMEFOLDER="$HOMEFOLDER_BASE$INDEX" mkdir "$HOMEFOLDER" chown as2-streaming-user:as2-streaming-user "$HOMEFOLDER" sudo mount -t nfs "$NFS_SHARE/$AppStream_UserName" "$HOMEFOLDER" スクリプトファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-user.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。フリートを停止して起動します。 AppStream 2.0 ユーザーセッションを起動します。S3 または同様のバックアップストレージをオフにするまで FSx ネットワークストレージはユーザーの MyFiles/HomeFolder2 ディレクトリに表示されるため、チームは必要に応じて FSx ストレージにファイルを移行できます。必要ならば以前のストレージをオフにすることができ、その場合 FSx ストレージは MyFiles/HomeFolder として表示されます。希望する場合、FSx と AppStream 2.0 組み込みストレージメソッドの両方を共存させることができます。 オプション 2 ) ユーザー間のファイル共有の提供 FSx を使用すると、すべてのユーザーで必要な共通ファイルで共同作業するために組織内のユーザーに共有フォルダーの場所を提供できます。プロセスはオプション 1 と似ていますが、すべてのフリートユーザーインスタンス間で共通のポイントにマウントされ、共有されます。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 FSx 共有ボリュームを使用して FSx ファイルシステムをイメージビルダーインスタンスにマウントし、共有利用のための共通ディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume" /fsx sudo mkdir /fsx/common sudo chown 1002:1004 /fsx/common 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 { "SessionStart": { &nbsp;&nbsp;&nbsp; "executables": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; …, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Context": "system", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Filename": "/opt/appstream/SessionScripts/system-start-fsx-common.sh", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Arguments": "", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "S3LogEnabled": true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp; "waitingTime": 60 &nbsp; }, &nbsp; … } ユーザー間で共通の共有フォルダーをマウントするには、 /opt/appstream/SessionScripts/system-start-fsx-common.sh の新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有で更新します。 #!/bin/bash NFS_SHARE="&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;/common" COMMONFOLDER_BASE="/fsx/common" # Mount FSX Storage for common storage sudo mount -t nfs "$NFS_SHARE" "$COMMONFOLDER_BASE" ファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-common.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。 フリートを停止および起動します。 AppStream 2.0 ユーザーセッションを起動します。Amazon FSx 共有ストレージが表示され、ユーザーは /fsx/common の下でデータを共有できるようになります。 クリーンアップ AWS アカウントで継続的な課金が発生しないようにするには、新しく作成されたすべての AWS リソースを削除します。 AWS マネジメントコンソール にログインして、フリート、イメージビルダー、FSx ファイルシステムなど、このデプロイメントの一部として作成した可能性のあるリソースを削除します。イメージの削除については、 AppStream 2.0 管理者ガイド を参照してください。FSx ストレージの削除については、 FSx for ONTAP ユーザーガイドの入門 リソースのクリーンアップ を参照してください。 まとめ Amazon AppStream 2.0 と Amazon FSx を使用すると、数千から数百万のファイルを継続的に同期する高性能ストレージのユースケースに対応できる仮想化デスクトップを構築できます。この例は、強化されたストレージ機能を必要とするハイエンドの共同開発でお客様にご利用いただいています。 適切な FSx ストレージ サービスの選択に関する詳細については、 Amazon FSx ファイルシステムの選択 の概要を参照してください。 高度なパフォーマンスチューニングの詳細については、 Amazon FSx for NetApp ONTAP パフォーマンス を参照してください。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Cloud Support Engineer の戸松が担当しました。 Ron Kolwitz は、米国連邦政府科学部門の顧客をサポートするシニアソリューションアーキテクトです。顧客と連携して、エンタープライズクラウドの導入と戦略に関する技術ガイダンスを提供し、適切に設計されたソリューションの構築を支援しています。特に航空宇宙と量子ベースのコンピューティングに熱心に取り組んでいます。余暇には、水上スキー愛好家の家族と過ごすのが好きで、大自然を楽しんでいる姿をよく見かけます。 Roy Tokeshi は、IT コンサルティング、教育、アーキテクチャ設計の分野で 25 年以上の経験を持つ、熟練した技術愛好家です。彼の技術に対する愛情は、新しいトレンドの探求と包括的なコミュニティの構築に注力していることを示しています。彼は複雑な概念を簡素化し、すべての専門家が技術を利用できるようにします。Roy は、AWS サービス、CNC、レーザー彫刻機、IoT を使用して作成および構築することを楽しんでいます。チェスは下手ですが、あらゆる年齢や職業の人々に、ボード上やオンラインでチェスをプレイするよう勧めるのが大好きです。 Robert Fountain は、ペンシルバニア州を拠点とするシニア EUC スペシャリストソリューションアーキテクトです。Robert は 2020 年から AWS に勤務しており、現在 6 つの AWS 認定を取得しています。オフィスの外では、Robert はナショナル・スキー・パトロールのメンバーであり、妻と 2 人の息子、そして愛犬の Daisy と一緒に過ごすことを楽しんでいます。 &nbsp; &nbsp;

オランダの私が住んでいる地域ではまだまだ冬が続いており、まれに顔をのぞかせる太陽の光はまたとない贈り物になります。この週末は、そのようなすばらしい時間を体験できました。静かな運河に沿ってサイクリングしていると、オランダの典型的な曇り空から金色の光が差し込み、完璧な静けさと安らぎを感じるひとときを生み出してくれました。ヨーロッパのこの地域では太陽の光がほとんど差さない 1 月にこのような輝きを垣間見ることは、とりわけ特別に感じます。2025 年のお正月気分も過ぎた新年の第 3 週目は、振り返りと前進する意気の両方をもたらします。テクノロジーの進歩をめぐってグローバルな会話が飛び交っていますが、このようなちょっとした個人的な瞬間は、急速に進化する世界の中で立ち止まり、ささやかな喜びに感謝することを思い出させてくれます。 では、1 月 13 日週の新しい発表を見てみましょう。 1 月 13 日週のリリース 私が注目したリリースをいくつかご紹介します。 AWS メキシコ (中部) リージョン – 2024 年 2 月にメキシコのインフラストラクチャを拡大する計画を発表した AWS は、3 つのアベイラビリティーゾーンを備え、API コードを mx-central-1 とする AWS メキシコ (中部) リージョンの提供を開始しました。このリージョンはメキシコ初の AWS インフラストラクチャリージョンとなり、中南米における AWS の存在感をさらに高めます。ローカルワークロード管理、データストレージ機能、低レイテンシーでのパフォーマンス向上、強固なセキュリティ標準を提供するこの新しいリージョンは、専用プロセッサを用いた最先端の人工知能と機械学習 (AI/ML) 機能、143 のセキュリティ標準とコンプライアンス認証をサポートする包括的なセキュリティ機能など、高度なクラウドテクノロジーを備えています。このリージョンの提供開始に伴い、AWS の規模は 36 の地理的リージョン内の 114 のアベイラビリティーゾーンに拡大されました。 AWS マネジメントコンソールが複数の AWS アカウントへの同時サインインのサポートを開始 – AWS マネジメントコンソール にあるマルチセッション機能を使用することで、複数の AWS アカウントにサインインし、単一のブラウザでリソースを管理できるようになりました。最大 5 つのセッションにサインインでき、異なるアカウント内、または同じアカウント内にあるルート、 AWS Identity and Access Management (IAM) 、フェデレーションロールの任意の組み合わせにすることが可能です。アプリケーションは、AWS のベストプラクティスガイドラインに従って、複数のアカウントを用いてスケールできます。アプリケーション問題やその他のアプリケーション関連のジョブをトラブルシューティングするために、開発、テスト、本番環境などのさまざまな環境のアカウントを使用して、複数のアカウント全体のリソース設定とステータスを比較することができます。 Amazon EC2 Flex インスタンスに新しいより大きなサイズを導入 – Amazon Elastic Compute Cloud (Amazon EC2) Flex (C7i-flex および M7i-flex) インスタンスでの 2 つの新しいより大きなサイズ (12xlarge および 16xlarge) の一般提供が発表されました。新しいサイズは EC2 Flex ポートフォリオを拡大し、既存のワークロードをスケールアップしたり、追加のメモリを必要とするより大規模なアプリケーションを実行したりするための追加のコンピューティングオプションを提供します。これらのインスタンスには、AWS でしか利用できないカスタム第 4 世代 Intel Xeon Scalable プロセッサが搭載されており、他のクラウドプロバイダーが使用する同等の x86 ベースの Intel プロセッサよりも最大 15% 優れたパフォーマンスを提供します。Flex インスタンスは、コンピューティング集約型ワークロードと汎用ワークロードの大多数でコストパフォーマンスのメリットと低料金を実現するための最も簡単な方法です。同等の前世代インスタンスよりも最大 19% 優れたコストパフォーマンスを提供し、コンピューティングリソースを完全に活用しないアプリケーションには最優先の優れた選択肢になります。Flex インスタンスは、ウェブサーバーやアプリケーションサーバー、バッチ処理、エンタープライズアプリケーション、データベースなどに最適です。さらに大きなインスタンスサイズ (最大 192 個の vCPU と 768 GiB のメモリ) や、継続的な高 CPU 使用率を必要とするコンピューティング集約型ワークロードと汎用ワークロードには、Amazon EC2 C7i および M7i の各インスタンスを使用できます。 AWS CloudFormation での AWS User Notifications の一般提供を発表 – AWS User Notifications は、AWS マネジメントコンソールの通知センター、E メール、 AWS Chatbot 、またはモバイルプッシュ通知を使用して AWS コンソールモバイルアプリ に送信される通知を設定し、 Amazon CloudWatch アラーム などの重要なイベントを常に把握しておくために使用できます。この機能を使用すると、Infrastructure-as-Code (IaC) プラクティスの一環として通知設定を定義して、 AWS CloudFormation テンプレート内で特定のリソースタイプに対する通知設定を指定することができます。例えば、 Amazon EC2 Auto Scaling グループがスケールアウトしたとき、 Elastic Load Balancing (ELB) ロードバランサーがプロビジョニングされたとき、または Amazon Relational Database Service (Amazon RDS) データベースが変更されたときにトリガーされる通知を設定できます。どのイベントが通知をトリガーし、誰が通知を受け取るのかをきめ細かく制御できます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 AWS 欧州 (ストックホルム) での Amazon EC2 M8g インスタンスの提供開始 – これらのインスタンスは、Graviton3 ベースの Amazon M7g インスタンスよりも最大 3 倍多い vCPU とメモリを用いたより大きなインスタンスサイズを提供します。AWS Graviton3 プロセッサと比較して、AWS Graviton4 プロセッサはデータベースで最大 40%、ウェブアプリケーションで最大 30%、大規模な Java アプリケーションで最大 45% 高速です。 AWS がメキシコのケレタロでの新たな AWS Direct Connect ロケーションと拡大を発表 – Direct Connect サービスは、AWS とデータセンター、オフィス、またはコロケーション環境の間に物理的なプライベートネットワーク接続を確立するために役立ちます。これらのプライベート接続は、パブリックインターネット経由での接続よりも安定性に優れたネットワークエクスペリエンスを提供できます。 AWS GovCloud (米国西部) リージョンでの Amazon EC2 C7i-flex インスタンスの提供開始 – EC2 Flex インスタンスのポートフォリオを拡大するこれらのインスタンスは、コンピューティング集約型ワークロードの大多数でコストパフォーマンスのメリットを実現するための最も簡単な方法を提供します。 AWS Backup が AWS GovCloud (米国) リージョンで組織全体のレポートのサポートを開始 – AWS Backup Audit Manager を使用して、データ保護ポリシーに関する集約的なクロスアカウントレポートとクロスリージョンレポートを生成し、バックアップアクティビティとリカバリアクティビティに関する運用データを取得できます。 アジアパシフィック (香港) リージョンでの Amazon OpenSearch Serverless の提供開始 – OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションで、複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 アジアパシフィック (タイ) リージョン での AWS Backup の提供開始 – AWS Backup を使用することで、アプリケーションデータのバックアップの作成と管理、イミュータブルなリカバリポイントとボールトを用いた不注意によるアクションまたは悪意のあるアクションからのデータの保護、およびデータ損失インシデントが発生した場合におけるデータの復元を一元的に実行できます。 アジアパシフィック (マレーシア) リージョンでの Amazon GuardDuty の提供開始 – この追加のリージョンを使用して、異常な動作、セキュリティ脅威、AWS アカウントをターゲットとした高度なマルチステージ攻撃シーケンスを継続的に監視して検出し、AWS アカウント、ワークロード、データの保護を支援できるようになりました。 追加リージョンでの Amazon EC2 R8g インスタンスの提供開始 – Amazon EC2 R8g インスタンスは、データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析などのメモリ集約型ワークロードに最適です。 欧州 (フランクフルト) での Amazon EC2 I8g の提供開始 – I8g インスタンスは、ストレージ集約型ワークロードに対し、Amazon EC2 で最も優れたパフォーマンスを提供します。 5 つの追加 AWS リージョンでの Amazon S3 Tables の提供開始 – Amazon S3 Tables は、Apache Iceberg サポートが組み込まれた初のクラウドオブジェクトストアと、表形式データを大規模に保存するための最も簡単な手段を提供します。S3 Tables は特に分析ワークロード向けに最適化されているため、継続的なテーブル最適化による非マネージド型 Iceberg テーブルよりも最大 3 倍速いクエリパフォーマンス、汎用 S3 バケットに保存されている Iceberg テーブルよりも最大 10 倍多い 1 秒あたりのトランザクション数を実現します。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。公式 AWS Summit ウェブサイト にアクセスして最新情報を入手し、お住まいの地域内で行われるイベントの登録開始時を把握するための通知にサインアップしましょう。 コラボレーションスペースで、没入型エクスペリエンスでもある AWS GenAI Lofts &nbsp;は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。&nbsp; お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日中に開催されるすべての AWS 主催の対面およびバーチャルイベント は、こちらで閲覧できます。 1 月 20 日週のニュースは以上です。1 月 27 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

このブログは 2025 年 1 月 15 日に Steve de Vera（AWS Customer Incident Response Team）と Jennifer Paz（AWS Customer Incident Response Team）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2025 年 1 月 17 日: 本投稿で詳解されている不正な方法のリスクを軽減するために、一時的な認証情報を使用することの重要性を強調するために、原文は更新されました。 Amazon Web Services（AWS） では、お客様のデータセキュリティが最優先事項であり、今後もそれは変わりません。 AWS Customer Incident Response Team（CIRT） と当社の自動セキュリティ監視システムは、最近 Amazon Simple Storage Service（Amazon S3） バケットに関連する異常な暗号化アクティビティの増加を確認しました。 これらの行為は AWS サービス内の脆弱性を悪用するものではありません。権限のないユーザーが、意図しない方法で利用できる有効な認証情報を用いたものであることを認識する必要があります。これらの行為は 責任共有モデル のお客様範囲で発生しますが、AWS では、お客様がこのようなアクティビティの影響を防止または軽減できる手順を推奨します。 私たちのセキュリティチームは、お客様と協力しながらカスタマー提供キーを使用した サーバーサイド暗号化（SSE-C） と呼ばれる暗号化方式を使用した、Amazon S3 におけるデータ暗号化イベントの増加を検出しました。これは多くのお客様が使用している機能ですが、SSE-C を使用した多数の S3 CopyObject コマンドによってオブジェクトが上書きされ、新しい暗号化キーでお客様データを再暗号化するというパターンを私たちは検出しました。私たちの分析により、これはお客様の有効な認証情報を入手し、それを使用してオブジェクトを再暗号化した悪意のある人物によって実行されていたことが判明しました。 アクティブディフェンスツール を使用して、多くのケースにおけるこの種の不正なアクティビティを防止することに役立つ自動緩和策を実装しました。これらの緩和策により、お客様が保護措置を行わない場合でも、すでに高い確率で防止に成功しています。ただし、攻撃者は有効な認証情報を使用しており、AWS が正常なアクティビティと悪意のあるアクティビティを明確に区別することは困難です。したがって、リスクを軽減するためにベストプラクティスに従うことを推奨します。 SSE-C の不正使用を防ぐために、次の 4 つのセキュリティのベストプラクティスを実装することをお勧めします: 一時的な認証情報を利用する データ復旧手順を実装する AWS リソースの予期しないアクセスパターンを監視する アプリケーションで必要な場合を除き、SSE-C の使用をブロックする 1. 一時的な認証情報を利用する 上述したアクティビティでは SSE-C 暗号化が使用されていますが、この行為と多くのセキュリティイベントの根本的な原因は、長期的なアクセスキーの侵害にあります。認証情報の侵害リスクを軽減する最も効果的な方法は、そもそも長期的な認証情報を作成しないことです。存在しない認証情報は公開または盗難されることはありません。また、AWS は、ソースコードまたは設定ファイルに認証情報を保存しないで済むような豊富な機能を提供しています。 AWS IAM ロール を利用することで、アプリケーションは、一時的な認証情報を使用して、 Amazon Elastic Compute Cloud（Amazon EC2） インスタンス、 Amazon Elastic Container Service（Amazon ECS） または Amazon Elastic Kubernetes Service（Amazon EKS） コンテナ、AWS Lambda 関数からの署名された API リクエストを安全に実行できます。AWS クラウドの外部システムにおいても、 AWS IAM Roles Anywhere を使用することで、長期的な AWS 認証情報がなくとも認証された API リクエストを実行できます。さらに、 AWS IAM Identity Center を使用すると、開発者は多要素認証（MFA）によって保護された長期的なユーザー ID に裏付けられた一時的な認証情報を取得できます。 これらの技術はすべて AWS Security Token Service（AWS STS） を利用し、アプリケーション内のコードまたは設定ファイルで長期的な AWS セキュリティ認証情報を配布または埋め込むことなく、AWS リソースへのアクセスを制御できる一時的なセキュリティ認証情報を発行します。 2. データ復旧手順を実装する データ保護メカニズムが整備されていない場合、データの復旧に時間がかかる可能性があります。データ保護のベストプラクティスとして、データが上書きされないように保護し、重要なデータのセカンダリコピーを保持することをお勧めします。 Amazon S3 で バージョニング を有効にすると、バケット内のオブジェクトの複数のバージョンが保持され、誤って削除または上書きされたオブジェクトを復元できます。特にバケット内のオブジェクトを頻繁に上書きするアプリケーションの場合には、バージョニングによってストレージコストが増加する可能性があることに注意する必要があります。この場合、古いバージョンを管理し、ストレージコストを制御するために Amazon S3 Lifecycle ポリシー を実装することを検討してください。 さらに、重要なデータを別のバケットにコピーしたり、バックアップを作成することもできます。また、別の AWS アカウントや AWS リージョンにコピーすることもできます。この場合、Amazon S3 の レプリケーション機能 を使用してバケット間でオブジェクトを自動的にコピーします。これらのバケットは、同じ AWS アカウントまたは別の AWS アカウント、同じ AWS リージョンまたは別の AWS リージョンでも可能です。Amazon S3 におけるレプリケーションでは、より厳格な目標復旧時点（RPO）と目標復旧時間（RTO）を持つお客様向けに SLA を提供しています。また、Amazon S3 バケットの定期的なバックアップを自動化するマネージドサービス AWS Backup for Amazon S3 を使用することもできます。 3. AWS リソースの予期しないアクセスパターンを監視する 監視を行わない場合、Amazon S3 バケットに対する不正なアクティビティに気付かない可能性があります。 AWS CloudTrail や Amazon S3 サーバーアクセスログ などのツールを使用して、データへのアクセスを監視することをお勧めします。 AWS CloudTrail を使用すると、Amazon S3 を含めた AWS リソース全体のイベントをログに記録したり、ログを 1 つのアカウントに統合して、セキュリティチームがアクセスして監視するなどのことが実現できます。また、 特定の Amazon S3 メトリクス またはログに基づいて Amazon CloudWatch アラーム を作成し、異常なアクティビティを警告することもできます。これらのアラートは、異常な動作を迅速に特定するのに役立ちます。 Amazon EventBridge と AWS Lambda を使用した是正措置の自動化も設定することができます。組織全体のすべてのバケットをスキャンし、 Amazon S3 ブロックパブリックアクセス を適用するために使用できる実装例もあります。また、 この記事 では、オブジェクトのアップロードの暗号化方法をリアルタイムで監査する方法が説明されています。 4. アプリケーションで必要な場合を除き、SSE-C の使用をブロックする アプリケーションが暗号化する際に SSE-C を使用していない場合は、Amazon S3 バケットのリソースポリシー、または AWS Organizations 内の組織に適用された Resource Control Policy（RCP）を使用して、SSE-C の使用をブロックできます。 Amazon S3 バケットのリソースポリシーは一般的にバケットポリシーと呼ばれ、お客様が個々の Amazon S3 バケットのアクセス許可を制御できるようにします。バケットポリシーは、S3 PutBucketPolicy API コール、AWS Command Line Interface（CLI）、または AWS マネジメントコンソールを使用して適用できます。バケットポリシーの仕組みの詳細については、 Amazon S3 のドキュメント を参照してください。次の例は、 &lt;your-bucket-name&gt; というバケットに対する SSE-C リクエストをブロックするバケットポリシーを示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictSSECObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3::: &lt;your-bucket-name&gt; /*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" } } } ] } RCP を使用すると、AWS Organizations 内の組織全体のリソースに適用される、アクセス許可の最大範囲をお客様が指定できます。RCP は、AWS Organizations UpdatePolicy API コール、AWS CLI、または AWS マネジメントコンソールを使用して適用できます。RCP の仕組みの詳細については、 AWS Organizations のドキュメント を参照してください。次の例は、組織内のバケットに対する SSE-C リクエストをブロックする RCP を示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictSSECObjectUploads", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "false" } } } ] } まとめ AWS 環境に対する一般的な攻撃から利用者の貴重なデータを守るために実行できる最も価値があり、本質的なことは、長期的な認証情報（アクセスキー/シークレットキー）の使用を控えるまたは最小限に抑えることです。その後、すべてのプリンシパルの権限を必要最小限に抑えるようにします（いわゆる「最小権限」分析）。さらに、このブログで説明した特定の攻撃パターンについては、最も一般的な指標を強調して示しました。お客様のセキュリティチームが環境を常に保護するために取り組んでいる間、AWS の多くのチーム （ AWS CIRT 、Amazon の脅威インテリジェンス、 Amazon S3 チームなどのサービスチームなど）が、貴重なデータを保護するために革新、コラボレーション、インサイトの共有に熱心に取り組んでいることを知っておいてください。 この投稿では、お客様のデータに対する最近の脅威に関する最新情報を提供し、紛失または盗難された AWS 認証情報を使用して SSE-C でデータを暗号化する悪意のあるユーザーのリスクから、お客様を保護するために使用できる 4 つのセキュリティのベストプラクティスを紹介しました。 攻撃者の戦術が進化しても、お客様のセキュリティに対する私たちの取り組みは揺るぎません。私たちは協力して、より安全なクラウド環境を構築し、お客様が自信を持って革新できるようにしています。 不正なアクティビティが疑われる場合は、すぐに AWS サポート にご連絡ください。 Steve de Vera Steve は、脅威の調査と脅威インテリジェンスに重点を置く AWS CIRT のマネージャーです。アメリカンスタイルのバーベキューに情熱を傾けており、バーベキュー競技会の認定審査員でもあります。Brisket という名前の犬を飼っています。 Jennifer Paz Jennifer は 10 年以上の経験を持つセキュリティエンジニアで、現在は AWS CIRT に所属しています。Jennifer は、お客様のセキュリティ課題への取り組みを支援し、複雑なソリューションを実装してセキュリティ体制を強化することに喜びを感じています。休暇には、熱心にウォーキング、ジョギング、ピックルボール、旅行、グルメに取り組み、常に新しい料理の冒険を追い求めています。

この記事は Getting started with Amazon Q Developer operational investigations （記事公開日：2024 年 12 月 21 日）を翻訳したものです。翻訳はデベロッパーアドボケイトの山口が担当しました。 このブログポストでは、AWS上の 運用調査のために Amazon Q Developer を使用する クイックスタートをご紹介します。この強力なAI支援トラブルシューティングツールをセットアップするためのステップバイステップのプロセスを説明します。ユーザー権限の設定、データアクセスの管理、暗号化の設定、そして最初の調査の開始方法について説明します。また、このブログでは、この新機能がどのように機能するかのセルフペースデモもご紹介します。 Amazon Q Developer の運用調査機能とはなにか 先日、この新機能の詳細を説明する 包括的なブログ記事 を公開しました。Amazon Q の運用調査機能は、生成AI技術の力を活用し、関連情報を浮き彫りにすることで、インシデントの迅速な調査と解決を支援します。Amazon Q は、メトリクス、ログ、トレース、デプロイメントイベント、およびその他のデータをスキャンして、根本原因の仮説と実用的な洞察を生成します。 はじめ方 CloudWatch コンソール https://console.aws.amazon.com/cloudwatch/ を開く 左側のナビゲーションペインでAIオペレーション、調査の順で選択する Configure for this accountを選択します。(注意: Investigation group を作成して Amazon Q Developer の運用調査を設定するには、 AIOpsConsoleAdminPolicy または AdministratorAccess IAMポリシーのいずれかがアタッチされているIAMプリンシパル、または同様の権限を持つアカウントにサインインする必要があります。調査グループの設定により、調査の共通プロパティを一元管理できます。） 調査の保持期間を選択します。デフォルトは90日です。 オプションで暗号化設定をカスタマイズすることができます。たとえば、AWSが提供するデフォルトの鍵ではなく、カスタマーが管理する鍵を使用したい場合などです。詳細については、 調査データの暗号化を 参照してください。 Create investigation group の画面で保持期間と高度な暗号化を設定できます (オプション) Getting startedウィザードのUser accessセクションは、Amazon Q Developer の運用調査機能とやり取りするさまざまなユーザーロールに適切な権限を設定する方法を理解するのに役立ちます。(スクリーンショット内のリンク先には詳細な情報が記載されたドキュメントがあります。) AWSは3つのマネージドIAMポリシーを提供しています。管理者用の AIOpsConsoleAdminPolicy 、調査の開始と管理が必要なユーザー用の AIOpsOperatorAccess 、情報の閲覧のみが必要なユーザー用の AIOpsReadOnlyAccess です。 User access画面では Amazon Q Developer Investigations assistant の IAM パーミッションをユーザーに与える方法を説明しています オプションで、Amazon Q Developer の運用調査機能を IAM Identity Center に接続できます。IAM Identity Center と統合することで、調査フィードに追加された提案を個々のユーザーに帰属させることができます。詳細については、このリンクを参照してください。 IAM Identity Center を設定し、提案がユーザーに適切に帰属するようにするための Identity aware console session の画面 “Next“を押して次に進みます “Investigation configuration” セクションでは、Q Developer が調査のためにテレメトリーデータにアクセスするために使用する IAM ロールを設定できます。”Auto-create”を選択します。これにより、必要な権限を持つ新しいロールが作成されます。 Amazon Q Developer の権限を設定する Investigation configuration の画面 Enhanced integration のセクションでは、Amazon Q Developer の調査実行をさらに支援する追加オプションを設定できます。次のステップでは、これらのオプションの機能について簡単に説明します。 Tags for application boundary detection : このセクションでは、アプリケーションで使用する既存のカスタムタグキーを指定できます。これらのタグは、Amazon Q Developer がリソースの関係を検出する際に検索を絞り込むのに役立ちます。詳細は こちら をご覧ください。 Enhanced ingetrations の画面。アプリケーションの境界を識別するためのタグを設定できます。 CloudTrail for change event detection のセクションでは、Amazon Q Developer が CloudTrail データにアクセスし、システム変更の分析と根本原因の仮説を改善できます。 CloudTrail for change event detection の画面 X-Ray for topology mapping と Application Signals for health assessment のセクションでは、Amazon Q Developer の機能を強化することができる追加のAWSサービスを紹介しています。 X-Ray と Application Signals のための追加の統合に関する画面 ”Next“を押して次へ進みます ウィザードの最後のセクションでは、サードパーティの統合を設定できます。これらには、チケットシステム、チャットとの統合、SNSが含まれます。本記事ではこれらについて詳しく説明しません。しかし、より詳細な情報を求めている場合は、 こちらのリンク をご覧ください。 “Complete setup”を選択して設定を開始します。数秒後、”Initial Setup success” の確認メッセージが表示されます。 次のステップ Amazon Q Developer の運用調査機能は、厳格なセキュリティ管理を維持しながら、インシデントレスポンスを加速させる強力な方法を提供します。セキュリティ体制をさらに強化するためには以下も実施してみてください。 ドキュメント の参照 必要に応じたIAMロールとIAMポリシー の調整 必要であればカスタマーのマネージドキーでの 暗号化の設定 設定が正しく動作しているかの検証のために テストの調査 を実施 Amazon Q Developer をあなたのAI搭載アシスタントにすることで、データとシステムを安全に保ちながら、AWSの問題をこれまで以上に迅速に解決できるようになります。セキュリティを優先して実装することで、システムとデータの完全性と機密性を維持しながら、その強力なAI機能を自信を持って活用できます。このバランスの取れたアプローチにより、セキュリティのベストプラクティスを妥協することなく、インシデントレスポンスとトラブルシューティングのプロセスを加速できます。 この機能を実際にご覧になるには、 インタラクティブデモ をご覧ください。 著者について Andres Silva Andres Silva は、Amazon Web Services（AWS）のグローバルクラウドオペレーション＆オブザーバビリティリーダー兼プリンシパルスペシャリストソリューションアーキテクトとして、企業のクラウド運用の変革を支援しています。AWSでの約10年を含む30年以上の技術経験を持ち、DevOps、クラウド技術、SaaSインフラ管理を専門としています。ノースカロライナ州ハイポイントを拠点に、オブザーバビリティ、AIOps、ガバナンスを中心に、企業全体のクラウド運用戦略を推進しています。AIを活用したインテリジェントなクラウドオペレーションフレームワークを構築・導入し、卓越した運用と自動化されたインシデント対応を大規模に実現するため、グローバル企業と提携しています。

このブログは 2023 年 2 月 6 日に Megan O’Neil (Principal Specialist Solutions Architect)、Karthik Ram (Senior Solutions Architect)、Kyle Dickinson (Sr. Security Solution Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェアによる被害は過去数年で大幅に増加し、世界中から注目を集めています。従来のランサムウェアは、主にサーバーやデータベース、共有ファイルシステムなどのインフラストラクチャリソースに影響を与えていました。しかし、 Amazon Simple Storage Service (Amazon S3) に保存されたデータを標的とするような、あまり馴染みのない事案もあります。ランサムウェア攻撃を未然に防ぎ、そして早期に特定して復旧対処できるように実施すべき重要な対策があります。このブログのゴールは、ランサムウェアから保護するために使用できる AWS のサービスと機能について学び、攻撃が発生した場合の調査方法を理解していただくことです。 ランサムウェア は、悪意のある攻撃者が組織から金銭を要求するために使用できるマルウェアの一種です。攻撃者は、未修正のソフトウェアの脆弱性を悪用や、弱いクレデンシャルを不正利用、過去に意図せず漏洩したクレデンシャルの使用やソーシャルエンジニアリングなどさまざまな手段を使って、ターゲットのデータやシステムへの不正アクセスを試みます。ランサムウェア攻撃が発生すると、正当な組織がデータやシステムにアクセスできなくなり、デジタル資産の安全な返還と引き換えに身代金が要求されます。攻撃者が正規のアクセスを制限または無効化する手段には、a) 暗号化または削除、b) アクセス制御の変更、c) ネットワークベースの DoS (Denial of Service) 攻撃などがあります。場合によっては、データアクセスが暗号化キーの提供やデータの返却によって復旧した後、データのコピーを持つ攻撃者から、そのデータを販売したり公開したりしないことを約束する二重の身代金要求がされることもあります。 次のセクションでは、Amazon S3 でのランサムウェア発生時の対応における 4 つの重要なフェーズ、検知、対応、復旧、保護について説明します。 観測できたアクティビティ AWS Customer Incident Response Team (CIRT) が観測するところによると、Amazon S3 内のデータを標的とするランサムウェア攻撃の最も一般的な原因は、 AWS Identity and Access Management (IAM) アクセスキー の漏洩です。他の要因としては、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされた IAM インスタンスプロファイルとアクセス許可を持つアプリケーションに欠陥があり、そのインスタンスが Instance Metadata Service Version 1 (IMDSv1) を使用している場合です。この場合、不正なユーザーが Amazon EC2 インスタンスの IAM インスタンスプロファイルから AWS Security Token Service (STS) セッション キー を使用して、Amazon S3 バケット内のオブジェクトを人質に取ることができる可能性があります。この記事では、最も一般的なシナリオである、IAM アクセスキーの漏洩に焦点を当てます。 検出 攻撃者がクレデンシャルを入手した後、 IAM プリンシパル に付与されているアクセス権限を把握するために、AWS API を繰り返し実行します。悪意のある者はこれを複数の方法で行うことができ、さまざまなアクティビティが発生する可能性があります。このアクティビティは、エラーが発生する API 呼び出しの増加により、セキュリティチームに警告を発する可能性があります。一方で、悪意のある者の目的が Amazon S3 オブジェクトの身代金要求である場合、API 呼び出しは Amazon S3 に特化したものになります。利用される IAM プリンシパルにおいて Amazon S3 へのアクセスが許可されている場合、 s3:ListBuckets 、 s3:GetBucketLocation 、 s3:GetBucketPolicy 、 s3:GetBucketAcl などの API アクションの増加が見られる可能性があります。 分析 このセクションでは、ランサムウェアイベントをより詳細に分析するのに役立つログとメトリクスデータについて説明します。 ランサムウェア攻撃が Amazon S3 に保存されたデータを標的とする場合、多くの場合、Amazon S3 バケットに保存されているオブジェクトが悪意のある攻撃者によってコピーされることなく削除されます。これは、オブジェクトが暗号化されるランサムウェア攻撃というよりも、データ破壊イベントに近いものです。 この操作を記録するログがいくつかあります。 Amazon S3 データに対する&nbsp;AWS CloudTrail イベントログ の有効化ができます。これにより、特定のオブジェクトに対して実行された読み取りや削除の操作を確認できます。 さらに、ランサムウェア事案の前に Amazon S3 の Amazon CloudWatch メトリクス を有効化していた場合は、 BytesDownloaded メトリクスの合計を使って、異常な転送スパイクを把握できます。 別の観点では、 region-DataTransfer-Out-Bytes メトリクスを使うことです。これは、Amazon S3 からインターネットへ転送されたデータ量を示します。このメトリクスはデフォルトで有効になっており、Amazon S3 の AWS 課金と使用状況レポートに関連付けられています。 詳細については、AWS CIRT チームの インシデント対応プレイブック: Amazon S3 のランサムウェア対応 、および GitHub リポジトリの AWS カスタマープレイブック で公開されている他の対応フレームワークを参照してください。 対応 次に、IAM アクセスキーが漏洩した場合の対応方法について説明します。ビジネスへの影響に基づいて、それらのクレデンシャルをすべて置き換えるために 2 つ目のアクセスキーセットの作成を検討します。これにより、侵害されたアクセスキーを非アクティブ化しても、正当なシステムが中断されることはありません。アクセスキーの無効化は、IAM コンソールまたはインシデント対応計画に基づいた自動化ツールを通じて実施します。同時に、将来参照できるように、インシデントの詳細な記録をセキュアで非公開のインシデント対応文書内に保存する必要もあります。アクティビティが IAM ロールまたは一時的な資格情報の使用に関連している場合は、追加のステップとして アクティブなセッションを取り消す 必要があります。これを行うには、IAM コンソールで アクティブセッションの取り消し を選択し、その時点以前にロールを引き受けたユーザーへのアクセスを拒否するポリシーを付加します。その後、露出したアクセスキーを削除できます。 さらに、 AWS CloudTrail のダッシュボードとイベント履歴 (90 日間のログが参照可能) を使用して、侵害された IAM ユーザーまたはロールによるアクティビティを確認できます。この分析により、悪意のある攻撃者が作成した可能性のある永続的なアクセスを示すことができます。また、IAM コンソールを使用して、4 時間ごとに更新される IAM 認証情報レポートを確認し、アクセスキーの最終使用時間、ユーザーの作成時間、パスワードの最終使用時間などのアクティビティを確認できます。あるいは、 Amazon Athena を使用して、 AWS CloudTrail ログを照会 し、同じ情報を取得することもできます。以下の Amazon Athena クエリは、Amazon Resource Names (ARN) で指定した IAM ユーザーにおける、特定期間内のアクティビティを取得するものです。 SELECT eventtime, eventname, awsregion, sourceipaddress, useragent FROM cloudtrail WHERE useridentity.arn = 'arn:aws:iam::1234567890:user/Name' AND -- Enter timeframe (event_date &gt;= '2022/08/04' AND event_date &lt;= '2022/11/04') ORDER BY eventtime ASC 復旧 悪意のある行為者からのアクセスを削除した後、データを復旧するための複数のオプションがあります。これについては次のセクションで説明します。Amazon S3 には現在 undelete 機能がなく、データ削除後の復旧機能がないことに注意してください。 Amazon S3 バージョニング機能 Amazon S3 バケットでバージョニングを使用することで、同じバケット内にオブジェクトの複数のバージョンを保持できます。これにより、リカバリプロセス中に特定のバージョンを復元できます。 Amazon S3 バージョニング 機能を使用すると、バケットに保存されたすべてのオブジェクトのすべてのバージョンを保存、取得、復元できます。つまり、意図しないユーザーアクションによる削除や上書きやアプリケーションの障害からより簡単に復旧できます。たとえば、オブジェクトを削除すると、Amazon S3 はオブジェクトを完全に削除するのではなく、削除マーカーを挿入します。以前のバージョンはバケット内に残り、非最新バージョンになります。これにより、必要に応じて以前のバージョンを復元できます。バージョン管理はデフォルトでは有効になっておらず、同じオブジェクトの複数のコピーを保持するため、追加のストレージコストがかかります。コストの詳細については、 Amazon S3 の料金 を参照してください。 AWS Backup の利用 AWS Backup を使用すると、Amazon S3 データのコピーを別のアクセス認証情報の下で作成および保管し、復元プロセス中にデータを復元できるようになります。AWS Backup は複数の AWS サービスに対する集中的なバックアップを提供するため、1 か所でバックアップを管理できます。Amazon S3 に対する AWS Backup では、過去 35 日間のいつでも任意の時点に復元可能な 継続的バックアップ と、無期限を含む指定期間データを保持可能な 定期的バックアップ 、2 つのオプションがあります。詳細は、 Amazon S3 に対する AWS Backup をご覧ください。 保護 このセクションでは、AWS で利用可能ないくつかの予防的セキュリティ対策について説明します。 Amazon S3 オブジェクトロック Amazon S3 バケットに対して Amazon S3 オブジェクトロック を有効にすることで、オブジェクトの変更や削除に対するさらなる保護レイヤーを追加できます。Amazon S3 オブジェクトロックを使用すると、write-once-read-many (WORM) を使ってオブジェクトを保存し、一定期間または無期限にオブジェクトが削除または上書きされるのを防ぐことができます。 AWS Backup ボールトロック Amazon S3 オブジェクトロックが Amazon S3 オブジェクトに追加の保護を提供するのと同様に、AWS Backup を使用する場合は、 AWS Backup ボールトロック を有効にすることを検討できます。これにより、バックアップボールトに保存および作成されるすべてのバックアップに対して、同じ WORM 設定が適用されます。AWS Backup ボールトロック は、AWS アカウントのルートユーザーによる誤った削除操作やマルウェアによる削除操作を防ぐのに役立ちます。 Amazon S3 インベントリ 組織内で Amazon S3 に保存されているオブジェクトの機密性を確実に理解するために、最も重要で機密性の高いデータを Amazon S3 全体で棚卸しし、データを保護し復旧を可能にするための適切なバケット設定が行われていることを確認します。 Amazon S3 インベントリ を使用すると、Amazon S3 バケット内のオブジェクトと、暗号化ステータス、レプリケーションステータス、オブジェクトロック情報などの既存の構成を把握できます。またリソース タグ を使用して、Amazon S3 内のオブジェクトの分類と所有者にラベルを付けることで、特定の Amazon S3 バケットに保存されているオブジェクトの機密性に合わせた自動アクションとコントロールを適用できます。 MFA 削除 別の予防的な対策として、Amazon S3 バージョニングを有効化している場合 多要素認証 (MFA) 削除 を適用することができます。MFA 削除は追加のセキュリティを提供し、削除操作を開始するユーザーに MFA デバイスの物理的または仮想的な所有を MFA コードで証明させることで、誤ったオブジェクト削除を防ぐのに役立ちます。これにより、削除操作に対するセキュリティレイヤーが追加されます。 一時的な認証情報に IAM ロールを使用する 多くのランサムウェア事案は、IAM アクセスキーの漏洩から発生するため、AWS では長期的な IAM アクセスキーを使用するのではなく、一時的な認証情報を提供する IAM ロールを使用することをお勧めしています。これには、AWS にアクセスする開発者に対して ID フェデレーション を使用すること、システム間アクセスに IAM ロールを使用すること、ハイブリッドアクセスに IAM Roles Anywhere を使用することが含まれます。ほとんどのユースケースでは、IAM アクセスキーを使用する必要はありません。今こそ、IAM アクセスキーの使用を環境から排除するための監査と作業を行う良い機会です。以下の手順を検討してください。 すべての AWS アカウント一覧を作成し、IAM ユーザー、認証情報が最後にローテーションされた時期と最後に使用された時期、および付加されたポリシーを特定します。 すべての AWS アカウントのルートアクセスキーを無効化して削除します。 認証情報をローテーションさせ、ユーザーに MFA を適用します。 一時的なロールベースのアクセスを活用するように再設計します。例えば、IAM ロールや IAM Roles Anywhere を使用します。 付加されたポリシーにおいて、ワイルドカードを削除するなど、最小限のアクセス許可であることを確認します。 顧客管理の AWS KMS 鍵によるサーバー側の暗号化 別の保護策として、 AWS Key Management Service (SSE-KMS) を使用したサーバー側の暗号化 を実装し、 カスタマー管理の鍵 を使用して Amazon S3 オブジェクトを暗号化することができます。カスタマー管理の鍵を使用すると、バケット内のデータを暗号化および復号化できるユーザーを指定するキーポリシーを適用する必要があり、これによりデータを保護するための追加のアクセス制御メカニズムが提供されます。また、AWS KMS 鍵を一元的に管理し、鍵の使用時期と使用者の証跡を監査することができます。 Amazon S3 に対する Amazon GuardDuty の保護 Amazon GuardDuty に対する Amazon S3 保護 を有効にできます。Amazon S3 保護により、Amazon GuardDuty はオブジェクトレベルの API 操作を監視し、バケットのデータに対する潜在的なセキュリティリスクを特定します。これには、異常な API アクティビティと Amazon S3 内のデータに関する異常な動作に関する検出結果が含まれ、セキュリティイベントの早期発見に役立ちます。 結論 この投稿では、Amazon S3 に保存されたデータを標的とするランサムウェア攻撃について学びました。事前に対策を講じることで、潜在的なランサムウェア攻撃を迅速に特定し、その後セキュリティインシデントのリスクを軽減するための追加の保護対策を講じることができます。 この投稿に関する質問がある場合は、 Security, Identity and Compliance re:Post で新しいスレッドを開始するか、 AWS サポートに問い合わせ てください。 AWS セキュリティニュースをさらに見たい方は、 X をフォローしてください。 Megan O ’ Neil Megan は脅威検知とインシデント対応に特化したプリンシパルスペシャリストソリューションアーキテクトです。Megan とそのチームは AWS の顧客が、ビジネス課題を解決する高度で、スケーラブルで、セキュアなソリューションを実装できるよう支援しています。 Karthik Ram Karthik は、オハイオ州コロンバスを拠点とするAmazon Web Services のシニアソリューションアーキテクトです。IT ネットワーク、インフラストラクチャアーキテクチャ、セキュリティの経験を持っています。AWS では、データ駆動型のアプローチを用いて顧客のビジネス課題を解決し、セキュアで革新的なクラウドソリューションの構築を支援しています。Karthik の専門分野は、脅威検知とインシデント対応（TDIR）に焦点を当てたクラウドセキュリティです。. Kyle Dickinson Kyle はシニアセキュリティソリューションアーキテクトで、脅威検知と事故対応に特化しています。彼は顧客がセキュリティインシデントに自信を持って対応できるよう支援しています。彼はまた、AWS のセキュリティ関連のライブ番組「AWS on Air: Lockdown」の司会もしています。仕事以外の時間は、ホッケーを楽しんだり、バーベキューをしたり、自分は大型犬と勘違いしている小型犬のシャーシを説得したりと、楽しく過ごしています。

このブログは 2021 年 6 月 29 日に Nabil Mohamed (Senior Technical Account Manager)、Bruce Walker (Senior Technical Account Manager)、Jessie Felix (Senior Product Manager with Amazon S3) によって執筆された内容を日本語化したものです。その後、2021 年 11 月に S3 Intelligent-Tiering Archive Instant Access ティア が発表されるなど、Amazon S3 Intelligent-Tiering ではさらにコスト効率を高めることが可能となっています。原文は こちら を参照してください。 あらゆる規模と業種の多くの顧客が、ビジネスとデータの両方が前例のないスケールで成長していると私たちに伝えています。 Amazon S3 は、どのような開発者でも、初期投資やパフォーマンスの妥協なしに、Amazon の利点を大規模に活用することを可能にします。顧客は、S3 で得られる弾力性と俊敏性を好んでいます。なぜなら、ビジネスの成長を促進するために、顧客向けの全く新しいアプリケーションや体験の創造に集中できるからです。そして、その成長に伴い、コスト管理とコスト最適化が不可欠となります。顧客は、アプリケーションのパフォーマンスに影響を与えたり、運用の負担を増やしたりすることなく、S3 のコストを最適化するための最良のアプローチを知りたがっています。データレイク、機械学習、衛星画像、DNA配列解析、コールセンターのログ、自動運転車のシミュレーション、さらにはお気に入りのメディアや自宅でのフィットネスコンテンツまで、想像できるあらゆるワークロードが S3 上で実行されています。同時に、組織全体で S3 のストレージコストを最適化するための基本原則は、一度学べば実装するのは難しくありません。移動、分析、またはアーカイブする必要があるデータがある場合でも、S3 にはデータのアクセス、パフォーマンス、およびコスト要件に最適化されたストレージクラスがあります。すべての S3 ストレージクラス は、99.999999999% (イレブンナイン) の耐久性と最高の可用性を実現するように設計されています。 このブログの目標は、予測可能で変化するアクセスパターンを持つワークロードのストレージコストを管理する方法と、コスト削減を実現するための具体的な方法について理解していただくことです。 予測可能なアクセスパターンを持つワークロードの最適化 一定期間後にアクセス頻度が低くなるデータをお持ちですか？例えば、ソーシャルメディアアプリのようなユーザー生成コンテンツを考えてみましょう。私たちはネットワークに動画や写真を共有しますが、アップロード直後は頻繁にアクセスされるものの、数週間後、あるいは数日後や数時間後には、アクセス頻度が低くなります。このようなユースケースでは、多くの顧客はデータがいつアクセス頻度が低くなるかを知っており、S3 標準ストレージクラスから低頻度アクセスやアーカイブ用に最適化された低コストのストレージクラスにデータを移動すべき適切なタイミングを通常特定できます。 予測可能なアクセスパターンを持つ多くの顧客は、アカウント内のすべてのバケットの使用状況を詳細に理解するために、 S3 Storage Lens を使い始めます。S3 Storage Lens の高度なメトリクスを有効にしている場合、アクセスが頻繁な、まれな、あるいはほとんどないデータセット (バケット) を特定するための アクティビティメトリクス にアクセスできます。GET リクエストやダウンロードバイト数などのメトリクスは、データセットが毎日どの程度アクセスされているかを示します。このデータを数ヶ月間にわたって傾向分析し (高度なメトリクスでは長期間のデータ保持が可能)、アクセスパターンの一貫性を理解し、アクセス頻度が低くなったデータセットを特定することができます。 データセットがいつアクセス頻度が低くなるか、またはアーカイブ可能になるかがわかれば、 Amazon S3 ライフサイクル ルールを簡単に設定して、S3 標準ストレージクラスに保存されているオブジェクトを、データの経過時間に基づいて自動的に S3 標準 – 低頻度アクセス、S3 1ゾーン – 低頻度アクセス、および/または、S3 Glacier ストレージクラスに移行することができます。ライフサイクルポリシーは、AWS マネジメントコンソール、 S3 REST API 、AWS SDK、または AWS コマンドラインインターフェイス (CLI) で設定および管理可能です。ポリシーはプレフィックスレベルまたはバケットレベルで指定します。例えば、オブジェクトを作成してから 30 日後に S3 標準 – 低頻度アクセスストレージクラスに移行したり、1 年後に S3 Glacier ストレージクラスにアーカイブしたりすることを選択できます。 未知または変化するアクセスパターンを持つワークロードの最適化 アクセスパターンが未知または変化するデータがある場合はどうすればよいでしょうか？多くの顧客は、 Amazon S3 Intelligent-Tiering (S3 Intelligent-Tiering) を使用して共有データセットを保存しています。このデータセットは、分析、機械学習、リアルタイムモニタリング、その他のデータレイクのユースケースのために、異なるアプリケーション、チーム、個人によって集約されアクセスされます。これらのユースケースでは、組織内の多くのユーザーが異なるツールを使用して S3 にアクセスすることが一般的です。例えば、 Amazon Athena を使用すれば標準 SQL で S3 のデータを簡単に分析できますし、 Amazon Redshift Spectrum を使用してデータのロードや変換なしに S3 のペタバイト規模のデータに対してクエリを実行することもできます。これらのユースケースの多くでは、年間を通じてアクセスパターンが大きく変動し、ほとんどまたは全くアクセスがない状態から、1 ヶ月に複数回データが読み取られる状態まで幅広く変化する可能性があります。これが S3 標準 – 低頻度アクセスストレージクラスに保存されている場合、取り出し料金が発生する可能性があります。 アクセスパターンが変化するユースケースを持つ顧客や、カスタマイズされた階層化ルールを管理したくない顧客は、S3 Intelligent-Tiering をデフォルトのストレージクラスとして使用することを検討してください。S3 Intelligent-Tiering は、アクセスパターンが変化しても、パフォーマンスへの影響なし、運用オーバーヘッドなし、取り出し料金なしで、コスト削減の方法を提供します。これは、4 つのアクセス階層にオブジェクトを保存することで機能します：高頻度アクセスと低頻度アクセス用に最適化された 2 つの低レイテンシーアクセス階層、および非同期アクセス用に設計された 2 つのオプションのアーカイブアクセス階層です。(訳註: 現在の S3 Intelligent-Tiering にはアーカイブインスタントアクセス階層が追加されており、5 つのアクセス階層を利用することが可能です) オブジェクトを S3 Intelligent-Tiering にアップロードまたは移行すると、自動的に高頻度アクセス階層に保存されます。S3 Intelligent-Tiering は、アクセスパターンを監視し、30 日間連続でアクセスされていないオブジェクトを低頻度アクセス階層に移動させることで機能します。また、1 つまたは両方のオプションのアーカイブアクセス階層を有効にすることもできます。アーカイブアクセス階層を有効にすると、S3 Intelligent-Tiering は 90 日間連続でアクセスされていないオブジェクトをアーカイブアクセス階層に自動的に移動します。180 日間連続でアクセスがない場合、S3 Intelligent-Tiering はオブジェクトをディープアーカイブアクセス階層に移動します。後でオブジェクトに再びアクセスされた場合、高頻度アクセス階層に戻されます。 このアプローチにより、考える必要なく、ストレージコストを最大 95% 削減することができます。S3 Intelligent-Tiering にはオブジェクト数に応じた小額の月次監視料金がかかりますが、これはオブジェクトのサイズが大きくなるほど、節約額が大きくなることを意味します。128 KB 未満のオブジェクトは自動階層化の対象外であるため、S3 標準ストレージクラスに保持することをお勧めします。顧客が S3 Intelligent-Tiering を好む理由は、取り出し料金がなく、アクセスパターンが変化しても予期せぬストレージ料金の増加がないためです。 ストレージ節約シナリオ 要約すると、S3 Storage Lens と S3 ライフサイクルポリシーを組み合わせて使用することで、オブジェクトをより安価なストレージクラスに移動する適切なタイミングを知っているか、容易に特定できる場合に、最大のストレージコスト削減を実現できます。また、アクセスパターンが未知または変化するデータに対しては、S3 Intelligent-Tiering クラスを使用することで最大のストレージコスト削減を実現できます。以下では、米国東部 (バージニア北部) リージョンにある、合計 1 PB のストレージと 1 億個のオブジェクトを持つバケットの 2 つの異なるワークロードを例に挙げ、アクセスパターンに適したストレージクラスを選択することで得られる潜在的なストレージコスト削減効果を示します。価格については、 S3 の公開価格 を参照してください。また AWS Pricing Calculator for Amazon S3 を使用して、ワークロードの S3 ストレージコストを見積もることもできます。 最初のシナリオでは、オンラインビデオプラットフォームのメディアアセットを作成後 30 日で S3 標準 – 低頻度アクセスストレージクラスに移動し、オブジェクトの 10% が月に 1 回アクセスされると仮定します。1 年間で、このユースケースでは S3 標準 – 低頻度アクセスを使用した場合 $90,583 (33.3%)、S3 Intelligent-Tiering を使用した場合 $89,711 (33.0%) のストレージコスト削減が達成されます。アクセスパターンが変化しないことが分かっている場合、S3 標準 – 低頻度アクセスストレージクラスを使用することで、このユースケースでの最低ストレージコストを実現できます。アクセスパターンの予測可能性が不確かな場合でも、S3 Intelligent-Tiering を使用することで、取り出し料金の急増を心配することなく、大幅なストレージコスト削減を実現できます。 予測可能なアクセスパターン 年間コスト S3 標準 標準 – 低頻度アクセス S3 Intelligent-Tiering (アーカイブ無効) ストレージコスト $270,999 $166,762 $178,288 PUT リクエスト* $500 $500 $500 GET リクエスト $48 $120 $48 ライフサイクル移行リクエスト* NA $1,000 NA データ取り出しリクエスト Free $12,582 Free モニタリングおよびオートメーション NA NA $3,000 トータルコスト $271,547 $180,964 $181,836 * PUT リクエストとライフサイクル移行リクエストは、オブジェクトのアップロードまたは移行時に発生する一回限りの料金です 2 つ目のシナリオでは、データウェアハウジングのデータセットを S3 Intelligent-Tiering にアップロードするとします。このユースケースでは、全オブジェクトの 30% が、組織全体での計画外の分析やレポーティングワークフローのために、月に少なくとも 4 回アクセスされると仮定します。1 年間で、このユースケースでは S3 Intelligent-Tiering を使用することで 67,273 ドル (24.7%) のストレージコスト削減が達成されます。このようなユースケースは、取り出し料金によって S3 標準よりも高くなる可能性があるため、S3 標準 – 低頻度アクセスには適していません。S3 Intelligent-Tiering を使用すれば、アクセスパターンが変化しても、パフォーマンスへの影響や運用のオーバーヘッド、取り出し料金なしで、コストを削減できます。 アクセスパターンの変更 年間コスト S3 標準 S3 Intelligent-Tiering (アーカイブ無効) 標準 – 低頻度アクセス ストレージコスト $270,999 $200,198 $166,762 PUT リクエスト* $500 $500 $500 GET リクエスト $576 $576 $1,320 ライフサイクル移行リクエスト* NA NA $1,000 データ取り出しリクエスト Free Free $138,412 モニタリングおよびオートメーション NA $3,000 NA トータルコスト $271,547 $204,274 $307,994 * PUTリクエストとライフサイクル移行リクエストは、オブジェクトをアップロードまたは移行する際の一回限りの料金です 多くの場合、顧客は長期間アクセスされていないデータセットのサブセットに対して、自動的にストレージコストをさらに削減したいと考えています。例えば、研究プロジェクトや機械学習モデルの再トレーニングにのみ時々使用される過去のデータセットがあります。このようなユースケースでは、データをアーカイブし、即座にアクセス可能になるまで数分から数時間待つことを許容できるかもしれません。これがあなたのユースケースに当てはまるなら、さらなるコスト削減のために S3 Intelligent-Tiering アーカイブアクセス階層 を有効にすることをお勧めします。 年間コスト S3 Intelligent-Tiering (アーカイブ無効) S3 Intelligent-Tiering (アーカイブ有効) ストレージコスト $200,198 $158,501 PUT リクエスト* $500 $500 GET リクエスト $576 $576 ライフサイクル移行リクエスト* NA NA データ取り出しリクエスト Free Free モニタリングおよびオートメーション $3,000 $3,000 トータルコスト $204,274 $162,577 * PUTリクエストとライフサイクルリクエストは、オブジェクトをアップロードまたは移行する際の一回限りの料金です * S3 Intelligent-Tiering (アーカイブ有効) の前提条件：オブジェクトの 30% を高頻度アクセス階層に、20% を低頻度アクセス階層に、25% をアーカイブアクセス階層に、25% をディープアーカイブアクセス階層に保存 最後に覚えておくべきいくつかのこと: オブジェクトサイズ: S3 Intelligent-Tiering は任意のサイズのオブジェクトに使用できますが、128 KB 未満のオブジェクトは高頻度アクセス階層に保持されます。アーカイブアクセス階層またはディープアーカイブアクセス階層にアーカイブされた各オブジェクトについて、Amazon S3 はオブジェクト名とその他のメタデータ用に 8 KB のストレージ (S3 標準ストレージクラス料金で課金) と、インデックスおよび関連メタデータ用に 32 KB のストレージ (S3 Glacier Flexible Retrieval および S3 Glacier Deep Archive ストレージクラス料金で課金) を使用します。これにより、すべての S3 オブジェクトのリアルタイムリストまたは S3 インベントリレポートを取得できます。 オブジェクトの寿命:&nbsp; S3 Intelligent-Tiering は 30 日以上の寿命を持つオブジェクトに適しており、このストレージクラスを使用するすべてのオブジェクトは最低 30 日が課金対象となります。 耐久性と可用性: Amazon S3 Intelligent-Tiering は 99.9% の可用性と 99.999999999% の耐久性を目指して設計されています。 価格: 月間のストレージ、リクエスト、データ転送 に対して料金を支払います。S3 Intelligent-Tiering を使用する場合、モニタリングおよびオートメーションのために小額のオブジェクト単位の月額料金を支払います。S3 Intelligent-Tiering に取り出し料金はなく、階層間のデータ移動に対する料金もありません。高頻度アクセス階層のオブジェクトは S3 標準と同じ料金で課金され、低頻度アクセス階層のオブジェクトは S3 標準 – 低頻度アクセスと同じ料金で課金され、アーカイブアクセス階層のオブジェクトは S3 Glacier Flexible Retrieval と同じレートで課金され、ディープアーカイブアクセス層のオブジェクトは S3 Glacier Deep Archive と同じレートで課金されます。 API と CLI によるアクセス: S3 CLI と S3 API を使用して、INTELLIGENT_TIERING ストレージクラスで S3 Intelligent-Tiering を利用できます。また、特定のバケットに対して PUT、GET、DELETE 設定 API を使用して S3 Intelligent-Tiering アーカイブを設定することもできます。 サポートする機能: S3 Intelligent-Tiering は、オブジェクトのアクセス層を報告する S3 インベントリや、データを任意の AWS リージョンにレプリケートする S3 プリケーションなどの機能をサポートしています。 結論 このブログでは、予測可能なアクセスパターンを持つユースケースと、変化するアクセスパターンを持つユースケースの ストレージコストを最適化 する方法について説明します。多くの場合、適切なストレージクラスを選択することで、お客様のストレージコストを最大 95% 削減できることがわかっています。これを実現するために、一部のお客様は異なるバケット間でカスタマイズされた階層化 S3 ライフサイクルポリシーを構築することを好み、多くのお客様は自動的にストレージコストを節約できる簡単な方法として S3 Intelligent-Tiering を使用しています。 重要なのは、データのアクセスパターンとビジネスニーズに基づいて適切なアプローチを選択することです。始める際には、ワークロードに最適なアプローチを決定するために、オブジェクトの以下のプロパティを考慮してください: 判断基準 S3 Intelligent-Tiering の検討 ストレージクラスとライフサイクル管理の検討 Overhead ストレージの最適化にほとんどまたは全くエンジニアリングリソースを割り当てる意思がない ストレージの最適化にリソースを割り当てる意思がある アクセス頻度 データレイク、ビジネスインテリジェンス、機械学習などの未知または変化するアクセスパターン ロングテールメディア、バックアップ、災害復旧などの予測可能なアクセスパターン オブジェクトのサイズ S3 Intelligent-Tiering は小額の階層化料金を請求し、自動階層化の対象となる最小オブジェクトサイズは 128 KB です。より小さなオブジェクトも保存できますが、常に高頻度アクセス階層の料金で課金されます。 標準 – 低頻度アクセスストレージクラスと 1 ゾーン – 低頻度アクセスストレージクラスの最小課金対象オブジェクトサイズは 128 KB、S3 Glacier Deep Archive ストレージクラスの最小課金対象オブジェクトサイズは 40 KB です。 オブジェクトの寿命 30 日以上保存される長寿命オブジェクトに最適。 S3 標準は 30 日以内に削除される短寿命オブジェクトに最適。 標準 – 低頻度アクセスストレージクラスと 1 ゾーン – 低頻度アクセスストレージクラスは 30 日以上保存される長寿命オブジェクトに最適、S3 Glacier Flexible Retrieval は 90 日以上、Glacier Deep Archive は 180 日以上の保存に最適 予測可能で変化するアクセスパターンを持つワークロードのストレージコストを制御および最適化する方法に関するこのブログをお読みいただき、ありがとうございます。Amazon S3 バケットの数が増加し、数十または数百のアカウントにまたがっている場合は、 「5 Ways to reduce data storage costs using Amazon S3 Storage Lens (Amazon S3 Storage Lens を使用してデータストレージコストを削減する 5 つの方法)」というブログ も併せてお読みください。これにより、S3 Storage Lens を使用して典型的なコスト削減の機会を特定する方法と、それらのコスト削減を実現するための変更を実施する方法について基本的な理解を得ることができます。 Nabil Mohamed Nabil Mohamed は AWS のシニアテクニカルアカウントマネージャーで、顧客の運用効率とコスト最適化の推進に注力しています。シアトルを拠点としており、ハイキングや妻との世界旅行、そして 2 匹の猫 (メインクーン) と過ごす時間を楽しんでいます。 Bruce Walker Bruce Walker はサンフランシスコを拠点とする AWS のシニアテクニカルアカウントマネージャーです。彼は顧客との信頼性、最適化、および運用メカニズムの改善に焦点を当てています。ブルースは妻と旅行することが大好きで、オーストラリアとキプロスの両方で家族と時間を過ごすことを楽しんでいます。 Jessie Felix Jessie Felix は、Amazon S3 のシニアプロダクトマネージャーで、S3 Intelligent-Tiering などの S3 のストレージ技術とデータサイエンスに焦点を当てています。2015 年に Amazon に入社し、AWS リクルーティング部門の分析およびデータインフラストラクチャの構築に携わりました。ビッグデータ分析への情熱から、2017 年に Amazon S3 チームに加わりました。仕事以外では、地元のカフェに行ったり、妻とラブラドール・レトリバーと一緒に湖畔でくつろいだりすることを楽しんでいます。

この投稿は株式会社ニコンの森谷 俊洋 氏、村上 隆哉 氏より金属 3D プリンター向けリモートモニタリングプラットフォーム開発の取り組みについて寄稿いただいたものです。本寄稿は前後編の 2 回に分けてご紹介するうちの前編となります。後編の内容は こちら よりアクセスできますので、ご興味のある回をご覧いただければ幸いです。 はじめに 株式会社ニコンではレーザー加工機 Lasermeister（レーザーマイスター）シリーズ を開発・販売しています。半導体露光装置で培った光計測、精密制御を応用し、レーザーによる様々な加工を高精度で行うことができ、金属積層造形からマーキング、接合、様々な材料の精密除去加工まで、材料加工分野の幅広いニーズに対応できる製品です。今回、この Lasermeister を対象にリモート監視を行う IoT 基盤として、 リモートモニタリングプラットフォーム One Board を開発しました。2024 年 10 月時点で One Board に接続済みの金属 3D プリンターは数十台を超え、今後も増加する見込みです。この One Board は AWS 上に構築しています。金属 3D プリンターからのデータ収集には AWS IoT Greengrass、ユーザー認証には Amazon Cognito を利用し、また時系列データの蓄積には、時系列データを扱うための完全マネージド型データベースであり、IoT 基盤のデータ蓄積プラットフォームとして実績のある Amazon Timestream を活用しました。Timestream により、金属 3D プリンターに搭載された各種センサから発生した時系列データへの素早いアクセスを実現しています。このように AWS の各種サービスを組み合わせることで 10 ヶ月という短期間でシステムを構築でき、また構築後の運用コストも安価に抑えられています。 本寄稿では、Lasermeister シリーズや One Board の概要を述べた後 One Board のアーキテクチャを説明します。また、後編では Timestream のデータモデルといった技術面を説明します。 製品概要 レーザー加工機 Lasermeister シリーズ レーザー加工機 Lasermeister シリーズは、金属積層造形を行う金属 3D プリンター Lasermeister 100A シリーズと Lasermeister LM300A、および、精密除去加工を行うレーザー除去加工機 Lasermeister 1000S シリーズからなります。この内、リモートモニタリングプラットフォーム One Board の現時点での対象は Lasermeister 100A シリーズと Lasermeister LM300A です。 . &nbsp;&nbsp; &nbsp; &nbsp; 参考1. Lasermeister 100A シリーズと Lasermeister LM300A の外観 Lasermeister 100A シリーズは、手軽に金属積層造形の技術を試していただけるよう、「誰でも簡単に使える装置」をコンセプトに開発した金属 3D プリンターです。とてもコンパクトなサイズで設置場所を選ばず、コンクリート建屋であればそのまま設置が可能でき、安全規格にも準拠、学生やデザイナーなど誰でも安心して使える装置となっています。また金属積層造形には様々な金属を金属粉体として利用可能です。 参考2. Lasermeister 100A シリーズを使った金属積層造形の例 一方、 Lasermeister LM300A は産業用途を考慮して開発した金属 3D プリンターです。主な特徴の一つとして、3D スキャナー Lasermeister SB100 と連携することで、タービンブレードなどの産業用部品向けの高精度で自動化された補修ソリューションを提供します。 リモートモニタリングプラットフォーム One Board One Board は、Lasermeister の状態を遠隔監視するプラットフォームであり、PC だけでなくスマホやタブレットなどを使って、金属 3D プリンターのステータスや金属粉体の残量といった状態をどこからでも簡単に把握できます。金属積層造形が完了するまでの残り時間も確認できるため、金属積層造形の終了に合わせて金属 3D プリンターの設置場所に向かうといった、利用者の効率的な働き方を推進します。この他、金属 3D プリンターのイベント履歴や金属 3D プリンター内に搭載された各種センサの値の時系列変化も確認できるため、金属 3D プリンターが正常に稼働していたかどうかや、万一トラブルが発生したときの原因追及にも使用できます。 図1. One Board の導入利点 One Board の画面では所有する金属 3D プリンターの一覧が表示され、各装置のステータスや粉体残量等を一目で確認できます。 参考3. One Boardの画面イメージ さらに金属 3D プリンターごとの詳細データとして、金属積層造形が完了するまでの残り時間やイベント履歴、各種センサ値の時系列変化を確認できます。 参考4. One Boardの画面イメージ また、万一 金属 3D プリンターがトラブルで緊急停止したとしても、利用者にはメール通知が届くため早期に気付くことができるとともに、カスタマーサポートにも同時に通知が共有され、トラブルの早期解決に貢献します。 アーキテクチャ One Board では以下のアーキテクチャを採用しています： 以下に、図中の①～④の処理の概要を記載します： 通信 SIM を搭載したゲートウェイ機器内にある AWS IoT Greengrass が定期的に金属 3D プリンターのセンサ値のデータを収集し、携帯回線を通じて Amazon S3 に送信。その後、Amazon S3 に保存されたことをトリガーに AWS Lambda が起動し、必要なデータの抽出や加工、Timestream への保存を行う。 AWS IoT Greengrass は数秒に 1 回の頻度で 金属 3D プリンターのステータスや金属粉体の残量、各種イベント等を収集するが、各種イベントのうち、金属 3D プリンターのアラートやエラーに関するものは Amazon SES を通じて 利用者やニコンの保守要員へ即座にメール通知する。 Amazon Timestream に保存された各種データは、Grafana と React を使って構築した Web アプリを通じてユーザーが確認できる。 One Board の各種設定値や構成情報は Amazon RDS for MySQL に保存し、各サービスが適宜参照している。 AWS で運用する利点 One Board をお客様に初回リリースしてから2年以上が経過した現在、One Board を運用する上での AWS の利点として以下を感じています： 多様なサービスの情報集約 One Board は AWS が提供する多様なサービスを組み合わせて構築したが、それら各サービスのログは Amazon CloudWatch に集約されており、運用中の挙動を確認しやすい。他にもAPI の使用状況は AWS CloudTrail に、各種最適化に関する情報は AWS Trusted Advisor に集約されており、それら情報の定期的なモニタリングに便利である。 安価な運用コスト 遠隔地にある金属 3D プリンターの状態を常時確認でき、万一のトラブルにも備えられる価値を考慮すると、AWS のコストは安価と考えている。また、AWS Billing and Cost Management にサービスごとのコストが整理されて表示され、コスト低減活動もやりやすい。 Timestream のスケーラビリティ 将来 One Board に接続される金属 3D プリンターの台数やユーザー数が更に増加する予定であり、蓄積されるデータ量の増加が想定されるものの、こちらについては Serverless アーキテクチャを採用する Timestream のスケーラビリティに期待している。 本稿では、リモートモニタリングプラットフォーム One Board の概要と、それを支えるアーキテクチャや AWS で運用することのメリットについて寄稿いただきました。後編については、「 【寄稿】ニコンのリモートモニタリングプラットフォームにおける Amazon Timestream の活用 」をご参照ください。 著者について 森谷俊洋 株式会社ニコン 次世代プロジェクト本部 第二開発部 第一開発課 リモートモニタリングプラットフォーム「One Board」のソフトウェア開発を担当。デジタルマニュファクチャリングへのAWSの活用に取り組んでいます。 村上隆哉 株式会社ニコン アドバンスドマニュファクチャリング事業部 戦略協業統括室 リモートモニタリングプラットフォーム「One Board」やLasermeisterシリーズのソフトウェア開発マネージャーを担当。デジタルマニュファクチャリングの推進をミッションとし、日々取り組んでいます。

この投稿は株式会社ニコンの森谷 俊洋 氏、村上 隆哉 氏より金属 3D プリンター向けリモートモニタリングプラットフォームにおける Amazon Timestream 活用の取り組みについて寄稿いただいたものです。本寄稿は前後編の 2 回に分けてご紹介するうちの後編となります。前編の内容は こちら よりアクセスできますので、ご興味のある回をご覧いただければ幸いです。 Amazon Timestream の活用 Amazon Timestream を選んだ理由 One Board の開発当初、オンプレミスのデータベースとクラウドのデータベースのどちらを採用するかをまず検討しました。その結果、以下の理由からクラウドのデータベースを選択しました： マネージドサービスとしてスケールアップ/ダウンが自動で行われるため、オンプレミスに比べて手間がかからず開発作業に注力できること ベストプラクティスも広く公開されていること 次にAWS以外のクラウドベンダーが提供するデータベースとも比較しました。その結果、以下の理由からAWSを採用しました： 社内で AWS の開発事例が多いこと AWS とコーポレート契約を締結しており、コストを抑えて利用できること 24 時間 365 日の問い合わせ可能サポートがあること 尚、One Board では時系列データ以外のデータ保管には Amazon RDS for MySQL を利用しており、ケースバイケースで最適なデータベースを選択しています。 データモデル One Board が Timestream で適用しているデータモデルの一部を以下に示します。One Board では単一のレコードに複数の測定値を登録するマルチメジャーレコードを採用しています： 表 1. One Board のデータモデル 各列の概要は以下の通りです： Serial_number 金属 3D プリンターの機体ごとの識別子。機体ごとのデータ集計に利用する Time レコードのタイムスタンプ Laser_power 金属 3D プリンターが金属積層造形に使うレーザーの出力の実測値 [kW] 。期待どおりに出力されることが金属積層造形の品質に影響するため、品質を示す指標の一つとして収集する Oximeter_1, Oximeter_2 金属 3D プリンター内に搭載する２種類の酸素濃度計の計測値 [%] 。金属 3D プリンターがレーザーを使って金属積層造形を行うには、金属 3D プリンター内の酸素濃度が一定値以下となる必要がある。また、金属 3D プリンターのオペレーション・ドアは安全のため金属積層造形中には自動施錠され、金属積層造形完了後に酸素濃度が一定値以上になると自動解除される。このように酸素濃度は金属積層造形の重要な指標であり、それぞれ計測レンジが異なる2種類の酸素濃度系を収集し、金属 3D プリンターが正しく動作したことを示す指標の一つとして収集する Gas_pressure レーザーを使った金属積層造形時の安全性を確保する不活性ガスの供給圧力 [kPa] 。供給圧力が一定値以下になると、安全のために金属積層造形が自動的に停止される。One Board は金属 3D プリンターが正しく動作したことを示す指標の一つとして収集する データ量や参照頻度 Amazon Timestream に保存するデータの量や参照頻度は以下の通りです： 発生するデータ量 金属 3D プリンター1台あたり、数百MB/日 保存されているデータの総量 2024 年 10 月時点で数百 GB 超 データの参照頻度 利用者一人あたり、1 時間に 1 回ほど参照 ※ 主なユース―ケースとして、金属 3D プリンターの稼働中にそのステータスや金属積層造形の予定完了時刻を確認する使い方を想定。 クエリのレスポンス Grafana から Timestream にクエリをかけてグラフ一つを表示するまでに約 2 秒 Amazon Timestream の良かった点 まず時系列データの保存に関しては、マルチメジャーレコードを利用することで直感的に格納データを理解でき有用でした。また、性能やコストの異なるメモリストアとマグネティックストアの２つのストレージ階層を、特段意識せずとも自動的に使い分けてくれる点も有用でした。一方で時系列データの活用に関しては、SQL として Date &amp; Time の変換機能 や Window 関数など一通りの機能が揃っており、使い慣れた SQL を利用することで取得したデータを様々に加工して Grafana へ表示することが可能である点を評価しています。また AWS マネジメントコンソールから容易に SQL を発行できる点も好評です。さらに現時点で性能問題は発生しておらず、安定したレスポンスを維持できています。 開発完遂に向けた取り組み One Board は開発者数 5 人ほどで開発をスタート、当時は筆者の所属部署には金属 3D プリンターの組込ソフトウェアの開発者はいるものの、クラウド開発の知見は皆無であったため、予定した期間内での開発完遂を目指し以下の取り組みを実施しました。その結果、約 10 か月間という短い期間で社外のお客様にリリースすることができました： 既に AWS 上での開発経験がある他部署に相談し協力を依頼した リーンスタートアップの手法を採用し、仮説設定→最低限の機能の試作→仮説検証のサイクルを繰り返した AWS の技術サポート窓口を適宜活用した 特に 3 点目に関しては、システム設計においてはマルチテナントを実現する必要がある中で、レコードへのアクセス権を厳密に管理するための方法が課題となりました。結果としてレコードのオーナーごとにデータベースを分け、データベース毎にアクセス権を限定した IAM ユーザーを用意するサイロモデルを採用することにしましたが、そういった過程において適宜 AWS サポート窓口を活用することで短時間で課題解決に至ることができました。 今後の方向性 現在は金属 3D プリンターの遠隔監視に使用している One Board の今後の方向性として、以下を想定しています。 蓄積したデータの活用 運用開始から 2 年以上が経過し、金属 3D プリンター内に設置した各種センサのデータが一定量蓄積されてきた。その間、金属 3D プリンターにおけるレーザー等の重要部品の故障事例も記録しているため、これらを組み合わせて、重要部品の故障予知の実現につなげたい サプライチェーン上で前後の工程に関するデータの蓄積・活用 例えば、金属 3D プリンターによる金属積層造形の品質に大きく関わり、その前工程で調達する金属粉体の状態やロット、あるいは、後工程である造形結果の外観検査結果を One Board に蓄積し、金属 3D プリンターのデータと組み合わせて確認することで、金属積層造形の品質向上に活用することを想定している エンジニアリングチェーン上で前後の工程に関するデータの蓄積・活用 金属 3D プリンターでは、事前に造形対象物の 3D CAD を用意し、それを CAM ソフトウェアでツールパスとよばれる金属3D プリンターの動作を表すデータに変換した後、ツールパスを基に金属積層造形を実行することが一般的である。このプロセスにおいて、3D CAD の形状や CAM ソフトウェアによる変換結果も金属積層造形の精度や造形時間に影響を与える。これら 3D CAD や CAM ソフトウェアのデータも、金属 3D プリンターのデータと組み合わせて One Board に蓄積することで、造形対象物に応じた金属積層造形の精度向上や造形時間の短縮に活用したい 図 1. 金属 3D プリンターにおけるサプライチェーンとエンジニアリングチェーン おわりに 本稿では、株式会社ニコンが開発・販売する金属 3D プリンター向けのリモートプラットフォーム One Board についてご紹介しました。One Board は AWS の様々なサービスを活用し構築しており、One Board の遠隔監視機能がもたらす価値を鑑みると、運用コストも安価に抑えることに成功しています。今後は蓄積したデータの活用や、サプライチェーンやエンジニアリングチェーンの前後の工程のデータの蓄積・活用を想定しています。 本寄稿シリーズでは、前編「 【寄稿】ニコンの金属 3D プリンター向けリモートモニタリングプラットフォーム開発の取り組み 」にて Lasermeister シリーズ や One Board の概要と One Board を支えるアーキテクチャやAWS で運用するメリットを説明いただきました。また、後編（本稿）では Amazon Timestream の活用やデータモデル設計といった技術面を説明いただきました。 著者について 森谷俊洋 株式会社ニコン 次世代プロジェクト本部 第二開発部 第一開発課 リモートモニタリングプラットフォーム「One Board」のソフトウェア開発を担当。デジタルマニュファクチャリングへのAWSの活用に取り組んでいます。 村上隆哉 株式会社ニコン アドバンスドマニュファクチャリング事業部 戦略協業統括室 リモートモニタリングプラットフォーム「One Board」やLasermeisterシリーズのソフトウェア開発マネージャーを担当。デジタルマニュファクチャリングの推進をミッションとし、日々取り組んでいます。

広告やマーケティングに携わる方々を主な対象として、2024 年 10 月 17 日に「生成 AI と AWS Ad/Marketing Tech Services で実現する広告・マーケティングイノベーション」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログではセミナーの内容を簡単にご紹介します。 見所としては以下3点です。 【いまさら聞けない!?】AWS の Ad/Mktg Tech サービスの効果的な活用方法 生成 AI やデータクリーンルーム等、AWS の Ad/Mktg Tech サービスの最新アップデート（2024年10月時点） データコラボレーションサービスである AWS Clean Rooms のお客様事例 Session 1. オープニング アマゾン ウェブ サービス ジャパン合同会社 事業開発統括本部 シニア事業開発マネジャー 松本 鋼治 資料ダウンロードリンク オープニングでは、本イベントの開催目的や、Amazon グループにおける広告マーケティングテクノロジーの位置付け、AWSとしてどのようなコンセプトでソリューション開発や支援を行っているかについて、全体概要をご説明いたしました。 広告・マーケティングテクノロジーの分野は Amazon グループ全体においても重要な位置づけを持ち、AWS の技術がその基盤を支えています。Amazon が提供する多様なサービス（eコマース、リテールメディアなど）は、AWSを活用した適切なマーケティングの仕組みとともに進化を続けています。特に、AWSの広告・マーケティングソリューションは以下の3つを重要なコンセプトとして展開されています： イノベーションの加速 コストパフォーマンスの最適化 データ連携の強化 また、生成 AI の活用にはデータが不可欠です。AWS のデータ管理技術は、プライバシーやセキュリティを確保しながら、企業のデジタルトランスフォーメーションを支援します。また、個人情報保護規制が強化される中、ファーストパーティデータを適切に管理し、ビジネスパートナーと連携して活用する仕組み作りが不可欠です。企業が競争力を高めるには、顧客やパートナーと共にデータや技術を活用し、安心・安全なイノベーションを推進することが求められていると考えます。 Session 2. 顧客の行動の理解促進と最適なキャンペーン展開 アマゾン ウェブ サービス ジャパン合同会社 ストラテジックインダストリ技術本部 デジタルソリューション部 ソリューションアーキテクト 関藤 寛喜 資料ダウンロードリンク 本セッションでは、デジタルマーケティングの課題と、AWS が提供する広告・マーケティングテクノロジーの最新ソリューション（2024年10月時点）について解説いたしました。 デジタルマーケティングの課題として、昨今の 3rd Party Cookie に関する規制の影響もあり、顧客行動の理解を深めて特定のセグメントに対して的確にキャンペーン情報を送信する上で、ターゲティングの精度やプライバシーへの配慮の難しさが挙げられます。それらの課題を解決するソリューションとして、Amazon Ads が提供するAmazon Marketing Cloud、そして AWS が提供する AWS Clean Rooms と AWS Entity Resolution について、それらの違いやサービス概要について解説いたしました。特に、AWS Clean Rooms と AWS Entity Resolution のサービスを組み合わせて実現する具体的なユースケースと、各サービスの最新アップデート（2024年10月時点）についてご紹介いたしました。 また、生成 AI を活用してユーザープロファイルを作成するユースケースや、実運用で課題になりがちな日本語データの突合のための前処理（ID マッチング）を AWS Entity Resolution で実現する方法についてもご紹介しています。 Session 3. AWS で実現するクッキーレス時代のマーケティング変革 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第三ソリューション部 部長/シニアソリューションアーキテクト 鈴木 浩之 資料ダウンロードリンク 本セッションでは、お客様からよく伺う広告マーケティングに関する課題をもとにした以下の３つのユースケースを取り上げ、生成 AI 機能を含む様々な AWS サービスを活用したマーケティング変革のためのアプローチについてご紹介いたしました。 他社データとのコラボレーションで顧客プロファイル拡充 パーソナライズしたセグメントにキャンペーン送信 Web サイトのユーザ行動分析 ユースケース 1 では、AWS Clean Rooms と AWS Entity Resolutions を利用した Customer 360 強化のためのデータコラボレーションや、生成 AI 機能によって進化した BI サービス Amazon QuickSight による可視化についてデモを交えてご紹介しました。ユースケース 2 では、マーケティングコミュニケーションサービス Amazon Pinpointと、Amazon Bedrock の生成 AI 機能を組み合わせ、顧客離反予測からパーソナライズされたオファー生成と提案の自動化のユースケースをご紹介しました。また、ユースケース 3 では、Google Analytics や Amplitude などの 3rd Party ツールと連携した WEB サイトのユーザー行動分析およびレコメンド生成の実現方法について解説しています。 Session 4. AWS で拓く地方都市における地域共創プラットフォームの未来 株式会社中国新聞社 メディア開発局 メディア開発部長 石井 将文様 資料ダウンロードリンク 株式会社中国新聞社様は、従来の強みを活かしながら新たな価値提供へのチャレンジを進められており、デジタル領域のプレゼンスを高めるビジネスドメインとして開始した新サービスである地域IDプラットホーム「たるポ」と、関連する取り組みについてご紹介頂きました。 「たるポ」は B2C と B2B それぞれの領域に様々な価値を提供するプラットフォームです。例として B2C 領域では、一つの ID で様々なサービスと幅広く連携可能になります。B2B 領域では、たるポのプラットフォームをそのまま導入することで、早く安く会員基盤を構築できる点や、個人情報と興味関心・行動などのデータを掛け合わせたデータ分析が可能となります。 たるポの特徴 AWS採用の理由と技術的背景について、複数ある中から以下３点を取り挙げられています スケーラビリティと可用性: 利用者の増加や外部システムとの連携を見据えた柔軟性確保、サービスの継続性担保。 マネージドサービスの活用: 運用コストを低減し、セキュリティを担保しながらも効率的な拡張を可能に エコシステムの充実: 外部連携も容易にする多種多様なサービス、ユーザーコミュニティの強さ、ドキュメントの豊富さ システム構成はサーバーレスを採用し、運用負荷を軽減されています。さらに、データ分析機能としてサーバーレス BI の Amazon QuickSight と Amazon Redshift Serverless を採用しています。 また、「たるポ」ではオンライン・オフラインのデータを幅広く収集・活用されており、AWS Clean Rooms を活用したデータコラボレーションを進行中で、他企業との連携による新たな価値創出を目指されています。個人を特定しないセキュアな環境で、自社と連携企業のデータをコラボレーションさせて新しい気づきを得るデータクリーンルームの概念が「たるポ」のビジョンにマッチしていると考えられています。同社では AWS と連携し、データ利活用体験を地域に広げるため、広島にて複数の企業を招き、データクリーンルームによるデータコラボレーションワークショップも開催されました。 参考） 【開催報告】中国新聞社/ AWS 共催 データコラボレーションワークショップ in 広島 Session 5. クロージング アマゾン ウェブ サービス ジャパン合同会社 事業開発統括本部 シニア事業開発マネジャー 松本 鋼治 クロージングでは、本イベント各セッションの振り返りのほか、AWS がご提供する各種支援プログラムについてご紹介しました。例えば、AWS の専門人材と先端テクノロジー・業界先進事例・Amazon のビジネスノウハウをもとに、お客様の経営層や次世代リーダーの方と議論を行う Executive Briefing Center （EBC）があります。また、ワークショップを通じて Amazon の顧客視点でのプロダクト企画手法である Working Backwards を体験・実践するプログラムである Digital Innovation Program (DIP) があります。さらに、サービス開発のコンサルティング支援を行う AWS Professional Services など、お客様のビジネスを加速・具体化する様々な支援プログラムをご紹介しています。 まとめ 今回のセミナーでは、広告マーケティング領域における市場動向や、Amazon および AWS の取り組み、生成 AI を含む各種 AWS 関連サービスやユースケースに加え、中国新聞社様にデータコラボレーションに関する事例をご紹介頂きました。 AWS は広告マーケティング業界において、広告主、マーケティング担当者、パブリッシャー、代理店、テクノロジーリーダー向けに様々なサービスやソリューションを提供し、お客様のイノベーションの実現に貢献を続けています。昨今注目される 生成 AI やデータクリーンルームなどの技術によって、その進化は加速していると言えます。 本イベントの各セッションが、皆様 1人1人の学びの一助となり、皆様ご自身や企業、組織のITのみならず経営や事業課題解決に貢献できれ ば幸いです。今後も広告やマーケティングに携わる皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しておりますので是非ご覧ください。 広告マーケティング業界参考情報 [1] 広告とマーケティングのための AWS [2] AWS Blog Marketing &amp; Advertising [3] AWS Black Belt Online Seminar AWS Clean Rooms 著者 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第三ソリューション部 部長/シニアソリューションアーキテクト 鈴木 浩之

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 1月も下旬になりました。そろそろ4月の新年度を意識して、いろいろなチャレンジや新しい取り組みについて思いを巡らせている方も多いのではないでしょうか？いろいろな方と会話する中で、「去年始めた生成AI活用を進めたい」「今年から新たに取り組むことになっている」「去年の取り組みを振り返って、より良い活用を模索したい」などいろいろな声をいただいています。AWSとしては、みなさんの新しい取り組みを様々な形でお手伝いしたいと思っていますので、引き続き情報のチェックをよろしくお願いします。 それでは、1 月 13 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「あらゆるデータソースに会話型インタフェースを追加する」を公開 この記事では、生成AIを構成するモデルが外部データや機能にアクセスする、Tool(Function Callingともいいます)機能を利用することで、モデル自身の学習データに含まれない知識や、リアルタイムな情報を取得できるようにする方法を説明しています。Tool機能を利用することで、最新の天気予報や今現在の株価などのリアルタイム情報を扱ったり、社内のデータベースを参照して必要なデータを利用できるように、生成AIアプリケーションを拡張することが可能になりますので、興味のある方はぜひご一読を。 ブログ記事「生成 AI アプリをノーコードで作成・社内配布できる GenU ユースケースビルダー」を公開 AWSジャパンが公開している生成AIアプリケーションのサンプル実装である GenU(Generative AI Use Case JP) で、事前に用意されているものではない独自のユースケースを自分で追加できる「ユースケースビルダー」という機能が提供されています。この記事では、ユースケースビルダーの利用方法をご紹介しています。 ブログ記事「エンタープライズ向けのマルチテナント型の生成 AI 環境を AWS で構築する」を公開 企業や団体内部の様々なチームが、個別に生成AIを活用したアプリケーションを開発している状況も珍しくなくなってきました。この記事では、組織内で共通する生成AIコンポーネントを集約し、重複する作業を集約することで全体を効率化し、イノベーションを加速する方法をご紹介しています。ちょっぴり長い記事ですが、ガバナンスや責任あるAIなどの観点についてもカバーされていますので、同時多発的に生成AI活用を検討している組織の方などにおすすめです。 ブログ記事「AWS の生成 AI を活用した Happy Sad アプリ、児童の心身の健康を向上」を公開 この記事は、子どもの感情に関する自己認識を向上させるとともに、教室で子どもと接する教員向けに感情状態のパターンや傾向認識を目的とした米国内での取り組みである「Happy Sadアプリ」に関するストーリーをまとめたものです。AWSの様々なお客様支援の枠組みを活用し、Happy Sadアプリの教育現場での適用を加速している一例です。 ブログ記事「Amazon Bedrock の新しい RAG 評価機能と LLM-as-a-Judge 機能」を公開 AWS re:Inventで発表された、生成AIアプリケーションの開発とテストの合理化に役立つ2つの機能について深掘りする記事の和訳を公開しました。この記事ではAmazon Bedrock Knolwedge Basesを利用してRAGアプリケーションを評価し最適化できる機能、モデル評価にLLMを活用することで人間が評価したものと近い品質のモデル評価を実現するLLM-as-a-Judge機能について掘り下げています。 サービスアップデート Amazon Q Developer plugin for CloudZeroが一般利用開始に Amazon Q Developerの機能が拡張され、AWSマネジメントコンソールを離れることなく、CloudZeroのクラウド費用最適化プラットフォームにアクセスできるようになりました。Amazon Q Developerを利用して、コストに関するインサイトや請求情報を得るためにシームレスにCloudZeroを呼び出すことが可能になります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年1月30日(木) 19:00-21:00に「 2025クラウドガバナンスはこう変わる！マルチアカウント運用のre:Invent最新情報と活用例 」が AWS Startup Loft Tokyo にて開催されます。このイベントでは AWS アカウントの実践的な運用方法や、ガバナンス強化のベストプラクティスについて、AWS アカウントの運用のエキスパートである企業様にご登壇頂くほか、昨年の re:Invent での発表を含む最新アップデート情報や Tips を共有する内容となっています。クラウド運用を改善していきたい方にとって、AWSのクラウドガバナンス、アカウント運用の最前線をキャッチアップする良い機会かと思いますので、お時間あれば、ぜひご参加ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月13日週の主要なアップデート 1/13(月) Amazon MSK Connect now supports updating connector configuration Amazon MSK Connect で既存コネクタの設定更新機能をサポートしました。この機能アップデートにより、コネクタの設定におけるデータソースやデータシンクの更新、処理設定を変更することができます。MSK Connect のコネクタ更新機能は、Amazon MSK Connect がサポートされているすべての AWS リーションで利用可能です。 AWS Security Hub now integrates with Amazon Route 53 Resolver DNS Firewall AWS Security Hub は Amazon Route 53 Resolver DNS Firewall と統合され、AWSアカウント全体のセキュリティアラートとコンプライアンスステータスを包括的に確認することができるようになりました。Route 53 Resolver DNS Firewall は悪意あるドメインに対する DNS クエリをブロックするとともに、信頼できるドメインに対するクエリ許可を行うマネージドファイアウォールです。今回の統合により、悪意あるDNS クエリに対するセキュリティ検出結果を、AWS Security Hub 内で、Amazon GuardDuty や Amazon Inspector などの複数のAWS サービスからのセキュリティ検出結果と併せて確認することが可能です。 1/14(火) EC2 Image Builder simplifies converting Windows ISO files to AMIs Amazon EC2 Image Builder で、Microsoft Windows の ISO ファイルを Amazon Machine Images (AMIs) に直接変換できるようになりました。今までは、Windows の ISO ファイルを AMIs に変換する際、複数のツールを利用したり、手動での作業が必要で、運用作業の負担がありました。今回のアップデートにより、EC2 Image Builder で Windows 11 ISO ファイルをシームレスにインポートできるようになったため、変換ワークフローの負荷軽減につながります。また、Amazon WorkSpaces で既存の Windows ライセンス (BYOL) を活用するプロセスも簡素化されます。この機能はすべてのAWS の商用リージョンで利用可能です。 1/15(水) Announcing larger General Purpose bundles for WorkSpaces Personal and Core Amazon WorkSpaces PersonalとAmazon WorkSpaces Core 用の GeneralPurpose.4xlarge (16vCPUと64GB RAM)および GeneralPurpose.8xlarge (32vCPUと128GB RAM) のバンドルを提供開始しました。これらのバンドルは 開発者はVisual Studio、IntelliJ、Eclipseなどのツールを使用して大規模なコンパイルや開発タスクを処理でき、エンジニアやサイエンティストは MatLab、GNU Octave、R、Stata を使用して複雑なシミュレーションを実行できるように設計されています。両バンドルとも 175 GB のルートボリュームと 100 GB のユーザーボリュームを含み、Windows Server 2022 と Windows 11 を BYOLオプションでサポートしています。アフリカ（ケープタウン）とイスラエル（テルアビブ）を除く、WorkSpaces Personal と WorkSpaces Core が提供されているAWSリージョンで利用可能です。 AWS Step Functions adds integration for 36 services including AWS End User Messaging AWS Step Functions は、AWS SDK 統合を拡張し、AWS End User Messaging や Amazon Q Apps (Amazon Q Business の機能) を含む 36 の AWS サービスのサポートを新たに提供しました。また、36 の新しく追加されたサービスに加えて、Step Functions は AWS Transfer Family、Amazon EC2、AWS Lambda、AWS Glue などの AWS サービスから 1,000 以上の新しい API アクションのサポートも追加しました。追加されたサービスの一覧リストは、 ユーザガイド をご参照ください。 Amazon MemoryDB and Amazon ElastiCache now supports Service Quotas Amazon MemoryDB と Amazon ElastiCache で Service Quotas をサポートしました。AWS Service Quotas コンソールを通じて、 Amazon MemoryDB および Amazon ElastiCache のクォータ制限を直接確認でき、そして管理が可能です。このアップデートにより、適格なリクエストに対する自動化された上限増加の承認を可能にし、サポートチケットの数を減らせます。 1/16(木) The AWS Management Console now supports simultaneous sign-in for multiple AWS accounts AWS マネージメントコンソールにおけるマルチセッションサポートを発表しました。この機能により、AWSコンソールで複数のAWSアカウントにアクセス可能となります。１つのブラウザにつき、最大で５つのセッションにサインインでき、同じアカウント、もしくは異なるアカウント内でルート、IAM、フェデレーテッドロールの柔軟な組み合わせでの利用が可能です。開発環境、テスト環境、本番環境と異なる環境ごとに別々のアカウントをそれぞれ複数のブラウザを利用したりする手間が軽減されます。 Introducing new larger sizes on Amazon EC2 Flex instances Amazon EC2 Flex（C7i-flex、M7i-flex）インスタンスで新しく2つの大きいサイズ（12xlarge、16xlarge）の一般提供を開始しました。これらのインスタンスは、AWS カスタムの第4世代 Intel Xeon スケーラブルプロセッサーを搭載しており、他のクラウドプロバイダーが使用する同等の x86 ベースの Intel プロセッサーよりも最大 15% 優れたパフォーマンスを提供します。両インスタンスサイズともに、日本においては東京リージョンで利用可能です。 Amazon Connect Contact Lens launches new real-time dashboard Amazon Connect Contact Lens で新しいダッシュボードの提供を開始しました。このダッシュボードでは、オペレーターの活動をリアルタイムでモニターでき、例えば、オペレーターが難しい対応状態にある場合、自動的に赤色でハイライトしたり、追加の支援が必要な状態を視覚的に素早く示すことができます。 1/17(金) Amazon S3 Tables are now available in five additional AWS Regions Amazon S3 Tables が東京リージョンを含む、５つの AWS リージョンで利用可能となりました。S3 Tables はビルトインの Apache Iceberg サポートを備えたオブジェクトストアで、分析用のワークロードに最適化されています。Amazon S3 Tables は今まで3つの US リージョン (オレゴン、バージニア、オハイオ) で利用可能でしたが、新たに、東京リージョンと４つのヨーロッパリージョン(フランクフルト、アイルランド、ロンドン、ストックホルム)でご利用いただけるようになりました。詳細は ユーザガイド をご参照ください。 AWS CodeBuild now supports test splitting and parallelism AWS CodeBuild でテスト分割をおこない、複数の並列環境で実行できるようになりました。単一のコンピューティングリソースを使用する条件下で、プロジェクトにおけるテスト数が増えると、テスト作業の時間も比例して増加してしまいます。今回のアップデートにより、シャーディング戦略に基づいて、テスト分割を行い、指定された複数のコンピューティングリソースで並列テストを実行することで、CI/CD パイプラインの全体的なテスト時間の短縮が期待できます。 1月28日(火) -31日(金) にかけて、「 AWS re:Invent Recap – インダストリー編 」のオンラインセミナーが行われます。先進的な取組をされている各業界のお客様が、 どのようにクラウドテクノロジーを活用しているかといった AWS re:Invent でのブレイクアウトセッションの講演内容を、インダストリーごとに厳選し、お届けします。ぜひ事前登録の上ご参加ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。