11月27日は、Amazon CodeCatalyst の新しいエンタープライズ層とカスタムブループリントをご紹介します。 Amazon CodeCatalyst のエンタープライズ層は、カスタムブループリントやプロジェクトライフサイクル管理などの機能を提供する新しい料金プランです。エンタープライズ層の料金は、ユーザー 1 人あたり月額 20 USD です。各エンタープライズ層スペースでは、有料ユーザー 1 人あたり 1,500 分のコンピューティング時間、160 時間の開発環境の利用時間、64 GB の開発環境ストレージが用意されています。カスタムブループリントを使用すると、アプリケーションコード、ワークフロー、インフラストラクチャのベストプラクティスを定義できます。また、これらのブループリントを CodeCatalyst スペースに公開して、プロジェクト作成時や既存プロジェクトへの標準適用時に使用できます。 ブループリントを使用すると、プロジェクトを数分でセットアップできるため、すぐにコーディングに取り掛かることができます。数回クリックするだけで、プロジェクトファイルを設定できるほか、特定のプロジェクトタイプのベストプラクティスを使用して、完全に統合された組み込みツール (ソースリポジトリ、問題管理、継続的インテグレーションおよびデリバリー (CI/CD) パイプラインなど) を設定できます。必要に応じて、GitHub などの一般的なツールを入れ替えることが可能で、その場合にも一貫したエクスペリエンスが保たれます。プロジェクトの存続期間中に開発者ツールの構築、統合、運用に費やす時間を削減できます。 カスタムブループリントでは、CodeCatalyst プロジェクトのさまざまな要素を定義できます。例えば、ワークフロー定義、Infrastructure as Code (IaC)、アプリケーションコードなどです。カスタムブループリントを更新すると、その変更はプルリクエストの更新として、ブループリントを使用するすべてのプロジェクトに反映されます。この合理化されたプロセスにより、プロジェクトの設定におけるオーバーヘッドが削減され、ベストプラクティスをプロジェクト全体に一貫して適用できます。管理者は、CodeCatalyst スペースの各ブループリントをどのプロジェクトが使用しているかを簡単に詳しく表示でき、プロジェクト全体における標準の適用状況を把握できます。 CodeCatalyst でカスタムブループリントを作成する CodeCatalyst コンソール を開いて、自分のスペースに移動します。 [Settings] タブの左側のナビゲーションペインで [Blueprints] をクリックし、次に [Create blueprint] をクリックします。ここで、ブループリントのベストプラクティスを体系化します。準備が完了したら、そのブループリントを自分のスペースに公開して、チームがプロジェクト作成時に使用できるようにします。 ブループリントを公開すると、 [Settings] タブの CodeCatalyst スペースにそのブループリントが表示され、管理できます。左側のパネルで、 [Blueprints] をクリックします。次に、 [Space blueprints] をクリックします。 カスタムブループリントから CodeCatalyst プロジェクトを作成するには、 [Create project] > [Space blueprints] の順にクリックします。 可用性 Amazon CodeCatalyst のエンタープライズ層は、米国西部 (オレゴン) リージョンと欧州 (アイルランド) リージョンで利用できます。ただし、デプロイは任意の商用リージョンに行えます。 詳細については、 Amazon CodeCatalyst のウェブページ をご覧ください。 構築しましょう! – Irshad 原文は こちら です。

AWS Fault Injection Service (FIS) は、大規模にカオスエンジニアリングを実践するために役立ちます。本日 (2023 年 11 月 30 日) 、FIS の新しい シナリオ を発表します。これにより、例えば AWS のアベイラビリティゾーンが全て停電したり、ある AWS リージョンから別のリージョンへの接続が途絶えた場合でも、アプリケーションが予定通りに機能するかを確認できます。 このシナリオを使った実験により、問題発生時にアプリケーションが単一リージョンでもマルチリージョンでも期待通りに機能するという自信を得られます。これにより、直接的および間接的な依存関係を深く理解し、復旧時間をテストするのに役立ちます。アプリケーションを試験して、期待通りに動作することを確認した後、実験結果をコンプライアンスの目的で使用できます。FIS と AWS Resilience Hub を組み合わせることで、アプリケーションの全体的な 耐障害性状況 を十分に理解するのに役立ちます。 シナリオ紹介 2021 年に AWS アプリケーションで制御された実験を行うため FIS を発表しました。その発表の際の 投稿 で、実験テンプレートの作成と使用方法を紹介しました。実験は、特定種類の AWS リソース群に影響を与えるよう設計された、強力かつ基本的な操作を用いて構築されます。例えば、以下のアクションは EC2 インスタンスと Auto Scaling Groups に作用します。 最近、これらのアクションをビルディングブロックとして、 AWS FIS Scenario Library を立ち上げました。ライブラリの各シナリオは、アプリケーションの回復力をテストするために使用できるイベントや条件を定義しています。 各シナリオは、実験テンプレートの作成に使用されます。シナリオをそのまま使用することも、任意のテンプレートを必要に応じてカスタマイズまたは拡張することもできます。 シナリオは、同じ AWS アカウントまたは他の AWS アカウントのリソースを対象にすることができます。 新しいシナリオ これらの情報を踏まえた上で、新しいシナリオを見ていきましょう。 AZ の可用性 : 電源の中断 – このシナリオでは、単一のアベイラビリティゾーンにある特定のリソース群に対して一時的に “電源を抜く” 操作を行います。対象となるリソースには、EC2 インスタンス (EKS および ECS クラスタのものを含む) 、EBS ボリューム、Auto Scaling Groups 、VPC サブネット、 Amazon ElastiCache for Redis クラスタ、 Amazon Relational Database Service (RDS) クラスタなどが含まれます。ほとんどの場合、複数のアベイラビリティゾーンにリソースを持つアプリケーションで実行しますが、このシナリオを単一のアベイラビリティゾーンで動作するアプリケーションに適用することもできます。この場合、アプリケーションが一時的に停止することが想定されます。単一のアベイラビリティゾーンをターゲットとし、指定した IAM ロールまたは Auto Scaling Groups が実験中に新しいインスタンスを起動したり、停止したインスタンスを起動できないようにすることもできます。 新しいターゲットとアクションエクスペリエンス では、シナリオ内のアクションと、それらが影響する AWS リソースのタイプなど、すべてを一目で簡単に確認できます： シナリオには、実験テンプレートをカスタマイズするためのパラメータが含まれています： 詳細パラメータ – ターゲティングタグ では、実験の対象となるリソースを見つけるために使用されるタグのキーと値をコントロールできます： クロスリージョン : 接続 – このシナリオは、テストリージョンにあるアプリケーションがターゲットリージョンのリソースにアクセスするのを防ぎます。これには、VPC に接続された EC2 インスタンス、ECS タスク、EKS Pod 、Lambda 関数からのトラフィックが含まれます。また、 Transit Gateway や VPC ピアリング 接続を通過するトラフィックや、リージョンをまたぐ S3 や DynamoDB のレプリケーションも含まれます。このシナリオは、初期設定で以下のようになっています： disruptionDuration パラメータを変更しない限りこのシナリオは 3 時間実行され、指定された方法でターゲットリージョンからテストリージョンを分離します。分離されたリージョン内で実験の影響を受ける AWS リソースを特定するために使うタグを管理するための詳細パラメータがあります。この設定を通じて、どのリソースが実験によって影響を受けるかを具体的に決めることができます： また、このシナリオで使用される Disrupt と Pause アクションは、それぞれ単体でも役立つかもしれません： 例えば、 aws:s3:bucket-pause-replication アクションは、リージョン内でレプリケーションを一時停止するために使用できます。 知っておくべきこと 新しいシナリオについて知っておくべきことがいくつかあります： リージョン – 新しいシナリオは、FIS が利用可能なすべての商用 AWS リージョンで、追加費用なしで利用可能です。 価格 – 実行した実験によって消費されたアクション分の時間に対して料金を支払います。詳細は AWS Fault Injection Service Pricing Page を参照してください。 サービス名 – このサービスは以前 AWS Fault Injection Simulator と呼ばれていました。 — Jeff ; Jeff Barr Jeff Barr は AWS のチーフエバンジェリストです。彼は 2004 年にこのブログを始め、それ以来ほぼノンストップで投稿を書いています。 翻訳はソリューションアーキテクト 渡部 拓実 が担当しました。原文は こちら です。

アマゾンウェブサービス (AWS) は、使いやすいクラウドコンタクトセンター Amazon Connect を 2017 年に提供開始しました。この度、提供開始以来初めて、2023 年第 1 四半期の The Forrester Wave : Contact Center as a Service でリーダーに選ばれました。このリーダーへの選出は、私たちのイノベーションのペースの早さと、それによってあらゆる規模のお客様が継続的に優れたカスタマーサービスを低コストで提供できた成功を反映していると考えています。 このレポートでは、最も重要な CCaaS プロバイダーのうち 11 社を 34 の基準で評価しています。Amazon Connect は、AI アーキテクチャ、プロアクティブエンゲージメント、カスタマーセルフサービス、エージェントデスクトップ、イノベーションロードマップ、顧客数、テキストと音声の分析を含む 11 の基準で最高得点を獲得しました。そして、AWS は最大の市場プレゼンスをもつ CCaaS プロバイダーと並びました。これは、AWS の CCaaS 分野での、財務、マーケットでの強みに関する Forrester の評価を反映していると考えています。 我々にとって、この選出は、Amazon Connect があらゆる規模の企業が顧客体験を最適化できるようにするイノベーションのスピードを物語っています。現在、何万もの AWS のお客様が Amazon Connect を使用して、毎日 1,000 万件を超えるコンタクトセンターでのやり取りを行っています。Best Western 、 Capital One、富士通、Intuit、John Hancock、New York Times、Priceline、National Australia Bank などのお客様が、Amazon Connect を使用して優れたカスタマーサービスを低コストで提供しています。 顧客体験の継続的な革新を目指すお客様にとって、 Forrester のレポートはビジネスに役立つコンタクトセンターソリューションを見つけるための貴重な指針となります。 The Forrester Wave : Contact Center as a Service, Q1 2023 の無償版はこちらからご覧いただけます 。 無料のオンラインイベント、AWS Contact Center Day もご覧ください。カスタマーサービスの未来、機械学習がどのように顧客とエージェントのエクスペリエンスを最適化できるかなどについて学ぶことができます。 今すぐ登録 ※訳注 オンラインイベントは2023年4月26日に開催されました。現在はイベントをオンデマンド配信でご覧いただけます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

はじめに 配送プロセスの最後の段階を「ラストマイル」と呼ぶのは、サプライチェーンや物流業界では一般的であり、宅配業者が担当します。ラストマイルの配送としては、例えば準備ができた食品をできるだけ速やかに配送する必要がある「即時配送」があり、他にもECサイトで購入した商品の「当日配送」や「多日配送」も含まれます。 ラストマイルは、配送の中で最も複雑でコストのかかる部分です。宅配業者は、ビジネス、物流、技術的な多数の複雑な問題を同時に解決する必要があります。 対応可能なドライバーの位置を監視する。 ルートと車両の空きスペースに基づいて、ドライバーに最適な配車を割り当てる。 ドライバーの移動距離を最小限に抑えることで、コストを抑える。 顧客の待ち時間をできるだけ短くする。 その他の特定のビジネスルールを遵守する。 COVID-19パンデミックの世界的な流行は、消費者の行動を大きく変えました。オンラインショッピングの需要が急増し、食品や日用品の宅配サービスも大幅に伸びています。アナリストは この傾向が続く と予測しています。（ただし、流行が収束した後は、少しずつ店舗での買い物に回帰する人も出てくるでしょう。） 配送業務やラストマイル物流サービスの開始を計画しているお客様からのよくある質問に対応するため、AWS ASEAN (東南アジア諸国連合) のプロトタイピングチームは オープンソースの コンテンツ を公開しました。これにより、企業は簡単に独自のラストマイル機能を構築できると同時に、即時配送と当日配送といったニーズに対応できます。IoT、サーバーレス、機械学習、地理空間技術を活用するとともに、イベント駆動型アーキテクチャも採用しています。 これはブログシリーズの第1部です。ここでは即時配送に焦点を当て、この新機能の詳細や仕組み、既存の環境への統合方法について説明しています。第2部では当日配送について説明する予定です。 機能的アーキテクチャ AWS 即時配送機能は、大まかに言うと、以下の 機能的アーキテクチャ図 (図 1) に示すように 2 つの主要部分で構成されています。 位置の追跡。 このモジュールにより、数万人のドライバーの現在地をほぼリアルタイムで追跡し、検索することができます。単純な位置検索や、より複雑な区域内のドライバー検索が可能です。設計上の重要なポイントは、ドライバーの位置特定までのレイテンシと、システムが同時に追跡できるドライバー数のスループットの2点です。 注文の発送。 このモジュールは、ドライバーに効率的に注文を割り当てるために使用されます。即時配送と当日配送の2つのサブモジュールがあり、まず即時配送についてこの記事で紹介します。配送事業は運用コストが高く、特に配送車両の管理が主な費用となります。そのため、注文とドライバーを適切にマッチングするシステムは、収益性と事業の持続可能性に大きな影響を与えます。このソリューションでは事前に定義された最適化手法を利用していますが、これらは会社のデータやビジネス要件に応じて容易に変更可能です。 図1.機能的アーキテクチャ 高度な技術アーキテクチャ 図2.高度な技術アーキテクチャ 図2 に示すアーキテクチャは、イベント駆動型のサーバーレスシステムを示しています。イベントバスとして Amazon EventBridge を活用しており、お客様のアプリケーションやソフトウェア、AWSサービスから発生したイベントを取り込んで大規模なイベント駆動型アプリケーションを構築できるようになっています。このコンポーネントがシステムの中核を担っており、すべての注文とステータス更新をシステムが処理します。また、ビジネスルールに基づいて特定のエンドポイントへメッセージを転送することも可能です。 システムのコアモジュールは2つです。 位置の追跡 注文の発送 位置追跡サービス このサービスは、位置情報が中心的な役割を果たすすべてのタスクを管理するのに役立ちます。 ドライバーの位置をGPSで追跡 位置情報の検索 ジオフェンシング AWS IoT Core サービスを高速メッセージブローカーとして利用し、ドライバーアプリと顧客アプリの間でメッセージを安全に送受信できます。MQTTプロトコルをサポートしており、MQTTプロトコルはHTTPと比較して同じ量の情報を少ないデータ量で送信できます。このユースケースでは、ドライバーアプリが位置データをAWS IoT Coreに継続的に送信し、そのデータパケットをリアルタイムストリーミングデータ収集・処理・分析サービスの Amazon Kinesis に転送します。そこから位置追跡サービスにインデックス化されます。データは、 基本的な取り込み を使用して取り込まれます。基本的な取り込みは、AWS IoTルールに従ってデバイスデータを対象サービスに安全に送信でき、メッセージングコストが発生しません。 位置追跡サービスは、Redis 互換の高速・耐久性のインメモリデータベースである Amazon MemoryDB for Redis と、OpenSearchのクラスターをAWS上で簡単にデプロイ・運用・スケーリングできる Amazon OpenSearch Service を組み合わせたものです。前者は「半径或いは矩形内の全ドライバーを追跡する」ようなシンプルなクエリを、後者は「ポリゴン内の全ドライバーを追跡する」ような複雑なクエリをそれぞれサポートしています。 ドライバーアプリは、AWS IoT Coreを通じて Amazon Eventbridge とステータス更新を送受信しています。一方で、 Amazon API Gateway は、さまざまな規模でのAPIの作成、保守、保護に役立つとともに、Amazon MemoryDB for Redisおよび位置追跡サービスのOpenSearchクラスタから位置情報を問い合わせるためのAPIを提供しています。 ジオフェンシング ドライバーに注文が割り当てられると、注文管理システムがEventBridgeにメッセージを送信します。位置追跡サービスがそのメッセージを受信し、割り当てられたドライバーの位置を追跡し始めます。MemoryDB for Redisを利用した位置情報制御により、ドライバーが目的地の近くに来た時点でEventBridgeに通知が送信されます。その情報は顧客や関連会社に共有されます。 図3.ジオフェンシングアーキテクチャ その他の考慮事項 ドライバーを継続的に追跡すると、モバイルバッテリーが急速に消耗する可能性があります。ただし、ドライバーを頻繁に追跡しないと、ドライバーがどのルートをたどったのか、特定の瞬間にどこにいるのかを正確に知ることが難しくなります。また、割り当てエラーにつながる可能性もあります。たとえば、ドライバーが特定のピックアップポイントの近くにいて、ロケーションが更新されていないためにそのピックアップポイントから注文を受け取れない場合などです。 ドライバーの位置を常に追跡すると、モバイルバッテリーの消耗が速くなる可能性があります。 しかし、頻繁に追跡しないと、ドライバーが実際にどのルートを通ったのか、ある瞬間にどこにいたのかを正確に把握することが難しくなります。 また、注文の割り当てミスにもつながりかねません。例えば、ドライバーが特定の地点の近くにいるにも関わらず、位置情報が更新されていないために、その地点からを注文を受け取れないといったケースです。 このシステムは、ドライバーの位置を見失うことなく、バッテリーの消費を抑えるため、次の2つの方法を採用しています。 アクティブモードとパッシブモードで、ドライバーの位置を追跡するために使用する周波数を変更しています。これらのモードはさまざまな周波数をオンにしてGPS位置情報を取得し、データをクラウドに送信しています。 位置情報の取得の頻度とクラウドへの送信頻度を分けています。GPS位置情報の取得頻度は上げていますが、クラウドへの送信頻度は下げています。 これらのアプローチは設定を変更することができます。ユーザーがアプリをデバイス上で起動した際、最新の構成が取得されます。既にアプリを実行しているデバイスで設定を変更した場合、ほぼリアルタイムでその変更が適用されます。 この図は、システムのフローを示しています。このシステムを使うと、アプリケーションに他の設定をプッシュすることもできます(例:A/Bテストを行う)。 図4.グローバルモバイルアプリ設定 注文管理： ルールエンジンと注文配分 注文管理モジュールは、ドライバーや配送場所、利用可能な時間帯、業務ルールなど、さまざまな制約を考慮しつつ、注文を一元管理してドライバーへ配送依頼を行うのに役立ちます。このモジュールは以下の2つのコア要素から構成されています。 注文オーケストレーターと、地域ごとに業務ルールを適用するためのプロバイダールールエンジン 配送プロバイダー 注文オーケストレーターとプロバイダールールエンジン 企業がラストマイル配送を含むビジネスを立ち上げる際、自社配送車両を構築するか、APIを利用してサードパーティの配送車両(複数可)を利用するかを選択できます。このシステムにより、注文を国内外の配送車両に分散させ、地域ごとに配分比率を設定できます。例えば、エリアA1では1社の配送業者(外部プロバイダーPr1)のみを利用する場合がありますが、エリアA2では、外部プロバイダーPr2とPr3の間で注文を分散する場合があります。この配分は、 プロバイダールールエンジン を利用して実施されます。 このプロトタイプは、外部プロバイダーが使える様々な実装に対応できるよう、 Webhook プロバイダーと ポーリング プロバイダーの2つの通信技術をサポートしています。 プロバイダールールエンジン プロバイダルールエンジンの実装は、ほとんどの利用シーンではシンプルですが、システムは拡張性と設定のしやすさを考慮して設計されています。 本番運用移行時には、お客様は独自の業務ルールを実装し、特定の分野でどのプロバイダーを選択するかを決定する必要があります。 追加の業務ルールへの対応や、新しい優先順位の定義、新しいオペレータを追加するなど、システムをカスタマイズすることができます。 図5.プロバイダールールエンジンによって選択される複数のプロバイダー (内部プロバイダーと外部プロバイダー) の例 人口地域 都市や町の特定の地域には、配送業者に関する独自のルールが設定されている場合があります。 例えば、「A1地域」と指定されたエリア内では、配送にその地域専属の配送車両しか利用できないことになっています。 一方で、「A2地域」と呼ばれる別の地域では、2社の外部プロバイダー間で注文を配分できるというルールになっています。 人口地域のリストは、フルマネージド型のサーバーレス key-value NoSQLデータベースである Amazon DynamoDB に保存され、プロバイダールールエンジンの設定は、それぞれの人口地域を示す同じテーブルに保存されます。レストランや食料品店などの店舗を登録するたびに、その場所がどの人口地域に属するかを示すタグが付与されます。 図6.地域ごとに異なるルール（例：地域ごとに異なる外部プロバイダー） 配送システム 即時配送システム について詳しく見てみましょう。 図7.即時配送プロバイダー このモジュールは、次の3つのプロセスを管理しています。 まず、 注文処理用のリクエストハンドラー が注文を受け取り、各注文にステータスを割り当てます。 次に、 ジオクラスタリングマネージャー が注文をグループ化し、位置関係に基づいてクラスターを形成します。 最後に、 発送オーケストレーター は 発送エンジン を起動してこれらのクラスタを分析し、事業者の定める制約を考慮してドライバーへの注文割り当てを決定します。 ジオクラスタリング デフォルト設定では、 即時配送プロバイダー は他のプロバイダーと同じインターフェースを公開しています。 注文オーケストレーターサービス は、Amazon API Gatewayのエンドポイントに対してHTTPリクエストを送信することで、これらのプロバイダーを呼び出します。プロバイダーは Amazon Kinesis を使用して注文をバッチ処理することができ、これにより一括で処理することが可能です。グループのサイズはビジネスニーズに応じて設定できます。ただし、グループサイズを大きくすると、クラスターが大きくなり、最適なソリューションの生成に時間がかかる可能性がある点に注意が必要です。 グループからの注文を処理する前に、 ジオクラスタリングマネージャー は事前最適化の手順を実行します。このコンポーネントは、分散アプリケーションのビジュアルワークフローである AWS Step Functions を使用して実装され、ピックアップ地点が近い注文をクラスター化します。これにより、 発送エンジン が利用可能な運転手を探す複雑な検索を行う必要がなくなるため、発送が最適かつスピーディーに行われるようになります。 発送オーケストレーター は、AWS Step Functionsを使用して実装されています。 ジオクラスタリングマネージャー によって作成されたすべてのジオクラスターに対して、発送オーケストレーターが実行されます。 発送オーケストレーターは、クラスターごとに配車を最適化し(コストを最小限に抑える)配車エンジンを起動します。ドライバーが選ばれると、発送オーケストレーターはAWS IoT Coreを通じてメッセージでドライバーに通知します。 ドライバーは配車を承諾または拒否できます。ドライバーが配車を拒否した場合、その配車はKinesisを使用してバッチに戻されます。 配車の状況は 注文状況ストア で管理されています。 図8.ジオクラスタリングの例 (ソース：GraphHopper) 発送エンジンによる制約解決 発送エンジン は、即日配送や当日配送などの配送ドメインに関連する最適化問題を解決するために使用されるカスタムアプリケーションです。プロトタイプでは、オープンソースのAIベースの最適化ソルバー「 OptaPlanner 」を利用して、こうした配送ドメインをモデル化し実装しています。技術的な詳細についてさらに学びたい場合は、関連する ブログとドキュメント を参考にすることをお勧めします。 制約の解決には、様々なレベルの制約(ハード、ミディアム、ソフトなど)と、最大化するスコア関数や最小化するコスト関数を定義できます。 OptaPlanner ドキュメント には、問題領域を適切にモデル化するために必要な全ての情報が記載されています。ドライバーを注文に割り当てる方法はたくさんあります。ソフトウェアは割り当てごとにスコアを計算し、最もスコアの高い割り当てを提供する必要があります。OptaPlannerは、最適な結果を得るために必要な計算量を削減するスマートな手法です。最良の制約解決アプローチは、システムが競合する優先順位に対応できるかどうかを検証します。例えば、注文をドライバー間で均等に分配するか、評価の高いドライバーに優先して割り当てるかなどです。 即時配送ソリューションを最適化する際の推奨事項は以下の通りです。 注文はできる限り対応可能なドライバーに均等に割り振る。空いているドライバーがいる場合は1人に注文を集中させるのではなく、そのドライバーに新規注文を割り当てる。 ピックアップ場所(レストランなど)からの距離が近いドライバーを優先的に選択する。(お客様が評価の高いドライバーや近隣の注文をまとめるなど、異なる判断基準を設定できることに留意する。) 使用されている地理空間技術に関するクイックノート：GraphHopperの役割 このシステムは、オープンソースのGraphHopperをルーティングエンジンとして利用しています。 位置追跡サービスでは、Amazon MemoryDB for Redisによる簡易な地理空間クエリと、Amazon OpenSearch Serviceによる複雑なポリゴン地理空間クエリの両方をサポートしています。 GraphHopperを使ってピックアップ地点周辺の等時線を取得し、その結果を利用してAmazon OpenSearchでポリゴン内のドライバーを検索するクエリを実行することができます。 それらの結果をキャッシュしておき、後で地理空間クエリに再利用することも可能です。 図9.等時線：車で10分または20分以内にどこまで行けますか？(ソース：GraphHopper) シミュレータ プロトタイプを大規模にテストするため、シミュレータが含まれています。プロトタイプはイベント駆動型のバックエンドシステムとして設計されているので、シミュレータは関連するイベント(ドライバーの位置情報更新、注文、注文割り当て、承認/拒否メッセージなど)を生成します。 シミュレータは、内部プロバイダと外部プロバイダの間で注文が適切に配分されているか、システムが指定された負荷を処理できるかどうかを判断するのに役立ちます。 シミュレーターを使用することで、ドライバー、店舗や倉庫などの出発地、顧客などの目的地といった、様々な関係者の動きを模倣することができます。これらのエンティティは、 Amazon Elastic Container Service (Amazon ECS)のコンテナを利用してシミュレートされます。これによって組織は、コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケーリングすることが可能となります。各コンテナは、それぞれの関係者の複数の行動をシミュレートできます。コンテナのサイズにもよりますが、1つのコンテナ当たり最大10個以上の行動をシミュレートできます。 ドライバーコンテナ は、ドライバーの動き(移動、注文の受け入れ/拒否、ピックアップ/配送)をシミュレートします。コンテナはクラウドからのメッセージを IoT トピック を通じて受信し、メッセージを受け取るとドライバーは割り当てを承認/拒否して配送をシミュレートし、ステータスの更新を別の IoT トピックに送信します。また、ドライバーは位置情報を定期的に送信することで、位置追跡モジュールによるデータの取り込みとインデックス作成をトリガーします。位置追跡モジュールは、ドライバーが乗車地点または降車地点に近づいたときにジオフェンシングイベントを送信する役割も果たしています。 オリジンコンテナ はIoTトピックから注文を受け取り、受け入れるか拒否するかを決定します。Web UIから拒否率を設定でき、自動的に拒否される注文の割合が決まります。 宛先コンテナ は、ランダムなオリジンを選択し、Web UIからシステムに注文を送信するロジックを提供します。このコンテナには、入力ファイルに基づいて既存のイベントを再生するオプションもあります。これにより、通常日のデータ分布(低負荷、中負荷、高負荷のピーク)を使用して、システムの反応を確認しながら、特定の負荷テストシナリオをシミュレートできます。イベントは、受注の時間間隔に基づいて、それらが表示される順序で再生されます。 図11.シンプルなシミュレーターアーキテクチャ 図12.シミュレーター UI 図13.シミュレータダッシュボード 負荷能力 プロトタイプは、5万人のドライバーの位置をリアルタイムで追跡し、5分間に5千件の配送注文を処理するようテストされています。これは1日当たり数十万件の注文量に相当します。システムは水平スケール可能で、この注文量を更に上回る規模にも対応できるよう設計されています。 個々のサービスのスケーリング 次のようなサーバーレスコンポーネントがあります。 AWS IoT Core AWS Lambda：サーバーやクラスターについて考えることなくコードを実行できます。 Amazon EventBridge AWS Step Functions：分散アプリケーションの視覚的なワークフローを提供します。 Amazon Kinesis Data Streams ：あらゆる規模のデータストリームを簡単にキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。 需要に応じて自動的にスケーリングします(AWS アカウントの上限を超えないよう注意が必要です)。 Amazon MemoryDB for Redis、Amazon OpenSearch、Amazon ECS でスケーリングする場合は、あらかじめ計画を立てる必要があります。これらのサービスは、水平スケールと垂直スケールの両方が可能です。 顧客のフロントエンドとバックエンドとの統合 Amazon EventBridgeに実装されている グローバルイベントハブ を利用することで、顧客システムやサードパーティシステムとの統合が容易になります。外部システムとの疎結合した連携が可能になるのです。 具体的には、イベントをグローバルイベントハブに公開し、イベント発生時の応答や更新状況をイベントハブを通じて確認できるようにします。このイベント駆動型アーキテクチャにより疎結合なアーキテクチャを実現できます。 注文発送サービスと位置追跡サービスはグローバルイベントハブを監視し、イベントをグローバルイベントハブに公開します。 例えば 注文発送サービスは、注文割り当ての詳細をグローバルイベントハブに公開し、ドライバーや位置サービスなどの関係者や機能コンポーネントに伝達しています。 位置追跡サービスの位置特定機能は、位置情報をグローバルイベントハブに公開しています。 また、注文発送サービスは、位置追跡サービスと直接連携して、指定区域内のドライバーなどのデータをリアルタイムで取得しています。これは注文発送に要求される速報性を確保するためです。 ドライバーアプリおよび顧客アプリにおけるパブリックエンドポイント ドライバーアプリは、MQTT プロトコルを使って AWS IoT Core 経由でクラウドと連携を行います。 顧客アプリは、HTTP プロトコルを使って AWS API Gateway で経由でクラウドと連携を行います。 図14.イベント伝播による統合 結論 即時配送のラストマイル配送ソリューションは、お客様の不要な労力を減らし、データ主導のイノベーションに注力できるよう支援します。システムの大部分はサーバーレスですが、その他の部分はマネージドサービスで構成されているので、メンテナンスと運用がしやすくなっています。ほとんどの部分が自動的にスケールするため、運用コストが比較的低く抑えられます。このシステムは、設定可能なルールエンジンと最適化エンジンを通じて革新を促進することができます。また、多くの配送業者がサードパーティの車両を利用している実状も考慮されています。 さらに、システムは、ラストマイル配送の課題を解決するために、さまざまな AWS サービスを効果的に使用する方法を示しています。これらのサービスには、AWS IoT Core、Amazon Kinesis、AWS Lambda、AWS Step Functions、Amazon API Gateway、Amazon MemoryDB for Redis、Amazon OpenSearch Service、Amazon ECS などが含まれます。 次回のブログ記事では、当日配送用の AWS ベースの ラストマイル配送ソリューション について詳しく見ていきます。 免責事項 このソフトウェアは Amazon Software License (ASL) に基づいて共有されているため、AWSはいかなる責任も負いません。システム設計では AWS Well-Architected の原則 に沿って、パフォーマンス、信頼性、コスト効率、持続可能性を考慮しています。実運用を開始する前に、十分な注意とテストを推奨します。 翻訳はソリューションアーキテクト 駒野 達也 が担当しました。原文は こちら です。  

はじめに コネクテッドモビリティソリューションが自動車業界の変化を促進しています。遠隔コマンド、センサー、カメラ、人工知能、5G モバイルネットワークにより、自動車はますますスマート化し、そしてコネクテッド化しています。コネクテッドモビリティソリューションが大きな顧客価値をもたらす一方で、セキュリティ、安全性、プライバシーの面で、適切な管理を要する新たなリスクをもたらします。 自動車メーカーは、サイバーセキュリティをコアビジネスに不可欠な要素として考慮し、車両プラットフォームと関連するデジタルモビリティサービスを最初から安全に設計する必要があります。自動車の相手先ブランド製造&nbsp;(OEM)&nbsp;業者やサプライヤーが、コネクテッドビークルのイノベーションとリスクのバランスを取れるように、AWS は AWS IoT でコネクテッドビークルプラットフォームを構築するための リファレンスアーキテクチャ を発表しました。このガイダンスは、AWS 上のコネクテッドモビリティソリューションのための以下の 10 個のセキュリティゴールデンルールに基づいた、多層的なアプローチを推奨しています。 1. 規制および社内コンプライアンス要件に対応するための共通フレームワークによるセキュリティリスク評価を実施する。 AWS は、コネクテッドカーの IT 技術を活用する前に、リスク、ギャップ、脆弱性を十分に理解し、主体的に管理できるように、サイバーセキュリティのリスク評価を実施することを推奨しています。自動車規制要件&nbsp;( UN-R155 および UN-R156 など)&nbsp;と社内要件を満たすために必要な管理策を決定します。クラウドリソースの最新の脅威モデルと、関連する車載コンポーネントの脅威分析とリスクアセスメント&nbsp;( TARA )&nbsp;を作成し、維持します。ISO 21434、NIST 800-53、ISO 27001 などの規格が有用なガイダンスを提供しています。 自動車 OEM は、消費者がアフターマーケット機器&nbsp;(保険用ドングルなど)&nbsp;や個人用機器&nbsp;(携帯電話など)&nbsp;を車内に持ち込み、メーカーが提供するインターフェースを介して車両システムに接続するリスクを考慮すべきです。 無線接続された ECU と低レベルの車両制御システム、特にブレーキ、ステアリング、推進力、パワーマネジメントなどの 安全上重要な機能を制御するシステム 間の接続を制限するためには、車載ネットワークのセグメンテーションと分離技術を使用する必要があります。 データの送信とコマンドの受信は、常に信頼できるエンドポイント&nbsp;(MQTT over TLS など)&nbsp;への接続を車両に確立させ、着信接続の試みを許可しないようにします。 リモートで車両のロックを解除するなど、クラウドから車両にコマンドが送信されるクローズドループオペレーションでは、セキュリティコントロールとテストをさらに厳密に行う必要があります。 参考リソース： AWS コンプライアンスプログラムとオファリング。 Amazon Virtual Private Cloud&nbsp;(Amazon VPC)&nbsp; は、ユーザーが定義した論理的に分離された仮想ネットワーク内に AWS リソースを起動できるサービスです。 AWS Network Firewall は、すべての Amazon VPC に必要不可欠なネットワーク保護を簡単に導入できるマネージドサービスです。 AWS Control Tower は、アイデンティティ、連携アクセス、アカウント構造に関するベストプラクティスのブループリントを使用して、新しいランディングゾーンのセットアップを自動化します。 AWS セキュリティブログの 脅威モデリングのアプローチ方法 。 2. 車両に搭載されているすべてのハードウェアとソフトウェアのアセットインベントリを管理する。 車両に搭載されているすべてのハードウェアとソフトウェアのアセットインベントリを作成し、維持します。このアセットインベントリは、メーカーやモデル、ECU ID または ESN にマッピングされた VIN、ハードウェアとソフトウェアの構成など、車両の主な特徴とともに、コネクテッドビークルのフリートの記録のためのシステムおよび単一の真のソースとして機能します。 アセットを機能&nbsp;(セーフティクリティカル、車両制御システム、車両ゲートウェイなど)&nbsp;、ソフトウエア更新が適用可能かどうか&nbsp;(パッチ適用可能か不可能か)&nbsp;、ネットワーク設計&nbsp;(オープンネットワーク用に設計されているか、クローズドネットワーク用に設計されているか)&nbsp;に基づいて分類し、その重要性と最新のセキュリティ制御をサポートする能力を認識します。必要に応じて、リスクを軽減するための代替策を適用します。 これらのシステムがどのように相互接続されているか、その関係&nbsp;(アセットの階層構造)&nbsp;を示す最新の車載ネットワークアーキテクチャを作成および維持し、ネットワークアーキテクチャのセキュリティレビューを実施します。 NHSTA の「現代自動車の安全のためのサイバーセキュリティのベストプラクティス&nbsp;( Cybersecurity Best Practices for the Safety of Modern Vehicles )&nbsp;」、特に「車両上のハードウェア及びソフトウェアのアセットのインベントリとその管理」に関するセクション 4.2.6 のガイダンスに従います。SPDX や CycloneDX などの業界標準を使用して、ソフトウェアサプライチェーンにおけるコードの可視性、透明性、セキュリティ、完全性を向上させるために、ソフトウェア部品表&nbsp;(SBOM)&nbsp;を維持します。 参考リソース： AWS IoT Core に接続されたデバイスのための AWS IoT Device Management クラウドインスタンスとオンプレミスのコンピュータのための AWS Systems Manager インベントリ 。 ソフトウェアパッケージとそのバージョンのインベントリの管理のための AWS IoT Device Management Software Package Catalog 。 NHSTA の現代の自動車の安全のためのサイバーセキュリティベストプラクティス 3. 各電子制御ユニット&nbsp;(ECU)&nbsp;に固有の ID と認証情報を提供し、認証とアクセス制御のメカニズムを適用する。車両とクラウドサービス間の通信に業界標準プロトコルを使用する。 各 ECU および最新の IoT デバイスに一意の ID を割り当て、ECU/デバイスがクラウドサービスに接続する時は、X.509 証明書とそれに対応する秘密鍵、セキュリティトークン、またはその他のクレデンシャルなどを使用して認証しなければならないようにします。 OCSP またはクレデンシャルの生成、配布、検証、ローテーション、および失効（ X.509 証明書の CRL の使用など）を促進するメカニズムを構築します。 デバイスで利用可能な場合は、Trusted Platform Modules&nbsp;(TPM)&nbsp;などのハードウェアで 保護されたモジュールを使用して、ルートオブトラストを確立します。秘密鍵などの秘密情報は、HSM のような特殊な保護モジュールに格納します。 制約のあるデバイス用に設計された軽量メッセージングプロトコルである MQTT のような業界標準プロトコルを使用します。 可能であれば、TLS バージョン 1.2 または 1.3 を使用して転送中の暗号化を実施し、セキュリティを強化します。 参考リソース： AWS IoT でのセキュリティとアイデンティティ 。 Amazon Cognito &nbsp;は、Web アプリやモバイルアプリの認証、認可、ユーザー管理を提供するサービスです。 AWS Identity and Access Management&nbsp;(IAM )&nbsp;は、AWS サービスとリソースへのアクセスを安全に管理できるサービスです。 AWS IoT Core における証明書要件の変更への対応方法に関するガイダンス 。 AWS プライベート CA ：AWS プライベート CA は、ルート CA や下位 CA を含むプライベートな認証局&nbsp;(CA)&nbsp;階層の作成を可能にします。 4. コネクテッドビークルの脆弱性管理の優先順位付けと実施、およびソフトウェアとファームウェアの更新のための適切な更新メカニズムを定義する。 ソフトウェアの普及と複雑化に伴い、不具合の数も増加し、その一部は悪用可能な脆弱性となり得ます。脆弱性に対処する際には、重要度&nbsp;( CVSS スコア など)&nbsp;に応じて優先順位をつけ、最も重要なアセットからパッチを適用します。 車載機器にソフトウェアやファームウェアをプッシュし、セキュリティ脆弱性にパッチを当て、機器の機能を向上させる仕組みを構築します。 ソフトウェアの実行を開始する前に、そのソフトウェアの真正性と完全性を検証し、それが信頼できるソース&nbsp;(ベンダーの署名入り)&nbsp;から提供されたものであり、安全な方法で入手されたものであることを確認します。 ソフトウェアのアップデートは、車両が安全な状態になり、さらにユーザーによって確認された場合にのみ実行できるようにします。 バージョンとパッチの状態を含め、接続されたデバイスフリート全体に展開されたソフトウェアのインベントリを維持します。 コネクテッドビークルのフリート全体のデプロイ状況を監視し、デプロイの失敗や停滞を調査するとともに、インフラストラクチャがフリートに対してセキュリティ更新をデプロイできない場合は関係者に通知します。 車両のソフトウェア更新に関する UNR 156 のような規制や、ソフトウェア更新エンジニアリングに関する ISO 24089 のような規格の範囲と要件を認識します。 参考リソース： Amazon FreeRTOS の OTA アップデート 。 AWS IoT Greengrass Core ソフトウェアの OTA アップデート 。 AWS IoT ジョブ は、AWS IoT に接続された 1 つ以上のデバイスに送信して実行するリモート操作のセットを定義します。 AWS Key Management Service&nbsp;(KMS )&nbsp;は、クラウド上の暗号操作に使用される鍵を簡単に作成し、制御することができます。AWS KMS に格納された非対称秘密鍵を使用してソフトウェアパッケージに署名し、対応する公開鍵を使用して ECU で署名を検証できます。 AWS IoT Device Management Software Package Catalog &nbsp;は、ソフトウェアパッケージとそのバージョンのインベントリを管理し、AWS IoTジョブと統合します。 5.&nbsp;保管時のデータを暗号化することにより、車両内およびクラウド内のデータを保護し、安全なデータ共有、ガバナンス、および主権のメカニズムを構築する。 暗号化と適切なアクセス制御が実装されている場合は、車両とクラウドの保管時のデータを暗号化し、不正アクセスのリスクを低減します。 前述のリスク分析に基づいて、コネクテッドビークル・システム全体で収集されたデータを特定し、分類します。 潜在的な不正データ改変を特定するために、静止状態の本番データを監視し、完全性チェックを適用します。 顧客のプライバシーと透明性への期待と、コネクテッドビークルを製造、配布、運用する法域における対応する法的要件を考慮します。 参考リソース： AWS データプライバシー 。 AWS Well-Architected Framework のセキュリティの柱における 保管中のデータの保護 。 センシティブなデータを発見し、保護するための&nbsp; Amazon Macie 。 AWS コンプライアンスプログラムとオファリング 。 6.&nbsp;車内で安全でないプロトコルを使用する場合は、ゲートウェイ ECU をクラウドへの安全なブリッジとして使用できます。 トランスポート層のセキュリティに加えて、機密データをバックエンドシステムに送信する前にクライアント側で暗号化することも検討します。 最新のインターネットネイティブ暗号ネットワークプロトコルを選択することで、データ転送、監視、管理、プロビジョニング、デプロイに使用するインバウンドおよびアウトバウンドのネットワーク通信チャネルの機密性と完全性を保護します。 可能であれば、特定の環境内で実装されるプロトコルの数を制限し、使用されていないデフォルトのネットワークサービスを無効にします。 必要な時に車両がオンラインでない場合&nbsp;(バッテリーを節約するためなど)&nbsp;を考慮して、信頼できるエンドポイントへの接続を確立するために車両をトリガーする別の方法を実装することを検討します。 参考リソース： デバイスを AWS IoT に安全かつ迅速に接続するための AWS IoT SDK 。 組み込みアプリケーションのネットワーキングとセキュリティのための FreeRTOS ライブラリ 。 AWS Encryption SDK は、クライアントサイドの暗号化ライブラリで、データをクラウドに送信する前に AWS KMS のキーを使用してクライアントサイドで車両データを暗号化するために使用できます。 AWS KMS を使用することで、クラウド上で暗号処理に使用する鍵を簡単に作成、管理することができる。 7. すべてのコネクティッド・リソース&nbsp;(特にインターネットに接続されたリソース)&nbsp;を強固にし、クラウドサービスへのセキュアな接続と車両へのリモートアクセスを確立する。 ECU や IoT デバイスなどのインターネットに接続されたネットワークリソースは、 Auto ISAC のセキュア設計原則 などのベストプラクティスに従って堅牢化する必要があります。 車両 ECU のネットワークサービスの利用は、必要不可欠な機能のみに制限します。 WS サービスへのアクセスには、長期的な認証情報の代わりにデバイスの証明書と一時的な認証情報を使用し、専用の暗号エレメントやセキュアフラッシュなどのメカニズムを使用して、保管時のデバイスの認証情報を保護します。デバイスは、ハードウェアのルートオブトラストとセキュアブートをサポートする必要があります。 プライベートセルラーネットワークと AWS IoT Core VPC エンドポイントを使用してクラウドへのプライベート接続を確立することにより、インターネットからネットワークトラフィックを分離します。 参考リソース： NIST Guide to General Server Security 。 AWS IoT Greengrass ハードウェアセキュリティ 。 Auto ISAC セキュリティ開発ライフサイクル 。 AWS サービスへのプライベート接続のための AWS PrivateLink 。 AWS IoT Core 認証情報プロバイダの VPC エンドポイント 。 8. セキュリティ監査と監視の仕組みを導入し、コネクテッドカーとクラウド全体でセキュリ ティアラートを一元管理する。 個々の車両やフリートが影響を受ける可能性のある、車両やクラウドリソースの脅威や脆弱性を検出して対応する仕組みを導入します。車載ネットワークとコネクテッド・サービスは、車両コンピューティング・リソースへの不正アクセスの検出をサポートするデータを生成します。 セキュリティイベント、脅威、脆弱性について車両を監視することをメーカーに義務付ける UNR155 などの規制に注意します。 ネットワークトラフィックのベースラインを作成し、異常とベースラインへの準拠を監視するために、コネクテッド・ビークル用の監視ソリューションを導入します。 ネットワークログ、アクセス制御の権限、資産構成の定期的なレビューを実施します。 セキュリティログを収集し、専用ツール&nbsp;(例えば、車両セキュリティ・オペレーション・センター&nbsp;(VSOC)&nbsp;内のようなセキュリティ情報・イベント管理&nbsp;(SIEM)&nbsp;クラスのソリューション)&nbsp;を使用してリアルタイムで分析する。 参考リソース： AWS IoT Device Defender は、コネクテッドカーの IoT デバイスのフリートを監視および監査します。 AWS Config ：AWS リソースの構成を評価、監査、評価します。 Amazon GuardDuty ：AWS アカウントとワークロードを保護するために、悪意のあるアクティビティと不正な動作を継続的に監視します。 AWS Security Hub ：AWS のセキュリティチェックを自動化し、セキュリティアラートを一元化します。 AWS リソースを監視するための Amazon CloudWatch と AWS CloudTrail 。 9. インシデント対応プレイブックを作成し、セキュリティ対応の成熟度に合わせて自動化を構築して、イベントを封じ込め、既知の良好な状態に戻す。 セキュリティインシデント対応計画を維持し、定期的に演習して、監視機能をテストします。 セキュリティログを収集し、自動化ツールを使用してリアルタイムで分析します。想定外の発見に関するプレイブックを作成します。 役割と責任を明確に理解したインシデント対応プレイブックを作成します。インシデント対応プレイブックには、準備手順、識別/トリアージ、封じ込め、対応、復旧、教訓も含めます。 インシデント対応手順を、ゲームデイや卓上演習で定期的にテストします。 手順がより安定するにつれて、その実行を自動化するが、人間による対話は維持します。 参考リソース： AWS セキュリティインシデント対応ガイド 。 AWS Systems Manager は、運用に関する洞察を収集し、日常的な管理タスクを実行するための、一元化された一貫性のある方法を提供します。 AWS Step Functions ：AWS Step Functions を使用すると、車両攻撃に関するセキュリティインシデント対応のために、手動承認ステップを含む自動化されたワークフローを作成できます。 AWS Security Hub &nbsp;は、AWS サービス、パートナー、またはその他のソースから取り込まれた車両固有の調査結果に対応し、格納します。 AWS での自動化されたセキュリティ対応 。 10. NIST の出版物や ISO/SAE 21434 に概説されているような、安全なソフトウェア開発のベストプラクティスに従う。 “シフトレフト“によって、システム開発の早い段階でセキュリティ対策に取り組み、セキュアなコードを実装します。パイプラインにコードをデプロイしてテストする時に、コードレビューを実施し、静的コード解析、動的アプリケーションセキュリティテストを使用します。製品のライフサイクルのできるだけ早い段階でサイバーセキュリティの管理と仕組みを適用し、開発・リリースサイクルを通じて、製品の寿命が尽きるまで継続的にテストを自動化します。 サイバーセキュリティはダイナミックで継続的に進化する性質があるため、自動車業界のメンバーは、 SAE International 、 ISO/IEC 33601 に基づく ASPICE フレームワーク、その他の ISO 規格 、 Auto-ISAC 、 NHTSA 、 Cybersecurity Infrastructure Security Agency&nbsp;(CISA) 、 NIST 、業界団体、その他公認の標準設定機関に基づく、またはそれらによって発行された、利用可能なサイバーセキュリティガイダンス、ベストプラクティス、設計原則、標準を常に把握しておくことが重要です。 Auto-ISAC&nbsp;への参加など、効果的な情報共有を通じて、教訓&nbsp;(脆弱性の共有など)&nbsp;を業界全体で迅速に採用する方法を制度化します。 参考リソース： Well-Architected CI/CD アプローチの選択 。 AWS Well-Architected Framework アプリケーションのセキュリティ 。 Amazon CodeGuru ：Amazon CodeGuru Security は、機械学習を使ってセキュリティポリシー違反や脆弱性を検出する静的アプリケーションセキュリティツールです。 AWS の CI/CD サービスを理解するために、この Complete CI/CD ブログポスト をチェックしてください。 AWS Well-Architected Framework の&nbsp; IoT Lens ：アーキテクチャのベストプラクティスに沿った IoT ワークロードを設計、デプロイ、アーキテクトするためのレンズ。 まとめ このブログポストでは、AWS の多層的なセキュリティアプローチと包括的なセキュリティサービスや機能を使用して、コネクテッドモビリティソリューションを安全に保つためのベストプラクティスのいくつかをレビューしました。AWS のコネクテッドビークル・セキュリティは、オープンスタンダードと認知度の高いサイバーセキュリティ・フレームワークに基づいて構築されています。自動車企業は、AWS のセキュリティサービスや、 AWS&nbsp;セキュリティコンピテンシーパートナー が提供する自動車ワークロードのためのセキュリティに特化したパートナーソリューションのネットワークから柔軟に選択できます。 詳細については、 AWS の取り組み: オートモーティブ&nbsp; をご覧ください。 この記事は&nbsp;Ryan Dsouza、Maitreya Ranganath、Omar Zoma&nbsp;によって書かれた&nbsp; Ten security golden rules for connected mobility solutions の日本語訳です。この記事は プロフェッショナルサービス本部 IoT コンサルタントの宮本 篤が翻訳しました。 <!-- '"` -->

最小権限の原則に従い、ユーザーはアプリケーション、ペルソナ、グループ、組織単位（OU）に基づいて、 Amazon Simple Storage Service（Amazon S3） のデータへのきめ細やかなアクセスを定義します。この方法は、不正アクセスのリスクを軽減し、セキュリティ侵害が発生した場合の損害を抑制するのに役立ちます。従業員が自分のタスクに不可欠なリソースへのアクセスのみを持つため、不注意による誤ったデータの取り扱いミスを抑制します。さらに、お客様は精密なユーザーアクティビティの追跡と分析を可能にする包括的な監査機能を望んでいます。この機能は、規制要件と内部ガバナンス基準への遵守に不可欠であり、異常な振る舞いやセキュリティインシデントの迅速な検出を可能にします。 先日、Amazon Web Services（AWS）は、新機能として Amazon S3 Access Grants を発表しました。これは、 Microsoft Entra （以前の Microsoft Azure AD）や Okta などのディレクトリ内のアイデンティティを Amazon S3 のデータセットにマッピングすることをユーザーに可能にします。これにより、ユーザーは企業アイデンティティに基づいてエンドユーザーに適切な Amazon S3 アクセスを自動的に付与することで、大規模にデータ権限を管理することができます。S3 Access Grants は、 AWS Identity and Access Management（IAM） と共に使用することも可能であり、Amazon S3 内の既存のリソースレベルのコントロール（例えば S3 バケットポリシー）を補完する簡単でスケーラブルな方法として利用できます。さらに、S3 Access Grants は、Amazon S3 データへのアクセスに使用されたエンドユーザーのアイデンティティとアプリケーションを AWS CloudTrail に記録します。これは、S3 バケット内のすべてのデータアクセスの詳細な監査履歴を提供するのに役立ちます。 この投稿では、S3 Access Grants とその構成についての概要を提供し、特定のアクセスパターンに基づいて S3 Access Grants の使用方法を例示します。これには、 IAM プリンシパルとの S3 Access Grants の使用方法と、企業ディレクトリからのユーザーやグループとの使用方法が含まれます。 大規模な詳細アクセスを実現 現在、ユーザーは Amazon S3 のデータへの詳細なアクセスを達成するために、アクセスパターンの規模と複雑さに応じてさまざまなアプローチを持っています。 Amazon S3 のデータへの詳細なアクセスを達成する方法は、アクセスパターンの規模と複雑さに基づいて変わります。小規模なデータセットの場合、ユーザーは通常、ポリシーサイズの制限内に収まる限り、 IAM アクセスポリシー と バケットポリシー を使用します。データセットとユースケースの数が増えるにつれて、AWS アカウント毎のリージョンあたり数千のアクセスポイントを許可する Amazon S3 アクセスポイント を使用するという代替オプションがあります。ただし、このアプローチには、データセットに適したアクセスポイントを見つけるための追加ロジックが必要であり、静的なアクセスパターンに適しています。データ権限の複雑で洗練された評価が必要な場合、第三のアプローチが検討され、ここでは「 IAM セッションブローカー 」パターンを採用し、ユーザーはアクセス決定のロジックを処理し、動的に短期の IAM セッション資格情報を生成します。この方法はスケーラビリティをサポートしていますが、ユーザー自身でアクセスパターンロジックを設計および実装する必要があります。 これらのアプローチではすべて、Amazon S3 データアクセスをユーザーやグループにマッピングし、アクセスを監査することに、ある程度のオーバーヘッドがあります。S3 Access Grants と IAM Identity Center の新しい Trusted Identity Propagation は、ユーザーやグループへの Amazon S3 の詳細なアクセスを管理するというこの複雑で時間のかかる作業をユーザーから取り除きます。 S3 Access Grants は、バケット、プレフィックス、またはオブジェクトレベルでの読み取り専用、書き込み専用、または読み書きアクセスなどの単純な権限を定義することをユーザーに可能にします。その後、ユーザーは IAM プリンシパルを S3 Access Grants に割り当てることができます。または、 AWS IAM Identity Center との統合を使用して、企業ディレクトリからユーザーやグループにアクセスを割り当てることができます。IAM Identity Center との統合を使用する場合、ユーザーはディレクトリにユーザーを認証する企業アプリケーションを持ち込むことができ、IAM Identity Center API との統合に数行のコードを追加することで、それらのアプリケーションが認証された各ユーザーの代理として Amazon S3 上のデータにアクセスできるようになります。さらに、IAM Identity Center 統合を使用すると、ユーザーのアイデンティティが Amazon S3 データへのすべてのアクセスとともに記録されるため、誰が何にアクセスしたかの監査が可能になります。 Amazon S3 Access Grants は、あなたのユースケースに適していますか？ Amazon S3 での多くの権限ユースケースは、IAM プリンシパルと S3 バケットの両方に対して IAM ポリシーを使用して、簡単かつ効果的に実装することができます。小規模なユースケースには、このアプローチをお勧めします。S3 Access Grants は、次のような状況で S3 でのデータ権限の管理を簡素化します： Amazon S3 に大量のデータセットがあり、IAM や S3 バケットポリシーの文字数制限が懸念される場合。 権限スキームがユーザー/グループからデータセットへのパターンにより自然に適合し、中間の IAM ロールを使用してアクセスを得るよりも、ディレクトリグループに直接権限を割り当てる方が簡単な場合。 より複雑な多対多のユーザーからデータへのマッピング、例えば個々のユーザーが複数のグループのメンバーであり、そのための Amazon S3 内のデータセットの和集合へのアクセスが必要なケース。 S3 Access Grants の仕組みを詳しく説明する前に、S3 Access Grants のさまざまな構成要素を理解しましょう。 Amazon S3 Access Grants – コンセプト S3 Access Grants は、その簡略化されたアクセススキームのためにいくつかのコンセプトを導入します。まず、それらを定義していきます。 S3 Access Grants インスタンス: S3 Access Grants インスタンスは、Amazon S3 データへのアクセスレベルが誰にどのように付与されているかを定義する個々の権限の論理的なグループです。1 つの AWS アカウント内の 1 つの AWS リージョンごとに 1 つのインスタンスを設定できます。このアカウントおよびリージョンレベルの S3 Access Grants インスタンスは、同じアカウントおよび AWS リージョンのすべてのバケットへのアクセスを制御できます。外部ディレクトリのユーザーやグループにアクセスを付与するために S3 Access Grants を使用する場合は、S3 Access Grants インスタンスを IAM Identity Center インスタンスに関連付ける必要があります。他の AWS アカウントの IAM プリンシパルにアクセスを付与する場合は、これらのクロスアカウント API 呼び出しを許可するために、S3 Access Grants インスタンスにリソースベースのポリシーを使用します。 ロケーション: S3 Access Grants は、特定の Amazon S3 プレフィックスへのアクセスをスコープとした IAM 資格情報を発行することで機能します。S3 Access Grants ロケーションは、これらの一時セッションが作成される IAM ロールに関連付けられています。最も一般的な設定は、すべての S3 Access Grants に対して s3:// で単一のロケーションを使用することで、AWS リージョンおよびアカウント内のすべての S3 バケットへのアクセスをカバーできます。S3 Access Grants はこれを「デフォルト」ロケーションと呼びます。より高度なユースケースで複数の異なる IAM ロールの使用が必要な場合、お客様はそれを行うために複数の S3 Access Grants ロケーションを作成できます。 権限: S3 Access Grants の個々の権限は、特定のエンティティ（IAM プリンシパル、ディレクトリユーザー、またはディレクトリグループ）に対して、S3 バケット、プレフィックス、またはオブジェクトへのアクセスを許可します。たとえば、特定のディレクトリグループ 01234567-89ab-cdef-0123-456789abcdef に s3://DOC-EXAMPLE-BUCKET/projects/foo/* への READ アクセスを許可する権限を持っている場合、そのグループのユーザーはそのバケット内の projects/foo/ の下のすべてに読み取りアクセスを許可されます。 S3 Access Grants の一時的な資格情報: アプリケーションは、新しい Amazon S3 API、 GetDataAccess を呼び出して、単一のオブジェクト、プレフィックス、またはバケットへのアクセス権限をリクエストし、READ、WRITE、または READWRITE の権限レベルを要求します。S3 Access Grants 機能はリクエストを設定された権限に対して評価します。一致する権限があれば、その権限のロケーションに関連付けられた IAM ロールを引き継ぎ、権限を IAM セッションの権限に正確にスコープし、Amazon S3 プレフィックスまでの権限を与えます。アクセス資格情報の有効期限はデフォルトで 1 時間ですが、15 分から 36 時間まで任意の値に設定することができます。 これらの構成を例を挙げて理解しましょう。最初のセクションではシナリオを説明し、次にそのシナリオに対して S3 Access Grants を実装します。 Amazon S3 Access Grants – セットアップ 私たちが説明する例において、S3 Access Grants がどのようにマップされるかを理解するために、 developerRole および analystRole 、2 つの IAM ロールを定義します。重要なのは、ロールは実際の人々ではなく、人々やサービスが引き受ける役割であるということです。後ほど、IAM Identity Center を使用して、アクセスが実際のユーザーやグループに基づいていることを示します。 アクセスパターンのシナリオ 以下の図では、 s3:// でスコープが定義されたデフォルトの Amazon S3 のロケーションと、アカウント内で Amazon S3 のアクションを実行する権限を持つ IAM ロール s3ag-location-role が定義されています。S3 Access Grants は、アクセスのリクエストに対してこの IAM ロールを使用して一時的な資格情報を作成します。 次に、以下のアクセスを定義します。IAM ロール developerRole は、 developer/ プレフィックスに対して READ および WRITE のアクセス権を持ちます。別の IAM ロール analystRole は、 analysis/ プレフィックスに対して READ アクセスのみが許可されます。左側の S3 Access Grants（青色で表示）は、 DOC-BUCKET-EXAMPLE バケット内のプレフィックス developer/ へのアクセスを developerRole に与えるために定義されています。右側の S3 Access Grants（緑色で表示）は、 DOC-BUCKET-EXAMPLE バケット内のプレフィックス analysis/ へのアクセスを analystRole に与えるために定義されています。これは 図 1 で示されています。 図 1: S3 Access Grants の概要 図 1 に示されているように、Bob がデータを読む時、 developerRole IAM ロールを使用して S3 Access Grants GetDataAccess API を呼び出します。 s3://DOC-BUCKET-EXAMPLE/developer/ で始まる任意の Amazon S3 プレフィックスまたはオブジェクトへの READ 権限を要求する場合、 GetDataAccess は s3://DOC-BUCKET-EXAMPLE/developer/* への権限を持つ S3 Access Grants の一時的な資格情報を返します。同様に、WRITE アクセスを要求することもできます。なぜなら、権限はそれも許可しているからです。 同様に、Alice は analystRole IAM ロールを使用して GetDataAccess を呼び出し、Amazon S3 の s3://DOC-BUCKET-EXAMPLE/analysis/ で始まるものへの READ アクセスを要求できます。そして、S3 Access Grants は適切にスコープされた IAM セッション資格情報を返します。しかし、WRITE 権限を要求する場合、データへの書き込み権限を与える権限がないため、アクセス拒否エラーが発生します。さらに、Alice が s3://DOC-BUCKET-EXAMPLE/developer/ の下のデータへのアクセスを任意のレベルで要求する場合、または Bob が s3://DOC-BUCKET-EXAMPLE/analysis/ の下のデータへのアクセスを任意のレベルで要求する場合も、アクセス拒否となります。 S3 Access Grants インスタンスあたり最大 10 万の権限と 1,000 のロケーションを持つことができます。個々のユーザーとプレフィックスのアクセス許可の組み合わせが追加または削除されるたびに、長く複雑な S3 バケットポリシーを編集する代わりに、各関係に対して個別の権限を追加および削除することができます。 アクセスパターンのシナリオのセットアップ S3 Access Grants についての基本的な概念を理解したところで、前のセクションで示した権限を作成する方法を見ていきましょう。この例では、IAM ロール developerRole と analystRole 、および S3 バケット DOC-EXAMPLE-BUCKET が既に存在しているとします。 1. S3 Access Grants インスタンスの作成: S3 Access Grants インスタンスを作成するには、以下のコマンドを実行します。 aws s3control create-access-grants-instance --account-id 123456789012 2. S3 Access Grants ロケーションの作成: 次のステップは、S3 Access Grants ロケーションを作成することです。これを行うには、S3 Access Grants サービスに信頼を持ち、Amazon S3 リソースへのアクセスを許可する IAM ロールが必要です。この IAM ロールを s3ag-location-role と呼びます。 i. S3 Access Grants IAM ロール : S3 Access Grants が資格情報を生成できるようにするためには、IAM ロールを作成し、それをロケーションに関連付ける必要があります。IAM ロール信頼ポリシーは、サービスプリンシパル access-grants.s3.amazonaws.com が以下のアクションを実行できるようにする必要があります： – sts:AssumeRole – 要求者のアイデンティティで IAM 資格情報を生成するために必要 – sts:SetSourceIdentity – IAM ロールを引き受ける権限を使用する場合に必要 – sts:SetContext – DIRECTORY_USER/DIRECTORY_GROUP の権限を使用する場合に必要 trust-policy.json というファイルを作成し、以下の内容をファイルにコピー＆ペーストしてください： //trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "access-grants.s3.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:SetContext" ] } ] } その後、以下のコマンドを実行してください： aws iam create-role --role-name s3ag-location-role \ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --assume-role-policy-document file://trust-policy.json ii.&nbsp;IAM ロールに Amazon S3 の権限を付与する IAM ポリシーを作成する iam-policy.json というファイルを作成してください //iam-policy.json { "Version": "2012-10-17", "Statement": [ { "Sid": "ObjectLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectAcl", "s3:GetObjectVersionAcl", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "ObjectLevelWritePermissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectVersionAcl", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "BucketLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "{{accountId}}" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:{{region}}:{{accountId}}:access-grants/{{instanceId}}" ] } } }, { "Sid": "KMSPermissions", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "*" ] } ] } 注記: この IAM ポリシーでは、プレースホルダー {{ accountId }}, {{ region }}, および {{ instanceId }} を、それぞれあなたのアカウント、AWS リージョン、Access Grants インスタンス ID の情報に置き換える必要があります。上記のポリシーはデフォルトロケーション用です。デフォルト以外のロケーションを作成する場合は、ポリシーのリソース要素内のロケーションリストを更新してください。 その後、以下のコマンドを実行してください： aws iam put-role-policy --role-name s3ag-location-role --policy-name s3ag-location-role --policy-document file://iam-policy.json iii. S3 Access Grants ロケーションの作成 IAM ロールを作成したので、アカウント用のデフォルト S3 Access Grants ロケーションを作成し、その IAM ロールと関連付けることができます。 aws s3control create-access-grants-location \ --account-id 123456789012 \ --location-scope s3:// \ --iam-role-arn arn:aws:iam::123456789012:role/s3ag-location-role ロケーションスコープを s3:// に設定することは、S3 Access Grants ロケーションを作成する際に推奨されるオプションです。これにより、すべての GetDataAccess リクエストに対して s3ag-location-role を使用して資格情報を発行するように S3 Access Grants に指示します。 S3 Access Grants を使用した Amazon S3 データへのアクセス（同一アカウントのシナリオ） 1. アクセス権限の作成: これで、IAM ロール developerRole と analystRole にそれぞれ developer/ および analysis/ プレフィックスへのアクセス許可を付与する権限を作成することができます。この時点で、 developerRole に s3://DOC-EXAMPLE-BUCKET/developer/* への読み書きアクセス権限を与えるための 1 つの権限と、 analystRole に s3://DOC-EXAMPLE-BUCKET/analysis/* への読み取り専用アクセス権限を与えるための別の権限を作成できます。 developer/ プレフィックスに developerRole 用の READWRITE S3 Access Grants の権限を作成します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/developer/*” \ --permission READWRITE \ --grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/developerRole analysis/ プレフィックスに analystRole 用の READ S3 Access Grants の権限を作成します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix=”DOC-EXAMPLE-BUCKET/analysis/*” \ --permission READ \ --grantee GranteeType=IAM,GranteeIdentifier=arn:aws:iam::123456789012:role/analystRole developerRole と analystRole の IAM ロールに Amazon S3 プレフィックスへのアクセスを S3 Access Grants の権限を通じて与えるため、データへの直接的なアクセス権限（例： s3:GetObject アクション）を与える必要はありません。代わりに、各ロールに必要なのは s3:GetDataAccess 、つまり S3 Access Grants からデータへのアクセスを要求する能力です。言い換えれば、S3 Access Grants は、これらの IAM ロールのどれがどのデータセットへのアクセス権を持っているかを評価します。 ここには、IAM ロール developerRole と analystRole に必要な IAM ポリシーの例があります： { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetDataAccess" ], "Resource": [ "arn:aws:s3:us-east-2:123456789012:access-grants/default" ] } ] } developer および analyst の IAM ロールのための権限が現在設定されています。次に、 developerRole を使用して Bob がその権限を利用して Amazon S3 のデータを読む方法を示します。 2. 一時的な資格情報のリクエスト: developerRole を使用して、Bob は S3 Access Grants の GetDataAccess API への API リクエストを行います。 aws s3control get-data-access \ --account-id 123456789012 \ --target s3://DOC-EXAMPLE-BUCKET/bob/developer/*&nbsp; \ --permission READ S3 Access Grants はリクエストを行ったプリンシパル、ターゲット、およびリクエストされた権限に基づいてリクエストを評価します。ターゲットがこのバケットとプレフィックスで始まる任意の権限と一致する限り、S3 Access Grants は成功レスポンスを返します。この成功レスポンスは S3 からのデータを返すわけではなく、そのデータにアクセスするための S3 Access Grants の一時的な資格情報を返します。前述のリクエストに対して、 GetDataAccess API は成功します。なぜなら呼び出し元である developerRole は、リクエスト ( s3://DOC-EXAMPLE-BUCKET/developer/ ) と一致するターゲット s3://DOC-EXAMPLE-BUCKET/developer/* に権限を持っているためです。 レスポンスは以下のようになります： { "Credentials": { "AccessKeyId": "ASIACKCEVSQ6C2EXAMPLE", "SecretAccessKey": "je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY", "SessionToken": "&lt;SessionTokenString...&gt;", "Expiration": "2023-11-07T17:34:37+00:00" }, "MatchedGrantTarget": "s3://DOC-EXAMPLE-BUCKET/developer/*" } 前述の成功レスポンスには一時的な IAM セッションの認証情報が含まれています。これらの認証情報を使用して、アプリケーションは例えば Amazon S3 の GetObject API などの Amazon S3 リクエストを行い、これらの認証情報が有効な期間内に s3://DOC-EXAMPLE-BUCKET/developer/ 下の任意のオブジェクトにアクセスすることができます。言い換えれば、S3 Access Grants アプリケーションは通常、個々のオブジェクトへのアクセスをそれぞれリクエストするべきではありません。代わりに、一致した権限の下での全てのアクセスに対して認証情報を再利用すべきです。 GetDataAccess への任意のリクエストがこの権限と一致する場合、成功レスポンスで同じ MatchedGrantTarget が結果として返されます。例えば、もし Bob が s3://DOC-EXAMPLE-BUCKET/developer/reports/file.txt への READ アクセスをリクエストした場合、それも権限と一致するため、S3 Access Grants は成功します。デフォルトでは、その成功レスポンスには一致した権限の下ですべてにアクセスするための一時的な IAM セッションの認証情報が含まれています。これは s3://DOC-EXAMPLE-BUCKET/developer/ です。ほとんどの S3 Access Grants の使用例では、アプリケーションが同じプレフィックスの下で多くの後続のリクエストを行う可能性が高いため、これが望ましい挙動です。しかし、アプリケーションがより狭い範囲のアクセスを望む場合が稀にあります。その場合、「privilege」オプションのパラメーターを「minimal」の値に設定できます。その場合、S3 Access Grants は特定のリクエストされたオブジェクトにのみアクセスする一時的な IAM セッションの認証情報を返します。 GetDataAccess リクエストと developerRole のレスポンスの例をいくつか示します。この例では、 developerRole に対して次の二つの権限があると仮定します： s3://DOC-EXAMPLE-BUCKET/developer/* への READ 権限 s3://DOC-EXAMPLE-BUCKET/developer/reports/* への READ 権限 developerRole への権限に対する privilege の動作を見てみましょう。 リクエストされた範囲 privilege 設定 返された範囲 効果 DOC-EXAMPLE-BUCKET/developer/ default DOC-EXAMPLE-BUCKET/developer/* “developer/”で始まるすべてのオブジェクトへの読み取りアクセス DOC-EXAMPLE-BUCKET/developer/ minimal DOC-EXAMPLE-BUCKET/developer/ “developer/”という名前の S3 オブジェクトへの読み取りアクセスのみ（そのようなオブジェクトがあることは一般的ではない）；“developer/”プレフィックスの下のオブジェクトへのアクセス権は無し DOC-EXAMPLE-BUCKET/developer/images/* minimal DOC-EXAMPLE-BUCKET/developer/images/* “developer/images/”で始まるすべてのオブジェクトへの読み取りアクセス DOC-EXAMPLE-BUCKET/developer/reports/file.txt default DOC-EXAMPLE-BUCKET/developer/reports/* “developer/reports/”で始まるすべてのオブジェクトへの読み取りアクセス（より具体的な一致した権限があったため） DOC-EXAMPLE-BUCKET/developer/reports/file.txt minimal DOC-EXAMPLE-BUCKET/developer/reports/file.txt キー developer/reports/file.txt を持つオブジェクトへの読み取りアクセス。他のオブジェクトへのアクセス権は無し 前述の例では、Amazon S3 内の 2 つのプレフィックスにロールベースのアクセスを提供することにより、S3 Access Grants の動作を説明しました。S3 内のたった 2 つの IAM ロールと 2 つのデータセットを使用するこのパターンは、直接の IAM 許可技術を使用して十分に実装することができ、そのために S3 Acess Grants は必要ありません。しかし、IAM ロール、Amazon S3 内のプレフィックス、およびアクセスマッピングの数と複雑さが増すにつれて、S3 Access Grants は管理上の利点を持ち始めます。これにより、単一の権限を一つずつ管理できるようになり、大規模に編集すると複雑になることがある一枚岩の IAM ポリシードキュメントの編集よりも効果的です。特に、これらの IAM ロールの一部がバケットとは異なる AWS アカウント内にある場合、S3 バケットポリシーのサイズ制限が、サポートできる異なるアクセスパターンの数に影響します。 次のセクションでは、AWS アカウント間でのアクセスのための S3 Access Grants の設定方法について説明します。 S3 Access Grants を使用した Amazon S3 データへのアクセス（クロスアカウントのシナリオ） S3 Access Grants インスタンスはリソースベースのポリシーをサポートしています。そのため、適切なリソースベースのポリシーがあれば、S3 Access Grants は他の AWS アカウントの IAM プリンシパルにアクセスを許可するためにも使用することができます。 この例では、AWS アカウント 111111111111 への権限の付与をサポートすることを目的としています。AWS アカウント 111111111111 の IAM プリンシパルが s3:GetDataAccess を使用して S3 内のデータにアクセスすることが期待されているため、このアクションをクロスアカウントで実行することを許可しています。ここに示されている s3:ListAccessGrants と s3:ListAccessGrantsLocations の権限は、このアカウントが S3 Access Grants をリストし、それらを使用してデータにアクセスすることを期待している場合に必要となります。 //s3ag-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "111111111111" }, "Action": [ "s3:ListAccessGrants", "s3:ListAccessGrantsLocations", "s3:GetDataAccess" ], "Resource": "arn:aws:s3:us-east-2:123456789012:access-grants/default" } ] } このポリシードキュメントを S3 Access Grants インスタンスに割り当てるには、次のコマンドを実行できます： aws s3control put-access-grants-instance-resource-policy \ --account-id 123456789012 \ --policy file://s3ag-policy.json \ --region us-east-2 この S3 Access Grants インスタンスのポリシーは通常のリソースベースのポリシーであり、IAM ポリシー言語がサポートするすべてをサポートしています。たとえば aws:PrincipalArn 条件を使用してアカウント 111111111111 の特定の IAM プリンシパルにアクセスを許可することもできましたが、通常はここでそれを行う必要はありません。代わりに、S3 Access Grantsインスタンス内で、そのアカウントの個々の IAM プリンシパルに対して詳細な権限を記述します。これらは S3 Access Grants で個別に管理する方が、リソースベースのポリシーで行うよりも簡単です。 以下は、アカウント 1111111111 から testingRole へのクロスアカウント権限付与の図です。 図 2: クロスアカウントアクセスを持つ Access Grants これまでに、同じ AWS アカウント内および異なる AWS アカウントの IAM プリンシパルにアクセスを許可するために S3 Access Grants を使用することについて話しました。特に強力な機能は、IAM Identity Center との S3 Access Grants の統合によってもたらされる、ディレクトリユーザーとグループに直接権限を付与する能力です。たとえば、組織のユーザーがデータにアクセスするために使用する企業アプリケーションがある場合、これらのユーザーとグループに直接アクセスを許可することができます。これにより、これらのアプリケーションは以前のようにユーザーを IAM ロールにマッピングする必要がなくなります。次のセクションでは、S3 Access Grants をディレクトリユーザーやグループと使用する方法を紹介します。 ディレクトリユーザーの S3 Access Grants を使用した S3 データへのアクセス S3 Access Grants を AWS IAM Identity Center と一緒に使用する場合、企業ディレクトリ内のユーザーまたはそのグループメンバーシップに基づいてロケーションへのアクセスをユーザーに提供することができます。IAM Identity Center は AWS クラウド内で持っているユーザーを取り込み、AWS 管理アプリケーションや AWS アカウントへの割り当てに利用できるようにする一つの場所を提供します。S3 Access Grants を IAM Identity Center に接続すると、ユーザーは S3 Access Grants を使用してシングルサインオン体験を提供するアプリケーションを通じて Amazon S3 データにアクセスすることができます。これらのユーザーは IAM ロールを直接理解したり使用したりする必要はありません。これによるもう一つの利点は、ユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに記録されることで、誰が（どのユーザーが）データにアクセスしたかを判断する監査作業が簡素化されることです。 S3 Access Grants をこの方法で使用する前に、まず AWS IAM Identity Center を設定する必要があります。詳細については、 ワークフォースアイデンティティの管理 を参照してください。知っておくべき主なことは、以下の通りです： IAM Identity Center にサポートされているアイデンティティプロバイダーを接続し、既存のユーザーとグループを使用するか、IAM Identity Center 内でユーザーとグループを作成することができます。 S3 Access Grants を使用するユーザーとグループを IAM Identity Center にプロビジョニングする必要があります。外部アイデンティティプロバイダーを使用する場合、これはクロスドメインアイデンティティ管理（SCIM）プロトコルを使用して行うのが最適です。 ユーザーは、IAM Identity Center と統合されている AWS サービスやアプリケーションを通じてデータにアクセスする必要があります。シングルサインオン体験を通じてデータセットにアクセスするアプリケーションを構築する方法については、 このブログ記事 を参照してください。 IAM Identity Center の設定方法については、 AWS IAM Identity Center を有効にする をご覧ください。 ここでは、企業のユーザーやグループ向けに S3 Access Grants で権限を作成する方法をご紹介します。 IAM Identity Center を有効にし、ID ソースを設定し、ユーザーをプロビジョニングしたら、ユーザーやグループに直接アクセスを許可する準備が整います。その手順は以下の通りです： 1. S3 Access Grants を IAM Identity Center に関連付ける この手順により、Access Grants で IAM Identity Center のユーザーやグループを参照できるようになります。これは S3 Access Grants コンソールでワンクリックで行うこともできます。 aws s3control associate-access-grants-identity-center \ --account-id 123456789012 \ --identity-center-arn arn:aws:sso:::instance/ssoins-1234567890abcdef 2. IAM Identity Center からユーザーやグループに権限を作成する Identity Center から特定のユーザーやグループに S3 Access Grant を作成するには、IAM Identity Center で GUID を見つける必要があります。以下では、IAM Identity Center コンソールでこの値を見つける場所を示しています。例えば、ユーザー「 Rafael 」の IAM Identity Center での GUID は 83d43802-00b1-7054-db02-f1d683aacba5 です。 図 3: ユーザー ID 付き Identity Center ユーザー情報 IAM Identity Center のユーザーの GUID を見つける別の方法としては、AWS CLI を通じて、または AWS SDK を使用してプログラム的に Identity Store API への API リクエストを行う方法があります。 こちらが Identity Store API のドキュメント です。 たとえば、このコマンドは IAM Identity Center のユーザーを名前と識別子と共にリストします。 aws identitystore list-users --identity-store-id d-1a2b3c4d1234 このコマンドはユーザーの GUID を返します。 aws identitystore get-user-id --region us-east-21 --cli-input-json '{ "IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { "AttributePath": "UserName", "AttributeValue": "rafael" } } }' このコマンドは IAM Identity Center のグループをリストします。 aws identitystore list-groups --identity-store-id d-1a2b3c4d1234 そして、このコマンドは “ TeamA ” という名前のグループの GUID を返します。 aws identitystore get-group-id --region us-east-21 --cli-input-json '{ "IdentityStoreId": "d-1a2b3c4d1234", "AlternateIdentifier": { "UniqueAttribute": { "AttributePath": "DisplayName", "AttributeValue": "TeamA" } } }' IAM Identity Center のディレクトリユーザーとグループに S3 Access Grants 権限を付与することは、IAM プリンシパルへのアクセスを付与することに似ています。付与される対象のタイプは DIRECTORY_USER または DIRECTORY_GROUP で、付与される識別子は IAM Identity Center がユーザーやグループを識別するために使用する GUID になります。 例えば、 get-user-id を使用して Rafael の GUID を取得し、以下のコマンドでそのユーザー ID&nbsp; 83d43802-00b1-7054-db02-f1d683aacba5 に DOC-EXAMPLE-BUCKET/rafael/* の範囲でアクセス権を付与します。 aws s3control create-access-grant \ --account-id 123456789012 \ --access-grants-location-id default \ --access-grants-location-configuration S3SubPrefix="DOC-EXAMPLE-BUCKET/rafael/*" \ --permission READWRITE \ --grantee GranteeType=DIRECTORY_USER,GranteeIdentifier=83d43802-00b1-7054-db02-f1d683aacba5 \ 結論 この投稿では、S3 Access Grants が Amazon S3 へのデータアクセスを拡張する方法について学びました。これらの権限は IAM プリンシパルをサポートするだけでなく、IAM Identity Center と同期された企業ディレクトリのユーザーとグループに直接アクセス権を付与することも可能です。 S3 Access Grants は、IAM ベースの技術よりも柔軟でスケーラブルなメカニズムを提供し、大規模なアクセスパターンを定義できます。IAM Identity Center Trusted Identity Propagation との統合により、認証された各ユーザーの代わりに Amazon S3 のデータにアクセスし、ユーザーを認証するデータアプリケーションを開発することができます。また、最終的なユーザーのアイデンティティが Amazon S3 の AWS CloudTrail データイベントに表示されるため、監査が簡素化されます。 S3 Access Grants について詳しく知りたい場合は、 ドキュメント をご覧ください。 Rafael Koike Rafael M. Koike は、サウスイーストのエンタープライズカスタマーをサポートするプリンシパルソリューションアーキテクトであり、Storage TFC の一員です。セキュリティ、ストレージ、ネットワーキング、アプリケーション開発における彼の専門知識は、お客様が安全かつ迅速にクラウドへ移行する際に重要な役割を果たしています。 Vaibhav Sabharwal Vaibhav Sabharwal は、ニューヨークを拠点とする Amazon Web Services のシニアソリューションアーキテクトです。新しいクラウドテクノロジーの学習に情熱を持ち、クラウド採用戦略の構築、革新的なソリューションの設計、オペレーショナル・エクセレンスの推進を顧客に支援しています。AWS の金融サービス技術分野コミュニティのメンバーとして、業界内の協力的な取り組みに積極的に貢献しています。 この記事は Scaling data access with Amazon S3 Access Grants (記事公開日: 2023 年 11 月 26 日) を翻訳したものです。翻訳は串上が担当しました。 <!-- '"` -->

AWS Migration Hub Orchestrator を使用する理由 世界中の何千ものお客様が、ミッションクリティカルな SAP アプリケーションの実行に AWS を信頼しています。まだオンプレミスの SAP アプリケーションについては、多くのお客様が AWS と SAP のベストプラクティスに従いながら、より簡単に AWS に移行する方法を求めています。 AWS Migration Hub Orchestrator for SAP は、手動タスクの多くを排除し、移行中に関係するさまざまなツール間の依存関係を管理し、移行の進捗状況を 1 か所で確認できるようにすることで、AWS への移行に必要な時間と労力を削減します。 このブログでは、AWS Migration Hub Orchestrator の仕組み、アーキテクチャ、サポートされている移行パターン、前提条件、および全体的な移行プロセスについて説明します。 AWS ソリューションの概要 AWS Migration Hub Orchestrator は、サーバーとエンタープライズアプリケーションの AWS への移行を簡素化および自動化し、移行を一元的に管理および追跡できます。 AWS Migration Hub Orchestrator を使用すると、SAP S/4HANA、SAP BW/4HANA、および SAP ERP on HANA などの SAP HANA ベースの SAP Netweaver アプリケーションを AWS に移行できます。AnyDB を使用して SAP アプリケーションを Amazon EC2 にリホストすることもできます。Migration Hub Orchestrator には、実証済みの SAP 移行のベストプラクティスに基づいた定義済みのワークフローテンプレートが用意されています。さらに、特定の移行要件に応じてステップを追加、並べ替え、または削除することで、移行ワークフローをカスタマイズできます。 Migration Hub Orchestrator がサポートする機能: HANA ベースのテンプレート駆動型 SAP NetWeaver アプリケーションのオンプレミスから AWS への移行 移行方法論とツールにより、技術的なダウンタイムと前後の手動タスクが最小限に抑えられます ワークフローのカスタマイズにより、お客様はお客様固有の移行タスクを実行する手順を追加することができます ソースシステムとターゲットシステム間の移行について、複数のアーキテクチャパターンをサポートします アプリケーションのパフォーマンスと可用性の要件を満たすように、必要に応じてターゲットシステム/SAP システムのコンポーネントのサイズを調整できます オペレーティング・システム・バージョンまたは Linux ディストリビューションの変更をサポートします たとえば、SUSE から RHEL へ、SLES 12 SP4 から SLES 15 SP1 へ 移行中の新しいマイナー HANA バージョンへのアップグレードをサポートします 例:HANA 2.0 SPS01 から HANA 2.0 SPS05 へ ソースシステムとターゲットシステムでサポートされている SAP アプリケーションアーキテクチャ: シングルノード — SAP アプリケーションまたは HANA データベースをシングルノードにデプロイします マルチノード — SAP アプリケーションまたは HANA データベースを異なるノードにデプロイします 高可用性 — SAP アプリケーションまたは HANA データベースを高可用性モードでマルチノードにデプロイします AWS Migration Hub Orchestrator を使用した SAP 移行アーキテクチャ: AWS Migration Hub Orchestrator は、 SAP のネイティブ HANA システムレプリケーション メカニズムを活用してソースとターゲット HANA システム間のデータレプリケーションを設定することにより、SAP HANA ベースの SAP NetWeaver システムを AWS に移行します。移行中は、AWS Launch Wizard for SAP を使用して SAP NetWeaver アプリケーションをホストするターゲット環境を AWS に設定する方法も案内されます。 AWS Migration Hub Orchestrator は現在、HANA データベースと SAP アプリケーションについて以下のソース/ターゲットパターンをサポートしています。 Source System Configuration (HANA Only) Target System Configuration (HANA Only) HANA scale-up/single node HANA scale-up/single node HANA scale-up/single node HANA HANA with High Availability HANA scale-out/multi-node HANA scale-out/multi-node HANA with High Availability HANA with High Availability Source System Configuration (SAP Application and HANA DB) Target System Configuration (SAP Application and HANA DB) SAP central system SAP central system SAP central system SAP distributed system SAP central system SAP application with High Availability SAP distributed system SAP distributed system SAP distributed system SAP applications with High Availability SAP applications with High Availability SAP applications with High Availability 図:マイグレーションハブオーケストレータを使用したシングルノード HANA からシングルノード HANA への移行のアーキテクチャ例 移行前のセットアップと前提条件: お客様は、SAP アプリケーションの移行を開始する前に、一般設定と 1 回限りのセットアップ作業が完了していることを確認する必要があります。 一般設定: オンプレミスと AWS 仮想プライベートクラウド (VPC) およびアカウント間のネットワークレベルの通信を可能にする AWS Direct Connect または AWS VPN SAP HANA システムレプリケーションの前提条件: ソースシステムとターゲットシステムの両方がインストールされ、構成されており、両方が独立して稼働していることを確認してください。 ターゲットシステムは、プライマリシステムと同じ SAP システム ID とインスタンス番号を持っている必要があります。 セカンダリ HANA DB の HANA データベースバージョンは、プライマリサーバーのバージョンと同じかそれ以上でなければなりません。 SAP HANA システムレプリケーションの 前提条件 の詳細については、SAP のドキュメントを参照してください。 ネットワーク要件: ソースとターゲットの SAP Elastic Compute Cloud (EC2) インスタンスは、プラグインサーバーからの SSH ポート 22 経由の通信を許可する必要があります。 API 呼び出しを通じて AWS Migration Hub Orchestrator サービスと通信するには、プラグインサーバーが HTTPS インバウンドおよびアウトバウンド TCP 443 ポートを使用してインターネットに接続する必要があります。 初回セットアップ作業: Migration Hub Orchestrator コンソールにアクセスするには、AWS Identity and Access Management (IAM) 権限が必要です。これらの権限により、AWS アカウントのマイグレーションハブオーケストレータリソースに関する詳細を一覧表示したり表示したりできる必要があります。ユーザーは IAM の前提条件 を満たす必要があります。 Migration Hub Orchestrator プラグインは、オンプレミスの VMware vCenter 環境にインストール ( セットアップ ) できる仮想アプライアンスです。このプラグインは、移行プロセス中にソース SAP システムでの移行アクティビティを調整します。 デプロイしたら、AWS コンソールのプラグインセクションでプラグインのステータスがアクティブであることを確認してください。 SAP ソースサーバーを検出: 移行の最初のステップは、オンプレミスの SAP サーバーの情報を検出し、検出されたサーバーを移行および追跡するアプリケーションにグループ化することです。AWS Migration Hub は、 AWS 検出ツール によるアプリケーション検出をサポートしています。 手順 に従って検出方法を選択し、移行予定のすべてのサーバーの検出を完了してください。 以下の図に示すように、検出プロセスの最後までに SAP ソースサーバーが検出ツールに表示される必要があります。 検出された SAP アプリケーションとデータベースサーバーは、「Applications」の下にグループ化する必要があります。AWS Migration Hub Orchestrator は「Application Name」を使用して定義済みのソースシステムを識別し、ターゲット AWS ランディングゾーンに移行します。 アプリケーション移行フェーズの準備: ソース HANA データベースの認証情報とターゲットシステムのキーペアが AWS Secrets Manager で管理されていることを確認します。 前提条件の手順 に従ってください。 キーペア名とシークレット名は同じでなければなりません。 たとえば、キーペア名「migrationhub-orchestrator-keyname123」など。 たとえば、シークレット名「migrationhub-orchestrator-keyname123」など。 (重要:キーペアは migrationhub-orchestrator-というプレフィックスで始まる必要があり、その後に英数字値が続く必要があります)。 AWS Launch Wizard for SAP を使用してターゲット SAP ランドスケープを AWS にデプロイし、デプロイ名はわかりやすいようにしておきます。移行プロセスでは、移行プロセス中にターゲットシステムのデプロイ名の入力を求められます。 移行プロセスでは、SAP HANA システムレプリケーションを利用してオンプレミスサーバーから AWS にデータを移行します。デプロイされたターゲットシステムは、「SAP HANA システムレプリケーションを設定するための一般的な前提条件」に記載されている HANA システムレプリケーションの前提条件を満たしています。 前提条件情報 については、SAP リファレンスリンクを参照してください。 SAP アプリケーションフェーズの移行: Migration Hub コンソールに移動し、「Orchestrator」→「Create Migration workflow」を選択します。 「Migrate SAP NetWeaver applications to AWS」テンプレートを選択し、「Next」をクリックします。 ワークフローの名前と説明を入力します。 Application name : 検出フェーズの移行前のアクティビティステップで作成されたアプリケーション名を選択します。 要件に応じて移行タイプを選択します。 ソース SAP アプリケーション情報を提供: AWS ADS Server ID for SAP application server: ソース SAP アプリケーションサーバーを選択します。 SAP system ID: ソース SAP SID を指定します。 SAP application hostname: ソース SAP アプリケーションのホスト名を指定します。 SAP HANA データベース構成を指定します。 HSR 用 SSL を無効にする場合は「I want to disable SSL encryption for database replication」チェックボックスを選択し、HSR 用 SSL を有効にする場合はオフのままにします。 SAP HANA replication mode: 要件に応じて [非同期] または [同期] を選択します。 HANA system ID (HANASID): ソース HANA SID Instance Number: ソース HANA インスタンス番号 Database hostname: ソース HANA データベースのホスト名 AWS ADS Server ID for SAP HANA database: ソース SAP HANA サーバーのホスト名 Credentials: 前提条件の一部として作成されたシークレット名を選択します。 Backup location: HANA データベースのバックアップ場所 (例:/backup) データベースレプリケーションで SSL 暗号化を選択する場合は、下部にある [Next] ボタンをクリックする前に、ターゲット HANA システムの global.ini ファイルの system_replication セクションにある enable_ssl パラメーターが ON に設定されていることを確認してください。データベースレプリケーションの SSL をオプトアウトする場合は、「“I want to disable SSL encryption for database replication」チェックボックスを選択するだけで、この設定ではパラメーターを調整する必要はありません。 [Next] をクリックして確認し、ワークフローを使用して移行を開始します。 ワークフローの入力内容を確認し、[Create] を選択します。 新しく作成したワークフローを選択し、[Actions]-&gt; [Run] オプションに移動して移行プロセスを開始します。 Migration Hub Orchestrator は、ほとんどのワークフローステップを自動化して移行プロセスを自動化します。追加の入力やユーザー操作が必要なため、一部のステップは手動です。ワークフローを完了するには、ワークフローのすべてのステップを実行する必要があります。 完了したワークフローの例は、下図のようなステータスになります。 よくある問題のトラブルシューティングと FAQ: 手順「Verify HANA System Replication status task status」が失敗しました ソース SAP および HANA システムにログインし、ターゲット SAP および HANA システムに ping を送信します。 ソースとターゲットの両方の SAP システムにプラグインサーバーからアクセスできることを確認します。 AWS セキュリティグループを検証し、プラグインサーバーから SAP ソースシステムとターゲットシステムの両方へのポート 22 の通信を許可します。 &lt;hdbadm&gt;としてログインして systemReplicationStatus.py を実行します。レプリケーションが行われておらず、ステータスが「initialization」の場合は、ターゲットシステムの HANA DB が稼働しているかどうかを確認してください。レプリケーションを開始するには、ターゲット HANA DB が稼働している必要があります。 &lt;hdbadm&gt;としてログインし、ステータスが「registration status of secondary host not available」の場合は HDBSettings.sh systemReplicationStatus.py を実行し、ソースシステムとターゲットシステムで /etc/hosts エントリが更新されていることを確認します。 プラグインはターゲット HANA システムにログインできません。 ターゲットシステムのシークレットマネージャーで指定したキーペア名が、ステップ 2.d で指定した名前と同期していることを確認します。 ターゲット SAP/HANA システムのセキュリティグループを検証し、プラグインサーバーからポート 22 を許可してください 失敗したステップを再試行するには? 失敗したステップのステータスをクリックし、再試行オプションを選択します。 ソースシステムに関連する失敗したステップのログはどこにありますか? 失敗したステップログは Amazon S3 バケットにあり、バケットのパスは以下のようにステータスメッセージの下に表示されます。 ターゲットシステムに関連する失敗したステップのログはどこにありますか? ターゲットシステムに関連する失敗したステップのログは、以下のように AWS Systems Manager の「Run Command」-&gt;「Command History」に記録されます。 結論: このブログでは、Migration Hub Orchestrator を使用して SAP HANA ベースのアプリケーションの AWS への移行を簡素化および自動化する方法を学びました。 AWS Migration Hub Orchestrator の詳細については、 AWS Migration Hub ページにアクセスするか、この ショート動画 をご覧ください。 このブログは、Pravin Yadav とChandrasekhar Chittuluru が共同執筆し、Partner SA 松本が翻訳しました。原文は こちら です。

この記事は AWS for Games updates from re:Invent 2023 を翻訳したものです。 AWS re:Invent 2023において、AWS for Games チームはお客様が AWS のゲーム開発ツールを使用している最新の方法を紹介し、現在 AWS Games Solutions Library で利用可能ないくつかの新しい専門的なガイダンスとパートナーソリューションを紹介しました。 AWS re:Invent 2023 における AWS for Games のお客様セッション動画には以下のものが含まれます。 Customer Keynote – Riot Games : Riot Games のグローバルインフラストラクチャおよび運用責任者である Brent Rich 氏は、スケジュールや優先順位の変更に直面しながらも、Riot と AWS の関係性がプレイヤーエクスペリエンスをどのように向上させたかについて語りました。 Exiting the data center: A League of Legends and VALORANT story : Riot Games が二つの大規模なゲームを中断することなくオンプレミスからクラウドに移行した方法について詳しく紹介されています。 Scaling Warhammer 40,000: Darktide from 0 to 100,000 players in 1 hour : Fatshark がサーバーレスなバックエンドアーキテクチャ、 Amazon GameLift 、 AWS Global Accelerator を使用して、数百万人のプレイヤー向けにゲームをどのようにスケーリングさせたかを知ることができます。 Modernization of Nintendo eShop: microservice and platform engineering : 任天堂がどのようにモノリシックアーキテクチャからマイクロサービスアーキテクチャに移行し、Nintendo Switch やその他の任天堂プラットフォームにある Nintendo eShop を強化したかを知ることができます。 Scaling a multiplayer game into the millions with Mortal Kombat 1 : Warner Bros. Games は、世界中の何百万人ものプレイヤーに向けてバージョンアップした「Mortal Kombat 1」を展開するために必要となったバックエンドのアーキテクチャについて詳しく紹介されています。 Improve your mobile and web app quality using AWS Device Farm : Riot Games は、 AWS Device Farm を使用してモバイルアプリのテストプロセスを合理化し、モバイルゲームと SDK の品質を向上させ、クラウド上の実際のデバイスで自動テストと手動テストを実行し、問題をより迅速に特定して修正し、アップデートをより高い頻度でリリースする方法を詳しく説明しています。 Improving user experience at Epic Games using Amazon Timestream : Epic Games は、 Amazon Timestream のアプリケーションをカバーし、Epic Games Store 全体で何百万人ものゲームプレイヤーのプレイ時間を監視し、そこからインサイトを引き出すためのスケーラブルなソリューションを構築した事例を紹介しています。 How Electronic Arts modernized its data platform with Amazon EMR : Electronic Arts が Amazon EMR に移行することで、HDFS から Amazon S3 へ、500 以上の ETL ジョブを Amazon EMR 上の Apache Spark へと、データプラットフォームをモダナイズした方法を紹介しています。 新しいガイダンスやパートナーソリューションを含む、 AWS Games Solution Library の最新のアップデートには以下が含まれます: Guidance for Game Analytics Pipeline on AWS (GAP V2) : ゲームクライアントやバックエンドサービスからテレメトリイベントを取り込むためのコード化、モジュール化されたサーバーレスの分析パイプラインを実装できます。 Guidance for Non-Player Character (NPC) Dialogue on AWS : ゲームおよび関連するゲーム開発インフラストラクチャ用のノンプレイヤーキャラクター(NPC)を作成するプロセスを自動化します。 Guidance for Identification of Problematic Betting &amp; Gaming on AWS : ゲームプレイヤーを問題のある賭博行為やゲーム内行動から保護するために、自動化された責任あるゲーム向けのメカニズムを作成する方法をデモンストレーションしています。 Guidance for a Game Production Environment on AWS : 可用性が高く低レイテンシーでユーザーに配信される、Unreal Engine 用の全体的なゲーム制作環境の構築を支援します。 AWS re:Invent 2023 の他のセッション動画をご覧になる場合は、 AWS Events content にアクセスしてください。最新の AWS for Games のお客様およびソリューションに関する最新情報については AWS for Games のブログ および LinkedIn をご覧ください。 翻訳はソリューションアーキテクトの渡邉が担当しました。

本ブログは、「 金融機関向け AWS FISC 安全対策基準対応リファレンス 」における「 金融機関等コンピュータシステムの安全対策基準・解説書（第11版） 」（以下、「FISC 安全対策基準・解説書（第11版）」）への対応についてまとめています。また、「 金融リファレンスアーキテクチャ日本版 」における「FISC 安全対策基準・解説書（第11版）」対応の概要についても記載しています。最後に、パートナー様における「金融リファレンスアーキテクチャ日本版」の活用事例をご紹介いたします。 1. FISC 安全対策基準・解説書に関しての AWS およびパートナー様の今までの取り組みの紹介 「FISC 安全対策基準・解説書」は、1985年に初版が発行されて以来、金融機関のシステムアーキテクチャおよび運用に関する指針として多くの金融機関によって活用されています。より安全に AWS をご活用いただくために、AWS は「金融機関向け AWS FISC 安全対策基準対応リファレンス 」を提供しています。これは「FISC 安全対策基準・解説書」が求める各管理策に対する AWS の取り組みとお客様の責任範囲で実施する事項をまとめており、お客様はどなたでも入手することが可能です。 一方、FISC 準拠支援のための AWS パートナーコンソーシアムはセキュリティ領域の知見を持ち寄り、金融業界における安全な AWS 活用を支援するために「 AWS FISC 安全対策基準対応リファレンス 参考文書 」を提供しております。 さらに、「金融リファレンスアーキテクチャ日本版」は、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワークとして、AWS が 2022年10月に正式版として発表 し、多くのお客様にご利用いただいております。その後、皆様からいただいたご意見を踏まえ、 2023年7月に複数のアップデート を行いました。 AWS では、 Design for failure 等のサービス設計や運用のベストプラクティスを踏まえた AWS Well-Architected フレームワークの提供や、日本における災害対策を踏まえた「 Resiliency in Japan-日本におけるAWSリージョンのレジリエンス- 」ホワイトペーパーの提供等ににより、お客様のコンテンジェンシープランの策定を支援しています。 AWS が公開している FISC 関連の文書の位置付けを以下の表にまとめています。 2. FISC 安全対策基準対応リファレンスと FISC 安全対策基準・解説書（第11版）対応について FISC は、2021年5月に、金融機関の様々なお客様のクラウドの安全な利活用を促進するために、「 金融機関等におけるクラウド導入・運用に関する解説書（試行版） 」を公表しました。その後、2023年5月に、「金融機関等におけるクラウド導入・運用に関する解説書（試行版）」の内容を正式に取り込んだ「FISC 安全対策基準・解説書（第11版）」を公表しました。第10版からの主要な変更点として、「クラウドサービス固有で対応すべき事項や特に留意すべき事項」に関する内容が追加されています。金融機関は、クラウドサービスの機能やクラウドサービスプロパイダーの運用などの情報を取得、確認した上で、クラウドサービスの機能やサードパーティのツールなどを利用して、金融機関が実施すべき手続きや対応を検討する必要があります。 AWS が提供している「金融機関向け AWS FISC 安全対策基準対応リファレンス 」は、「FISC 安全対策基準・解説書」の各項目のうち、AWS のサービスや情報に関連する事項に対して、AWS の対応状況と関連資料参照先の情報提供を行うための資料です。AWS を利用する金融機関のお客様は、当リファレンスを参照して、AWS が「FISC 安全対策基準・解説書」に対応できているかどうかを確認することができます。※1 今回、当リファレンスをアップデートし、「FISC 安全対策基準・解説書（第11版）」に対応する内容の追加を行いました。第11版で追加された「クラウドサービス固有で対応すべき事項や特に留意すべき事項」に対応する際に参考となる、関連する AWS の機能や運用に関する情報、および&nbsp; AWS Well-Architected フレームワークなどのベストプラクティスに関する情報を追加しました。第10版から追加された部分は、当 リファレンス の変更履歴からご確認いただけます。金融機関のお客様は、アップデートされたリファレンスを参照することで、AWS の最新の対応状況をより効率的に確認し、クラウド移行や運用におけるセキュリティ対策の検討に活用することができます。 ※1：「FISC 安全対策基準・解説書」には AWS のサービスが該当しない項目があること、かつ情報システムに対する安全対策の達成目標は、個々の情報システムのリスク特性に応じて、お客様のご判断で適切な内容で決定されるべきであることから、当リファレンスは AWS を利用するお客様が「FISC 安全対策基準・解説書」に準拠できることを保証するものではございません。 3. 金融リファレンスアーキテクチャ日本版と FISC 安全対策基準・解説書（第11版）対応について 「金融リファレンスアーキテクチャ日本版」においても、「FISC 安全対策基準・解説書（第11版）」に対応する内容のアップデートを実施しました。変更点は以下のとおりです。 3.1 AWS Well-Architected フレームワーク FSI Lens for FISC における ベストプラクティス の追加 「AWS Well-Architected フレームワーク FSI Lens for FISC」は、「FISC 安全対策基準・解説書」に沿って、回復力、セキュリティ、および運用パフォーマンスを促進する金融サービス業界 (FSI) のワークロードを設計、デプロイ、設計する方法に焦点を当てたベストプラクティス集です。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、複数のベストプラクティスを追加しました。 AWS Well-Architected フレームワーク FSI Lens for FISC の位置付け 3.2 AWS Well-Architected フレームワーク FSI Lens for FISC における FISC 安全対策基準 実務基準 リファレンス項目一覧表 の最新化 「AWS Well-Architected フレームワーク FSI Lens for FISC」では、「FISC 安全対策基準・解説書」の各実務基準において、参照すべき AWS Well-Architected フレームワーク、AWS Well-Architected フレームワーク FSI Lens for FISC の一覧表を提供しています。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、一覧表の最新化を行いました。 3.3 FISC 安全対策基準 実務基準と AWS Control Tower コントロールの 対応表 の最新化 「FISC 安全対策基準・解説書」の観点から、有効化すべき AWS Control Tower のコントロールを抽出し、対応表を提供しています。今回、2023年10月13日時点の最新のコントロール（459個）に対して、「FISC 安全対策基準・解説書（第11版）」の内容を反映して最新化を行いました。 3.4 BLEA for FSI ガバナンスベース及び各金融ワークロード（ 勘定系 、 顧客チャネル 、 マーケットデータ 、 オープン API 、 データ分析プラットフォーム ）における FISC 安全対策基準 実務基準に対する対策内容一覧の最新化 「FISC 安全対策基準・解説書」の各実務基準に対して、BLEA for FSI ガバナンスベース、および各金融ワークロードにおける対策内容の一覧を提供しています。今回、「FISC 安全対策基準・解説書（第11版）」で追加された内容に対応して、一覧の最新化を行いました。 4. パートナー様での金融リファレンスアーキテクチャ日本版活用について パートナー様での金融リファレンスアーキテクチャ日本版活用について、シンプレクス株式会社様及びキンドリルジャパン株式会社様の事例を紹介いたします。 4.1 シンプレクス株式会社様 シンプレクス株式会社様（以下、Simplex様）では、AWS 上で提供する金融サービスのセキュリティベースラインとして、コストを抑える工夫を取り入れながら金融リファレンスアーキテクチャ日本版の BLEA for FSI を活用されています。さらに、「FISC 安全対策基準・解説書」実務基準の準拠状況を可視化するため AWS Well-Architected フレームワーク FSI Lens for FISC も活用されています。下記活用状況の詳細を記載します。 Simplex様では様々な金融サービスの構築・運用サービスを提供しています。AWS 環境で Simplex様が運用管理する原則全てのアカウントに適用されるセキュリティベースラインとして、Simplex様固有の要件を踏まえた実装に加え、金融リファレンスアーキテクチャ日本版の BLEA for FSI ガバナンスベースのエッセンスを取り入れています。以下ではSimplex様固有の要件とカスタマイズ内容を紹介いたします。 金融リファレンスアーキテクチャ日本版を適用する場合、基本的には AWS Control Tower にアカウントを登録する必要があります。Simplex様では開発当初はAWS環境の作り直しを頻繁に行うため、AWS Control Tower によるセキュリティ評価がその度に実行されコストが増大する課題がありました。この課題を解決すべく、開発フェーズに応じて AWS アカウントに二段階でセキュリティベースラインを適用する方式を採用しています。具体的にはまず AWS アカウント発行時には AWS Control Tower への登録はすぐには実施せず、Amazon GuardDuty 等のセキュリティサービスにて必要最低限のセキュリティ統制を効かせて開発を実施します。次に、開発が進み環境の作り直しが落ちついたタイミングで AWS Control Tower にアカウントを登録し、金融リファレンスアーキテクチャ日本版の BLEA for FSI ガバナンスベースを効かせることで、コストを抑えることを実現しています。 金融機関のお客様に提供するシステムは、FISC 安全対策基準の実務基準に準拠することが求められるケースがあります。Simplex様では AWS Well-Architected フレームワーク FSI Lens for FISC を AWS アカウントに追加適用することで、FISC 実務基準の準拠状況を定量的に可視化しています。 4.2 キンドリルジャパン株式会社様 キンドリルジャパン株式会社様（以下、キンドリル様）はお客様のビジネスアジリティを加速するためのプラットフォームを開発中です。本プラットフォームはキンドリル様で開発した標準テンプレートをポータル上で選択することで、AWS の各種クラウドサービスを活用したアプリ開発環境や必要なインフラストラクチャーの自動構築が可能となります。また、ポータルへの情報やリンクの集約を行うことにより、開発者や運用者の状況理解の負荷を軽減し、お客様の開発速度およびビジネスアジリティを加速します。 金融業界向けの標準テンプレートの開発にあたっては、金融業界の要求する品質やセキュリティー等への対応が求められます。キンドリル様ではこれまで金融業界向けの経験や実績をもとにしたコンテナー基盤を多くのお客様に提供してきましたが、FISC 準拠や災害対策など近年高まりつつあるお客様の懸念事項に対し、より一層の対応が求められます。 本プラットフォームの開発にあたっては、キンドリル様がこれまで培ってきた経験や実績に加えて、AWS 金融リファレンスアーキテクチャ日本版を活用することで高品質かつ迅速な市場への提供を実現します。具体的には、金融リファレンスアーキテクチャ日本版に含まれるオープン API と勘定系の２つのワークロードをテンプレート化の対象とし、AWS Well-Architected フレームワーク FSI Lens for FISC や金融グレードの統制への対策を組み込むことで、金融業界で求められる機密性と可用性に関するベストプラクティスを利用した高い安全性を確保します。また、他の業種向けの標準テンプレートの開発においても、金融リファレンスアーキテクチャ日本版の持つアーキテクチャおよび CDK テンプレートをベースとすることで、開発が加速され、本プラットフォームの持つケーパビリティーの拡大に寄与しています。 謝辞 アマゾン ウェブ サービス ジャパン合同会社の下記メンバーで FISC 安全対策基準・解説書（第11版）対応を行いました。 FISC 安全対策基準対応リファレンス：高野、松本(照)、保坂、能仁、富永、立花、阿部、渡邉、神部 金融リファレンスアーキテクチャ日本版：木村、保坂、北嵐、畑、遠藤、疋田、都築、辻本、松本(耕)、佐藤、神部

Amazon Timestream は、高速でスケーラブルなフルマネージドの時系列専用データベースであり、1 日に何兆もの時系列データを簡単に保存および分析できます。Timestream は、直近のデータをメモリに保持しつつ、定義したポリシーに基づいてコストが最適化されたストレージ層に履歴データを移動することで、時系列データのライフサイクル管理にかかる時間とコストを節約します。 本投稿では、 バッチロード 機能を使用して、 Amazon Relational Database Service (Amazon RDS) for PostgreSQL から Timestream に時系列データを移行する方法を説明します。尚、時系列データが Amazon Aurora PostgreSQL 互換エディション に存在する場合にも、同じソリューションが機能します。 Timestream の概念 始める前に Timestream の主要な概念をいくつか確認してみましょう。 時系列 – 一定の時間間隔にわたって記録された 1 つ以上のデータポイント (またはレコード) のシーケンス。 レコード – 時系列内の単一のデータ ポイント。 ディメンション – 時系列のメタデータを説明する属性。ディメンションはディメンション名とディメンション値で構成されます。 メジャー – レコードによって測定されている実際の値。例として、株価、CPU またはメモリの使用率、温度または湿度の測定値などが挙げられます。メジャーはメジャー名とメジャー値で構成されます。 Timestream のバッチロード機能を使用すると、Amazon Simple Storage Service (Amazon S3) に保存されている CSV ファイルからデータを取り込むことが可能となり、他のツールを使ったり、カスタムコードを記述する必要はありません。 ソリューションの概要 本ソリューションでは、 マルチメジャー レコードを使用してデータをモデル化し、RDS for PostgreSQL データベースからサンプルデータセットを Timestream にロードします。マルチメジャーレコードを使用すると以下の利点があります。 時系列データをよりコンパクトな形式で保存できるため、ストレージのコスト削減につながります。 コンパクトなストレージは、より単純なクエリ作成に役立ち、クエリパフォーマンスの向上が期待できます。 多くの場合でデータベーススキーマ変更がほぼ必要無くなる為、リレーショナルデータベースから Timestream へのデータ移行を簡素化する事ができます。 本アーキテクチャでは、まずAmazon RDS for PostgreSQL の aws_s3 エクスポート拡張機能 を使用して、時系列データを S3 バケットに CSV ファイルとしてエクスポートし、同時にエポック形式へのタイムスタンプ変換も実行します (これはバッチロードの 前提条件 です)。データが S3 バケットに保存された後、バッチロード機能を利用して、Timestream データベースへの時系列データの 1 回限りの移行を実行します。 以下の図は、本アーキテクチャを示しています。 前提条件 このソリューションを実装するには、次のリソースを作成します。 時系列データを保存する RDS for PostgreSQL インスタンス。セットアップ手順については、 こちら を参照してください。 Amazon S3 からダウンロードされた サンプルデータセット 。ダウンロードしたファイルを確認し、 \ copy コマンドを使用して RDS for PostgreSQL データベースにインポートします。 Amazon RDS for PostgreSQL からのデータを格納する S3 バケット。手順については、 Create your first S3 bucket および Setting up access to an Amazon S3 bucket を参照してください。 AWS Identity and Access Management (IAM) のポリシーとロール。 時系列データを保存し、バッチロードのターゲットとなる Timestream テーブル。手順については、 こちら を参照してください。クエリ実行を最適化するには、顧客定義のパーティション化キーを使用して、ディメンションの hostname に基づいて Timestream テーブルをパーティション化します。次のスクリーンショットは、Timestream コンソールでのこの構成を示しています。パーティション化キーについては、本投稿の後半で詳しく説明します。 さらに、バッチロードの 前提条件 、 クォータ 、 ベストプラクティス を確認することをお勧めします。 データセット Timestream のテーブルは、 measure_name と呼ばれる特別な属性 (または列) をサポートしています。Timestream は、 measure_name の値を使用してデータを分割し、インデックスを作成します。今回は、次のスクリーンショットに示すように、 region の分類を含んだ形で measure_name 属性をデータセットに追加しました。 サンプルデータセットは、AWS の複数のリージョンとアベイラビリティゾーンで実行されているコンピューティングインスタンス群からの CPU とメモリのメトリクスで構成されています。 Amazon S3 への PostgreSQL エクスポート用の Amazon RDS を準備する エクスポートを準備するには、次の手順を実行します。 Amazon RDS for PostgreSQL エンジンのバージョンが Amazon S3 にエクスポートする機能をサポートしていることを 確認 します。 Amazon RDS for PostgreSQL に aws_s3 拡張機能をインストール します。 Amazon RDS for PostgreSQL の アクセス許可 を S3 バケットに付与します。 Amazon RDS for PostgreSQL から時系列データをエクスポートする このステップでは、 aws_s3.query_export_to_s3 関数を使用して、時系列データを Amazon RDS for PostgreSQL から S3 バケットにヘッダー付きの CSV 形式でエクスポートします。 SELECT * FROM aws_s3.query_export_to_s3( 'SELECT cast(EXTRACT(epoch from time) * 1000000 as BIGINT) as time, measure_name, region, location, hostname, mem_usage, cpu_usage from perf_metrics', aws_commons.create_s3_uri('test-aws-dms-target-bucket/batchload', 'perf_metrics.csv', 'us-west-2'), options :='format csv, HEADER true'); Timestream バッチロードの前提条件 を満たすために、 EXTRACT 関数を使用してタイムスタンプ列をエポック (マイクロ秒) 形式に変換することに注意してください。 パフォーマンス指標データのモデリング バッチロードを使用して Timestream テーブルにロードするデータセットの属性と、それがパフォーマンスにどのように影響を与えるのか見てみましょう。 time – パフォーマンスメトリクスが収集された正確な時間 measure_name – パフォーマンス メトリックを分類するための集約属性 region – ホストが存在するリージョン location – ホストが配置されているアベイラビリティーゾーン hostname – メトリクスが収集されるホスト名 mem_usage – ホストのメモリ使用率 cpu_usage – ホストの CPU 使用率 適切なディメンジョンとメジャーを選択する 従来のリレーショナルデータベースから Timestream に移行する場合、テーブルと列を既存のデータベースから Timestream にそのままダンプすればうまくいくと考えるかもしれません。ですが、本当の課題は、クエリパターンを理解し、適切なディメンション、メジャー、およびオプションでパーティションキーを選択することにあります。 レコードのタイムスタンプを含むディメンションは、レコードを誰が、何を、いつ、どこで記録したかを特定するのに役立ちます。また、ディメンションは、データを整理および分類し、クエリの一部としてデータをフィルタリングするために使用されます。したがって、本投稿で使用するテーブルの region 、 location 、および hostname は、サーバーパフォーマンスのメトリックデータを整理および分類するための理想的な選択肢です。 メジャーは定量的なデータ (時間の経過とともに変化する値) であり、データの数学的計算 (合計、平均、変化率の差などの計算) と定量的分析を実行するための値を提供します。したがって、本投稿で使用する列 (測定値) mem_usage と cpu_usage は、ホストのパフォーマンスに関連する重要なメトリックを取得します。 ディメンションの数、メジャー (レコードごとの最大メジャー、テーブル全体の一意のメジャー)、およびレコードの最大サイズには 制限 がある為、データモデルを設計する際には、これらの要素を考慮する必要があります。多くの場合、Timestream に取り込まれるデータは、時系列分析に必要な属性以外の追加の属性を含むイベントまたはメトリクスを通じて発生します。制限に達しないようにするには、必要な属性のみをターゲットにします。データに関連性がなく、一緒にクエリを実行しない場合は、1 つの統合テーブルよりも個別のテーブルを使用する方が適しています。 データモデリングのベストプラクティスの詳細については、 こちらのブログ を参照してください。 顧客定義のパーティションキーの選択 顧客定義のパーティションキー は、クエリを高速化し、特定の時系列データ関連のニーズに基づいてより効率的に洞察を得るために必要な柔軟性を提供する新機能です。パーティショニングは、複数の物理ストレージユニットにデータを分散するために使用される技術で、より高速かつ効率的なデータの取得を可能にします。顧客定義のパーティションキーを使用すると、クエリパターンやユースケースに合わせたパーティションスキーマを作成できます。 Timestream でパーティション化する場合、パーティションキーを自身で選択するか、 measure_name 列に基づくデフォルトのパーティションを使用するかを選択できます。 カーディナリティの高い列を持ち、クエリの述語として頻繁に使用されるディメンションに基づいてパーティション キーを選択することを推奨します。これにより、パーティション間でデータが均等に分散され、パフォーマンスの問題が回避されます。 このパフォーマンスメトリクスの使用例では、 measure_name (デフォルト) や hostname などのカーディナリティの高い列がパーティションキーとして適している可能性がありますが、どの列がクエリ作成時のフィルタリングに頻繁に使用され、カーディナリティの高い列であるかによって選択する必要があります。この使用例では、クエリアクセスパターンは述語として hostname を頻繁に使用しており、カーディナリティの高い列でもある為、 hostname を顧客定義のパーティションキーとして構成しました。 デフォルトのパーティション分割ではなく、顧客定義のパーティションキーを使用することを強くお勧めします。 顧客定義のパーティションキーを使用したクエリパフォーマンスの最適化の詳細については、 こちらのブログ を参照してください。 Timestream のバッチロードを実行する バッチロードタスクを作成 するには、次の手順を実行します。 Timestream コンソールのナビゲーションペインで、 管理ツール 、 バッチロードタスク の順に選択します。 バッチロードを作成 を選択します。 ターゲットデータベース では、前提条件として作成したデータベースを選択します。 ターゲットテーブル で、前提条件として作成したテーブルを選択します。必要に応じて、 新しいテーブルを作成 を選択して、このペインからテーブルを追加できます。 データソースの S3 の場所 で、ソースデータが保存されている S3 バケットを選択します。 S3 を参照 ボタンを使用して、アクティブな AWS アカウントがアクセスできる S3 リソースを表示するか、S3 の場所の URL を入力します。データ ソースは同じリージョンに存在する必要があります。 ファイル形式の設定 では、デフォルト設定を使用して入力データを解析できます。 高度な設定 を選択し、CSV 形式のパラメーターを選択し、入力データを解析するパラメーターを選択することもできます。これらのパラメータの詳細については、 こちら を参照してください。 次に、Visual Builder を使用して データモデルマッピング を構成します。 エラーログリポート の エラーログの S3 の場所 で、エラーの報告に使用される S3 の場所を選択します。このレポートの使用方法については、 こちら を参照してください。 暗号化キータイプ で、次のいずれかを選択します。 Amazon S3 マネージドキー (SSE-S3) &nbsp;– Amazon S3 が作成、管理、および使用する暗号化キー AWS KMS キー (SSE-KMS) – AWS Key Management Service (AWS KMS) によって保護された暗号化キー 次へ を選択します レビューして作成 ページで設定を確認し、必要に応じて編集します。 バッチロードタスクを作成 を選択します。 バッチロードの ステータス を確認します。 問題が発生した場合は、一般的なエラーの トラブルシューティング を参照してください。 バッチ ロードタスクが正常に完了したら、Timestream クエリエディターに移動して結果をクエリできます。 データは次のスクリーンショットのように表示されるはずです。&nbsp; クリーンアップ 継続的な料金が発生しないように次のリソースを削除しましょう。 RDS for PostgreSQL インスタンス S3 バケット Timestream テーブル IAM ポリシー と ロール 結論 本投稿では、バッチロード機能を使用して時系列データをリレーショナルデータベースから Timestream に移行する方法を説明しました。ビジネスニーズに合わせて Amazon QuickSight または Grafana ダッシュボードを使用してデータを視覚化する方法についても利用して頂く事をお勧めします。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

みなさん、こんにちは、カスタマーソリューションマネージャー (CSM) の西口です。このブログ記事では、AWS の コスト最適化 および可視化を支援するダッシュボードである Cost and Usage Dashboard (CUD) と Cloud Intelligence Dashboards のひとつである CUDOS Dashboard (CUDOS) をご紹介します。 これらビジュアル化されたダッシュボードは、AWS コンソールにアクセスできない、より広い範囲のステークホルダーに対して、コストに関するインサイトやインタラクティブな分析結果を共有することを容易にします。コストの「見える化」、そしてその分析した情報の共有について、課題をお持ちのお客様におすすめします。 また、AWS では、定常的に無駄なコストを減らし適切なコスト状態とするための「最適化」活動を実践するフレームワークとして Cloud Financial Management (CFM) を提唱しています。これらのダッシュボードを利用することで、CFM フレームワークの 4 つの柱のうち特に「可視化」の実現に寄与することが可能となっています。CFM フレームワークについては こちら をご参照ください。 このブログの流れとして、CUD と CUDOS の各特徴を説明した後にそれぞれのユースケースを説明します。その特徴やユースケースを通じて、ダッシュボードが AWS コストの最適化および可視化にどう役立つか詳しく見ていきましょう。 CUD と CUDOS の特徴 CUD は、Amazon QuickSight によって提供され、オープンソースプロジェクトの Cloud Intelligence Dashboards (CID) から着想を得たダッシュボードです。CUD は CID のダッシュボードの 1 つである CUDOS の主要なシートやビジュアル (グラフやチャート) を抽出しており、AWS コンソール画面からセットアップすることが可能です。具体的には AWS コンソールの AWS Billing and Cost Management の Data Exports ページから CUD を数分でデプロイすることができます。後述の CUDOS に比べると、セットアップが簡単であり、また Amazon Athena や AWS Glue クローラのようなベースとなる AWS サービスが不要という特徴があります。そのため運用上の理由などで Amazon Athena の利用を制限している環境やお客様でも CUD を利用することが可能です。CUD のセットアップ方法については こちら を参照ください。 一方、CUDOS も Amazon QuickSight によって提供されるダッシュボードですが、セットアップに Amazon Athena と AWS Glue クローラを使用する AWS CloudFormation (CFn) テンプレートベースのデプロイメントが必要です。CUDOS では CFn のデプロイメントが必要であるため、CUD に比べるとセットアップは簡単ではありませんが、AWS のリソースレベルの情報表示、 リザーブドインスタンス (RI) や Savings Plans (SPs) に関するインサイト、CUDOS 以外の他の CID のダッシュボードを利用することでコスト以外のデータソースをサポートするなど CUD にはない特徴もあります。CID のセットアップ方法については Well-Architected Labs を参照ください。 表 1) CUD と CUDOS の特徴と代表的な違い 特徴 Cost and Usage Dashboard (CUD) CUDOS Dashboard デプロイメントの方法 AWS コンソールからのデプロイ CloudFormation, Command Line, Terraform AWS Organizations 管理単位全体のコスト使用状況確認 管理アカウントのみ 管理アカウント、または専用の個別アカウント (注) 複数の AWS Organizations を統合可能 – ○ 必要な AWS サービスの違い Amazon Athena や AWS Glue クローラが 不要 (Amazon S3, Amazon QuickSight は必要) Amazon Athena や AWS Glue クローラが 必要 (Amazon S3, Amazon QuickSight は必要) コスト使用状況に対する情報表示 ○ ○ リソースレベルの詳細表示 – ○ リザーブドインスタンス (RI) や Savings Plans (SPs) に関する情報表示 – ○ 注：専用の個別アカウントとは、CUDOS 構築時に作成したダッシュボード参照用アカウントのこと。詳細は こちら を参照ください。(リンク先では、Destination / Data Collection Account と表記) CUD と CID の違いについての詳細情報を確認したい場合は こちら を参照ください。但し、CUD と CUDOS ではなく、CUD と CID との違いに言及したドキュメントである点にはご注意ください。 CUD と CUDOS のユースケースと差異 CUD と CUDOS の使い分けをより深く理解してもらうために、Amazon QuickSight のシート (タブ) ごとのユースケース例を用いて違いをご紹介します。Amazon QuickSight の基本的な用語や機能については こちら を参照ください。CUD でも様々なユースケースをカバーしています。前章でご紹介した通り CUD はリソースレベルの詳細表示が省略されているため、 ARN やリソース ID レベルでコスト状況を分析したい場合には、CUDOS を利用ください。CUDOS のみで確認できる具体的なグラフは図 1 から図 11 をご参照ください。 表 2) CUD と CUDOS のユースケースと差異 シート名 内容 利用ユースケース例 CUD CUDOS CUDOS と CUDの特徴的な差異 Introduction ダッシュボード全体像やそれぞれのシートの内容に関する情報を紹介 ダッシュボードの概要を確認する。 ○ – CUD のみ存在 Executive: Billing Summary 保持するアカウント全体の支払い状況と変動の傾向 毎月の請求金額と償却コストの実績を比較しながら、リザーブドインスタンスや Savings Plans やクレジットなどの割引の効果をアカウント単位やサービス単位で確認。割引が十分に活用されているかの分析を通して支払い全体像の把握を行う。 ○ ○ CUD ではリザーブドインスタンスや Savings Plans、クレジットなどによる支払い額の削減に関する情報が含まれない Executive: RI/SP Summary リザーブドインスタンスや Savings Plans の使用状況 リザーブドインスタンスや Savings Plans の購入金額や使用率に加えて、これらの割引による実際の削減額を確認。加えて、オンデマンドやスポットインスタンスなど購入オプションごとの比率を分析を行う。インスタンス調達オプションの変更や追加の必要性を把握する。 – ○ CUDOS のみ存在 Executive: MoM Trends アカウントやサービス単位の月次の変動傾向 アカウントやサービスの単位で３ヶ月間のコスト変動のトレンドや償却コストの状況を確認。使用コストが大きく変動しているアカウントやサービスに関して変動の妥当性の評価を行う。 ○ ○ – (差異なし) Compute Amazon Elastic Compute Cloud (Amazon EC2) や AWS Fargate、AWS Lambda の使用状況や変動の傾向 EC2、Fargate、Lambda について、購入オプションによる単価の現状や過去推移の分析を行うことにより、購入オプションの追加や変更の必要性を確認する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 1) Storage Amazon Elastic Block Store (Amazon EBS) や Amazon Elastic File System (Amazon EFS)、Amazon FSx などのストレージファイルシステム EBA、EFS、FSx について、月間ストレージコスト、保管データ容量、単価、データ操作ごとのコストを確認。想定外の大容量データの保存や、SnapShot の過剰な取得によるコスト異常を発見する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 2) Amazon S3 Amazon Simple Storage Service (Amazon S3) の使用状況と変動の傾向 アカウントやバケットごとの S3 利用料金や、Amazon Simple Storage Service Glacier (Amazon S3 Glacier) の使用状況を確認。S3 バケット使用状況の妥当性や、S3 のストレージクラスの変更の必要性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 3) Databases Amazon Relational Database Service (Amazon RDS) や Amazon DocumentDB (with MongoDB compatibility)、Amazon Redshift、Amazon ElastiCache、Amazon OpenSearch Service などデータベースに関する使用状況と変動の傾向 各サービスについて、アカウントやリージョン、プロダクトファミリー、データベースエンジンごとの償却コスト、リザーブドインスタンスの使用率、購入オプションの使用状況などを確認。データベースサービス利用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 4) Amazon DynamoDB Amazon DynamoDB の使用状況と変動の傾向 データ転送やバックアップなど操作ごとの発生コストをアカウントごとやテーブルごとに確認。DynamoDB の使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 5) Messaging and Streaming Amazon Kinesis と Amazon Managed Streaming for Apache Kafka (Amazon MSK) の使用状況と変動の傾向 Kinesis と MSK について、アカウントごとに詳細状況を確認。Kinesis のコストはリソース単位、 MSK のコストはクラスターごとに確認。それぞれのサービスの使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 (図 6) Data Transfer and Networking データ転送とネットワークの使用状況と変動の傾向 アカウントごとのデータ転送コストに加えて、データ転送量や、リージョン間通信、VPN Peeringなどのコスト内訳を確認。併せて AWS Direct Connect、Elastic Load Balancing (ELB)、 NAT Gateway、 VPN、 Amazon Virtual Private Cloud (Amazon VPC) Endpoint のそれぞれにおいて、日次のコスト詳細や Public IPv4 、 Amazon CloudFront の使用状況を確認。データ転送とネットワーク状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 7) AI/ML Amazon SageMaker や Amazon Comprehend、Amazon Textract、Amazon Rekognition、Bedrock の使用状況と変動の傾向 SageMaker や Amazon Bedrock、Amazon Textract、Amazon Rekognition のアカウントごとのコスト現状や過去推移を確認。使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 8) Monitoring &amp; Observability Amazon CloudWatch と AWS CloudTrail の 使用状況と変動の傾向 CloudWatch と CloudTrail、AWS Config のアカウントごとのコスト現状や過去推移を確認することで、モニタリングとオブザーバビリティ関連サービス使用状況の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 9) End User Computing (※ CUDOSでは上記名称。CUD では Amazon WorkSpaces) Amazon Workspaces の使用状況と変動の傾向 Amazon WorkSpaces のコスト現状や過去推移を確認することで、エンドユーザコンピューティング環境の妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 10) GameTech &amp; Media Amazon GameLift と AWS Elemental MediaConnect などの使用状況と変動の傾向 Amazon GameLift や MediaConnect などのコスト現状や過去推移を確認することで、ゲームやメディアに関するサービスの妥当性を評価する。 ○ ○ CUD ではリソースレベルの詳細グラフが省略 TAGsplorer タグの状況分析 タグ毎の使用量やトレンドについて詳細を確認することで、タグ単位の使用量推移や妥当性の評価を行う。 – ○ CUD ではシートそのものが省略 OPTICS Explorer その他すべての使用状況と変動の傾向 アカウント毎に使用している主要サービスや、日単位での利用金額の傾向など、他のレポートとは異なる視点での分析を行う。 ○ ○ CUD ではリソースレベルの詳細グラフが省略(図 11) Other Recommendations その他の有用なグラフ ここまでで使用されていない Anomaly Detection からの通知の確認などを行う。 – ○ CUD ではシートそのものが省略 図 1) Compute タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 50 のコストが発生している Lambda usage をリソース ID 単位で確認可能。 図 2) Storage タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している EBS ボリューム使用量をリソース ID 単位で確認可能。 図 3) Amazon S3 タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している S3 に対する操作をリソース ID 単位で確認可能。 図 4) Database タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の Top 20 のコストが発生している Database に関するUsage を Database ARN 単位で確認可能。 図 5) Amazon DynamoDB タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間のテーブル単位のコストを確認可能。 図 6) Messaging and Streaming タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の操作単位やリソース ID 単位のコストを確認可能。 図 7) Data Transfer &amp; Networking タブで省略されているリソースレベルの詳細グラフの例。CUDOS ではリソース ID 単位で過去 30 日間のコスト Top 10 や、日次のコスト状況を確認可能。 図 8) AI/ML タブで省略されているリソースレベルの詳細グラフの例。 CUDOS では過去 30 日間の Top 10 のコストが発生している Amazon Bedrock に関するUsage をリソース ID 単位で確認可能。 図 9) Monitoring &amp; Observability タブで省略されているリソースレベルの詳細グラフの例。CUDOS では過去 30 日間の CloudWatch のコストをリソース ID 単位で確認可能。 図 10) Amazon Workspaces タブで省略されている詳細グラフの例。CUDOS では End User Computing タブとして、過去 30 日間の Top 20 のコストが発生している Usage を Workspace id 単位で確認可能。 図 11) OPTICS Explorer タブで省略されている詳細グラフの例。 CUDOS では 過去 30 日間の Top 10 のコストが発生している Usage を リソース ID 単位で確認可能。 おわりに 本ブログでは、AWS コスト最適化と可視化を支援する ダッシュボードである CUD と CUDOS の特徴と差異、その利用ユースケース例をご紹介しました。皆さまの AWS のコスト最適化および可視化のヒントになりましたでしょうか。 初めて AWS コストに関するダッシュボードを利用する場合は簡単に構築できる CUD の利用をおすすめします。また、その一方で CUDOS のみで確認できるダッシュボードも存在しますので、必要なユースケースによっては CUDOS やそれ以外の CID の利用もご検討ください。 参考情報 New – Cost and Usage Dashboard powered by Amazon QuickSight Visualize and gain insights into your AWS cost and usage with Cloud Intelligence Dashboards and CUDOS using Amazon QuickSight AWS Data Exports AWS Billing and Cost Management 向けのデータエクスポートを発表

AWS は、新しいインターネット監視サービスである Amazon CloudWatch Internet Monitor のリリースを発表しました。インターネット上でのパフォーマンスと可用性は、AWS アプリケーションのユーザー体験の水準を高めるのに役立つ重要な指標です。ユーザー体験は、お客様が制御出来ない未知の事象に大きな影響を受ける可能性があります。お客様のアプリケーションでより良いユーザー体験を提供するには、インターネットの状況とユーザー体験を把握している必要があります。 Internet Monitor では、AWS でのワークロードの利用状況に合わせて、可用性やパフォーマンスなどのインターネット測定値を継続的に監視できます。Internet Monitor を使用すると、時間の経過に伴う平均的なインターネットの性能の指標や、場所やインターネットサービスプロバイダー (ISP) ごとの問題 (イベント) に関する洞察を得ることができます。また、Amazon CloudFront、Amazon WorkSpaces ディレクトリ、または Amazon Virtual Private Cloud (Amazon VPC) で直接ホストされているアプリケーションのエンドユーザーのユーザー体験に影響を与えているイベントを簡単に特定できます。アプリケーションエンドポイントに関連する測定値により、問題の範囲、場所、根本原因をすばやく特定できるため、修正に必要なアクションを実行できます。これらすべてを、アプリケーションコードを変更することなく、またワークロードのパフォーマンスに影響を与えることなく実行できます。 Internet Monitor は、ユーザーとアプリケーション間のインターネットを含んだ通信経路をモニタリングし、CloudWatch の各サービス表示できます。 ユーザー体験 – CloudWatch Synthetics と CloudWatch Real User Monitoring (RUM) インターネットの健全性 – Internet Monitor アプリケーションスタックの健全性 – CloudWatch ServiceLens と AWS X-Ray リソースの健全性 – CloudWatch Metrics と CloudWatch Logs (* このブログ執筆時では、CloudWatch ServiceLens は AWS X-Ray service map と統合され、 X-Ray trace map になりました。) Internet Monitor の構成要素 Internet Monitor の仕組みを説明する前に、構成要素について説明します。 モニター : モニターは、監視するリソースを定義したコンテナです。 ヘルスイベント : Internet Monitor はトラフィック性能の大幅な低下を検出すると、ヘルスイベントを作成します。各ヘルスイベントには、影響を受けるクライアントの地理情報とネットワークプロバイダー (ISP) の情報が含まれています。 パフォーマンスおよび可用性スコア ( ヘルススコア ) : アプリケーションへのトラフィックのうち、パフォーマンスの低下や可用性の低下が発生していない割合を統計的に推定したものです。これらのスコアは CloudWatch メトリクスとしても利用できます。 CloudWatch Logs : クライアント固有のロケーションとネットワークプロバイダー向けに、Internet Monitor は、パフォーマンスと可用性スコア、転送されたバイト数、および往復時間 (Round Trip Time , RTT) を含む測定値を CloudWatch Logs に送信します。 仕組み Internet Monitor は、さまざまな AWS リージョンとエッジロケーション、およびお客様がアプリケーションエンドポイントにアクセスするネットワーク間で、AWS が既に収集しているデータを活用します。この接続情報は、インターネット上の接続の問題を事前に検出し、顧客体験を向上させるための対策を講じるために、AWS 自身も使用しています。 すべての AWS リージョンで、インターネットのどの部分がそのリージョンとどのように接続されているかといったネットワークの構成情報を AWS は把握しています。これにより、AWS はネットワークプローブ *と上位プロトコルプローブの両方を、インバウンドとアウトバウンドの両方で使用しモニタリングを実施できます。これらのパフォーマンスと可用性の測定値をベースラインとして、さまざまな地域のエンドユーザーに重大な問題の発生を認識できるように、ヘルススコアを計算します。モニターを作成すると、Internet Monitor はユーザーのリソースに基づいてトラフィックプロファイルを作成し、ユーザーの場所と各ユーザーへのトラフィックの割合を記述します。次に、トラフィックプロファイルが AWS ベースラインパフォーマンスプロファイルと比較します。このプロファイルから、ベースラインからの推定減少を示すパフォーマンススコアと可用性スコアが計算されます。 ( プローブ (probe)* とは 英語で探査・検査を意味し、対象のシステムの性能等を検査する行為およびツールやソフトウェアをさします) Internet Monitor では、さまざまな AWS サービスの使用やトラフィックの再ルーティングに関するパフォーマンスメトリクスを表示することで、サーバー初期応答時間 (Time To First Byte, TTFB) を改善するための洞察や推奨事項も提供します。これは、Amazon CloudFront を使用したり、ワークロードトラフィックをさまざまな AWS リージョンに再ルーティングしたりすることで、ユーザーエクスペリエンスをどのように改善できるかを理解するのに役立ちます。 ヘルスイベントに関するアラート モニターを作成したら、次はアラートを設定します。Internet Monitor のヘルスイベントに関するアラートを受け取る方法はいくつかあります。何を選択するかは、フィルタリングの要件、履歴レコードタイプ、アラームがトリガーされたときのアクションなどによって異なる場合があります。 パフォーマンスと可用性スコアの Internet Monitor のイベントメトリクスに基づいた CloudWatch アラーム CloudWatch Logs のメトリクスフィルターを使用して生成されたメトリクスに基づく CloudWatch アラーム Internet Monitor によって生成されたヘルスイベントをフィルタリングするための Amazon EventBridge ルール CloudWatch アラームは、ユーザー体験のメトリクスをより詳細なレベルで追跡するために追加のメトリクスが必要な場合に役立ちます。 また、Internet Monitor がヘルスイベントを作成するまでには至らない影響がユーザーに発生したときにアラートが必要な場合でも、アラームを発行することができます。加えて、 EventBridge を使用すると、Internet Monitor によって生成されたイベントに対するイベント駆動型の自動応答を作成できます。 前提条件 以下のセクションでは、“VPC や CloudFront ディストリビューションなどの基本的な AWS ネットワーキングサービス”, “WorkSpaces ディレクトリの設定“に精通していることを前提としています。各サービスの詳細については説明しませんが、Internet Monitor でそれらを使用するために必要な手順の概要を説明します。AWS リソースに関する詳細情報は、対応する ユーザーガイド に記載されています。 Internet Monitor のセットアップ ここで、顧客向けのウェブアプリケーションを Amazon Elastic Compute Cloud (EC2) に、リモートチームメンバー向けのインターネットに面したAmazon WorkSpaces ディレクトリをホストしている場合を考えましょう。これらのインターネットに公開されたリソース全体で、エンドユーザーのユーザー体験をグローバルに監視する必要があります。大半のエンドユーザーが北米にいるため、他の地理的ユーザーとは別にアプリケーションにアクセスする際のユーザー体験も監視する必要があります。 モニターを作成してリソースを追加し、ヘルスイベントを通知するように CloudWatch アラームを設定するだけで、Internet Monitor を使い始めることができます。 EC2 でホストされている Web アプリケーションの監視 Step 1 : Internet Monitorでモニターを作成する モニターを作成するには、CloudWatch コンソールのアプリケーションのモニタリングの下にある [インターネットモニター] ページで [モニターを作成] を選択します。モニターの名前を入力し、 [リソースを追加] を選択します。この例では、EC2 でホストされるウェブアプリケーションがあるため、VPC を追加します。リソースページで VPC を選択し、次に [追加] を選択します。 [次へ] を選択し、設定を確認して、 [モニターを作成] を選択します。モニターがアクティブになるまでに数分かかります。 (* 新しいコンソールでは、図1 にあるような Step 1、Step 2 は1つのページで設定する仕様に変更されています。) 図1 – Internet Monitor コンソールでのモニターの作成 ワークロードとその監視ニーズによっては、リソースのグループごとにインターネットモニターで個別のモニターを作成する必要がある場合があります。今回の例では、WorkSpaces ディレクトリ用に別のモニターを作成します。 Step 2 : アラート設定の例 アラートには、Amazon EventBridge を使用します。アプリケーション要件とユーザーベースの例を考慮して、可用性スコアのしきい値を 50%、パフォーマンススコアのしきい値を 50% と定義し、影響を受ける総トラフィックをトラフィックの 1% 以上と指定します。EventBridge ルールは、上記の条件に一致するイベントのログの作成と同時に、このイベントの通知を SNS キューに送信します。(ここでの値はあくまでも一例です。アプリケーションやビジネスに適したレベルでしきい値を設定してください。) イベントフィルターを設定するには、AWS マネジメントコンソールで Amazon EventBridge に移動します。 [EventBridge ルールを作成] を選択し、関連する名前と説明を入力します。ルールには [ defaultイベントバス] を使用し、イベントソースには [その他] を選択します。サンプルイベント構成をスキップし、 [作成のメソッド] として [カスタムパターン] を選択します。例を下記に示します。 { "source": ["aws.internetmonitor"], "detail": { "Status": ["ACTIVE"], "ImpactedLocations": { "CountryCode": ["CA", "US"], "$or": [{ "internetHealth": { "Performance": { "experienceScore": [{ "numeric": ["&lt;", 50] }], "percentageOfTotalTrafficImpacted": [{ "numeric": ["&gt;", 1] }] } } }, { "internetHealth": { "Availability": { "experienceScore": [{ "numeric": ["&lt;", 50] }] } } }] } } } 次に、イベント用に 2 つのターゲットを設定します。1 つは新しい Amazon Simple Notification Service (SNS) トピックで、もう 1 つは CloudWatch の ロググループです。これらは、ログの経時的な変化の分析とレポートを目的としています。ルールに一致するInternet Monitor のヘルスイベントが発生すると、そのイベントは SNS キューと CloudWatch のロググループで受信されます。 図2 – EventBridge ルールのターゲットの設定 Amazon WorkSpaces ディレクトリのモニタリング Step 1 : WorkSpaces ディレクトリのモニターを作成する EC2 のモニター作成の手順に従って、WorkSpaces ディレクトリリソースのモニターを作成します。一部のリソースタイプでは、同じような監視要件を持つリソースを 1 つのモニターにグループ化できます。ただし、WorkSpaces ディレクトリをInternet Monitor の VPC と同じモニターに追加することはできないため、新しいモニターを作成します。 Step 2 : アラート設定の例 WorkSpaces ディレクトリを使用するお客様にとって重要な指標は、往復時間 (Round Trip Time, RTT) です。RTT が 100 ミリ秒を超えると、エンドユーザーのパフォーマンスエクスペリエンスに影響します。今回のユースケースでは、北米のエンドユーザーのみを対象に RTT を視覚化するカスタムメトリクスを作成します。そのための手順は以下のとおりです。 a) クライアントの場所に基づいて Internet Monitor のイベントログをフィルタリングします。 b) Internet Monitor イベントログ用のカスタム CloudWatch メトリクスフィルターを作成します。 c) カスタムメトリクスに基づいてアラームを設定します。 それぞれの設定フローを、詳しく見ていきます。 a) クライアントの地理情報に基づくイベントログのフィルタリング CloudWatch Logs のコンソールでは、Internet Monitor のログデータを JSON 形式で名前空間 /aws/internet-monitor/&lt;your-monitor-name&gt;/&lt;granularity&gt; にて視覚化できます。この例では、北米のエンドユーザーの場合、国レベルの細分化が最も役立ちます。内部のログストリームには、個々の測定イベントが含まれています。各イベントには、クライアントロケーションの地理情報とネットワーク情報、トラフィック統計、可用性スコア、パフォーマンススコアが含まれます。これは、Internet Monitor コンソールに集約されて表示される情報と同じです。 図3 – JSON 形式の Internet Monitor イベントログの例 インターネットモニターのログをフィルタリングするには、 ClientLocation.CountryCode フィールドを次の設定で使用します。例 : {$.clientLocation.CountryCode=US || $.clientLocation.CountryCode=CA} 。これにより、米国またはカナダのクライアントロケーションのログイベントを視覚化できます。 図4 – Internet Monitor のログストリームが、北米にあるクライアントロケーションのイベントのみを表示するようにフィルタリングされている例 b) Internet Monitorイベントログ用の CloudWatch メトリクスフィルターを作成する クライアントの地理情報に基づいてログがフィルタリングされたら、 [メトリクスフィルターを作成] を選択し、フィルターメトリクスの名前と名前空間を設定して、関連するカスタムメトリクスをグループ化します。この例では、90 パーセンタイル (p90) の RTT 値である InternetHealth.Performance.RoundtripTime.p90 に基づいてメトリクスを生成しています。メトリクスの感度が p90 なので、平均値を使用すると見落とされるであろう異常を警告することができ、トリガーの頻度が高すぎることも回避できます。 図 5 – CloudWatch Logs コンソールを使用して Internet Monitor ログイベントに基づくメトリクスフィルターを作成 要件に応じて、構成に p50、p90、または p95 を使用できます。測定パーセンタイルの詳細については、 CloudWatch ユーザーガイド を参照してください。新しいメトリクスフィルタである NorthAmericanRTT は、最初に一致するログイベントが処理された直後に利用できるようになります。 c) カスタムメトリクスに基づいてアラームを設定する 新しいメトリクスに基づいてアラームを作成するには、CloudWatch アラームコンソールを使用して、新しく作成したメトリクスをモニター用に選択します。一例として、RTTのしきい値条件として 100ms を選択しました。また、静的しきい値の代わりに異常検出を使用するアラームを作成して、より正確なユーザーエクスペリエンス分析を行うこともできます。異常検出の詳細については、 CloudWatch ユーザーガイド を参照してください。 アラームのしきい値条件を設定したら、次の図に示すように、アラートを送信する SNS トピックを選択し、アラームを作成します。 図6 – Internet Monitor メトリクスの指定と CloudWatch アラームコンソールでのしきい値の設定 Internet Monitorのイベントの分析 ここで、パフォーマンスまたは可用性が設定したしきい値のいずれかを下回ったというアラートを受け取ったとします。調査を開始するには、モニターのInternet Monitorコンソールの [概要] タブをクリックしてください。概要タブには、監視対象リソースの可用性とパフォーマンスのスコア、および関連するアクティブヘルスイベントが表示されます。 図7 – Internet Monitor コンソールの概要タブで、ヘルススコアと台湾とオーストラリアでのヘルスイベントを示すマップが表示されている様子 この例では、台湾とオーストラリアのユーザーに影響を及ぼすヘルスイベントを確認できます。ヘルスイベントの詳細を確認するには、CSV 形式または JSON 形式で詳細をダウンロードできます。 [アクション] を選択し、必要な形式を選択します。このファイルには、選択した期間のすべてのヘルスイベントが含まれており、関心のあるイベントのみを含めるようにフィルタリングできます。1 つのイベントを見ると、イベントの詳細には、クライアントの場所、ネットワークサービスプロバイダー名、ASN、影響を受けたトラフィックの割合などの情報が含まれていることがわかります。JSON 形式のイベントの例を次に示します。 { "EndedAt": null, "EventArn": "arn:aws:internetmonitor:us-east-1:617055091360:monitor/retryblogmonitor/health-event/2022-10-11T01-15-00Z/availability", "EventId": "2022-10-11T01-15-00Z/availability", "ImpactType": "AVAILABILITY", "ImpactedLocations": [ { "ASName": "TPG Telecom Limited", "ASNumber": 7545, "internetHealth": { "Availability": { "ExperienceScore": 84.78, "PercentOfClientLocationImpacted": 15.22, "PercentOfTotalTrafficImpacted": 8.66 } }, "City": "Canberra", "Country": "Australia", "CountryCode": "AU", "Latitude": -35.2504, "Longitude": 149.1702, "Metro": "", "ServiceLocation": "us-east-1", "ServiceName": "VPC", "Status": "ACTIVE", "Subdivision": "Australian Capital Territory", "SubdivisionCode": "" } ], "PercentOfTotalTrafficImpacted": 8.66, "StartedAt": "2022-10-11T01:15:00.000Z", "Status": "ACTIVE" } 図7 に示す情報を読み取っていきます。ここでは、その場所にいるクライアントの 15.22% が影響を受けました。これは、当時アプリケーションを使用していた全クライアントの 8.66％ に相当します。 ユーザーエクスペリエンスをさらに深く掘り下げるには、 [Historical Explorer] タブに移動して、地域やネットワークプロバイダー、および時間枠でフィルタリングされたより多くのパフォーマンス指標を視覚化します。 図8 – オーストラリアにフィルタリングされたインターネットトラフィックグラフを表示する、Internet Monitor の Historical explorer タブ Internet Monitor を使用してアプリケーション配信を最適化 ここで調査しているような、クライアントネットワークプロバイダーの問題が原因と思われるイベントについては、短期的に実行できるアクションがいくつかあります。 アプリケーションがすでに複数のリージョンから提供されている場合、影響を受けるトラフィックを、別のインターネットパスでアクセスできる別の AWS リージョンのリソースにシフトできる可能性があります。 ネットワークプロバイダーに連絡して、問題を認識しているかどうか、解決策に取り組んでいるかどうかを確認してください。これは、お住まいの地域以外のプロバイダーの場合は、選択できない可能性があります 自分のステータスページやソーシャルメディアを更新して、ある場所で発生している問題はその地域のインターネットのパフォーマンスによるものであることをユーザーに知らせることが出来ます。 影響を受ける顧客からの質問に答えるために、カスタマーサポートを準備する。 長期的なアプローチとしては、例えば Amazon CloudFront のようなサービスを使用して、クライアントトラフィックが通過するインターネットパスを最小限に抑えるなど、エンドユーザーへのアプリケーション配信を改善することが考えられます。AWS リージョンのユーザーおよびオリジンリソースまたはエンドポイントに最も近い AWS POP からのトラフィックはすべて、AWS グローバルネットワークを介して伝送されます。 [トラフィックインサイト] タブでは、可用性やパフォーマンススコア、サーバー初期応答時間 (Time to first byte, TTFB) 別にソートして、さまざまな場所でアプリケーションのパフォーマンスを向上させる方法を調べることができます。また、地理的フィルターやネットワークプロバイダーフィルターを使用して、特定の地域のデータをさらに詳しく調べることもできます。 Internet Monitor では、 [トラフィック最適化の提案] で、EC2 や CloudFront リソースの使用に切り替えたり、トラフィックを他の AWS リージョンやエッジロケーションにルーティングしたりした場合に、クライアントロケーションとネットワークプロバイダーの組み合わせで予想される TTFB 改善の予測も表示されます。さまざまなオプションを試して、それぞれの組み合わせで最良の結果が得られるものを確認してください。 図9 – クライアントロケーショングラフごとの総トラフィックやトラフィック最適化の提案が表示される、Internet Monitor のトラフィックインサイトタブ 環境のクリーンアップ Internet Monitor の機能を確認し終わったら、必ずテスト環境をクリーンアップし、作成したリソースを削除してください。まず、モニターを削除し、次に EventBridge ルール、CloudWatch ログルール、アラーム、メトリクス、ロググループ、SNS トピックなど、作成したその他のリソースを削除します。 その他の注意点 1 つの AWS リージョンに同じようなユーザーベースのアプリケーショングループがある場合は、1 つのモニターを作成して、グループ全体のユーザーエクスペリエンスの集計を監視します。 Internet Monitorの 1 つのモニターで、複数のリージョンのリソースを監視できます。 VPC と CloudFront ディストリビューションを追加する場合、WorkSpaces ディレクトリを同じモニターに追加することはできません。 Internet Monitor には、メトリクス、ログ、作成されたダッシュボード、アラーム、またはインサイトに対して、通常の CloudWatch 料金がかかります。詳細については、 CloudWatch の料金表ページ をご覧ください。 Internet Monitor の AWS CloudFormation サポートはまもなく利用可能になる予定です。 Internet Monitor は現在 20 の AWS リージョン でご利用いただけます。 まとめ このブログでは、Amazon CloudWatch Internet Monitor を紹介しました。これは、AWS がグローバルネットワークインフラストラクチャから収集した接続データを利用して、、インターネットに接続するアプリケーションのパフォーマンスを可視化する新しいサービスです。Internet Monitor は、他の方法では気付かないエンドユーザーのエクスペリエンスに影響を与える要因を使用して、十分な情報に基づいた意思決定を行うことができるため、ワークロードの導入戦略を最適化できます。インターネットモニターの詳細については、 ドキュメント をご覧ください。 本記事は、Alexandra Huides, Tony Hawke らの「 Introducing Amazon CloudWatch Internet Monitor 」を翻訳したものです。翻訳は ソリューションアーキテクトの 伊藤 威が担当しました。

11月27日は、 Amazon ElastiCache Serverless の提供開始についてお知らせします。これは、お客様が 1 分以内にキャッシュを作成し、アプリケーションのトラフィックパターンに基づいて容量を即座にスケールできる新しいサーバーレスオプションです。ElastiCache Serverless は、2 つの一般的なオープンソースキャッシュソリューションである Redis および Memcached と互換性があります。 ElastiCache Serverless を使用すると、最も要求の厳しいワークロードであっても、即座にキャッシュを運用できます。キャパシティプランニングにかける時間を削減でき、キャッシュの専門知識も不要です。ElastiCache Serverless は、アプリケーションのメモリ、CPU、ネットワークリソースの使用状況を常に監視し、処理するワークロードのアクセスパターンの変化に合わせて即座にスケールします。また、複数のアベイラビリティーゾーンにわたってデータを自動的にレプリケートし、サービスレベルアグリーメント (SLA) によって、すべてのワークロードに対する最大 99.99% の可用性が保証されています。そのため可用性の高いキャッシュを作成でき、時間とコストの節約になります。 キャッシュのデプロイと運用には大幅な簡素化が求められていました。ElastiCache Serverless は、基盤となるクラスタートポロジとキャッシュインフラストラクチャを抽象化し、簡素化されたエンドポイントエクスペリエンスを提供します。再接続やノードの再検出を行わなくても、アプリケーションの複雑さを軽減し、より優れた運用を実現できます。 ElastiCache Serverless では、前払いコストは発生せず、使用したリソースに対してのみ料金が発生します。アプリケーションで使用したキャッシュデータストレージと ElastiCache 処理装置 (ECPU) リソースの量に対してのみお支払いいただきます。 Amazon ElastiCache Serverless の開始方法 まずは ElastiCache コンソール に移動し、左側のナビゲーションペインで [Redis キャッシュ] または [Memcached キャッシュ] をクリックします。ElastiCache Serverless は、Redis 7.1 以降または Memcached 1.6 以降のエンジンバージョンをサポートしています。 例えば、Redis キャッシュの場合は、 [Redis キャッシュを作成] をクリックします。 デプロイオプションは 2 つあり、 [サーバーレス] と [独自のキャッシュを設計] のいずれかを選択して、ノードベースのキャッシュクラスターを作成します。 [サーバーレス] オプションをクリックしたら、 [新しいキャッシュ] をクリックして名前を指定します。 デフォルト設定を使用して、デフォルトの VPC、アベイラビリティーゾーン、サービス所有の暗号化キー、セキュリティグループにキャッシュを作成します。推奨されるベストプラクティスが自動的に設定されます。追加の設定を入力する必要はありません。 デフォルト設定をカスタマイズする場合、独自のセキュリティグループの設定や、自動バックアップの有効化ができます。また、キャッシュが特定のサイズを超えないように、コンピューティングとメモリの使用量に上限を設定することも可能です。キャッシュがメモリの上限に達すると、有効期間 (TTL) のあるキーは、最近で最も使用されていない (LRU) ロジックに従って削除されます。コンピューティングの上限に達すると、ElastiCache はリクエストを調整するため、リクエストのレイテンシーが増加します。 新しいサーバーレスキャッシュを作成すると、エンドポイントやネットワーク環境など、接続性とデータ保護の設定を詳しく確認できます。 これで、アプリケーションに ElastiCache Serverless エンドポイントを設定できました。また、Redis をサポートする任意の Redis クライアント ( redis-cli など) を使用して、クラスターモードでエンドポイントに接続できるようになります。 $ redis-cli -h channy-redis-serverless.elasticache.amazonaws.com --tls -c -p 6379 set x Hello OK get x "Hello" キャッシュの管理は、 AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用して行えます。詳細については、AWS ドキュメントの「 Amazon ElastiCache for Redis とは 」を参照してください。 既存の Redis クラスターがある場合は、ElastiCache Serverless キャッシュの作成時に、ElastiCache バックアップまたはバックアップファイルの Amazon S3 ロケーションを標準の Redis rdb ファイル形式で指定します。これにより、データを ElastiCache Serverless に移行できます。 Memcached キャッシュの場合は、Redis と同じ方法で新しいサーバーレスキャッシュを作成して使用できます。 Memcached 用に ElastiCache Serverless を使用すると、大きなメリットが得られます。なぜなら Memcached エンジンでは本来、高い可用性と即座のスケール機能を備えていないためです。Memcached で高い可用性を実現するために、カスタムビジネスロジックの記述、複数キャッシュの管理、サードパーティのプロキシレイヤーを使用したデータのレプリケートを行う必要がなくなります。サービスレベルアグリーメント (SLA) によって最大 99.99% の可用性が保証され、複数のアベイラビリティーゾーンにわたるデータのレプリケートが可能になりました。 Memcached エンドポイントに接続するには、以下の出力例に示す openssl クライアントと Memcached コマンドを実行します。 $ /usr/bin/openssl s_client -connect channy-memcached-serverless.cache.amazonaws.com:11211 -crlf set a 0 0 5 hello STORED get a VALUE a 0 5 hello END 詳細については、AWS ドキュメントの「 Amazon ElastiCache for Memcached の使用開始 」を参照してください。 監視とパフォーマンス ElastiCache Serverless は、キャッシュのスケールアップと並行してスケールアウトを開始することで、最適なタイミングでキャパシティのニーズに応えます。そのため、アプリケーションのダウンタイムやパフォーマンスの低下を発生させずにスケールできます。 ElastiCache Serverless のパフォーマンスを示すために、簡単なスケーリングテストを実施しました。まず、読み取りと書き込みの比率が 80/20 で、キーサイズが 512 バイトの一般的な Redis ワークロードから始めます。Redis クライアントは、Redis コマンド「READONLY」を使用して、レプリカから読み取り (RFR) を実施するように設定されています。これにより、読み取りパフォーマンスを最適化します。このテストの目的は、レイテンシーに影響を与えずに、ElastiCache Serverless でワークロードをいかに高速にスケールできるかを示すことです。 上記のグラフからわかるように、10 分ごとに 1 秒あたりのリクエスト数 (RPS) が 2 倍になり、テストの目標リクエストレートである 100 万 RPS に到達しました。テストの実施中、p50 GET のレイテンシーが約 751 マイクロ秒のままであり、常に 860 マイクロ秒未満であることが確認されました。同様に、p50 SET のレイテンシーは約 1,050 マイクロ秒のままであり、スループットが急激に増加しても 1,200 マイクロ秒を超えないことが確認されました。 留意点 エンジンバージョンのアップグレード – ElastiCache Serverless は、新機能、バグ修正、セキュリティアップデート (エンジンの新しいマイナーバージョンやパッチバージョンを含む) をキャッシュに透過的に適用します。新しいメジャーバージョンがリリースされると、ElastiCache Serverless はコンソールに通知を送信し、 Amazon EventBridge にイベントを送信します。ElastiCache Serverless のメジャーバージョンアップグレードは、アプリケーションを中断しないように設計されています。 パフォーマンスと監視 – ElastiCache Serverless は、メモリ使用量 ( BytesUsedForCache )、CPU 使用量 ( ElastiCacheProcessingUnits )、キャッシュメトリクス ( CacheMissRate 、 CacheHitRate 、 CacheHits 、 CacheMisses 、 ThrottledRequests など) を含む、一連のメトリクスを Amazon CloudWatch に公開します。また、ElastiCache Serverless は、キャッシュの作成、削除、制限更新などの重要なイベントに対して Amazon EventBridge イベントを発行します。使用可能なメトリクスとイベントの完全なリストについては、ドキュメントを参照してください。 セキュリティとコンプライアンス – ElastiCache Serverless キャッシュは、VPC 内からアクセスできます。 AWS Identity and Access Management (IAM) を使用することで、データプレーンにアクセスできます。デフォルトでは、ElastiCache Serverless キャッシュを作成した AWS アカウントのみがアクセスできます。ElastiCache Serverless は、保管中および転送中のすべてのデータを暗号化しており、これには ElastiCache Serverless への各接続を暗号化する Transport Layer Security (TLS) が使用されています。オプションで、VPC 内、サブネット内、IAM アクセス内、暗号化用の AWS Key Management Service (AWS KMS) キー内のキャッシュに対するアクセスを制限することもできます。ElastiCache Serverless は PCI-DSS、SOC、ISO に準拠しており、HIPAA に対応しています。 今すぐご利用いただけます Amazon ElastiCache Serverless は、中国を含むすべての商用 AWS リージョンでご利用いただけるようになりました。ElastiCache Serverless では、前払いコストは発生せず、使用したリソースに対してのみ料金が発生します。キャッシュされたデータ (GB/時)、使用した ECPU、スナップショットストレージ (GB/月) に対してのみお支払いいただきます。 詳細については、「 ElastiCache Serverless ページ 」と「 ElastiCache Serverless の料金ページ 」をご覧ください。ぜひお試しいただき、 AWS re:Post for Amazon ElastiCache または通常の AWS サポートのお問い合わせからフィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに SAP Enterprise Portal (EP) などの SAP Java アプリケーションでは、HTTP(s) 要求のエントリポイントとして SAP Web ディスパッチャを使用します。SAP Web ディスパッチャは、インターネットまたはイントラネットからの要求を受信し、アプリケーションサーバー間で要求を分散します。インターネットベースの HTTP(s) リクエストの場合、SAP Web Dispatcher はインターネットにアクセスできる必要があるため、パブリックサブネットにインストールする必要があります。多くの SAP のお客様は、アタックサーフェスを減らすためにパブリックサブネットに EC2 インスタンスを設置することを避けています。 このブログでは、SAP EP アプリケーションに Elastic Load Balancing （ELB）を使用する方法について説明します。SAP EP アプリケーションは、HTTP リクエストの負荷分散に Application Load Balancer（ALB）を使用します。SAP Web dispatcher とは異なり、ALB はサーバーレスサービスであり、AWS によるマネージドサービスです。SAP EP に HTTP トラフィックを提供するインターネットに面した ALB を構成することができます。ALB では、既知の脆弱性に対処するための AWS Web Application Firewall （WAF）、コンテンツ高速化のための Amazon CloudFront 、TLS/SSL 証明書を管理するための AWS Certificate Manager （ACM）と統合することができます。 Application Load Balancer とその特徴 ALB は可用性の高いサービスで、クライアントからの HTTP(s) リクエストを受け取り、ルールに基づいてターゲットグループに振り分けます。各ターゲットグループには、SAP EP の単一または複数のアプリケーションサーバーの IP アドレスまたは EC2 インスタンス ID と HTTP ポートの組み合わせが含まれます。HTTP(s) リクエストは ALB によってアプリケーションサーバーに転送されます。 ALB は以下の SAP EP の要件を満たすことができます。 可用性が高く、複数のアベイラビリティゾーン（AZ）にリクエストを分散できる、レイヤー 7 の HTTP（s）ロードバランシングサービス。 高セキュリティ、高信頼性、スケーラブルなマネージド AWS サービスであり、手動でのサーバーメンテナンスが不要（サーバーレス）。 HTTP(s) リクエストは、ホストおよび/またはポートベースのマッピングに基づいて、複数のアプリケーションサーバーに転送することができます。 TLS/SSL 暗号化オフロード。ALB は SSL 証明書と連携してロードバランサーとクライアント間のトラフィックを暗号化します。受信トラフィックは、SAP アプリケーションをホストする EC2 インスタンスに到達する前に、アクセス制御リスト（ACL）に対する厳格なチェックを通過しなければなりません。 Simple and Protected GSS-API Negotiation（SPNEGO）と Security Assertion Markup Language（SAML）によるシングルサインオン（SSO）をサポートし、Active Directory などのアイデンティティプロバイダと認証します。 HTTP リクエストフィルタリング。WAF は、 このブログ で紹介した SQL インジェクションのような Open Web Application Security Project (OWASP) の攻撃に対する追加のセキュリティ・レイヤーとして、ALB と共に使用することができます。WAF はまた、ACL とルールの形でトラフィック検査とフィルタリングルールのサポートを提供します。 ドキュメント に従って、WAF でカスタムルールを定義することもできます。 SSL 証明書の管理。ACM は、この ドキュメント で説明されているように、SSL/TLS 証明書を管理するために使用することができます。 アーキテクチャ 1) SAP EP のシングル ALB アーキテクチャ 複数の SAP アプリケーションサーバー間で負荷を分散するために、単一の ALB を使用することができます。ALB は、インターネットに面したものでも、イントラネットに面したものでもかまいません（内部 ALB とも呼ばれます）。ダイレクト・コネクトまたは仮想プライベート・ネットワーク（VPN）を介して顧客のネットワークから到着する HTTP（s）リクエストに対して、「内部」ALB はリクエストを転送し、アプリケーション・サーバーに負荷分散します。しかし、顧客がインターネットから SAP EP へのアクセスを許可したい場合、図 1 の右側の図のように、 パブリックサブネット上のインターネットに面した ALB が必要になります 。 図 1：左：SAP EP の単一内部 ALB アーキテクチャ、右：SAP EP の単一インターネット ALB アーキテクチャ 2) SAP EP の ALB サンドイッチ・アーキテクチャ 図 2：SAP EP の ALB サンドイッチ・アーキテクチャ 図 2 に示すように、インターネットに面した ALB をパブリックサブネットに、2つ目の内部 ALB をプライベートサブネットに配置することで、2 つの ALB を組み合わせることができます。このような配置は、SAP アプリケーションのサブネットがインターネットに露出しないため、爆発半径を小さくすることができ、 AWS Well-Architected Framework と整合して耐障害性を確保しながら、アーキテクチャをよりセキュアにすることができます。 アーキテクチャの説明 パブリックサブネットがネットワークアカウントにあり、プライベートサブネットが AWS 本番アカウントにある 2 アカウント戦略が考えられます。同じアーキテクチャを 1 つのアカウントでデプロイすることもできます。 ネットワークアカウントはインターネットにアクセスできますが、AWS 本番アカウントはインターネットに直接アクセスできません。これにより、AWS 本番アカウントはよりセキュアになります。 2 つの ALB を考えました。Network アカウントの ALB は、SAP EP 用のインターネットに面した ALB です。これはインターネット（外部）ユーザーにサービスを提供し、それはイントラネット（内部）ユーザーにサービスを提供するイントラネットに面した（内部）ALB に接続されています。 図 2 では、可用性と回復力を向上させるために、複数の AZ と Amazon EC2 Auto Scaling グループに分散した VM シリーズのファイアウォールを使用しています。 このようなサンドイッチ・アーキテクチャは、インバウンド・トラフィックのファイアウォール検査の要件に対応するために使用されます。トラフィックはまず、VM シリーズ・ファイアウォールの Auto Scaling Group のフロントエンドとして使用される ALB を通過する。各ファイアウォールの宛先は、その背後にターゲットグループ（この場合は EC2 インスタンス）を含む ALB です。このアプローチにより、セキュリティ検査層とウェブフロントエンド層の両方が、互いに独立したコスト効率の良い方法でスケールイン/スケールアウトできるようになります。詳細はこちらの ブログ を参照してください。 インターネットに面した ALB の構成 インターネットに面した ALB は HTTP または HTTPS トラフィックをリッスンするように設定されます。セキュリティを向上させるために HTTP ポート 80 を HTTPS ポート 443 にルーティングします。 デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているので、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。 HTTPS リスナーについては、 ACM 証明書 またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書をデプロイする。 フローは以下の通りである： トラフィックはインターネットに面した ALB で受信されます。 ALB はトラフィックをファイアウォール・インスタンス・ベースのターゲット・グループに転送します。 ファイアウォールインスタンスでは、静的ネットワークアドレス変換（NAT）またはポート間 NAT ポリシーが内部 ALB にトラフィックをルーティングするために使用されます。 内部 ALB はファイアウォールからトラフィックを受信します。 内部 ALB の設定 ポート 80 は、ファイアウォールを経由してルーティングされた、インターネットに面した ALB からの着信要求をリッスンする HTTP ポートとして定義されています。 ポート 443 は、企業ネットワーク内で SAP EP に直接アクセスするユーザーをリッスンする HTTPS ポートとして定義されています。 デフォルトのセキュリティポリシー ELBSecurityPolicy-2016-08 は、TLSv1.2 をサポートしているため、インターネットに面したロードバランサーと内部のロードバランサーの両方に推奨されるポリシーです。 HTTPS リスナーについては、 ACM 証明書 またはサードパーティ証明書を使用して、ALB 上に 1 つの SSL/TLS サーバー証明書を展開します。 図 3 内部 ALB リスナー 内部 ALB のターゲットグループ SAP EP アプリケーションサーバーのすべての IP アドレスがターゲットグループに追加されます。EC2 インスタンスを追加することもできる一方、EC2 インスタンス ID は障害による終了時に変更される可能性があり、新しいインスタンスがその代わりになる可能性があるため、 「IP アドレス」をターゲットとして追加する ことが望ましい。 図4 内部ALBのSAP EPのターゲットグループ SAP EP のターゲットグループの属性 Stickiness Type Application cookie[app_cookie] Stickiness Duration 17 hours App cookie name saplb_* 図 5：SAP EP のスティッキネス属性 SAP EP は、アプリケーションベースのスティッキネスを有効にする必要があります。これは、ステートフルなユーザー・セッションをサポートするために、後続のリクエストを関連するアプリケーション・サーバーに渡すために必要です。バックエンドの SAP EP が saplb_* クッキーを追加し、ALB がその値をコピーして AWSALBAPP-* クッキーと呼ばれる別のクッキーを作成することを確認する必要があります。 スティッキネス期間は、ユーザのセッションが常に ALB によって特定のアプリケーションサーバにルーティングされることを保証するのに十分でなければなりません。これは要件に基づいて調整できます。営業時間または 1 日を推奨します。 リスナールール リスナーは、設定したプロトコルとポートを使用して接続要求をチェックするプロセスです。ALB を作成するときにリスナーを定義し、いつでもロードバランサーにリスナーを追加できます。例えば、図 3 に示すように、内部 ALB に 2 つのリスナーを定義しました： インターネットに面した ALB から到着するトラフィック用の HTTP 80 HTTPS 443 社内ネットワークから来るトラフィック用 リスナーのリスナールールは、ALB が登録されたターゲットにどのようにリクエストをルーティングす るかを決定する。各ルールは、優先度、1 つ以上のアクション、および 1 つ以上の条件で構成されます。詳細については、この ドキュメント を参照してください。 内部 ALB リスナールール 以下の表は、ALB でのルールと設定の例を示しています。 ルール番号 Internal ALB Listener –Port 443 (Rule for internet traffic/internet facing ALB forward) Internal ALB Listener – Port 80 (Rule for intranet traffic) Corresponding SAP Web Dispatcher Rule 5 If Source IP is 10.0.0.0/8 OR 192.168.138.0/23 PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* Then Forward to sap-ep-prod-alb-tg: 1(100%) If PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* “Return Fixed Response- This Feature is Blocked over Internet” #User Administrator if %{PATH} regimatch ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.*) [and] If %{REMOTE_ADDR} !regimatch 10(.*) [and] %{REMOTE_ADDR} !regimatch 192.168.138(.*) [and] %{REMOTE_ADDR} !regimatch 192.168.139(.*) RegForbiddenURL ^/webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin(.*) – [break] 6 If PATH is */webdynpro/dispatcher/sap.com/tc~sec~ume~wd~umeadmin/* “Return Fixed Response- This Feature is Blocked over Internet” 上記の 2 つのリスナールール 5 と 6 は、ユーザー管理エンジン（UME）管理者がシステム管理者の内部からのみアクセスできることを保証します。 ルール 5 は、社内サブネット範囲 10.0.0.0/8 または 192.168.138.0/24 または 192.168.139.0/24 内の IP アドレスからの UME 管理者へのアクセスを許可することを示します。 ルール 6 は、UME Admin がその他の IP アドレスからのアクセスを許可されていないことを示します。 図 6：ALB 内部 HTTP リスナーポート 443 の設定 インターネットに面した ALB リスナーのルール HTTP 要求がポート 443 でリッスンしているインターネット向け ALB に到達すると、インターネット向け ALB のターゲットグループとして定義されている内部 ALB にトラフィックを転送します。 リスナー・ルールに従って、インターネットから UME Admin へのリクエストがあると、図 7 と図 8 のようにブロックされます。 図 7: 内部 ALB HTTP リスナー・ポート 80 の設定 図 8：インターネットからユーザ管理 URL にアクセスしようとした結果 ALB の属性とセキュリティに関する考慮事項 ALB が無効なパケットをドロップし、有効でないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるように ALB が設定されていることを確認することを推奨します。 TLS 1.1 は TLS 1.1 と比較してセキュリティが強化されているため、ALB レベルでは TLS 1.2 が有効です EC2 のオートスケーリングが計画されている場合は、削除保護を無効にする必要がある。 アイドルタイムアウトは、SAP アプリケーションの処理タイムアウトと同じかそれ以上でなければなりません。デフォルトでは、SAP EP のタイムアウトは 600 秒で、これをインターネットとイントラネットの両方の ALB に組み込む必要があります。 インターネット経由で SAP EP 経由で SAP ECC バックエンドコンテンツにアクセスするための ALB サポート ALB が SAP EP への接続をサポートし、インターネット経由で SAP EP から SAP ECC バックエンドにリダイレクトできるようにしたいと考えています。オープンネットワーク上で SAP EP から SAP ECC バックエンドへのトラフィックの流れの詳細については、この SAP ブログ をご覧ください。 一部のお客様には、インターネットトラフィックの完全修飾ドメイン名 (FQDN) とポートの組み合わせを 1 つだけ許可する厳しいポリシーがあります。このような場合、複数の SAP システム間で負荷を分散するには、コンテキストベースまたはパスベースのマッピングが必要です。たとえば、顧客がポート 443 を持つ外部 ALB を 1 つだけ許可していて、SAP EP と SAP Fiori への接続を許可する必要がある場合、リスナールールの条件には、SAP EP の場合は「/irj/portal」または「/nwa」、SAP Fiori の場合は「/fiori」によるマッピングが必要です。ALB が 1 つしかない場合、特に「/icon」、「/sap」などの共通コンテンツでは、パスの競合が発生する可能性があります。そのため、インターネットユーザーやイントラネットユーザー向けに設計するには、複数の SAP ソリューションに対して 2 つ以上の ALB を組み合わせることをお勧めします。 次のアーキテクチャは、コンテキストベースのマッピングに使用される 2 組の ALB を示しています。1 組は SAP EP 用、もう 1 組は SAP ECC がそれぞれのアプリケーションにアクセスするためのものです。 図 9: インターネット経由で SAP EP から SAP ECC コンテンツにアクセスするためのマルチ ALB アーキテクチャ インターネット経由で SAP EP 経由で SAP ECC 機能を利用するという目標を達成するために、2 組の ALB を検討しました。ペア 1 には、前述の SAP EP で説明したアーキテクチャを備えたインターネット向けの ALB と内部 ALB が含まれています。ペア 2 には、SAP ECC システム用のインターネット向け ALB と内部 ALB のセットがもう 1 つ含まれています。 SAP ECC webdynpro URL にはインターネット経由で直接アクセスせず、SAP EP または同じドメインのシステムからのみアクセスできるようにする必要があります。 これは、図 10 に示すように、SAP ECC のインターネット向け ALB にリスナールールを実装することで実現されます。このルールでは、「HTTP ヘッダーリファラー」フィールドにより、ECC サービスには ess-ep.example.com ALB FQDN からのみアクセスでき、インターネット経由の ECC サービスへの直接アクセスは HTTP 応答 402 でブロックされます。 図 10: ECC ALB リスナールールの HTTP ヘッダーリファラー SAP ERP の内部 ALB には、リスナーポート 443 を介して直接アクセスできるため、社内ネットワークから直接アクセスすることも、SAP EP から参照することもできます。 図 11: SAP EP の ESS iView 図 12: システムエイリアス設定 たとえば、インターネットユーザーは、SAP EP ALB ベースのポータル URL https://ess-ep.example.com/irj/portal にログインして、SAP ECC 上で稼働する従業員セルフサービス (ESS) webdynpro アプリケーションにアクセスできます。このアプリケーションは、図 11 に示すように https://ess-ecc.example.com/sap/bc/webdynpro/ZHRESS にある SAP ECC ALB を使用してセットアップされています。 SAP ECC の「システムエイリアス」は、SAP ECC ALB FQDN で定義されています。これにより、図 12 に示すように、https://&lt;EP-ALB URL &gt;/irj/portal-&gt; システム管理-&gt; システムランドスケープまで SAP EP からの直接 SSO が可能になります。SAP ECC のインターネットトランザクションサーバー (ITS) ホスト名とアプリケーションサーバーホスト名は、SAP ECC ALB FQDN で定義されています。 予想される HTTP リクエストフロー: ユーザーはまず SAP EP ポータルの URL にアクセスし、/irj/portal を開きます。 リクエストは VM シリーズのファイアウォールを通過する前に、インターネットに直接接続されている SAP EP ALB に到達します。 その後、SAP EP の内部 ALB に転送され、最後に SAP EP アプリケーションサーバに転送されます。 SAP EP 内に入ると、ユーザーが ESS タブをクリックすると、リクエストは SAP ECC のインターネットに直接接続された ALB にリダイレクトされます。 その後、リクエストは VM シリーズのファイアウォールに送信され、SAP ECC 内部 ALB に到達してリスナールールを検証します。 一致条件に基づいて、トラフィックを SAP ECC ターゲットグループに送信して SAP ECC アプリケーションサーバーに到達します。 ユーザーがインターネット経由で SAP ECC webdynpro URL に直接アクセスしようとすると、アクセスは拒否されます。これは、図 10 に示すように、ルールに示されている「リファラー」である SAP EP ALB が ECC ALB にアクセスする唯一の方法だからです。 HTTP リファラーは外部 ALB 側にしか実装されていないため、イントラネットユーザーが内部 ALB に直接接続しても、URL に直接または間接的にアクセスしても問題はありません。 ALB パフォーマンス分析とトラブルシューティング ALB のパフォーマンスをモニタリングするには、 Amazon CloudWatch コンソール、メトリックスに移動して目的の ALB を選択するか、EC2 コンソール-&gt; 負荷分散-&gt; ターゲットグループに移動し、目的のターゲットグループを選択して [モニタリング] タブをクリックします。詳細については、次の AWS ドキュメント を参照してください。以下は ALB の CloudWatch メトリクスの図の例で、インドの営業時間のピーク時に 30 分間、リクエスト数が 1500 ～ 2000 リクエストだった場合の平均「目標応答時間」が約 150 ～ 200 ミリ秒であることを示しています。 図 13: Amazon クラウドウォッチ ALB パフォーマンスメトリックス このナレッジベース を参照して、高レイテンシーまたはタイムアウトの問題による ALB パフォーマンスのトラブルシューティングを行うことができます。SAP EP に関連する問題を絞り込んだら、ICM ログまたはデフォルトトレースで手がかりがないか確認してください。このような問題を解決するには、 SAP Note 2579836 を確認してください。 結論 このブログ記事では、SAP EP アプリケーション用の ALB のユースケース、アーキテクチャパターン、セットアップ手順について詳しく説明しました。お客様は、ALB の機能や利点を活用するために、SAP アプリケーションに ALB を使用しています。ALB は AWS のマネージドサービスであり、基盤となるオペレーションレイヤーや EC2 インスタンスのメンテナンスを必要としません。可用性が高くスケーラブルなサービスとして提供されるため、SAP 環境を簡素化できます。 SAP on AWS の詳細については、 AWS 製品ドキュメント をご覧ください。 さらに専門的なガイダンスが必要な場合は、AWS アカウントチームに連絡して、地元の SAP スペシャリストソリューションアーキテクトまたは AWS プロフェッショナルサービス SAP 専門プラクティスに依頼してください。 SAP on AWS ディスカッションにご参加ください。 カスタマーアカウントチームと AWS サポートチャネルに加えて、 Re: Post — AWS コミュニティ向けの 再考された Q&amp;A エクスペリエンス で私たちと交流することもできます。SAP on AWS ソリューションアーキテクチャチームは定期的に SAP on AWS のトピックを監視し、お客様やパートナーを支援するためのディスカッションや質問に回答しています。質問がサポートに関連していない場合は、re: Post でのディスカッションに参加して、コミュニティのナレッジベースに追加することを検討してください。 このブログは Sumit Dey が共同執筆し、翻訳は Partner SA 松本が担当しました。原文は こちら です。

Amazon Aurora Limitless Database のプレビューを開始しました。Aurora Limitless Database は自動水平スケーリングをサポートする新機能であり、1 秒間に数百万件の書き込みトランザクションを処理し、1 つの Aurora データベースでペタバイト規模のデータを管理できるようにします。 Amazon Aurora リードレプリカを使用すると、1 つのデータベースインスタンスが提供できる上限を超えて、Aurora クラスターの読み込みキャパシティを増やせます。今回、Aurora Limitless Database によって、データベースの書き込みスループットとストレージ容量を単一の Aurora ライターインスタンスの上限を超えてスケールできるようになりました。Limitless Database に使用されるコンピューティング能力とストレージ容量は、クラスター内のライターインスタンスとリーダーインスタンスの容量とは独立して追加されます。 Limitless Database を使用することで、大規模なアプリケーションの構築に集中できます。ワークロードをサポートするために、複数のデータベースインスタンスにわたってデータをスケールする複雑なソリューションを構築、保守する必要はありません。Aurora Limitless Database はワークロードに基づいてスケーリングを行い、これまで複数の Aurora ライターインスタンスが必要だった書き込みスループットとストレージ容量を実現します。 Amazon Aurora Limitless Database のアーキテクチャ Limitless Database には、複数のデータベースノード (トランザクションルーターまたはシャード) で構成される 2 層アーキテクチャが使用されています。 シャードは Aurora PostgreSQL DB インスタンスであり、それぞれがデータベースのデータのサブセットを保存します。これによって並列処理が可能になり、書き込みスループットが向上します。トランザクションルーターは、データベースの分散性を管理し、単一のデータベースイメージをデータベースクライアントに提供します。 トランザクションルーターは、データの保存場所に関するメタデータの管理、受信した SQL コマンドの解析とシャードへの送信、シャードからのデータの集約と単一の結果のクライアントへの返信、分散トランザクションの管理による分散データベース全体の整合性の維持を行います。Limitless Database アーキテクチャを構成するすべてのノードは、DB シャードグループに含まれています。DB シャードグループには、Limitless Database リソースにアクセスするための独立したエンドポイントがあります。 Aurora Limitless Database の利用開始 Aurora Limitless Database のプレビューを利用するには、サインアップをしてください。間もなく招待されます。プレビューは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) の各 AWS リージョンにて、新しい Aurora PostgreSQL クラスターのバージョン 15 で利用可能です。 Aurora クラスターの作成ワークフローの一環として、 Amazon RDS コンソール または Amazon RDS API で Limitless Database と互換性のあるバージョンを選択します。次に、DB シャードグループを追加して、新しい Limitless Database テーブルを作成できます。また、Aurora キャパシティユニット (ACU) の最大値を選択できます。 DB シャードグループを作成したら、エンドポイントを含む詳細を [データベース] ページで確認できます。 Aurora Limitless Database を使用するには、 psql または PostgreSQL で動作するその他の接続ユーティリティを使用して、DB シャードグループのエンドポイント (Limitless エンドポイント) に接続する必要があります。 Aurora Limitless Database には、データを格納するテーブルが 2 種類あります。 シャードテーブル – このテーブルは複数のシャードに分散されています。データは、シャードキーと呼ばれるテーブル内の指定された列の値に基づいてシャード間で分割されます。 参照テーブル – このテーブルでは、すべてのデータがすべてのシャードに存在するため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。製品カタログや郵便番号など、あまり変更されない参照データによく使用されます。 シャードテーブルまたは参照テーブルを作成したら、大量のデータを Aurora Limitless Database にロードし、標準の PostgreSQL クエリを使用してそれらのテーブル内のデータを操作できます。 プレビューが公開中 Amazon Aurora Limitless Database のプレビューで、そのパワーをいち早く体験できます。 ぜひ サインアップ してお試しいただき、 AWS re:Post for Amazon Aurora または通常の AWS サポート窓口をとおしてフィードバックをお寄せください。 – Channy 原文は こちら です。

責任ある人工知能 (AI) 戦略の一環として、 Guardrails for Amazon Bedrock (プレビュー版) を使用して、ユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードを実装することで、ユーザーと生成系 AI アプリケーション間の安全なやりとりを促進できます。 AWS は、教育と科学に焦点を当てて、開発者が責任ある AI を AI ライフサイクル全体に統合できるよう支援することで、責任ある人間中心の考え方で生成系 AI を開発することに取り組んでいます。Guardrails for Amazon Bedrock を使用すると、自社のポリシーと原則に沿った適切で安全なユーザーエクスペリエンスを提供するためのセーフガードを一貫して実装できます。拒否トピックとコンテンツフィルターを定義して、ユーザーとアプリケーション間のやり取りから望ましくない有害なコンテンツを削除するのにガードレールが役立ちます。これにより、基盤モデル (FM) に組み込まれているあらゆる保護機能に加えて、より高いレベルの管理が可能になります。 Amazon Bedrock の微調整されたモデルや Agents for Amazon Bedrock を含むすべての大規模言語モデル (LLM) にガードレールを適用できます。これにより、さまざまなアプリケーションに詳細設定を適用する方法に一貫性が保たれるため、要件に基づいてユーザーエクスペリエンスを綿密に管理しながら、安全にイノベーションを進めることができます。Guardrails for Amazon Bedrock は、安全性とプライバシー管理を標準化することで、責任あるAI の目標に沿った生成系 AI アプリケーションの構築を支援します。 Guardrails for Amazon Bedrock で利用できる主な管理について簡単に説明します。 主な管理 Guardrails for Amazon Bedrock を使用すると、次のポリシーセットを定義してアプリケーションに安全対策を講じることができます。 拒否トピック — 短い自然言語による説明を使用して、アプリケーションのコンテキストでは望ましくないトピックのセットを定義できます。例えば、銀行の開発者は、投資アドバイスを提供しないように、オンラインバンキングアプリケーションのアシスタントを設定したい場合があります。 私は拒否トピックを「投資アドバイス」という名前で指定し、「投資アドバイスとは、収益の創出または特定の財務目標の達成を目的とした資金または資産の管理または配分に関する問い合わせ、ガイダンス、または推奨を指します」など、自然な言葉で説明しています。 コンテンツフィルター — 憎悪、侮辱、性的、暴力などのカテゴリーで有害なコンテンツをフィルタリングするように閾値を設定できます。多くのFMには、望ましくない有害な応答の発生を防ぐための保護機能がすでに組み込まれていますが、ガードレールを使用すると、ユースケースと責任ある AI ポリシーに基づいて、そのようなインタラクションを必要な程度にフィルタリングするための追加の管理が可能になります。フィルター強度が高いほど、フィルタリングが厳密になります。 PII リダクション (準備中) — 名前、E メールアドレス、電話番号などの個人を特定できる情報 (PII) を選択できるようになります。これらの情報は、FM が生成した応答で編集したり、PII が含まれている場合はユーザー入力をブロックしたりできます。 Guardrails for Amazon Bedrock は Amazon CloudWatch と統合されているため、ガードレールで定義されたポリシーに違反するユーザー入力や FM 応答をモニタリングして分析できます。 プレビューをお試しください 現在、Guardrails for Amazon Bedrock は、制限付きのプレビュー版でご利用いただけます。Guardrails for Amazon Bedrock にアクセスしたい場合は、通常の AWS サポートの連絡先にお問い合わせください。 プレビュー版では、Amazon Bedrock で利用できるすべての大規模言語モデル (LLM) にガードレールを適用できます。これには、Amazon Titan Text、Anthropic Claude、Meta Llama 2、AI21 Jurassic、Cohere Command が含まれます。Agents for Amazon Bedrock だけでなく、カスタムモデルでガードレールを使用することもできます。 詳細については、 Guardrails for Amazon Bedrock に関するウェブページをご覧ください。 –&nbsp; Antje 原文は こちら です。

7 月に、プレビュー版として Agents for Amazon Bedrock をご紹介 しました。現在、 Agents for Amazon Bedrock は一般公開されています。 Agents for Amazon Bedrock は、多段階のタスクのオーケストレーションによって、生成系人工知能 (AI) アプリケーション開発を加速するのに役立ちます。Agents は、基盤モデル (FM) の推論機能を使用して、ユーザーが要求したタスクを複数のステップに分解します。Agents は、デベロッパーから指示された手順に従ってオーケストレーション計画を作成します。その後、企業の API を呼び出すことと、検索拡張生成 (RAG) を使用してナレッジベースにアクセスすることによって計画を実行し、エンドユーザーに最終的な応答を提供します。この仕組みを知りたい場合は、「 高度な推論入門 」や「 RAG 入門 」など Agents に関する私の以前のブログをチェックしてください。 本日より、Agents for Amazon Bedrock には、オーケストレーションの制御の改善や思考の連鎖による推論の可視性の向上など、強化された機能も搭載されています。 目立たないところでは、Agents for Amazon Bedrock は、小売注文の管理や保険金請求の処理など、ユーザーが要求するタスクのプロンプトエンジニアリングとオーケストレーションを自動化しています。エージェントはオーケストレーションプロンプトを自動的に作成し、ナレッジベースに接続されている場合は会社固有の情報で補足し、API を呼び出して自然言語でユーザーに応答します。 デベロッパーは、新しいトレース機能を使用して、計画を実行する際に使用された推論を追っていくことができます。オーケストレーションプロセスの中間ステップを表示し、この情報を使用して問題のトラブルシューティングができます。 また、エージェントが自動的に作成するプロンプトにアクセスして変更できるため、エンドユーザーエクスペリエンスをさらに向上させることができます。この自動的に作成されたプロンプト (またはプロンプトテンプレート) を更新して、FM によるオーケストレーションと応答を改善し、オーケストレーションのより細かい制御を可能にできます。 推論手順の表示方法とプロンプトの変更方法を紹介します。 推論手順を表示 トレースにより、思考の連鎖 (CoT) と呼ばれるエージェントの推論を可視化できます。CoT トレースを使用して、エージェントがどのようにタスクを実行するかをステップバイステップで確認できます。CoT プロンプトは、 ReAct ( 推論 と 行動 の相乗効果) と呼ばれる推論技術に基づいています。ReAct と特定のプロンプト構造の詳細については、 私の以前のブログ記事「高度な推論入門」 をご覧ください。 まず、 Amazon Bedrock コンソール に移動し、既存のエージェントの作業ドラフトを選択します。次に、 [テスト] ボタンを選択し、サンプルユーザーリクエストを入力します。エージェントの応答で、 [トレースを表示] を選択します。 CoT トレースには、エージェントの推論がステップバイステップで表示されます。各ステップを開いて CoT の詳細を確認します。 可視性が向上することで、エージェントがタスクを完了するために用いた論理的根拠を理解しやすくなります。デベロッパーは、この情報を使用してプロンプト、手順、およびアクションの説明を改良し、ユーザーエクスペリエンスを繰り返しテストして改善する際のエージェントのアクションと応答を調整できます。 エージェントが作成したプロンプトを変更する エージェントは、指示された手順に基づいてプロンプトテンプレートを自動的に作成します。ユーザー入力の前処理、オーケストレーション計画、および FM 応答の後処理を更新できます。 まず、Amazon Bedrock コンソールに移動し、既存のエージェントの作業ドラフトを選択します。次に、 [高度なプロンプト] の横にある [編集] ボタンを選択します。 ここでは、4 種類のテンプレートにアクセスできます。前処理テンプレートでは、エージェントが ユーザー入力をコンテキスト化および分類する方法を定義します。オーケストレーションテンプレートでは、短期記憶、実行可能なアクションと利用可能なナレッジベースのリストとその説明、および問題を分解してこれらのアクションと知識をさまざまな順序または組み合わせで使用する方法のいくつかの例をエージェントに提供します。ナレッジベース応答生成テンプレートでは、ナレッジベースがどのように使用され、応答に要約されるかを定義します。後処理テンプレートでは、エージェントが最終応答をフォーマットしてエンドユーザーに提示する方法を定義します。テンプレートのデフォルトをそのまま使用することも、テンプレートのデフォルトを編集してオーバーライドすることもできます。 留意点 ここでは、Amazon Bedrock のエージェントを使用する際に知っておくべきベストプラクティスと重要事項をいくつか紹介します。 Agents は、特定のタスクに集中できるようにすると最高のパフォーマンスを発揮します。目的 (手順) が明確で、利用可能な一連のアクション (API) に焦点が当てられているほど、FM は適切な手順を推論して特定しやすくなります。エージェントにさまざまなタスクを任せる必要がある場合は、エージェントを別々に分けて作成することを検討してください。 その他のガイドラインは次のとおりです。 API の数 – エージェントでは 3～5 個の API を使用し、少数の入力パラメータをいくつか指定します。 API 設計 – 冪等性の確保など、API を設計する際の一般的なベストプラクティスに従います。 API 呼び出しの検証 – API 設計のベストプラクティスに従って、すべての API 呼び出しに網羅的な検証を行います。これは特に重要です。なぜなら、大規模言語モデル (LLM) は幻覚のような入出力を生成する可能性があり、これらの検証はそのような事態が発生した場合に役立つことが証明されているからです。 利用可能なリージョンと料金 Agents for Amazon Bedrock は現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。エージェントによる推論呼び出し ( InvokeModel API) に対して課金されます。 InvokeAgent API は別途課金されません。「 Amazon Bedrock の料金 」にはすべての詳細が記載されています。 詳細はこちら Agents for Amazon Bedrock の製品ページ Agents for Amazon Bedrock ユーザーガイド コンソールの Agents for Bedrock –&nbsp; Antje 原文は こちら です。

11月28日、 Amazon Bedrock で独自のデータを使用して基盤モデル (FM) をプライベートかつ安全にカスタマイズして、ドメイン、組織、ユースケースに固有のアプリケーションを構築できるようになったことを紹介できることを嬉しく思います。カスタムモデルを使用すると、会社のスタイル、意見、サービスを反映した独自のユーザーエクスペリエンスを作成できます。 微調整 では、タスク固有の独自のラベル付きトレーニングデータセットを供給することによってモデルの精度を高め、FM をさらに専門的にできます。 事前トレーニングの継続 では、カスタマーマネージドキーを使用した安全で管理された環境で、ラベルのない独自のデータを使用してモデルをトレーニングできます。事前トレーニングの継続によって、当初のトレーニングよりもしっかりした知識と適応性が蓄積されて、モデルがさらにドメイン固有のものになります。 2 つのモデルカスタマイズオプションについて簡単に説明します。 Amazon Bedrock コンソール または API を使用して、微調整ジョブや事前トレーニング継続ジョブを作成できます。コンソールで、 [Amazon Bedrock] に移動し、 [カスタムモデル] を選択します。 Meta Llama 2、Cohere Command Light、Amazon Titan の FM を微調整する Amazon Bedrock は、 Meta Llama 2 、 Cohere Command Light 、および Amazon Titan のモデル の微調整もサポートするようになりました。コンソールで微調整ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [微調整ジョブの作成] を選択します。 AWS SDK for Python (Boto3) を使用した簡単なデモを次に示します。Cohere Command Light を微調整してダイアログを要約するようにしましょう。デモの目的で、公開されている dialogsum データセットを使用していますが、これを貴社固有のデータにして構いません。 Amazon Bedrock での微調整に備えて、データセットを JSON Lines 形式に変換して Amazon S3 にアップロードしてあります。各 JSON 行には、プロンプトフィールドと完了フィールドの両方が必要です。最大 10,000 件のトレーニングデータレコードを指定できますが、数百の例で既にモデルのパフォーマンスが向上していることがわかる場合があります。 {"completion": "Mr. Smith's getting a check-up, and Doctor Haw...", "prompt": Summarize the following conversation.\n\n#Pers..."} {"completion": "Mrs Parker takes Ricky for his vaccines.Dr.P...", "prompt": "Summarize the following conversation.\n\n#Pers..."} {"completion": "#Person1#'s looking for a set of keys and asks...", "prompt": "Summarize the following conversation.\n\n#Pers..."} 簡潔にするために、プロンプトフィールドと完了フィールドを編集しました。 次のコマンドを使用して、微調整をサポートしている使用可能な基盤モデルを一覧表示できます。 import boto3 bedrock = boto3.client(service_name="bedrock") bedrock_runtime = boto3.client(service_name="bedrock-runtime") for model in bedrock.list_foundation_models( byCustomizationType="FINE_TUNING")["modelSummaries"]: for key, value in model.items(): print(key, ":", value) print("-----\n") 次に、モデルカスタマイズジョブを作成します。微調整をサポートする Cohere Command Light モデル ID を指定し、カスタマイズタイプを FINE_TUNING に設定し、トレーニングデータの Amazon S3 ロケーションを示します。必要に応じて、微調整のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "cohere.command-light-text-v14:7:4k" bedrock.create_model_customization_job( customizationType="FINE_TUNING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "1", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-summarization.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) # ジョブのステータスを確認 status = bedrock.get_model_customization_job(jobIdentifier=job_name)["status"] ジョブが完了すると、カスタムモデルの一意のモデル ID を受け取ります。微調整されたモデルは、Amazon Bedrock によって安全に保管されます。モデルをテストしてデプロイするには、 プロビジョンドスループット を購入する必要があります。 結果を見てみましょう。データセットから例を 1 つ選択し、微調整前のベースモデルと、微調整後のカスタムモデルに、次のダイアログを要約するように依頼します。 prompt = """次の会話を要約してください。\\n\\n #人物 1#: こんにちは。John Sandals という名前で予約しています。\\n #人物 2#: 身分証明書を見せていただけますか。\\n #人物 1#: はい。これです。\\n #人物 2#: どうもありがとうございます。Sandals 様、クレジットカードはお持ちですか。\\n #人物 1#: はい、もちろん。アメリカンエキスプレスでいいですか。\\n #人物 2#: 申し訳ありません。現在、私どもでは、マスターカードと VISA しか受け付けておりません。\\n #人物 1#: アメリカンエキスプレスでは駄目なんですね。 それでは、VISA もあります。\\n #人物 2#: ありがとうございます。お部屋番号は 507 で、禁煙、クイーンサイズベッドになります。よろしいですか。\\n #人物 1#: はい、結構です。\\n #人物 2#: ありがとうございます。こちらがキーになります。何かご用のときは、いつでもダイヤル 0 にお掛けください。\\n\\n Summary: """ Amazon Bedrock InvokeModel API を使用してモデルをクエリします。 body = { "prompt": prompt, "temperature": 0.5, "p": 0.9, "max_tokens": 512, } response = bedrock_runtime.invoke_model( # 微調整前の応答にはオンデマンド推論モデル ID を使用する # modelId="cohere.command-light-text-v14", # 微調整後の応答には、デプロイしたカスタムモデルの ARN を使用する modelId=provisioned_custom_model_arn, modelId=base_model_id, body=json.dumps(body) ) 微調整前の基本モデルの応答は次のようなものです。 #人物 2# は John Sandals の予約について応対しています。John は自分のクレジットカード情報を伝え、#人物 2# は、マスターカードと VISA しか受け付けないことを確認しました。John の部屋は 507 号室で、何か必要な場合は #人物 2# が対応します。 微調整後の応答は次のようなものです。短く、的を射たものです。 John Sandals は予約したホテルにチェックインしています。#人物 2 # は彼のクレジットカードを受け取って鍵を渡します。 Amazon Titan Text の事前トレーニングの継続 (プレビュー) Amazon Bedrock での事前トレーニングの継続は、現在、Titan Text Express や Titan Text Lite などの Amazon Titan Text モデルのパブリックプレビューでご利用いただけます。コンソールで事前トレーニング継続ジョブを作成するには、 [モデルのカスタマイズ] を選択し、 [継続的な事前トレーニングジョブの作成] を選択します。 次も boto3 を使った簡単なデモです。投資会社に勤務しているとしましょう。金融業界の用語に関する知識をモデルに追加するために、財務レポートとアナリストレポートで事前トレーニングを継続したいとします。デモ用に、トレーニングデータとして Amazon の株主レターのコレクションを選択しました。 事前トレーニングの継続に備えて、今度も、データセットを JSON Lines 形式に変換し、Amazon S3 にアップロードしてあります。ラベル付けされていないデータを扱っているので、各 JSON 行にはプロンプトフィールドのみが必要です。最大 100,000 件のトレーニングデータレコードを指定でき、通常は少なくとも 10 億個のトークンを供給すると有効性が確認できます。 {"input": "Dear shareholders: As I sit down to..."} {"input": "Over the last several months, we to..."} {"input": "work came from optimizing the conne..."} {"input": "of the Amazon shopping experience f..."} 簡潔にするために、入力フィールドを編集しました。 次に、データを指すカスタマイズタイプ CONTINUED_PRE_TRAINING のモデルカスタマイズジョブを作成します。必要に応じて、事前トレーニングの継続のためにハイパーパラメータを調整することもできます。 # カスタマイズしたい基盤モデルを選択 base_model_id = "amazon.titan-text-express-v1" bedrock.create_model_customization_job( customizationType="CONTINUED_PRE_TRAINING", jobName=job_name, customModelName=model_name, roleArn=role, baseModelIdentifier=base_model_id, hyperParameters = { "epochCount": "10", "batchSize": "8", "learningRate": "0.00001", }, trainingDataConfig={"s3Uri": "s3://path/to/train-continued-pretraining.jsonl"}, outputDataConfig={"s3Uri": "s3://path/to/output"}, ) ジョブが完了すると、別の一意のモデル ID を受け取ります。カスタマイズしたモデルは、Amazon Bedrock によって今度も安全に保管されます。微調整の場合と同様に、モデルをテストしてデプロイするには、プロビジョンドスループットを購入する必要があります。 留意点 知っておくべき重要な事項をいくつか次に示します。 データプライバシーとネットワークセキュリティ – Amazon Bedrock を利用すると、自らのデータを管理できるほか、すべての入力とカスタマイズは、ご利用の AWS アカウント以外には非公開のままとなります。プロンプト、完了、カスタムモデル、微調整や事前トレーニングの継続に使用されるデータなどのデータは、サービスの改善には使用されず、サードパーティのモデルプロバイダーと共有されることもありません。データは、API 呼び出しが処理される AWS リージョンに残ります。すべてのデータは、送信時および保管時に暗号化されます。 AWS PrivateLink を使用して VPC と Amazon Bedrock の間にプライベート接続を作成できます。 課金 – Amazon Bedrock では、モデルのカスタマイズ、保存、および推論に対して課金されます。モデルのカスタマイズでは、処理されたトークン数に応じて課金されます。これは、トレーニングデータセット内のトークンの数にトレーニングエポックの数を掛けたものです。エポックとは、カスタマイズ中にトレーニングデータを 1 回完全に通過することです。モデルストレージは、1 か月あたり、モデルごとに課金されます。推論は、プロビジョニングされたスループットを使用してモデルユニットごとに時間単位で課金されます。料金に関する詳細については、「 Amazon Bedrock の料金 」を参照してください。 カスタムモデルとプロビジョニングされたスループット – Amazon Bedrock では、プロビジョニングされたスループットを購入することで、カスタムモデルで推論を実行できます。これにより、長期契約と引き換えに一貫したスループットレベルが保証されます。アプリケーションのパフォーマンスニーズを満たすために必要なモデルユニットの数を指定します。カスタムモデル評価の初期段階では、プロビジョニングされたスループットを長期契約なしで時間単位で購入できます。長期契約がない場合、プロビジョニングされたスループットごとに 1 モデルユニットのクォータを使用できます。1 つのアカウントにつき最大 2 つのプロビジョニングされたスループットを作成できます。 可用性 Meta Llama 2、Cohere Command Light、および Amazon Titan Text FM の微調整サポートは、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでご利用いただけます。事前トレーニングの継続は、現在、米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンでパブリックプレビューとしてご利用いただけます。詳細については、「 Amazon Bedrock デベロッパーエクスペリエンス 」ウェブページと ユーザーガイド をご覧ください。 Amazon Bedrock で FM を今すぐカスタマイズしましょう! –&nbsp; Antje 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 re:Invent ではキーノート以外にも多数のブレイクアウトセッションが実施されましたが、Youtubeにはそのセッションの多くの録画がアップロードされています。400以上のセッション録画があがっており、観やすいように技術ジャンルごと（例えばDatabaseとかServerless等）に分けて再生リストが作られています。ぜひre:Inventのキャッチアップにご利用ください。 – AWS Events 再生リスト (Youtube) 前回もご案内したように、日本語でのre:Invent振り返りオンラインセミナーも来年開催予定です。業界カット、ソリューションカットで整理して説明しますので、ご興味がある方はぜひお申込みください。 – AWS re:Invent Recap – ソリューション編 – AWS re:Invent Recap – インダストリー編 また、1月18日(木)に実施される初心者向けセミナー「AWS Builders Online Series」のクロージングセッションでも50分間でAWS キーメッセージと主要アップデートが解説されます。こちらもご活用ください。 – AWS Builders Online Series それでは、先週の主なアップデートについて振り返っていきましょう。 2023年12月11日週の主要なアップデート 12/11(月) AWS AppConfig now supports AWS PrivateLink AWS AppConfig が AWS PrivateLink をサポートしました。これにより、インターネットゲートウェイをもたないVPC内のリソースからAppConfigのAPIにアクセスすることが可能になります。 AWS CloudShell has migrated to Amazon Linux 2023 (AL2023) 管理コンソール内から簡単に呼び出せるシェル環境 AWS CloudShell のOSが Amazon Linux 2 (AL2) から Amazon Linux 2023 (AL2023) に変更されました。既存のCloud Shell環境のホームディレクトリは維持されていますが、OSが提供するパッケージは異なりますので（例えばPython 2はサポートされなくなります）、利用の前には動作を確認いただくのが良いでしょう。詳細は こちらのドキュメント を参照してください。 AWS Lambda supports additional concurrency metric for improved quota monitoring AWS Lambda のCloudWatchメトリクスとして ClaimedAccountConcurrency が追加されました。これは、使用されたunreserved concurrency、割り当て済のreserved concurrency とprovisioned concurrencyの合計をレポートするもので、あとどれぐらい同時実行可能かを把握するために利用できます。 AWS CodeDeploy now supports application stop hooks during Amazon EC2 Auto Scaling Group scale-ins CodeDeploy は ASG (Auto Scaling Group) スケールイン中にアプリケーションの停止フック (Stop Hook)を呼び出すことができるようになりました。これによりスケールダウン時の進行中タスクの完了や、アプリケーションリソースの開放等を適切なタイミングで実行可能です。AGS インスタンスの更新操作中にもフックを呼び出すことができるため、アプリケーション稼働させながらインスタンスにパッチを適用する際にも活用可能です。 Amazon Athena now supports user identities for data access and audit Amazon Athena で AWS IAM Identity Center からの trusted identity propagation がサポートされました。これによりシングルサインオンしたユーザーの権限に基づいたクエリや、監査が可能になります。詳細は こちらのドキュメント を参照してください。 12/12(火) Introducing managed package repository support for Amazon CodeCatalyst Amazon CodeCatalyst でマネージドパッケージリポジトリが一般提供開始（GA）になりました。CodeCatalyst ユーザーが npm パッケージをセキュアに保存し、共有可能なパッケージリポジトリです。またこのレポジトリ経由でOSSのパッケージも取得可能です。詳細は こちらのドキュメント を参照してください。 Amazon MSK extends AWS IAM support to all programming languages for existing clusters Amazon Managed Streaming for Apache Kafka (Amazon MSK) のIAMサポートが、AWS SDKが動作するすべてのプログラミング言語で利用できるようになりました。これによりIAMベースでKafkaリソースへのアクセス制御が可能になります。この連携はオープンスタンダードである SASL/OAUTHBEARER ベースで実装されています。詳細は こちらのブログ をご覧ください。 12/13(水) Connect GraphQL APIs to existing MySQL and PostgreSQL databases with AWS Amplify AWS Amplify は AWS Cloud Development Kit (CDK) で作成された GraphQL API のバックエンドとしてこれまでのDynamoDBサポートに加え、既存のMySQLとPostgreSQLを利用できるようになりました。これにより既存のデータソースを活用しつつ、ウェブ/モバイルアプリ用のフロントエンド用 API レイヤーを簡単に構築できます。詳細は こちらのブログ をご覧ください。 Amazon EC2 Inf2 instances, optimized for generative AI, now available globally Amazon EC2 Inf2 インスタンスの利用可能なリージョンが拡大され、新たに東京、ムンバイ、シンガポール、アイルランド、フランクフルトリージョンで利用可能になりました。Inf2 インスタンスは、 AWS Inferentia2 アクセラレーターを内蔵した深層学習等の推論に向くインスタンスで、大規模言語モデル (LLM) やビジョントランスフォーマ向けに高いコストパフォーマンスを提供します。 12/14(木) AWS Lambda adds support for Python 3.12 AWS Lambda のマネージドランタイムおよびコンテナイメージで Python 3.12 がサポートされました。また、Amazon CloudFrontのエッジロケーションで稼働するLambda@Edgeでも同様にPython3.12が利用可能になっています。 AWS Data Exchange now supports data grants for sharing data across organizations AWS Data Exchange で data grants が一般提供開始(GA)になりました。Data Exchangeに登録したリソース(S3やRedshiftの表等)へのリードオンリーアクセスを期限付きで別のAWSアカウントに共有する機能です。Data Exchangeの管理コンソールから簡単な操作で設定が可能です。詳細は ドキュメントをご覧ください 。 AWS IoT Core allows customers to use their own CAs with fleet provisioning AWS IoT Core で、 ユーザー独自のCA (Certificate Authority)をフリートのプロビジョニングに利用可能になりました。AWS IoT にはセキュアな通信のために X.509 クライアント証明書を発行する機能がありますが、今回の機能更新により独自の公開鍵インフラストラクチャ (PKI)を利用することが可能になります。 12/15(金) Amazon Kinesis Data Firehose supports delivery of decompressed CloudWatch Logs to destinations Amazon Kinesis Data Firehose で CloudWatch Logs からの出力ファイルを展開して転送先(S3とSplunk)に連携する機能が追加されました。CloudWatch Logsのデータは初期状態でgzip圧縮されているため、連携後の処理でgzipファイルが扱えない場合は別途展開を実装する必要がありましたが、この機能によりKinesis Data Firehoseの設定だけで展開可能になります。展開処理には追加の費用が発生しますので 料金表を確認してください （現時点では日本語ページは新料金が反映されていないので、英語に変更してご覧ください）。 Amazon Linux announces support for KVM and VMWare images with AL2023.3 Amazon Linux 2023 の3回目の四半期アップデートである AL2023.3 のKVMおよびVMware用のイメージがダウンロード可能になりました。 こちらから ダウンロード可能です。AL2023.3の変更点については こちらのリリースノート を参照してください。 Amazon Connect Cases now supports creating rules for monitoring and updating your cases クラウドコンタクトセンター Amazon Connect でケース（問い合わせ）をプログラム的に管理し、エスカレーションワークフローを設定できる機能が追加されました。Amazon Connect Case のルールデザイナーでルールを設定可能です。例えば、ケースが更新されるたびにタスクを自動的に作成したり、アラートメールを送るといった自動化が可能です。また、コンタクトセンターの会話を分析するAmazon Connect Contact Lensと連携して、会話内容に応じたフォローアップタスクの設定も可能です。 今年も毎週お届けしてきた 週刊AWS は、次号(12/25予定)が年内の最終号になる予定です。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (twitter – @simosako )

概要 クラウドアプリケーションとサービスを効果的に運用するには、監視とオブザーバビリティに重点を置く必要があります。チームにとって、メトリクスの定義、キャプチャ、分析、オペレーションの可視性の確保、ログから実用的な洞察を抽出することが重要です。 多くの企業では、技術チームがインテグレーションシステムを共有して、管理するサービスやインフラストラクチャを監視しています。共有されたオブザーバビリティシステムは、組織のパフォーマンスと可用性のデータを統合します。これにより、チームはサービスとコンポーネント間の関係を視覚化できます。チームはリアルタイムのデータを利用して共同作業を行い、パフォーマンス、可用性、またはセキュリティ問題の原因を迅速に特定します。 ワークロードがさまざまなクラウドで実行されるマルチクラウド環境では、一元化されたオブザーバビリティソリューションを作成すると、アプローチがサイロ化され、複雑さが増し、直接的および間接的なコストが増加する可能性があります。マルチクラウド環境でワークロードを実行するお客様にとって、全体像を把握し、統一された方法で監視を行うことは非常に重要です。 AWS は、ハイブリッド環境やマルチクラウド環境におけるモニタリングとオブザーバビリティの改善に役立ついくつかのサービスを提供しています。これらのサービスの1つが Amazon CloudWatch で、AWS、オンプレミス、その他のクラウド上のリソースとアプリケーションの状態を監視するのに役立ちます。 この記事ではAmazon CloudWatch の機能を使い、 Azure Monitor からのメトリクスデータクエリを使用して、マルチクラウド環境のワークロードを監視する方法を紹介します。 この機能により、ハイブリッド環境やマルチクラウド環境で実行されるワークロードや、独自のカスタムデータソースを可視化できます。Amazon EC2 インスタンスと Azure 仮想マシンの両方からの CPU 使用率などのデータを同じダッシュボードでクエリして視覚化し、このデータから アラームを作成 できます。 図 1. 機能の概要 CloudWatch データソースは、メトリクスクエリを実行する AWS Lambda を利用しています。クライアントシークレットや Azure サブスクリプション ID などのリモート認証情報のストレージは、 AWS Secrets Manager によって管理されます。 AWS CloudFormation はこれをユーザーに代わってスタックとして作成します。このアプローチは拡張可能なソリューションを生み出します。メトリクスデータソースの同じフレームワークに基づいて構築されています。このフレームワークにより、 Amazon S3 の CSV ファイルのデータや、 Amazon Managed Service for Prometheus のメトリクスを CloudWatch に組み込むことができます。他のデータソースの詳細については、 ドキュメント を参照してください。 前提条件 AWS アカウントを保有していること Owner 権限を持つ Azure アカウントのサブスクリプションを保有していること ステップ 1. Microsoft Entra ID ポータルで「アプリの登録」を作成する Azure メトリクスデータを Amazon CloudWatch にインテグレーションするには、Azure テナントから「アプリの登録」を作成する必要があります。このプロセスについては簡単に説明しますが、この記事では Azure ロールベースのアクセス制御 (Azure RBAC) や特定のセキュリティとガバナンスのニーズに関する詳細は説明しません。 ここで説明するプロセスを実装する前に、必ずレビューして、セキュリティ要件を満たしていることを確認してください。この設定では、Amazon CloudWatch のサブスクリプション内のすべてのリソースへの Reader アクセスをモニタリングできることに注意してください。 クラウドアプリケーションの管理者として Microsoft Entra 管理センター にサインインします。 「ID」 メニューを選択し、次に「アプリケーション」を選択し、「アプリの登録」を選択します。 「新規登録」を選択します。 名前 (例: Amazon CloudWatch) を入力し、ユースケースに合ったテナントオプションを選択します。これはデフォルトの 「この組織ディレクトリのみに含まれるアカウント (既定のディレクトリ のみ – シングル テナント)」設定のままにします。 「登録」 を選択します。 「証明書とシークレット」メニューを選択し、「新しいクライアントシークレット」を選択します。 「説明」 と 「有効期限」 を入力します。 このシークレットは、有効期限が切れる前に AWS 側で更新する必要があることに注意してください。 「追加」を選択します。 「値」をコピーして安全に保管してください。これは、パスワードやその他のアクセストークンに似た機密性の高い文字列です。 「概要」メニューから次のフィールドをコピーします。 アプリケーション (クライアント) ID ディレクトリ (テナント) ID 「アプリの登録」を作成したら、次のステップ 2 で Azure サブスクリプションからデータを読み取る権限を付与する必要があります。 代替方法: Azure CLI を使用してアプリ登録を作成する このコマンドは、単一テナントの「アプリの登録」を作成します。 az ad app create --display-name 'Amazon CloudWatch' \ --sign-in-audience 'AzureADMyOrg' 前のコマンドから返された ID を以下の引数に置き換えます。 az ad sp create --id 'ID' 引数の ID を、以下の引数の最初のコマンドの ID に置き換えます。 az ad app credential reset --id 'ID' 出力に表示されるパスワードは、Amazon CloudWatch の設定に使用されるため、書き留めておきます。 代替方法: Azure PowerShell を使用してアプリの登録を作成する このコマンドは、単一のテナントの「アプリの登録」を作成します。 New-AzADApplication -DisplayName "Amazon CloudWatch" -SignInAudience "AzureADMyOrg" 前のコマンドから返された App_ID を以下の引数で置き換えます。 New-AzADServicePrincipal -ApplicationId "App_ID" 最初のコマンドから返された ID を以下の引数に置き換えます。 New-AzADAppCredential -ObjectId "ID" | Format-List シークレット値は Amazon CloudWatch の設定に使用されるため、書き留めておきます。 ステップ 2. ポータルで Azure サブスクリプションにアクセス許可を付与する Microsoft Azure Portal にサインインし、グローバル検索ボックスで 「サブスクリプション」を検索します。 Amazon CloudWatch とインテグレーションしたいサブスクリプションを選択します。 メニューから「アクセス制御 (IAM)」を選択し、次に「追加」を選択し、「ロールの割り当ての追加」を選択します。 リストから「Monitoring Data Reader」を選択し、「次へ」を選択します。 「メンバーを選択する」を選択し、「アプリの登録」の名前を入力します。 名前を入力するまでリストに表示されない場合があることに注意してください。「アプリの登録」の名前を選択し、「選択」をクリックします。 最後に、「次へ」を選択し、「レビューと割り当て」を選択します。 これらの権限が適用されていることを確認するには、サブスクリプション内の他のリソース (仮想マシンなど) の IAM ページを確認してください。 代替方法: Azure CLI を使用して Azure サブスクリプションにアクセス許可を付与する 以下のコマンドの Subscription_ID をサブスクリプションに置き換え、app_ID を上記で使用した az コマンドの出力に置き換えます。 az role assignment create --role 'Monitoring Data Reader' \ --scope '/subscriptions/Subscription_ID' --assignee 'app_ID' 代替方法: Azure PowerShell を使用して Azure サブスクリプションにアクセス許可を付与する New-AzADServicePrincipal コマンドから返された ID を下の引数に置き換え、Subscription_ID をサブスクリプションに置き換えてください。 New-AzRoleAssignment -ObjectId "Id" -Scope "/subscriptions/Subscription_ID" -RoleDefinitionName "Monitoring Data Reader" ステップ 3: Azure からメトリクスデータを読み取るように CloudWatch を設定する まず、CloudWatch コンソールの左側のナビゲーションで「設定」を選択し、次に「メトリクスのデータソース」を選択します。 図 2. CloudWatch サービスの設定ページ 次に、「データソースを作成」、「Azure Monitor」、「次へ」 の順に選択します。 図 3. メトリクスデータソースのリストから Azure Monitor 選択 データソースに名前を付けます。この名前は、作成された CloudFormation スタックの名前として表示されることに注意してください。Directory (tenant) ID、Application (client) ID、およびシークレットデータを入力し、「データソースを作成」を選択します。 図 4. Azure アプリの認証情報を使用して新しいデータソースを構成する CloudFormation へのリンクを辿ることで、スタックの進行状況を確認できます。通常、このプロセスは 2 分以内に完了します。Prometheus や Amazon RDS などの他のメトリクスデータソースでは、オプションで VPC 内に Lambda 関数を作成できます。これにより、プロビジョニング時間が 1 ～ 2 分長くなる場合があります。この画面が表示されたら、インテグレーションは完了です。 図 5. CloudWatch の完成したインテグレーションページ ステップ 4. Azure 環境のデータを視覚化する CloudWatch を使用して Azure Monitor にメトリクスデータのクエリを実行できるようになりました。「CloudWatch メトリクスを開く」ボタンをクリックするか、左側のナビゲーションメニューで「すべてのメトリクス」を選択し、次に「マルチソースクエリ」を選択して、ドロップダウンでデータソース名を選択します。 図 6. マルチソースクエリのコンソールの図 サブスクリプション、リソースグループ、その他のフィールドを選択します。CloudWatch は、AWS アカウントと同様に Azure サブスクリプションを監視するようになりました。 図 7. CloudWatchを使用して Azure VM の CPU を視覚化 このインテグレーションがどのように機能するかについて一言 – Azure Monitor (CloudWatch の他のメトリクスデータソースタイプと同様) は CloudWatch に永続化されません。そのため、CloudWatch は Azure のデータにアクセスする際にオンデマンドで Azure にクエリを実行します。これは CloudWatch アラームにも当てはまります。CloudWatch アラームも同様に、アラーム評価ごとに十分なデータポイントをクエリして、アラート条件が満たされているかどうかを確認します。メトリクス Lambda に対応するロググループで、すべてのクエリの詳細を確認できます。 よくある問題のトラブルシューティング Lambda はメトリクスデータソースインテグレーションのクエリを実行するために使用され、ログは CloudWatch Logs に保存されます。ロググループは、設定のエラーを見つけるために利用できます。 最もよく見られるエラーと、解決方法に関する注意事項は次のとおりです。 エラーメッセージ： INFO Sending response: { Data: [], SubscriptionIds: [] } これは、Azure IAM が権限を適用しておらず、Lambda が Azure からのサブスクリプションを列挙できないことを示しています。正しいサブスクリプションでステップ 2 が完了していることを確認してください。 エラーメッセージ： INFO An error occurred: RestError: Commonly allowed time grains:... すべてのメトリクスデータソースのタイプがこの機能をサポートしているわけではありません。ストレージアカウントの使用状況メトリクスなど、Azure Monitor に集約される頻度が低いデータを表示しようとすると発生する場合があります。これは、あまり頻繁に入力されないメトリクスでは予想される動作です。詳細については、Azure Monitor API のドキュメントをご覧ください。 エラーメッセージ： INFO An error occurred: AuthenticationRequiredError: invalid_client ensure your credentials are correct これは通常、AWS Secrets Manager に間違った認証情報が保存されていることが原因です。テナント ID、アプリケーション ID、シークレット値が正しいことを再確認してください。CloudFormation スタックを再作成しなくても、これらの値を AWS Secrets Manager で直接変更できます。 インテグレーションを次のレベルへ ハイブリッドおよびマルチクラウドの監視およびオブザーバビリティソリューションは、クラウド運用を監視するための強力なメカニズムです。CloudWatch をソリューションの中心的なコンポーネントとして使用することで、これらの機能を自動化し、拡張機能を使用して付加価値を高めることができます。最も強力な方法の 1 つは、Azure 環境内のメトリクスデータに基づいてアラームを作成することです。CloudWatch アラームは、管理者へのページ送信、JIRA チケットの作成、サーバーの再起動、フェイルオーバーの開始など、あらゆる自動ワークフローをトリガーできます。 CloudWatch は 1 つ以上のクラウド環境で問題が発生したときにアラートを出す、複合アラームを作成できます。Azure と AWS の両方で動作するワークロードがあり、両方のプロバイダーにデプロイすると機能停止が発生することを考えてみましょう。クラウド環境全体の HTTP エラーの総数に基づく複合アラームを使用し、アクションをトリガーします。これらはすべて、Azure と AWS の両方で作成されたクラウドネイティブなメトリクスに基づいています。ユースケースによっては、環境ごとにアラームを分けるよりもこの方が適している場合があります。 コストと削除 CloudWatch で外部メトリクスデータソースを使用しても追加料金は発生しませんが、Lambda、Secrets Manager、CloudWatch Logs、および CloudWatch アラームの使用には標準料金がかかります。 Azure Monitor API からデータを取得する場合の料金の詳細については、Azure のドキュメントを参照してください。 ステップ 3 で作成した CloudFormation スタックを削除するだけで、インテグレーションを解除できます。これにより、Lambda 関数とシークレット情報が Secrets Manager から削除されます。 まとめ CloudWatch を使用してマルチクラウドのオブザーバビリティソリューションを作成すると、さまざまな環境のメトリクスを視覚化してアクションを実行できます。アラーム、ダッシュボード、 Metric Math などの CloudWatch の機能を使用すると、高度なクエリを作成して、サイロ化されたオペレーションデータを解放し、複数のクラウドプロバイダーを使用する際の複雑さに対処する時間を短縮できます。この機能を使用することで、AWS から外部のメトリクスデータにアクセスしてアクションを実行できるため、CloudWatch はメトリクスデータを運用するための中心的な役割を果たします。 著者について Rich McDonough Rich McDonough は、Amazon Web Services (AWS) のPrincipal Technologist です。IT業界で20年以上の経験を持つ彼は、ディレクター、アーキテクト、DevOpsの役職を歴任し、スタートアップの分野でスキルを磨きました。主なフォーカスエリアは、バックエンド開発、DevOps プラクティスの作成、デジタルネイティブビジネスのクラウド移行でした。現実世界のビジネス上の問題に対処し、AWS サービスの運用を加速させる拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築できるようお客様をサポートしている同氏は、「オペレーションエクセレンスに理不尽なほど情熱を注いでいる」のです。Rich は、ワークショップの講師、講演、AWSの顧客のためのソリューション開発を楽しんでいます。 Aidan Keane Aidan Keane は AWS の Senior Specialist Solutions Architect で、Microsoft ワークロードを専門としています。彼はテクノロジー業界で25年間働いており、テクノロジーに情熱を注いでおり、顧客向けの新しい技術ソリューションの構築と探求を楽しんでいます。仕事以外では、ゴルフ、サイクリング、リバプールFCに情熱を注ぐ熱心なスポーツ愛好家です。彼は家族との充実した時間を楽しんでいるほか、アイルランドやペルーへ旅行しています。 Aviad Tamir Aviad Tamir は、金融サービス業界向けのソリューションを専門とする AWS の Senior Solutions Architect です。彼はテクノロジー業界で25年間にわたり、新興企業と大企業の両方で働いてきました。彼はオープンソースの哲学、知識の共有、より良いソフトウェアの構築が好きです。 翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文は こちら です。