Solution Architect Empowerment Team (SET) は、AWS Worldwide Specialist Organization (WWSO) 内の部門で、1,600 人のスペシャリストソリューションアーキテクトにサービスを提供しています。その主力プロダクトである OZONE は、次の 4 つの主要分野でこれらのアーキテクトを支援するために設計された、データドリブンエンパワーメントフレームワークです。 Amazon の顧客重視の価値観に則った重要な顧客活動へのフォーカス 生産性と効率性の最大化 アーキテクトの活動が AWS の顧客とサービス利用に与えたインパクトの可視化 リーダーがデータを用いて迅速で影響力のある意思決定を行うための支援 SET はさまざまな部門のさまざまな社内パートナーと協力して、専用のデータインテリジェンスツールを開発しています。これらのツールは、ソリューションアーキテクトのリーダーや関係者により早く、より価値のあるインサイトを活用できるようにすることで、広範なチームが相対するお客様の体験向上に役立ちます。 このブログ記事では、SET がインサイト配信環境を Amazon QuickSight に移行して、コスト削減とスケーラビリティを実現した方法について説明します。 様々なデータ、複雑な計算、パフォーマンスに関する課題 OZONE は、顧客エンゲージメント、トレーニングなどさまざまな AWS ソースからのデータを使用し、スペシャリストソリューションアーキテクトにデータドリブンのインサイトを提供するサービスです。 これらの強力なインサイトを提供するために、OZONE は、データセットの統合、複雑なクエリの実行、カスタム計算と視覚化を備えたダッシュボードの提供が可能な、強力なビジネスインテリジェンス (BI) ツールで動作させる必要がありました。 特に、クエリ、分析、複雑な計算の実行には各々のデータセット (200 GB 以上) を利用する必要があり、作業で利用している大規模で分散した多くのデータソースに対応したいと考えていました。データの利用にあたっては、データ収集・加工のパイプラインを介して追加のデータを取り込む必要があったため、既に保持しているクラウド資産との連携や統合も重要でした。そして、機械学習を使用してデータ分析を強化し、パターンを検出し、インサイトを得るまでの時間を短縮するなど、よりインテリジェントな方法でこれらのデータを使用できるようにしたいと考えていました。 さらに、ビジュアルのレンダリング時間短縮は優先度の高い課題でした。以前の BI ツールではダッシュボードの読み込み時間が遅く、前払いのライセンスモデルを使用していたため、より広範なユーザーに対してセルフサービス分析を提供することが困難でした。 これらすべてを念頭に置き、BI のニーズに応える代替ツールを探す時が来たと判断しました。理想的には、大規模利用でも費用対効果が高く、既存のクラウド技術スタックとうまく統合でき、より高度なデータモデリングと分析が可能なものです。 Amazon QuickSight によりBI の摩擦を軽減し、高度な機能を有効化する 新しい BI ツールを探すとき、私たちはいくつかの重要なニーズを念頭に置いていました。コスト削減や他の分野での改善が実現でき、なおかつ手頃な価格で拡張できる分析ソリューションが理想です。 2022 年 8 月、私たちは OZONE ダッシュボードを QuickSight に移行することを決定し、次のことが可能になりました。 ユーザーベースのライセンスコストからの脱却 より複雑な計算や高度な分析が可能なダッシュボードの構築 OZONE の幅広いユーザーへの公開 データパイプライン用のクラウド技術スタック ( Amazon S3 、 Amazon DynamoDB 、 AWS Glue 、 Amazon Redshift など) を活用 Amazon QuickSight Q のような高度な機能を導入、会話機能やその他の次世代機能を有効化 重要なビジネスインサイトをより早く、より確実に提示 QuickSight はデータウェアハウス向けの Amazon Redshift など他の AWS サービスと統合されており、シームレスなデータフローとより効率的な分析パイプラインの構築が可能になりました。 また、目標設定方法論 (目標や主要な結果など) に関するさまざまなビジネスユースケースを実装することもできました。KPI とメトリクスを設計し、組織、チーム、機能レベルにおける戦略的ビジネス目標に対するほとんどの進捗状況を測定することが可能です。これらの指標には、ソリューションアーキテクトのアクティビティ、Salesforce の商談価値、営業サイクルの長さ、商談勝率、製品価値、ソリューションアーキテクトのエンゲージメントメトリクスなどが含まれます。これらの洞察により、OZONE はベースライン、データトレンド、予測、What-if 分析などのデータモデルをサポートし、ソリューションアーキテクトのリーダーシップによる、より多くの情報に基づいたビジネス上の意思決定を可能にします。 OZONE Reflections / Insights ダッシュボード 私たちの OZONE エンパワーメントフレームワークは、関係者がより良い意思決定を行うために必要な深いインサイトを得られるようにするもので、「Reflections」と「Insights」という 2 つの主要なダッシュボードで構成されています。私たちは QuickSight を使用し、これらのダッシュボードをわずか 3 か月で導入することができました。 これらの高度にインタラクティブなダッシュボードにより、ユーザーはビジュアルをドリルダウンし、フィルターを適用し、分析を探索することで、より深い洞察を得ることができます。また、QuickSight にはさまざまな組み込みの視覚化オプションがあり、これらのインサイトやレポートを簡単にカスタマイズすることができます。 OZONE Reflections は、スペシャリストソリューションアーキテクト、およびソリューションアーキテクトのリーダーシップに対し、自分たちの取り組みが顧客にどのような変化をもたらすかをより明確に把握するために必要なツールを提供します。このダッシュボードでは、ソリューションアーキテクトのアクティビティをドメイン、チーム、各ソリューションアーキテクトの各レベルで分析し、定義された大目標の達成状況を確認することができます。また、アクティビティ状況から予測されるペースを計算して、ソリューションアーキテクト、チーム、ドメインが定義した目標に対してどの程度進捗しているかを把握することもできます。関係者はドメインレベルのインサイトについては Domain Reflection ダッシュボード、チームレベルのインサイトについては Team Reflection ダッシュボード、ソリューションアーキテクトレベルのインサイトについては Solution Architect Reflection ダッシュボードを参照することが可能です。 OZONE Insights は、WWSO ソリューションアーキテクトのリーダーが主要なビジネス目標の達成におけるドメインの有効性判断を可能とするための KPI とメトリクスをダッシュボードとして提供します。 このインサイトはソリューションアーキテクトの影響を測定する上でも不可欠となっており、顧客エンゲージメントや、顧客の成果を促進するその他のドメイン固有の活動への参加状況を測定することによって行われます。ダッシュボードには 5 つの主要なビジネス指標が示されています：[1] スペシャリストソリューションアーキテクトのエンゲージメント率とその商談が月間経常収益に与える影響、[2] スペシャリストソリューションアーキテクトの関与した商談の勝率と商談のサイクルタイムに与える影響、[3] トップスペシャリストソリューションアーキテクトのドメインアクティビティ、[4] どのステージで商談に参加しているか、 [5] スペシャリストの参加によって影響を受ける顧客の数 OZONE の QuickSight ダッシュボードは、AWS 財務チームが管理している Amazon Redshift クラスターからデータを取得します。複数のデータソースを利用して顧客とアカウントのデータを取得することで、ダッシュボードは顧客向けアクティビティの主要なメトリクスと KPI に関する情報をユーザーに提供できます。 OZONE は、Web アプリケーションポータルを介して、ドメイン、チーム、および機能レベルのスペシャリストソリューションアーキテクトチームからの情報を収集するため、データの消費者であると同時に作成者でもあります。私たちのデータパイプラインは Amazon DynamoDB、AWS Glue、および Amazon S3 を使用して構築されており、Amazon Redshift クラスターに統合されています。このアップストリームデータについては、ETL と airflow を介して夜間更新のサイクルを維持しています。そうすることで、QuickSight においてダッシュボードを作成する際に、常に最新のデータセットを使用し続けることができます。 以下の図は、OZONE の技術アーキテクチャと、Web アプリケーションから QuickSight へのデータフローを示しています。 また、 埋め込み分析 にも QuickSight を使用しています。QuickSight の埋め込み機能により、一元管理された Web アプリケーションポータルである OZONE Intelligence Suite にインタラクティブなダッシュボードを埋め込むことができました。 このツールにより、利用者に対して単一のビュー、つまり、ビジネスへのインパクトとソリューションアーキテクトのパフォーマンスに関するインサイトを得るのに役立つ統合データエクスペリエンスを提供することができます。 スペシャリストソリューションアーキテクト向け BI ユーザーエクスペリエンスの強化 QuickSight の様々な利点により、スペシャリストソリューションアーキテクトリーダーのユーザーエクスペリエンスが強化されました。 より高速なインサイトの獲得 QuickSight を使用すると、さまざまなデータソースを統合、分析や視覚化のための複雑な計算を準備といった時間のかかるタスクを削減し、より迅速にインサイトを得ることができます。QuickSight の活用はユーザーの時間を大幅に節約する結果に繋がりました。Amazon Redshift は、分析に必要なデータモデルを構築し QuickSight に接続して分析を行う際に役立っています。多くの Amazon Redshift データレイクのデータを簡単に結合し、分析用のデータモデルを作成できます。 より素早いデータ統合とユーザーエクスペリエンス OZONE の SPICE モードは 5,000 万件を超えるレコードの消費を加速します。SPICE の共通部分式除去 (CSE) 機能によりクエリが最適化されることでダッシュボードの読み込みや複雑な計算の結果が速くなり、全体的なユーザーエクスペリエンスが向上します。 アクセシビリティとスケーラビリティの向上 QuickSight の拡張性により、WWSO 組織内の 1,600 人のスペシャリストソリューションアーキテクト全員が、パフォーマンスに影響を与えることなく複数のデータセットに同時にアクセスできます。これにより、OZONE の提供範囲を現在のユーザーベースを超えて拡大することも可能になりました。 より速く、より自然なレポート作成とデータ視覚化 OZONE は QuickSight のオートナラティブ機能を使用しています。オートナラティブ機能は、分析の簡単な要約を説明分の形式で提供します。これにより、スペシャリストソリューションアーキテクトのリーダーは重要なインサイトを簡単に抽出し、定期的なビジネスアップデートに役立てることができます。こうした自動化された説明文はスペシャリストソリューションアーキテクトの与えるインパクトに焦点を当てているため、ビジネスレビューの文書やレポートに直接コピーできます。OZONE のダッシュボードでは、時系列データを使用したトレンドの視覚化や比較分析もサポートされており、これらの説明をさらにわかりやすいものにしています。 Q を利用した自然言語クエリ OZONE は QuickSight Q を通じて、スペシャリストソリューションアーキテクトのリーダーからの質問を解釈し、カスタムビジュアルを生成、データインサイトを迅速に得ることができます。基礎となる OZONE データセットの Q トピックは、回答精度を向上させるようにトレーニングされており、エンドユーザーは Reflections ダッシュボードではカバーされていないビジネス上の質問への回答を得ることができるようになっています。 全体的として、QuickSight は開発プロセスを合理化し、さまざまなデータセットにわたる重要なデータインサイトを統合し、スペシャリストソリューションアーキテクトのリーダーが大規模なデータをもとにタイムリーな意思決定を行えるようになりました。 OZONE チームと QuickSight チームとのコラボレーションにより、読み込み時間が短縮され、クエリ時間が最適化された、パフォーマンス効率の高いビジネスインテリジェンスダッシュボードが生まれ、ユーザーエクスペリエンスの向上を実現することができました。また、スペシャリストソリューションアーキテクトが AWS サービスの採用やさまざまなビジネスセグメントにわたるカスタマージャーニーへの影響を測定できるようになったことで、WWSO ソリューションアーキテクト組織内の運用効率が向上しました。 QuickSight ダッシュボードは美しく見えます。また、以前のツールよりも読み込みがはるかに高速です。全体として、ダッシュボードは非常に便利で、満足しています。チームのすべてのソリューションアーキテクトへの伝道はすでに始まっています 。 — WWSO SA リーダー QuickSight をはじめましょう ZONE チームでは QuickSight への移行により、組織全体にわたるデータ統合とインサイトの提供を改善することができました。 QuickSight の採用により、サービスの提供コストをはるかに抑えながら、これまで以上に多くのことを行えるようになりました。また、同時に ML 対応の分析や自然言語クエリなど、これまで以上に魅力的な高度な機能を簡単に試すことも可能になりました。 QuickSight がお客様のビジネスの費用対効果、プロセス効率、インサイト提供の向上にどのように役立つかについて、詳しくは Amazon QuickSight をご覧ください。 記事の翻訳は Solutions Architect 宮﨑 太郎が担当しました。原文は こちら です。

2023 年 7 月: この投稿の内容について正確性の確認をしました。 私たちのお客様の多くは、大規模なミッションクリティカルな SQL Server データベースに Amazon Relational Database Service (Amazon RDS) for SQL Server を使用しています。お客様は、Amazon RDS for SQL Server における大規模なデータベースを保護するための最適なソリューションを求めています。これにより、データ損失の許容範囲であるリカバリポイント目標 (RPO) と、サービスの中断からサービスの復旧までの最大許容遅延時間であるリカバリ時間目標 (RTO) の要件を満たすことができます。 データベース管理者の責任の 1 つは、会社のデータを保護することです。Amazon RDS for SQL Server には、データのバックアップとリストアに役立つ 複数のオプション があります。Amazon RDS for SQL Server を使用して大規模データベースのバックアップ戦略を立てる際には、次の点を考慮する必要があります。 データベースのサイズはどのくらいなのか？ RDS DB インスタンス上の個々のデータベースまたは複数のデータベースのどちらをリストアするのか? バックアップとリカバリの戦略には、リージョン内および リージョン間の保護 が必要なのか? 通常、Amazon RDS for SQL Server のデータを保護するには、自動バックアップまたは 手動スナップショット の使用、 AWS Backup 、 ネイティブバックアップとリストア 、またはその組み合わせなど、複数の方法から選択できます。ただし、(5 TB を超える) 大規模な SQL Server データベースを管理すると、何テラバイトもの情報が含まれることがあり、面倒な場合があります。 この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースの 2 つのバックアップとリストアのオプションについて説明します。 ネイティブバックアップ/リストアアプローチ Amazon RDS は SQL Server データベースの ネイティブバックアップとリストア をサポートしています。RDS for SQL Server データベースのフルバックアップを作成し、そのファイルを Amazon Simple Storage Service (Amazon S3) に保存できます。その後、そのバックアップファイルを既存の RDS for SQL Server DB インスタンスにリストアできます。このバックアップファイルをオンプレミスサーバーまたは別の RDS for SQL Server DB インスタンスにリストアすることもできます。 SQL_SERVER_BACKUP_Restore オプショングループ を追加することで、Amazon RDS for SQL Server の ネイティブ SQL バックアップとリストア を有効にできます。 次の図は、ネイティブバックアップおよびリストアソリューションのアーキテクチャを示しています。 前提条件 始める前に、次の前提条件が必要です。 Amazon RDS for SQL Server インスタンス Amazon RDS for SQL Server へのアクセス許可 を持つ S3 バケット データベースを複数のバックアップファイルにバックアップする 次のコマンドを使用して、RDS for SQL Server データベースのネイティブバックアップを実行します。 exec msdb.dbo.rds_backup_database @source_db_name='database_name', @s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name.extension', [@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'], [@overwrite_s3_backup_file=0|1], [@type='DIFFERENTIAL|FULL'], [@number_of_files=n]; @number_of_files は、バックアップが分割 (チャンク) されるファイルの数を示します。最大数は 10 です。 複数ファイルへのバックアップは、フルバックアップと差分バックアップの両方でサポートされています。値 1 を入力するかパラメータを省略すると、単一のバックアップファイルが作成されます。 大規模なデータベースのバックアップを生成する場合は、バックアップファイルを複数に分割して生成することをお勧めします。このプロセスにより、バックアップの生成時間が短縮されます。ビジネス要件が Amazon S3 から大規模なデータベースのバックアップをダウンロードすることである場合、複数のバックアップファイルをダウンロードする方が 1 つの大きなバックアップファイルをダウンロードするよりも高速です。 次のスクリプトは、gp2 ストレージと r5b.4xlarge インスタンスを使用してサンプルの RDS for SQL Server データベース (10 TB) を単一のバックアップファイルにバックアップします。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBSingleFile.bak' , @overwrite_s3_backup_file=1; 単一のバックアップファイルを使ったとき、個々の Amazon S3 オブジェクト のサイズは最小 0 バイトから最大 5 TB までの範囲であるためバックアップは次のエラーで失敗しました。 “[2022-09-09 13:26:22.083] タスクの実行が開始されました。 [2022-09-09 13:26:22.300] タスクの失敗または RDS 自動バックアップの優先バックアップウインドウとの重複のため、タスクが中止されました。 [2022-09-09 13:26:22.303] タスクは中止されました [2022-09-09 13:26:22.310] S3 にアップロードするための 524288000 バイトを超える S3 チャンクを生成できません。” この制限を回避するために、データベースを複数のファイルにバックアップする別のアプローチを採用します。この方法は、RPO と RTO を削減するためにも推奨されます。 4 つのバックアップファイルを使用して同じスクリプトを実行できます。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBMultiFile*.bak' , @number_of_files=4; 次のスクリーンショットに示すように、バックアップは正常に完了しました。 さまざまなデータベースサイズで同様のテストを実行しました。 たとえば、5 TB データベースの単一ファイルのバックアップを作成するには、次のコマンドを使用します。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak' , @overwrite_s3_backup_file=1; 次のスクリーンショットはバックアップを実行した結果を示しています。 1 つのファイルを使用した 5TB データベースのバックアップは 602 分で完了しました。 複数のバックアップファイルからデータベースをリストアする 単純なスクリプトをプロシージャとして作成、コンパイルして、それを T-SQL ツールとして使用することで大きなデータベースバックアップファイルをいくつかの小さなファイルに分割できます。 バックアップファイルからデータベースをリストアするには、 restore Database コマンド用のすべてのバックアップファイルが必要であることに注意してください。 この手順は、SQL Server バージョン 2014 以降で機能します。 複数ファイルのバックアップを使用して 10 TB データベースをリストアするには、次のリストアコマンドを使用します。アスタリスク (*) は、S3 ARN の file_name 部分のどこにでも使用できます。アスタリスクは、生成されたファイル内で一連の英数字の文字列に置き換えられます。 exec msdb.dbo.rds_restore_database @restore_db_name= 'TPCC' , @s3_arn_to_restore_from= 'arn:aws:s3:::sqlbackup-tpcc/backup/10TB/TPCC10TBbackup*' ; 次のスクリーンショットは、リストアが 470 分で正常に完了したことを示しています。 次のリストアコマンドを使用して、単一のデータベースファイルバックアップを使用して 5 TB データベースをリストアします。 exec msdb.dbo.rds_restore_database @restore_db_name= 'TPCC' , @s3_arn_to_restore_from= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak' ; 次のスクリーンショットは、リストアが 1008 分で正常に完了したことを示しています。 テスト結果 次の表は、r5b.4xlarge インスタンスを使用して Amazon RDS for SQL Server のさまざまなデータベースサイズで実行されたテストをまとめたものです。 1 TB および 5 TB のデータベースサイズのバックアップとリストアにかかる時間は、単一ファイルと比較して 4 つのマルチファイルを使用することで改善されることがわかりました。 1 つのファイルで S3 にアップロードできる最大オブジェクトは 5 TB であるため、現時点では 5 TB を超えるデータベースサイズ (例: 10 TB) を 1 つのファイルでバックアップおよびリストアすることはできません。 Test Instance Activity Type Single File (minutes) Four Files (minutes) Performance Improvement (%) 1 TB (gp2, 3 TB storage allocated) Backup 151 56 62.91 1 TB (gp2, 3 TB storage allocated) Restore 200 57 71.50 1 TB (i01-40000 IOPS) Backup 140 52 62.86 1 TB (i01-40000 IOPS) Restore 154 54 64.93 5TB (gp2, 10 TB storage allocated) Backup 602 235 60.96 5TB (gp2, 10 TB storage allocated) Restore 1008 291 71.23 5 TB (io1-40000 IOPS) Backup 601 212 64.73 5 TB (io1-40000 IOPS) Restore 991 208 79.01 10TB (gp2,16TB storage allocated) Backup N/A 663 N/A 10TB (gp2,16TB storage allocated) Restore N/A 681 N/A 10 TB (io1-40000 IOPS) Backup N/A 590 N/A 10 TB (io1-40000 IOPS) Restore N/A 470 N/A 影響を確認するために、バックアップファイルの数を 8 に増やして同様のテストを実行しました。 exec msdb.dbo.rds_backup_database @source_db_name= 'TPCC' , @s3_arn_to_backup_to= 'arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB8files*' , @number_of_files=8; この特定のインスタンスでは、テストしたインスタンスサイズで 4 つのバックアップファイルを使用した場合と比較して、結果にタイミングの違いはありませんでした。 最適なファイル数 はインスタンスのサイズによって異なります。たとえば、インスタンスに 32 vCPU がある場合、インスタンスを 8 つのファイルに分割する方が 4 つのファイルよりも高速になります。 スナップショットアプローチ Amazon RDS for SQL Server では、自動バックアップに加えて 手動スナップショット を取得できます。これらは DB インスタンスのストレージボリュームスナップショットであり、個々のデータベースだけでなく DB インスタンス全体をバックアップします。スナップショットバックアップにかかる時間は、DB インスタンスのサイズとクラスによって異なります。このテストでは、r5b.4xlarge インスタンスを使用しました。 私たちが気づいた興味深い結果の 1 つは、16 TB のストレージが割り当てられた 10 TB のデータベースの場合、最初の手動スナップショット (バックアップ) に約 11 時間かかったということです。ただし、スナップショットからのリストアにはわずか 23 分しかかかりませんでした。これは、データベースの RTO を短縮するのに役立ちます。 データベースインスタンスの最初のスナップショットには、データベースインスタンス全体のデータが含まれています。同じデータベースインスタンスの後続のスナップショットは増分です。つまり、最新のスナップショットの後に変更されたデータのみが保存されます。 最初の手動スナップショットの後、次のスナップショット取得にかかる時間はわずか 5 分、リストア時間は 20 分でした。スナップショットによるリストアアプローチは、他のデータベースの RPO と RTO を短縮するのにも役立ちます。 リストアされたデータベースインスタンスのステータスが利用可能になるとすぐに使用できます。 DB インスタンスはバックグラウンドでデータの読み込みを続けます。これは遅延読み込みとして知られています。迅速なアクセスが必要なテーブルに対する遅延読み込みの影響を軽減するには、 SELECT * などのテーブル全体のスキャンを伴う操作を実行できます。これにより、RDS for SQL Server インスタンスはバックアップされたテーブルデータを Amazon S3 からダウンロードできるようになります。 次の表は、初期スナップショットバックアップとリストアに関する調査結果をまとめたものです。 Test Instance Activity Type Duration (Minutes) 1 TB (gp2, 3 TB storage allocated) Snapshot_Backup 109 1 TB (gp2, 3 TB storage allocated) Snapshot_Restore 16 5 TB (gp2, 10 TB storage allocated) Snapshot_Backup 480 5 TB (gp2, 10 TB storage allocated) Snapshot_Restore 20 10 TB (gp2, 16 TB storage allocated) Snapshot_Backup 635 10 TB (gp2, 16 TB storage allocated) Snapshot_Restore 23 後片付け この投稿のリソースの使用が終了したら、不要な料金が発生しないように AWS リソースをクリーンアップしてください。具体的には、このテストで使用した RDS for SQL Server インスタンスと S3 バケットからすべてのオブジェクトを削除します。 結論 この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースを最小限の RTO と RPO でバックアップおよびリストアする方法に関する 2 つのアプローチについて説明しました。まず、SQL Server のネイティブバックアップを使用して複数のファイルにバックアップとリストアを最適化する方法を説明しました。この方法は、単一ファイルにバックアップする場合と比較して、バックアップ時間とリストア時間を短縮するのに役立ちます。次に、手動スナップショットのアプローチとパフォーマンステストから得られた結果を示しました。 著者について Yogi Barot は、AWS のマイクロソフトスペシャリストプリンシパルソリューションアーキテクトです。さまざまな Microsoft テクノロジを扱った 22 年の経験があり、専門は SQL Server およびさまざまなデータベース テクノロジです。 Yogi は、AWS での Microsoft ワークロードの実行に関する深い AWS の知識と専門知識を持っています。 Vikas Babu Gali は、アマゾンウェブサービスの Microsoft ワークロードを専門とするシニアスペシャリストソリューションアーキテクトです。インド出身の Vikas は、クリケットをしたり、屋外で家族や友人と時間を過ごすことを楽しんでいます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。

生成系 AI は、多くの企業にとって関心のある分野です。 Gartner は、2024 年までに、エンタープライズアプリケーションの 40% に会話型 AI が組み込まれると予測しています。2020 年には、この数字は 5% 未満でした。AWS では、さまざまなビジネスセグメントで生成系 AI をどのように使用できるかお客様から頻繁に聞かれます。カスタマーエクスペリエンス (CX) は特に大きな関心を集めている分野です。 この 3 部構成のブログ投稿シリーズの 第 1 部 では、生成系 AI とは何か、それが CX の状況をどのように変えているか、そしてそれがもたらすビジネス成果について説明しました。また、 Amazon Connect による 生成系 AI の活用例のデモ も紹介しました。 シリーズの第2部では、ビジネス上の課題を解決するために、他の方法と比較してどのような場合に生成系 AI を使用すべきかに焦点を当てます。また、問題提起から逆算して、ユースケースに適用できる最適なテクノロジーの決定をお手伝いします。 顧客体験の向上に向けた大規模言語モデル (LLM) の適用 ほとんどの LLM は、 基盤モデル (FM) を使用して構築されています。 FM は、広範囲にわたる一般化されたデータとラベル付けされていないデータに基づいてトレーニングされます。FM は、言語の理解、テキストや画像の生成、自然言語での会話など、さまざまな一般的なタスクを実行できます。FM は、他のモデルを構築するための基盤となります。また、FM 自体を直接使用することもできます。 LLM で作成された出力は、まるで人間が書いたかのように見えるため、カスタマーエクスペリエンスアプリケーションにおける人間とテクノロジーのインターフェースとして理想的です。ただし、他のテクノロジーと同様に、生成系 AI の使用には賛否両論があります。適切な用途を判断するには、これらを慎重に検討する必要があります。 適用機会のある領域 生成系 AI は、他の機械学習技術では簡単には実現できない顧客体験を向上させる機会を提供します。LLM は非常に柔軟です。同じモデルで、質問への回答、文書の要約、言語の翻訳、文章の完成など、複数のタスクを実行できます。自然な「人間が作成したような」コンテンツを生成できるため、定型化された情報に頼る必要がなくなり、回答を高度にパーソナライズできるようになります。生成系 AI の実際のユースケースを見てみましょう。 Amazon.com では現在、生成系 AI を使用して、1つの製品に関する複数のレビューを要約しています。以下の例では、Amazon.com は生成系 AI を使用して、ストレージキャビネットに関する 3,000 件を超えるレビューを、読みやすく、データが豊富な 1 件のレビューにまとめています。購入者は時間をかけて複数のレビューを熟読する代わりに、このまとめを見ることで、購入について迅速に決定を下すことができます。 生成系 AI は、知識集約型の自然言語処理にも使用できます。これは、 LLM がナレッジベースのアーカイブにある特定の質問に答えるために使用する手法です。これはコンタクトセンターのエージェントを補助するアプリケーションで非常に役立ちます。 以下の例では、顧客がレンタカー会社に連絡してキャンセル料について問い合わせています。 音声文字起こしを使用して、キャンセルに関する質問があったことをシステムが検出し、インテリジェント検索を使用してその質問に関連する内部文書を検索しました。そして、生成系 AI は、それらの文書から導き出された回答を要約することで、このユースケースを強化します。 エージェントが顧客に提供できるソリューションを含む簡潔な応答を生成系 AI が返しました。これにより、エージェントは複数のナレッジ記事を熟読して回答を作成するための時間を節約でき、平均処理時間 (AHT) を節約できます。 生成系 AI の活用例のデモ の中でもこのシナリオの全容を説明しています。 課題がある領域 適用機会だけでなく、生成系 AI にはいくつかの課題もあります。これには、対応の正確さ、コスト管理、スピード、使いやすさなどがあります。LLM は非常に大規模で強力なモデルであるため、他の従来の AI モデルや代替の自動化技術よりも処理速度が遅く、コストも高くなる可能性があります。また、他の方法よりもリスクが高い場合もあります。例えば、一見もっともらしく見えるコンテンツが生成されたり（ハルシネーション）、偏見が含まれていたり、会社の特定の価値観に沿っていないようなアウトプットを生み出すことがあります。アウトプットを完全にコントロールできないと、ガバナンスやコンプライアンスに影響を与える可能性があるため、それらを考慮する必要があります。 生成系 AI の課題への取り組み AWS では、設計、開発、デプロイ、運用全体を通じて責任ある AI を念頭に置いて FM を構築しています。AWS は、正確性、公平性、知的財産と著作権に関する考慮事項、適切な使用、プライバシーなど、さまざまな要素を考慮しています。これらの要素は、トレーニングデータの取得プロセス全体、FM 自体、またユーザープロンプトの前処理や出力の後処理に使用する技術 においても対処されています。AWS は、お客様からのフィードバックを基に機能を積極的に改善していますが、モデルの学習には顧客データを使用しないため、ユーザーのプライバシーとセキュリティがより強化されています。 生成系 AI の利用者としては、考慮すべき緩和戦略があります。その鍵となるのが、人間に最新情報を伝えることです。企業が生成系 AI の使用方法を学習、適用する場合は、顧客向けのユースケースではなく、社内のユースケースから始めましょう。生成系 AI モデル ( Anthropic の Claude 2 や Amazon Titan など) と直接やり取りする場合、プロンプトエンジニアリングの分野が重要になります。つまり、モデルが提供する出力を制御し、特定のニーズに合わせて出力を形作る入力を作成する方法を学ぶことです。プライバシーやセキュリティの問題に対処するには、Llama-2 などのモデルやホスト可能な他のモデルを自社サーバー上で完全にセルフホストすることを選択できます。ただし、これらの分野に重点を置き、確かな実績を持つ AWS のような信頼できるプロバイダーのマネージドサービスを使用することもできます。生成型 AI の利用者として、責任ある AI に対してできる最大の寄与できる点は、ユースケースを慎重に選択することです。 Working backwards: 生成系 AI に適したユースケースか判断する方法 Amazonでは、お客様のニーズから始めて、お客様が直面している問題の根源にたどり着くことを、「Working backwards」と呼びます。まず、ソリューションから始めるのではなく、問題から逆算して、適切なソリューションが何であるかを評価してください。次に、その業務に適したツールを見つけます (複数ある場合もあります)。問題から逆算していくうちに、その問題を解決するためのさまざまなアプローチが見つかるかもしれません。場合によっては、手動によるプロセスを採用したり、ロジックやルールを適用したりすることもあります。また、従来の AI を使用したり、生成系 AI を利用することもあります。各選択肢を詳細に説明し、その長所と短所を評価します。このプロセスは、チェックリストというよりは旅のようなものであることに注意してください。 手動プロセス — 手動プロセスでは、プロセスの各段階で人員が必要です。このプロセスは単なるデータドライバーでなく、毎回意思決定が下されるような、少量で機密性の高いワークロードや複雑なワークロードに適しています。例えば、人命の損失に関する保険金請求業務では、人間が高い判断力と共感力をもって処理することを望むでしょう。しかし、エージェントや熟練した作業者が必要でいくつかの課題があるため、手動プロセスの拡張は困難です。トレーニング、スケジューリング、人員の減少/退職の管理や人件費が、この方法を大規模に展開する際の複雑さの原因となっています。 ロジックとルール — 単純で反復的なタスクは、論理的な意思決定に基づくフローを使用して解決できます。これらには生成系 AI は必要ありません。その一例として、従来の 自動音声応答 (IVR) システムや、セルフサービス用のメニュー方式のチャットボットを使用して顧客をエージェントにルーティングすることが挙げられます。このような場合、フローは単純で、繰り返し可能で、論理的で、ルールに基づきます。この場合の利点は、コストが低く (非常にシンプルな自動化と複雑でないサービスが必要)、リスクが低い (監査/テスト/理解/変更が容易) ことです。また、多くの場合組織ですでに持っているスキルセットでもあります。このアプローチの課題は、より複雑な要件や意思決定に基づく要件には対応できないことです。 従来の AI — 問題がより複雑になり、単純なルールやロジックでは複雑になりすぎた場合、従来のAIが活躍するようになります。たとえば、IVR で従来の会話型 AI を使用してユーザーの意図を検出し、パスワードのリセットなどの簡単なタスクを処理できます。生成系 AI でも同じことができますが、ユースケースによっては、大きなハンマーを使って画びょうを打ち込むような方法になることもあります。従来の AI システムは 1 種類の仕事をするように訓練されていますが、一般的にこれは特定のタスクに対して非常にうまく機能することを意味します。特定の機能だけが必要であれば、より小規模な単一目的のモデルを実行する方が、一般的に低コストで高速です。 注目すべきは、従来のAIは、文字起こし、分類、自然言語理解などのコンタクトセンターのユースケースで依然として大きな役割を果たすということです。生成系 AI は、既存の AI ソリューションに取って代わるのではなく、より強化するものです。Amazon Connect は従来の AI をさまざまな方法で活用しており、AI を中核として開発されました。たとえば、 Amazon Connect Contact Lens は、文字起こしと理解モデルを使用してコンタクトセンターの分析を行います 。 生成系 AI — この項目で説明したいのは、生成系 AI が差別化要因となり、他に着目しているオプションに比べて大幅に改善するユースケースです。こうしたシナリオは、多くの場合、(従来の AI では実現できなかった) 新しいアウトプットを生み出すことが鍵となるシナリオです。たとえば、先ほどの Amazon.com のレビューの例から、生成系 AI は要約に優れていることがわかります。 コンタクトセンターではどうでしょうか？ A) 休暇のために予約をしているお客様からの電話の例を見てみましょう。以下は、通話の記録のスクリーンショットです。通話の書き起こしの横には、生成系 AI を使用して作成された、通話の詳細で簡潔な要約が表示されます。 通話をレビューするマネージャーやスーパーバイザーは、書き起こし全体を読む時間を費やすことなく、概要をすばやく閲覧できるようになります。 B) もう1つの複雑な例として、生成系 AI の推論機能を使用してエージェントコーチングツールを作成することが挙げられます。 このツールにより、生成された通話の書き起こしを基に、評価フォームの質問に対する答えをスーパーバイザーに自動的に回答できるようになります。下のスクリーンショットは、書き起こしのサンプルとそれに関連する評価フォームを示しています。評価フォームには、生成系 AI が提供した分析を使用した回答が自動的に入力されます。 単純な分類器とは異なり、質問には「はい」または「いいえ」以上の答えを得ることができ、答えの背後にある理由もわかります。これにより、スーパーバイザーとマネージャーは、生成系 AI が提供した答えをすばやく検証できます。その後、必要に応じてスーパーバイザーが答えを調整できます。 どちらの例でも、生成系 AI は人間によるプロセスを強化して効率を高め、スーパーバイザーやエージェントが顧客に集中できる時間を増やしています。ただし、これらのアウトプットを最大限に活用する方法についてスタッフを教育することが重要です。特定の会社やユースケースに最適なアウトプットが得られるようにシステムをチューニングするためには、ある程度の繰り返しが必要な場合があります。重要なのはこうした生成系 AI のアウトプットをやみくもに受け入れてはいけないことです。 上記の例では生成系 AI が問題を解決しましたが、すべてのユースケースに適しているとは限りません。私たちは、ユースケースの選択方法に責任を持つ必要があります。生成系 AI が適切なソリューションかどうかを判断するうえで参考になる質問をいくつかご紹介します。 このユースケースは、AI を使用するのが無責任なユースケース（不正確な出力などによる潜在的な害が価値を上回るケース）ではないか このユースケースは、既存の方法ですでに解決されており、生成系 AI に切り替えても大幅に改善される可能性が低いのではないか このユースケースは、既存のソリューションで置き換えるよりも、生成系 AI を使って強化できるユースケースなのか 実験や効果の評価にはどれくらいの初期費用がかかるのか。既存のマネージドサービスやすぐに使用できる標準の機能はないか 反復して実装を安全にテストしたり、学習する時間を確保できるか この決定を下すのにふさわしいスキルがあるか 生成系 AI は強力なツールですが、習得するには時間と投資も必要です。各ユースケースやビジネスに独自の微妙な違いがあり、検討すべき点も異なります。 結論 生成系 AI は、まだ大きな可能性を秘めた非常に新しいテクノロジーであり、成長の余地があります。生成系 AI をいち早く試すことで、新しい機能が登場したときに、適切な機会にそれを採用する準備が整います。詳細については、 AWS での生成系 AI をご覧ください。ここでは、その他の実際のユースケース、教材、 Amazon Bedrock などのテクノロジー 、そしてもちろん相談できる専門家も見つけることができます。私たちはカスタマーサービスのユースケースに適したテクノロジーソリューションを見つけるために、逆算して取り組む方法について、お客様と協力する準備が整っています。生成系 AI と Amazon Connect を使い始める方法については、アカウントチームに相談することをお勧めします。 著者について Mike Wallace は AWS でアメリカのカスタマーエクスペリエンス分野のソリューションアーキテクトをリードしています。 Gillian Armstrong はビルダーソリューションアーキテクトです。彼女は、クラウドがテクノロジーを使って問題を解決する機会をより多くの人に広げていることにわくわくしています。特に、会話型 AI などのコグニティブテクノロジーによって、人間らしい方法でコンピューターと対話できるようになったことに興奮しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

先日(2023/9/14) に開催した AWS オンラインセミナー「さあ、始めよう！ AWS が提供するサーバーレス時系列データベース」の資料・動画を公開しました。今回のセミナーでは Amazon Timestream を利用した事例や、実際のデモをご覧いただきながら時系列データの活用方法をご紹介しています。 当日、参加者の皆様には数多くの QA を頂きありがとうございました。頂いた QA の一部についても共有しておりますので、併せてご参照ください。 【資料/動画】 時系列データのユースケースと Timestream 概要 資料 ( PDF ) | 動画 ( Youtube ) Demo for Beginners – 初めての Timestream 入門 資料 ( PDF ) | 動画 ( Youtube ) Amazon Timestream 新機能紹介とデモ 資料 ( PDF ) | 動画 ( Youtube )   【QA】 Q. 時系列データ分析に Amazon Redshift を使っているのですが、Timestream との違いを教えてください。 A. Redshift は、データウェアハウス専用のリレーショナルデータベースに位置づけられます（参考： AWS が提供するクラウドデータベース ）。ポイントとしては Timestream は時系列に特化した関数が用意されているという点です。一方で Redshift はより汎用性の高い DWH 専用の RDB になりますので、時系列データに特化してシンプルにデータを扱いたい場合に Timestream をご検討いただければ思います。 Q. メモリストアからマグネティックストアに変更するのは簡単に出来ますでしょうか？ A. メモリストアの保持期間を過ぎると自動的にマグネティックストアにデータは移行されますが、一方で現時点でメモリストアの保持期限内でマグネティックストアに変換する事は出来ません。よって本日ご紹介したバックアップ機能を利用し、メモリストアのデータをマグネティックストアにリストアすることをご検討ください。 Q. テーブル作成時、それぞれのデータストアの保持期間を設定するとのことですが、マグネティックストアの保持期間が経過するとデータは削除されますか？保持期間経過後のデータを、例えば S3 の Glacier Deep Archive などに移行することは可能でしょうか？ A. 保持期間が経過すると削除されます。 Timestream の Export 機能を利用して出力したデータを S3 に移動いただくことが可能です。（参考： Amazon Timestream が Amazon S3 へのデータのアンロードのサポートを開始 ） Q. Single measure と Multi measure の使い分けを教えてください。 A. 基本的には Multi measure の利用を前提にご検討ください。一方で SELECT 対象の列が2個以下といったように少ないことが事前に把握できている場合は、クエリコストの観点で Single measure の方が良いです。 Q. Amazon DynamoDB から Timestream への移行を検討していますが、 DynamoDB 側の既存データにおいて NULL 型を許容している項目についての扱いに悩んでいます。 A. 対象が Dimension 列となる場合は NULL も許容されます。一方で Measure の場合は1つのレコードに対して何かしら値が格納されている必要があり NULL は許容されません（ Multi measure の場合は1つ以上値が入っている必要があります）。従いまして例えば NA といった値を格納することや、レコード自体を格納せずに欠損値として扱い、クエリ実行時に補完関数を利用するといったケースが考えられます。 Q. SQL を実行しないとテーブルアイテムの探索はできない、という理解で良いでしょうか？ A. 各テーブルのカラム情報はクエリエディタを利用し確認できます。一方で、テーブルに格納されているデータ自体は SQL で検索いただく必要がございます。 Q. bin関数を利用する際に、 UTC ⇔ JST の変換は可能でしょうか？ A. 現時点で Timestream では Timezone を事前に変更しておくことはできませんが、 SQL での問い合わせの際に date_add 関数で時刻計算が可能です。例えば timestamp が UTC という前提で、以下のような関数をご利用いただくと JST での出力が可能となります。 bin(date_add('hour' , 9 , timestamp ), 1d) Q. バッチロードに対応するのは CSV だけでしょうか？データを Paruqet や AVRO で用意しているため。 A. はい、現時点では CSV ファイルのみの対応になります。 Parquet や AVRO の場合は一旦 CSV に変換していただく必要がございます。 Q. バッチロードは増分追加のイメージでしょうか？洗い替えの機能もあるのでしょうか？ A. はい、増分追加となります。現時点で洗い替えはできませんので、仮に洗い替えをしたい場合はテーブル作成から再度実行いただく必要がございます。 Q. 1000万件 CSV データのロード時間はどのぐらいでしょうか？ A. ファイルの分割数やカラム数によってインポート時間は変わるため、実機にてお試しいただければと思います。尚、バッチロードのベストプラクティスが公開されているので、こちらを元にお試しいただくことを推奨致します。（参考： Batch load best practices – Amazon Timestream ） Q. DynanoDB のように検証用途でローカル PC に Timestream をセットアップして利用することは可能ですか？ A. 現時点で Timestream をローカル PC にセットアップする手段は提供していません。尚、 Timestream では一定の範囲内で無料でお使いいただくことができますので、無料利用枠でのご利用をご検討ください（参考： AWS 無料利用枠 ） Q. Timestream のユースケースにおいて IoT Application での利用がありましたが、 Timestream をデータレイクとして活用できるのでしょうか？データレイクを作る場合は Amazon S3 が望ましいのでしょうか？ A. 時系列データに特化して扱いたい場合は Timestream をデータレイクとして利用することも考えれるかとは思いますが、こちらはユースケースに依存します。例えば IoT デバイスから出力されたデータを一時的に Timestream に格納し、欠損データの補完やミリ秒から秒単位への変換作業、また時系列関数や分析関数を利用した集計作業を行なった上で、汎用データを格納する先としての S3 に流し込む、といったユースケースもあろうかと思います。このように適材適所で検討する必要がありますので、まずはお客様のやりたいことを元にアーキテクチャを一緒に検討できますので、AWSの担当者までご相談いただければと思います。   — 著者 長久保 武 データベース スペシャリスト ソリューション アーキテクト

今年は新たにAWS カスタマーエクスペリエンスチームが re: Invent 体験の向上に役立つヒントや、AWS をさらに使いやすくするためのさまざまな改善点について学ぶためのヒントを紹介します。AWS Village のキオスクにお越しください。そして以下のセッションをぜひチェックしてください。セッションでは、アプリケーション管理、インシデント対応の自動化に関するベストプラクティスを取り上げ、クラウドへの移行を加速させるために役立つ製品を紹介します。 参加する前に準備しよう AWS Console Mobile Application（AWS コンソールモバイルアプリケーション）をダウンロードして、重要なイベントを見逃さないように通知を設定 AWS Console Mobile Application では、選択した AWS リソースの表示と管理が可能で、プッシュ通知を受信して最新情報を入手したり、外出先でも AWS リソースに接続したりできます。 AWS User Notifications （AWS ユーザー通知）は、AWS Healthイベント、Amazon CloudWatch アラーム、Amazon EC2 インスタンスの状態変化などの AWS サービスからの通知を AWS Console Notifications Center(AWS コンソール通知センター)で設定して表示できるようにする新しいサービスです。100 以上の AWS サービスの通知を設定したり、カスタム通知フィルタを設定したり (たとえば、タグが = 本番稼働中であり、状態が「開始中」のバージニア北部リージョン の EC2 インスタンスなど)、通知を受け取りたいチャネル (電子メール、AWS Console Mobile Applicationへのモバイルプッシュ通知、または AWS Chatbot による Slack や Microsoft Teams などのチャットクライアントなど) を指定したり、イベント集約を有効にしたりして、関連するイベントをバンドルして生成される通知の数を減らすことができます。 AWS User Notificationの過去のブログ投稿 で詳細をご覧ください。 AWS Chatbot、AWS User Notifications、AWS Console Mobile Applicationにより、外出先でも接続状態を維持 セッションのご紹介 セッションカタログ にある以下のセッションをお気に入りに登録して、AWSの製品やサービスについて詳しく学んでください。 DOP324 | Accelerating application development with AWS client-side tools (AWS クライアントサイドツールによるアプリケーション開発の加速) 11 月 27 日午前 9 時( Pacific Time )、Caesars Forum, Level 1, Summit 221 AWS はクラウドサービスだけではありません。質の高いアプリケーションを簡単に開発できるように設計された AWS のクライアントサイドのツールとライブラリが多数あります。このchalk talkでは、開発環境で利用できるツールをいくつか紹介します。AWS アプリケーション開発を加速させるコマンドラインツール (AWS CLI)、ライブラリ (AWS SDK)、IDE 統合、アプリケーションフレームワークについて詳しく学んでください。周りのみんながアジェンダの設定を手伝ってくれるので、どのビルダーにとっても必ず得るものがあるはずです。 COP313 | Automate incident management of modern workloads using ChatOps (ChatOps を使用して最新のワークロードのインシデント管理を自動化する) 11 月 27 日午後 4 時 30 分( Pacific Time )、Caesars Forum, Level 1, Academy 416 問題への対処、システム停止の最小化、インシデント対応の改善には、迅速かつ効率的に行動することが重要です。このビルダー向けセッションでは、AWS Chatbotや AWS Systems Manager などの AWS サービスと、Microsoft Teams や Slack などの一般的なコミュニケーションおよびコラボレーションプラットフォームを使用して ChatOps を実装する方法を学びます。chat-drivenな運用ワークフローを実装して、最新のワークロードの運用上の問題の診断と修正を支援する方法をご覧ください。参加するにはノートパソコンを持参する必要があります。 COP334 | Simplify application management for operational excellence (アプリケーション管理を簡素化してオペレーショナルエクセレンスを実現) 11 月 29 日午前 10 時( Pacific Time )、Caesars Forum, Level 1, Alliance 305 アプリケーションが進化し成長するにつれ、複数のサービスにまたがる複数のアプリケーションの監視とサポートは、運用チームにとってどんどん難しくなっているかもしれません。このchalk talkでは、AWS の専門家と共に深く掘り下げて、AWS Service Catalog AppRegistry と AWS Systems Manager の機能であるApplication Managerを使用して、アプリケーション全体のオペレーショナルエクセレンスを維持する方法を学びます。AWS クラウドでアプリケーションを定義する方法を学び、それらのアプリケーションに対して運用上のアクションを実行して、コンプライアンス、コスト、パフォーマンスに関連する問題に対処し、修正する方法を探ります。 DOP220 | Simplify building applications with AWS SDKs (AWS SDK でアプリケーション構築を簡素化) 11 月 29 日午後 3 時( Pacific Time )、Wynn, Level 1, Lafite 9 AWS SDK は、アプリケーションやサービスからAWS サービスを使用する上で重要な役割を果たします。このセッションでは、AWS SDK の現状と将来について学びます。開発者体験を簡素化し、新しい機能を活用する方法をご覧ください。SDK がどのように進化し、複数の言語で一貫したエクスペリエンスを提供し、高レベルの抽象化によってより多くのことができるようになり、AWS での構築が容易になるかをご覧ください。Smithy のようなオープンソースツールを使用して AWS SDK を構築する方法と、これらのツールを使用して顧客のニーズに応える独自の SDK を構築する方法をご覧ください。 COP328 | How to manage applications at scale and innovate faster with AWS (AWS を使用してアプリケーションを大規模に管理し、イノベーションを加速する方法) 11 月 29 日午後 4 時 30 分( Pacific Time )、Caesars Forum, Level 1, Academy 407 アプリケーションをサポートするエンジニア、アプリケーションセキュリティを監視する IT 管理者、アプリケーション支出を調査する財務アナリスト、アプリケーションの信頼性を維持する運用スペシャリストたちにとって、増え続けるアプリケーションリソースを管理することはますます困難になるかもしれません。AWS のサービスとツールがどのようにアプリケーション管理を簡素化し、問題の迅速な修正、より迅速なイノベーション、時間の節約、安全なスケーリングを実現できるかをぜひご覧ください。Amazon CloudWatch でアプリケーションのパフォーマンスを管理する方法、AWS Security Hub でセキュリティ体制を改善する方法、AWS Cost Explorer でコストを最適化する方法、AWS Systems Manager でアプリケーション全体のオペレーショナルエクセレンスを向上させる方法をご覧ください。 エキスパートに会いましょう Expoの AWS Village でAWSのエキスパートと交流しましょう セッションへの参加に加えて、The Venetianホテルを会場としているExpoの、 AWS Village内 にある AWS マネジメントコンソール とカスタマーエクスペリエンスのキオスクにもぜひお越しください ( キャンパスマップ )。ホイールを回して賞品を獲得したり、AWSのエキスパートに会いましょう。 AWS マネジメントコンソール AWS マネジメントコンソールのPrincipal Product Managerである Grace Kitzmiller が、ツールバーのCloudShell、プライベートアクセス、その他のエクスペリエンスの改善などの新機能を紹介します。#AWSwishlist をお持ちいただき、AWS マネジメントコンソールのキオスクで詳細をご覧ください。 AWS Chatbot AWS Chatbot のPrincipal Product Managerである Abhijit Barde は、カンファレンス全体を通して AWS マネジメントコンソールのキオスクに出席しています。ぜひ立ち寄って、組織で ChatOps を有効にする方法を学び、彼のセッション「COP313 | Automate incident management of modern workloads using ChatOps(ChatOps を使用して最新のワークロードのインシデント管理を自動化する)」に参加してください。 Cloudscape Design System Olga MadejskaはAWS デザインシステムである Cloudscape の責任者です。カスタマーエクスペリエンスキオスクに立ち寄って、AWS マネジメントコンソールのユーザーインターフェイスと、ウェブアプリケーションを構築するためのオープンソースデザインシステムである Cloudscape の使用方法について話し合ってください。 AWS Documentation AWS Documentation 担当Senior Product Managerの Betty Liou は、カンファレンス全体を通して AWS Village の AWS カスタマーエクスペリエンスキオスクに出席しています。技術ドキュメントチームと re: Invent でリリースされる新機能の詳細をご覧ください。 PeerTalk 最後に、本ブログの著者であるRick Suttlesは個別相談の専門家として皆さんとお会いする準備ができています！ re: Inventの参加者は PeerTalk を対面で利用できるようになりました。私または私たちのチームの誰かとの１対１ミーティングをリクエストして、50以上あるグループミートアップに登録してください。 筆者 Rick Suttles 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。

VMware Cloud on AWS チームは、 AWS re:Invent 2023 でお客様とお会いできることを楽しみにしています。より速く、より費用対効果の高いクラウドへの移行方法を探しているお客様向けに、洞察に満ちたセッションをご用意しています。VMware Cloud on AWS のブレイクアウト・セッション、チョーク・トーク、ワークショップでは、移行のベストプラクティス、災害対策、モダナイゼーションなどのトピックを取り上げています。 AWS re:Invent は年間で最も包括的なクラウドコンピューティングイベントであり、活気に満ちた刺激的なコミュニティで皆様にお会いできるのを楽しみにしています。私たちのセッションをお客様のアジェンダに追加して、インスピレーションを得て学ぶ準備をしてください！ VMware は AWS パートナーであり、re:Invent Emerald スポンサーでもあります。今年のカンファレンスでは、エキサイティングなセッションを予定しています。re:Invent での VMware のプレゼンスについて、詳しくは VMware のスポンサーページ をご覧ください。 エンタープライズワークロードのブースでお待ちしています ご質問があれば、エンタープライズワークロードのブースで VMware Cloud on AWS チームが直接お答えします。以下の時間帯に、エキスポの AWS Village のブース #35 にお立ち寄りください。 11 月 28 日 — 午前 10 時～午後 12 時 11 月 28 日 — 午後 2 時～午後 4 時 11 月 29 日 — 午後 12 時～午後 2 時 11 月 30 日 — 午後 2 時～午後 4 時 (※ 時間はいずれも現地時間、太平洋標準時（PST）です。) re:Invent 2023 VMware Cloud on AWS セッション・コンテンツ ブレイクアウト・セッション AWS のエキスパート、お客様、パートナーが提供するブレイクアウト・セッションは、特定のトピックについて1時間かけて深く掘り下げた講義形式のセッションです。VMware Cloud on AWS ブレイクアウト・セッションを提供すること、そして、ハネウェルとフィリップス66の2社をステージにお招きできることを嬉しく思います。 ENT101 – An enterprise cloud journey: Speed and scale with VMware Cloud on AWS スピードと規模は、どの組織のデジタル変革においても重要な成功要因です。ハネウェルがどのようにしてデジタルトランスフォーメーションへの道を切り開き、移行前に直面していた課題を克服したかを知ることができます。VMware Cloud on AWS を使用して、既存のハードウェアをどのように使用し、アプリケーションを書き直さずに移行し、既存のスキルを最大限に活用できるかをご覧ください。このセッションに参加して、厳しい期限が迫っている大規模な移行に取り組む方法について、AWSとハネウェルの双方のベストプラクティスを学びましょう。 太平洋標準時 11 月 28 日 — 午後 12 時 30 分 — 午後 1 時 30 分 | MGM Grand 120 | アジェンダに追加 ENT102 – Fueling resilience: Phillips 66’s journey with VMware Cloud on AWS 変化を乗り越え、イノベーションを受け入れることは、ビジネスを成功させるために不可欠です。複雑なクラウド移行に取り組み、データ保護を確保し、レガシーシステムに囲まれた業界において競争力を獲得する方法について、AWS と フィリップス66から直接話を聞くことができます。フィリップス66の迅速でスケーラブルなクラウド運用の過程からインスピレーションを得て、ご自分の移行に適用する方法に関する実践的なヒントを学んでください。 太平洋標準時 11 月 29 日 — 午前 8 時 30 分 — 午前 9 時 30 分 | MGM Grand 120 | アジェンダに追加 チョーク・トーク チョーク・トークは、少人数の参加者で行われる、非常にインタラクティブな1時間のセッションです。それぞれが AWS のエキスパートによる短い講義から始まり、その後、聴衆との質疑応答が行われます。VMware Cloud on AWS のエキスパートは、技術的なディスカッションに参加して、お客様のあらゆる質問に喜んでお答えします。 ENT209 – Are you well-architected? Enhance VMware workload migration with AWS VMware ワークロードのクラウド準備状況を評価し、依存関係を特定する方法を学べます。AWS Well-Architected フレームワークを使用して堅牢な移行計画を作成し、そのフレームワークの 6 つの柱をワークロード設計に適用する方法をご覧ください。AWS のエキスパートに相談して、耐障害性、拡張性、費用対効果の高い設計に関する重要な考慮事項を見つけながら、自信を持って VMware ワークロードをクラウドに移行できるようになります。 セッション 1: 太平洋標準時 11 月 29 日 — 午後 4 時 30 分 — 午後 5 時 30 分 | MGM Boulevard 169 | アジェンダに追加 セッション 2: 太平洋標準時 11 月 30 日 — 午後 12 時 30 分 — 午後 1 時 30 分 | MGM Grand 101 | アジェンダに追加 ENT320 – Advanced hybrid network architectures for VMWare Cloud on AWS オンプレミスと VMware Cloud on AWS の間で vSphere ベースのハイブリッド環境を運用する予定がある、または現在実行している場合は、AWS Direct Connect、AWS Site-to-Site VPN 、AWS Transit Gateway 、および VMware Transit Connect を使用して堅牢なネットワークアーキテクチャを構築する方法をご覧ください。セキュリティアプライアンスによる入出力セキュリティ、カスタム Tier-1 ゲートウェイによるマルチテナンシー、マルチエッジ SDDC による帯域幅のスケーリングなどの高度な概念について、詳しく学んでください。 太平洋標準時 11 月 29 日 — 午前 10 時 30 分 — 午前 11 時 30 分 | MGM Premier 320 | アジェンダに追加 ワークショップ ワークショップは 2 時間のインタラクティブなセッションで、少人数のチームで AWS サービスを使用して実際の問題を解決します。各ワークショップは、メインスピーカーによる短い講義（10～15分）から始まり、残りの時間はグループでの作業に費やされます。ご自分のラップトップを忘れずにお持ちください。 ENT313 – Deep dive into backup and data protection for VMware Cloud on AWS ハイブリッドクラウド環境を採用する上では、強固なバックアップおよびデータ保護戦略を確立することが重要です。AWS 責任共有モデルによってクラウド上で信頼できるセキュリティを実現する方法についてエキスパートの話を聞いてください。実践的な演習を通じて、AWS Backup がワークロードの保護と信頼性の高い移行にどのように役立つかを学べます。参加にはご自身のラップトップが必要になります。 セッション 1: 太平洋標準時 11 月 27 日 — 午後 2 時 30 分 — 午後 4 時 30 分 | Caesars Forum Summit 216 | アジェンダに追加 セッション 2: 太平洋標準時 11 月 29 日 — 午後 3 時 00 分 — 午後 5 時 00 分 | Mandalay Bay Islander I | アジェンダに追加 ENT329 – Scale VMware Cloud on AWS without adding nodes 追加のストレージサービスを使って VMware Cloud on AWS SDDC を拡張する、実践的なスキルを身に付けましょう。実践的な演習を通じて、さまざまなユースケースに適したストレージオプションを特定し、クラウドインフラストラクチャを最適化する方法を学ぶことができます。AWS のエキスパートが、VMware Cloud Flex Storage、Amazon FSx for NetApp ONTAP、Amazon FSx for Windows File Server、および AWS DataSync によるストレージアーキテクチャの作成について、順を追って説明します。参加にはご自身のラップトップが必要になります。 太平洋標準時 11 月 30 日 — 午後 2 時 00 分 — 午後 4 時 00 分 | Caesars Forum Summit 228 | アジェンダに追加 AWS re:Invent 2023 でお会いしましょう VMware Cloud on AWSチームは、AWS re:Invent 2023 で皆様にお会いすることを楽しみにしています。会場のさまざまな洞察に満ちた体験を通して、ラスベガスで皆様とご一緒できるのが楽しみです。 VMware Cloud on AWS が、クラウドへの移行をより速く、安全で、費用対効果の高い方法で実現する方法について詳しくは、当社の Web サイトにアクセスして、最新情報をフォローしてください。 VMware Cloud on AWS Web サイト (AWS) VMware Cloud on AWS Web サイト (VMware) この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。

11 月 27 日から 12 月 1 日までラスベガスで開催されるクラウドコンピューティングカンファレンス、 AWS re: Invent 2023 で皆様にお会いできることをとても楽しみにしています。re: Invent に初めて行かれる方も、そうではない方も、AWS re: Invent の熱量と様々な機会にはきっと驚かされることでしょう。 AWS クラウドオペレーション トラックは、それを構成するソリューション領域 ( モニタリングとオブザーバビリティ 、 運用管理 、コンプライアンスと監査、クラウドガバナンス) をカバーする合計 96 のセッションで構成されています。本トラックでは、豊富な洞察、ベストプラクティス、楽しいキオスクアクティビティを通じて、クラウド管理スキルを新たな高みに引き上げることができます。 このブログでは、 クラウドガバナンス と コンプライアンス・監査 に焦点を当てます。これらは、組織がリスクを評価し、コンプライアンスと監査データを一元化し、自動化を使用してセキュリティとコンプライアンス体制を改善するのに役立つクラウド運用内の2つのソリューション分野です。AWS クラウドガバナンスは ビジネス目標に合わせてAWSクラウドを使うのに役立ち、AWS クラウドコンプライアンスは規制要件、基準、法律、業界の枠組みを満たすのに役立ちます。 AWS ビレッジのクラウド運用キオスク: セッションへの参加に加えて、The Venetianホテルを会場としているExpoの、 AWS Village内 にあるクラウドオペレーションキオスク ( キャンパスマップ ) にもぜひお越しください。ホイールを回して賞品を獲得したり、AWSのエキスパートに会い、クラウド運用の未来について学んでいきましょう。 クラウドガバナンスとコンプライアンスについての理解を深めるために、キオスクやおすすめのセッションについて下記にお知らせします。ぜひ セッションカタログ でこれらのセッションをお気に入りに登録してください。 参加すべきクラウドガバナンスおよびコンプライアンスセッション トップ10 COP207 | Don’t let cloud compliance and operations exceed your budget – Chalk Talk （ クラウドのコンプライアンスと運用が予算を超えないようにする） このチョークトークでは、コンプライアンスと運用のニーズを満たすモダンでスケーラブルなアーキテクチャを構築しながら、コストを最適化し続ける方法を学びます。AWS Config と AWS CloudTrail の使用を最適化するためのさまざまなベストプラクティスと推奨事項について説明します。最適な支出につながる複数のユースケースを検討し、AWS のベストプラクティスを利用することがこれらのシナリオにどのように役立つかを学んでください。あなたのご質問をお待ちしています！ COP209 | How to customize AWS compliance and auditing services – Breakout Session (AWS コンプライアンスおよび監査サービスをカスタマイズする方法 ) セキュリティ運用、コンプライアンス、監査の設定はチャレンジングです。特に、起きていることをすべて視覚化し、管理し、対応しやすくすることは容易ではありません。また、フルマネージドサービスを使用すると、リスクは軽減されてもイノベーションは制限されることがあります。AWS Security Hub、AWS CloudTrail Lake、AWS Control Towerを通じて AWS Config を使用し、運用とコンプライアンスを成功させるための環境をセットアップする方法をご覧ください。 COP304 | Customizing accounts swiftly and securely with AWS Control Tower – Chalk Talk (AWS Control Towerによるマルチアカウント環境の迅速かつ安全なカスタマイズ ) AWS Control Tower でマルチアカウント環境を構築する際には、ネットワーク、セキュリティ、ID、コンプライアンスについて、標準的なプラットフォームをカスタマイズしながらアカウントを事前に設定する必要があります。このチョークトークでは、さまざまな自動化オプションを使用して、アカウント全体で一貫したプラットフォームツールとリソースを実装する方法を学びます。また、AWS Control Tower と AWS ID & Access Management (IAM) を使用して制御、ポリシー、権限の境界を構築し、分散型でスケーラブルな環境を実現するためのベストプラクティスについても説明します。 COP311 | Simplify continuous auditing and compliance on AWS – Workshop (AWS での継続的な監査とコンプライアンスを簡素化) このワークショップでは、AWS のリージョンとアカウント全体にわたる継続的な監査とコンプライアンスを一元化して簡素化するために、AWS クラウドオペレーションサービスを利用する手順について説明します。まず、AWS Systems Manager Explorer を使用して AWS Config Rules のコンプライアンスステータスを収集する方法を学ぶことから始めます。次に、AWS Systems Manager Automation documents (runbooks) を使用して、準拠していない AWS Config Rulesの修正を自動化する方法を学びます。最後に、AWS Audit Manager を使用して対象のプロセスから証拠を収集し、監査に備えましょう。参加するにはノートパソコンを持参して頂く必要があります。 COP315 | Architecting AWS Accounts for scale – Chalk Talk (大規模な AWS マルチアカウント環境の設計) このチョークトークは、アカウント設定、統制管理、そしてAWS OrganizationsやAWS Control Tower によるセキュリティ境界の確立など、マルチアカウント環境を構築するためのベストプラクティスに焦点を当てています。これらのベストプラクティスに従うことで、コストを最適化しながら、ビジネスアプリケーションとデータをより簡単に管理し、オペレーショナルエクセレンス、セキュリティ、信頼性を実現する方法を学びましょう。 COP318 | Best practices for cloud governance – Breakout Session (クラウドガバナンスのベストプラクティス) 組織全体をクラウドに移行させる方法を決めるのは難しい場合があります。どこから始めればよいでしょうか。ハイブリッド環境や規制された環境をどのように管理するべきでしょうか。このセッションでは、権限管理、安全なワークロードデプロイ、ガバナンスの戦略など、AWS 上で優れた設計とスケーラブルな基盤を構築するためのクラウドガバナンスのベストプラクティスを学びます。クラウドの導入に成功した組織から AWS が学んだインサイトをご覧ください。 COP328 | How to manage applications at scale and innovate faster with AWS – Breakout Session (AWS を使用してアプリケーションを大規模に管理し、より迅速にイノベーションを起こす方法) アプリケーションをサポートするエンジニア、アプリケーションセキュリティを監視する IT 管理者、アプリケーション支出を調査する財務アナリスト、アプリケーションの信頼性を維持する運用スペシャリストのいずれであっても、増え続けるアプリケーションリソースを管理することはますます困難になるかもしれません。AWS のサービスとツールがどのようにアプリケーション管理を簡素化し、問題の迅速な修正、より迅速なイノベーション、時間の節約、安全なスケーリングを実現できるかをぜひご覧ください。Amazon CloudWatch でアプリケーションのパフォーマンスを管理する方法、AWS Security Hub でセキュリティ体制を改善する方法、AWS Cost Explorer でコストを最適化する方法、AWS Systems Manager でアプリケーション全体のオペレーショナルエクセレンスを向上させる方法をご覧ください。 COP331 | Implementing end-to-end compliance on AWS, featuring BMW – Breakout Session (BMW をフィーチャーした AWS 上でのエンドツーエンドのコンプライアンスの実装) 今日、組織はコンプライアンス要件とセキュリティ要件のバランスを取るという課題に直面しています。このセッションでは、AWS リソースのセキュリティとコンプライアンスを定義し維持するためのエンドツーエンドの体験を説明します。お客様の環境における統制の作成と自動化、コンプライアンス違反の確認と是正に使用できるツールについて学んでください。AWS CloudFormation、AWS Config、AWS Security Hub、AWS ControlTower、AWS Systems Managerなどの複数のサービスを統合して、リソースのコンプライアンスを維持する方法をご覧ください。 COP333 | Optimize costs in your multi-account environments – Breakout Session (マルチアカウント環境のコストを最適化) クラウドへの移行やクラウドでのスケーリングを行うお客様は、ビジネスへの影響を最大化しながら、コストを最適化して支出を削減したいと考えています。このセッションでは、マルチアカウントの AWS 環境 (AWS Control Tower、AWS Organizations) でコストを効率的かつ大規模に最適化するためのベストプラクティスと推奨事項を紹介します。クラウド導入のどの段階にいても、AWS Compute Optimizer などのツールをタグ付けしながら使用するといったコントロールを行い、コスト削減戦略をワークロードやリソースに適用する方法を学んでください。 COP338 | Using generative AI to improve your compliance and auditing processes – Chalk Talk (生成 AI を使用してコンプライアンスと監査プロセスを改善) コンプライアンスの管理は面倒なプロセスですが、監査に備えるためには必要なことです。面倒なプロセスのためではなくイノベーションにリソースを使うために、AWS Config や AWS CloudTrail などのサービスを Amazon CodeWhisperer と組み合わせると、カスタムのコンプライアンスルールをより迅速に構築し、監査ログに対してより効果的にクエリを実行できます。監査の時期になったら、CodeWhisperer を使用して CloudTrail で監査証拠をクエリできるようにすることもできます。このチョークトークに参加して、AWS のジェネレーティブ AI がどのようにコンプライアンスや監査プロセスをより迅速かつ効率的にするのかを学びましょう。 COP340 | What’s new with AWS governance and compliance – Breakout Session (AWS ガバナンスとコンプライアンスの最新情報) ガバナンスとコンプライアンスに最適化された環境をつくると、生産性と運用効率を向上させることができます。これにより、お客様はビジネス成果の達成と時間とコストの節約に集中できます。このセッションに参加して、AWS がガバナンスとコンプライアンスの分野でどのように革新を行っているかをご覧ください。最近リリースされた製品と、それを利用してさまざまな課題を解決する方法について学んでください。 注: Breakout session（ブレイクアウトセッション）は、1 人以上のスピーカーが多数の聴衆にコンテンツをプレゼンテーションすることで構成されます。Workshop(ワークショップ)は、参加者が少人数のグループで AWS を使用して問題の解決策を構築するインタラクティブなセッションです。Chalk talk(チョークトーク)は非常にインタラクティブで、AWS の専門家による短い講義から始まり、その後に 45 ～ 50 分のホワイトボードと Q&A セッションが続きます。Builders’ session(ビルダーズセッション）は、1 人の AWS 専門家が主導する小グループのセッションで、短いデモンストレーションから始まり、参加者がフォローアップし、AWS の専門家と実験や構築を行います。 重要なポイント おすすめセクションに参加し、キオスクでAWSの専門家と会うことで、クラウドガバナンスとコンプライアンスのベストプラクティスを学ぶことができます。これにより、セキュリティ、運用、規制、コストの基準を順守できると同時に、イノベーションを起こしてより迅速に行動できるようになります。最後になりますが、少し休憩しながらキオスクで楽しい時間を過ごしていただければ幸いです。 筆者 Tiffany Chen, Winnie Chen 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。

Amazon CloudFront がリリースされてから 15 年も経ったなんて信じられません。 2006 年に Amazon S3 がリリースされたとき、デベロッパーはその柔軟性を気に入って、ストレージがボトルネックにならない新たな種類のグローバル分散アプリケーションを構築し始めました。これらのアプリケーションは、地球上のあらゆるユーザーのために、高いパフォーマンス、信頼性、コスト効率を提供する必要がありました。そこで 2008 年に、小規模なチーム (「 ツーピザチーム 」) が、わずか 200 日で CloudFront をリリースしました。 Jeff Barr は 9 月に まだ名前のない新しいサービス についてほのめかし、その 2 か月後に CloudFront をリリース しました。 CloudFront は当初から、低レイテンシーと高速データ転送を実現しながら、長期契約なしでエンドユーザーにコンテンツを配信する簡単な方法を提供してきました。 Amazon S3 用のシンプルなキャッシュとしてリリースされたこのサービスは、短期間でフル機能のコンテンツ配信ネットワークに進化しました。現在、CloudFront は驚異的なスピードでアプリケーションを世界中に配信し、NFL、クリケットワールドカップ、FIFA ワールドカップなどのライブスポーツイベントをサポートしています。 同時に、弊社はアプリケーションを保護するための最良のツールを提供したいとも考えています。2015 年に、エッジで高速かつ安全なアクセスコントロールを提供するために、 AWS WAF と CloudFront の統合を発表しました。その後、サービス全体でシグナルを組み合わせて、堅牢な脅威インテリジェンスの開発に重点的に取り組みました。この脅威インテリジェンスは CloudFront と統合し、一般的なエクスプロイトや分散型サービス拒否 (DDoS) 攻撃からアプリケーションを保護するための AWS Shield を追加します。例えば、最近、Amazon CloudFront に対する HTTP/2 リクエストの異常な急増が検出されました。当社はすぐに、新しいタイプの HTTP リクエストフラッド DDoS イベントが CloudFront によって自動的に緩和 されていることに気付きました。 HTTP よりも下位のレベルでも多くの動作が実行されます。例えば、CloudFront を利用してアプリケーションを提供する場合、そのアプリケーションが受信したすべてのパケットは、目に見えるレイテンシーを発生させない完全にインラインの DDoS 緩和システムによって検査されます。これにより、CloudFront ディストリビューションに対する L3/L4 DDoS 攻撃がリアルタイムで緩和されます。 また、 s2n-tls (「信号対雑音」の略) などの内部的な改善も行いました。これは、シンプルさを優先しながら、小さく高速になるように設計された TLS プロトコルのオープンソース実装です。もう 1 つの同様の改善点は、Rust で記述されたオープンソース QUIC プロトコル実装である s2n-quic です。 CloudFront を利用すると、さまざまな機能を通じてコンテンツに対するアクセスを制御することもできます。認証された視聴者のみにアクセスを制限したり、地理的制限機能を通じてコンテンツにアクセスできる特定の地理的場所を設定したりできます。 セキュリティは常に重要ですが、あらゆる組織が専任のセキュリティエキスパートを擁しているとは限りません。堅牢なセキュリティをより実現しやすくするために、CloudFront には、 ワンクリックでのウェブアプリケーションファイアウォールの設定 、 セキュリティに関するレコメンデーション 、 直感的なセキュリティダッシュボード などの組み込み保護機能が含まれるようになりました。これらの統合されたセキュリティ機能を使用すると、チームはセキュリティに関する深い専門知識がなくても、重要な安全策を講じることができます。当社の目標は、すべてのお客様がセキュリティに関するベストプラクティスを簡単に実装できるようにすることです。 ウェブアプリケーションの配信 過去 15 年間で、ウェブアプリケーションはさらに高度になり、エンドユーザーにとって不可欠なものとなりました。CloudFront がリリースされたとき、当社は S3 バケットに保存されたコンテンツの配信をサポートすることに重点的に取り組みました。 動的コンテンツ は、ユーザーごとにウェブサイトの一部が変化するウェブアプリケーションを最適化するために導入されました。また、動的コンテンツは、グローバルに配信する必要がある API へのアクセスを改善します。 アプリケーションの分散が進む中で、当社は、デベロッパーがそのグローバルなフットプリントとエッジのリソースを効率的に利用するのをサポートする方法を検討しました。エンドユーザーに近いコンテンツのカスタマイズとパーソナライズを可能にし、レイテンシーを最小限に抑えるために、 Lambda@Edge が導入されました 。 必要なコンピューティングリソースが少なくなると、 CloudFront Functions は、低レイテンシーの HTTP 操作とパーソナライズされたコンテンツ配信を実現するために、エッジロケーション全体で軽量の JavaScript 関数を実行できます 。最近、 CloudFront Functions が拡張され、HTTP ステータスコードやレスポンス本文の変更など、レスポンスをさらにカスタマイズできるようになりました 。 今日では、CloudFront は 1 日に 3 兆件を超える HTTP リクエストを処理し、50 か国の 100 を超える都市にある 600 超のポイントオブプレゼンスと 13 のリージョンレベルのエッジキャッシュからなるグローバルネットワークを使用しています。この規模は、極めて要求の厳しいオンラインイベントを実現するのに役立ちます。例えば、 2023 年の Amazon Prime Day では、CloudFront は 1 分あたり 5 億件を超える HTTP リクエスト (合計 1 兆件を超える HTTP リクエスト) のピーク負荷を処理しました。 60 万人を超えるアクティブなデベロッパーが Amazon CloudFront を利用してアプリケーションを構築し、エンドユーザーに配信しています。チームがフルスピードで作業するのをサポートするために、CloudFront は 継続的デプロイ を導入しました。これにより、デベロッパーは、フルデプロイの前にトラフィックの一部で設定変更をテストおよび検証できます。 メディアとエンターテイメント 今では音楽、映画、テレビシリーズを自宅でストリーミングするのが一般的になりましたが、15 年前はまだ DVD をレンタルするのが一般的でした。ストリーミングサーバーの実行は技術的に複雑で、高いパフォーマンスを実現するために必要なグローバルインフラストラクチャにアクセスするには長期契約が必要でした。 まず、技術標準がまだ発展途上であったため、当社はカスタムプロトコルを使用して 音声および動画ストリーミング機能のサポートを追加 しました。多数の視聴者に対応し、高い費用対効果でのライブイベントの配信を簡素化するために、CloudFront は、 ライブ HTTP ストリーミングをリリース し、その直後に Flash ベースのデバイス (当時人気がありました) と Apple iOS デバイスの両方の サポートを改善 しました。 メディア業界がインターネットベースの配信に移行し続ける中、AWS は、Software Defined Video ソリューションのパイオニアである Elemental を買収 しました。Elemental の製品の統合は、放送やコンテンツ制作などのユースケース向けに、動画インフラストラクチャを効率的かつ経済的にスケールする サービス、ソフトウェア、アプライアンス を提供する上で有益でした。 テクノロジーとインフラストラクチャの進化は、 NASA が CloudFront を利用して史上初の宇宙からのライブ 4K ストリーム を行ったときのように、新しい通信方法の実現を可能にしてくれます。 今日では、世界最大級のイベントや主要な動画プラットフォームは CloudFront を利用して、大規模な動画カタログやライブストリームコンテンツを数百万人に配信しています。例えば、CloudFront は、20 以上の主要な放送局のために、 2022 年 FIFA ワールドカップのストリームをグローバルに配信しました 。最近では、Prime Video において、NFL シーズンの サーズデーナイトフットボール のある試合中、CloudFront は 120 Tbps を超えるピークデータ転送を処理し、クリケットワールドカップを世界中の何百万人もの視聴者に配信するのをサポートしました。 今後について この 15 年間で多くのことが変わりましたが、セキュリティ、パフォーマンス、スケーラビリティに重点的に取り組むことに変わりはありません。AWS では常に Day 1 であり、CloudFront チームはフィードバックに基づいて改善する方法を常に模索しています。 ボットネット の台頭により、絶えず進化し、非常に動的で、変化し続ける脅威が増え続けています。レイヤー 7 DDoS 攻撃の増加には歯止めがかからず、ボットトラフィックは急増しています。これに伴い、当社はネットワーク境界、エッジ、リージョンにおける脅威を緩和する方法を進化させ、お客様が適切なセキュリティオプションをより簡単に設定できるようにしています。 ウェブアプリケーションはより複雑かつインタラクティブになっており、レイテンシーと回復力に対する視聴者の期待はさらに厳しくなっています。これにより新たなイノベーションが促進されます。新しいアプリケーションは 生成系人工知能 (AI) を使用するため、ニーズは進化していきます。これらの傾向は今後も拡大し続けることが想定されるため、当社の投資は、これらの新しいユースケースをサポートするセキュリティ機能やエッジコンピューティング機能の改善に重点的に振り向けられます。 現在のマクロ経済環境に鑑みて、多くのお客様、特に中堅中小企業やスタートアップのお客様は、どのようにコストを削減できるかに注目しています。最適な費用対効果を提供することは、CloudFront において常に最優先事項となっています。AWS リソースから CloudFront エッジロケーションに転送されるキャッシュ可能なデータについては、追加料金は発生しません。また、CloudFront からインターネットへの 1 か月あたり 1 TB のデータ転送が無料利用枠に含まれています。CloudFront は、従量制料金モデルで動作し、前払いコストや最小使用量要件はありません。詳細については、「 CloudFront の料金 」をご覧ください。 AWS re:Invent が間もなく開始されるにあたり、最新のイノベーションについて学び、エキスパートとつながるのに役立つ次のセッションにぜひご注目ください。 NET322 | Evolve your web application delivery with Amazon CloudFront NET328 | Live video streaming with Amazon CloudFront and Peacock NET307-R | Ask the experts: Edge compute with Amazon CloudFront ウェブサイトと API を高速化し、保護された状態を維持する方法の詳細については、 AWS デベロッパーセンター の「 Application Security and Performance 」セクションをご覧ください。 Amazon CloudFront を利用してレイテンシーを低減し、アプリケーションのセキュリティを強化しましょう。 – Danilo 原文は こちら です。

楽しみながら生成系 AI について学び、クールなアプリを構築する準備ができているなら、 PartyRock.aws をぜひチェックしてください。実験したり、プロンプトエンジニアリングについて学んだり、ミニアプリを構築したり、アプリを友達と共有したりすることができますが、コードを書いたり、AWS アカウントを作成したりする必要はありません。また、共有されているアプリを土台にして、それをアレンジすることでアプリをさらに強化し、カスタマイズすることもできます。 PartyRock の使用 使用を開始するには、 https://partyrock.aws/ にアクセスしてから [サインイン] をクリックし、Apple、Amazon、または Google のアカウントを使用してログインします。 認証されると、PartyRock のフロントページが表示されます。サンプルアプリをいくつかチェックする、または [独自のアプリを構築] をクリックして、構築を開始することができます。 構築したいアプリの説明を入力してから PartyRock の生成系 AI を使ってスタートダッシュを切ることも、ウィジェットごとに自分でアプリを構築することも可能です。 私は今、 AWS re:Invent のブログ記事にどっぷりとつかっているところです。同僚のほとんどは、草稿が出来上がるのを辛抱強く待ってくれますが、進み具合を何度もたずねてくるせっかちな人も何人かいます (「もうすぐ着く～？」の大人版ですね)。こんな時にもユーモアのセンスを忘れないようにしようとしてはいますが、対応がちょっとばかり皮肉っぽくなってしまうこともあります。では、PartyRock が役立つかどうか見てみましょう。プロンプトを入力してから、 [アプリを生成] をクリックします。 私のアプリ ( Snarky Patient Blogger (皮肉たっぷりな辛抱強いブロガー)) の準備は数秒で整ったので、入力をいくらか書き込んで、私のニーズを満たすに十分な皮肉が出力に込められているかどうかを確認します。 いい感じに仕上がったので、これを分解してどんな仕組みになっているかを見てみましょう! アプリケーション ( Snarky Patient Blogger ) には、 [ユーザー入力] と [皮肉たっぷりな応答] の 2 つのウィジェットがあります。最初のウィジェットの編集アイコンをクリックすると、タイトル、ローディングテキスト、そしてデフォルト値があるのがわかります。タイトルは、ウィジェットがお互いを名前で参照することを可能にします。 このシンプルなウィジェットは、Amazon Bedrock の InvokeModel 関数に対するコールをカプセル化します。ウィジェットは、 Claude v2 モデルの使用と、 [ユーザー入力] ウィジェットを参照するシンプルなプロンプトを指定します。私は、どちらか一方を変更し、変更を保存して、結果が出るまで 1～2 秒待つことで実験できます。例えば、モデルを Claude Instant に変更すると、少し違った応答が返されます。 今度は、返信を視覚的に表現したいと思います。 [テキスト生成] ウィジェットを使用して応答で最も重要な名詞を見つけてから、 [画像生成] ウィジェットを使用して結果を視覚化します。最初のウィジェットを追加して、シンプルなプロンプトを使用します。 再試行 アイコンをクリックしてテストします。出力は申し分ありません。 [画像生成] ウィジェットを追加して、プロンプトを少しばかりいじってみます。1～2 分もすると、思っていたとおりのものができました。 完成したアプリはこんな感じです。 アプリに満足したら、 [公開して共有する] ことができます。 完成したアプリは https://partyrock.aws/u/jeffbarr/E-FXPUkO7/Snarky-Patient-Blogger にあるので、ぜひ遊んでみてください。このアプリは、ログインして [リミックス] をクリックすることで、さらに上を行く独自のアプリを作るための土台として使用することもできます。 ちょっと待ってください、今日はこれだけじゃないんです 私のブログ記事ではよくあることですが、今回もすべての機能をひとつ残らず説明する余裕がありませんでした。私が説明できなかった機能をいくつかご紹介します。 空のアプリ – 私の例ではアプリビルダーを使用しましたが、 [空のアプリから始める] を選択し、ウィジェットを選択して、それらを思いどおりに設定することもできます。 リミックス – 既存のアプリ (私のアプリか、別の公開アプリ) を土台にして、それを [リミックス] することでカスタマイズしたり、強化したりすることができます。 チャットボットウィジェット – プロンプトを出発点として使用して、アプリとやり取りすることができます。 @ 参照 – アプリを構築しているときに、「@」を使用して他のウィジェットを名前で参照できます。 詳細設定 – 一部のウィジェットには詳細設定があります。例えば、テキスト生成ウィジェットには、モデルの [Temperature] パラメータと [Top P] パラメータをコントロールするオプションがあります。 バックステージ – PartyRock のバックステージでは、自分のアプリと、PartyRock クレジットの累計消費量を確認できます。 知っておきたいこと PartyRock について知っておきたい事柄には、次のようなものがあります。 料金 – AWS では PartyRock の新規ユーザーに対して、クレジットカードの提供や AWS アカウントのサインアップが必要ない無料トライアルを期間限定で提供しています。ユーザーが、発生する料金を心配せずに基本的なスキルの取得を開始できるようにするためです。クレジットの消費量は、先ほどご紹介した バックステージ で追跡できます。クレジットの使用は、入力トークン、出力トークン、および生成された画像に基づいて計算されます。詳細については、「 PartyRock FAQ 」の「 Billing and Support 」セクションをお読みください。 モデルアクセス – 追加のモデルへのアクセスを徐々に提供していく予定です。 開発中 – さらに多くのウィジェットと機能に取り組んでいます。今後の情報にご期待ください。 学習リソース – 詳細については、これらのリソースをご覧ください。 PartyRock Getting Started PartyRock FAQ PartyRock Featured Apps パーティータイム 次のステップを決めるのはあなたです。 PartyRock にログインし、クールなアプリを作って、知り合い全員と共有しましょう。皆様のアイディアをお待ちしています! – Jeff ; 原文は こちら です。

本記事では、 AWS AppSync と GraphQL API を活用して、Amazon Bedrock の基盤モデル (FM) とエージェントをパブリック API とプライベート API およびデータベースの両方にシームレスに接続する方法について説明します。 Amazon Bedrock は生成系 AI サービスであり、基盤モデル (FM) で生成系 AI アプリケーションを構築し拡張する最も簡単な方法です。Amazon Bedrock の包括的な機能により、様々なトップクラスの FM を簡単に試すことができ、ファインチューニングや検索拡張生成 (RAG) などのテクニックを使用して、お客様のデータで FM を個別にカスタマイズし、コードを書くことなく複雑なビジネスタスクを実行するマネージドエージェントを作成することができます。AWS AppSync は、複数のマイクロサービス API とデータベースを単一の、自己文書化され、イントロスペクション可能な API エンドポイントに統合する API を構築する最も簡単な方法です。 データを生成系 AI に公開することが新たな課題をもたらす FM に自身のプライベートデータへの管理されたアクセスを提供することで生成系 AI と FM の能力を活用して構築できる新しいアプリケーションの種類は、広がります。しかし、FM にプライベートデータへのアクセスを許可することで、以下のような新たな課題が生じます。 FM に提供される API は自然言語で記述される必要があり、FM は実行可能なアクション、呼び出し方法、返すデータを理解しなければならない。 FM がプライベート API にアクセスする際には、API が詳細なエラーメッセージと、有効な入力の定義を提供する必要がある。 プライベート API への FM のアクセスは、FM が意図しない、破壊的な、または悪意のある行動をとらないように、厳密に制御されるべきである。 FM とそのエージェントによって行われるアクションは、多様なシステムとデータストアに渡って監視され、ログに記録される必要がある。 FM を企業データに接続する方法は様々あります。例えば、Amazon Bedrock エージェント は、FM を文書化された REST API に接続する簡単な方法を提供します。しかし本記事では、カスタム FM エージェントと GraphQL API を使用して FM をプライベートデータに接続するメリットを探ります。AWS AppSync と GraphQL を使用することで、単一の、自己文書化された、そして機械が挿入可能な API を介して、すべてのプライベートデータへのアクセスを FM に提供することができます。これにより、FM は利用可能な企業データに簡単にアクセスし、理解し、対話することができます。また、単一の GraphQL API エンドポイントを通じてプライベートデータへの FM アクセスをルーティングすることで、FM のアクションを保護、管理、観察するシンプルな方法を提供します。本記事では、GraphQL と AWS AppSync に支えられた、FM とデータ間の接続レイヤーとして機能するアーキテクチャについて説明します。しかしその前に、FM が外部データとどのように連携するかを見てみます。 FM が外部データを利用する方法 ここ数ヶ月、そしてここ数年の人工知能の進歩の速さには目を見張るものがあります。モデルはより強力になり続け、できることを新たな高みへと押し上げています。モデルにどのように質問するか (プロンプトエンジニアリング ) を探求した結果、 reAct の論文 にあるような斬新なテクニックが生まれました。このプロンプトアプローチでは、FM は現在の会話とどのような行動をとることができるかについてのデータを提供され、その後、FM は理由 (Reason)、行動 (Action)、観察 (Observation) のステップのプロセスを通じて、抽象的な問題を解決するためのステップを踏むよう求められます。 このプロンプトを視覚化した例を見てみます。下の図では、オレンジ色のハイライトが FM によって生成されます。 まず、すべてのプロンプトアプローチの鍵となるのは、FM が何をするよう求められているのか、どのように行動すべきなのかを説明することです。また、FM はどのような行動をとることができるかも説明されます。簡潔にするために、問題のアクションの完全な説明は含まれていませんが、FM はどのような操作にアクセスでき、それぞれをどのように呼び出すことができるのかについての詳細な説明が必要です。後述する作業例では、queryDatastore オペレーションが何をするのか、どのような形式でデータが欲しいのか、どのようなタイプが利用可能なのかについてより詳細に説明します。 FM は現在の状態についてどう考え、次のステップとして何を考慮すべきかを自然言語で記述したものである Reason (理由) を提供するように要求されます。 次に FM は取りたい具体的な行動 (Action) を求められます。 FM 生成はこのステップで一時停止し、FM が要求した所定のアクションを呼び出します。このアクションは、データベースクエリであったり、ワークフローの実行であったり、ベクターストアとのインターフェイスであったり、FM が必要とするものであれば何でもかまいません。その出力は、アクションの観察 (Observation) として会話履歴に返されます。 その後、FM は再び応答することができます。上の例では、FM は答えを知っていることを示しますが、もし観察の結果が予期せぬものであったり、全体像が摑めなかった場合は、他にどのようなデータが必要なのかを推論する機会となります。 答えにたどり着いた FM は、”submit answer” ツールの起動を要求するため、プロセスを停止し、これを答えとして記録します。 GraphQL と AWS AppSync で FM をプライベートデータに接続する方法 AWS AppSync は、開発者が安全でタイプセーフかつ柔軟な GraphQL API を作成することを可能にし、構築されたデータグラフに対してデータを読み取り、操作するために入力されるリクエストを解析、型チェック、認証、解決するスキーマを提供します。このように、AWS AppSync はデータの上にセキュアでタイプセーフなレイヤーとして配置されます。認可は、どのデータストアにデータが保存されているかに関わらず、定義したデータタイプの各フィールドに対して設定することができる。型はオプションとしてマークすることができ、サブ型や再帰参照を含むことができます。このような構成により、使いやすく説明的なクエリ言語を備えた 柔軟性の高いデータグラフ を作成することができます。 アクション定義としてのスキーマ定義 AWS AppSync は、明確に定義された構造で API が何を行うかを定義する GraphQL Schema 上でネイティブに動作します。説明のために、この例では自動車ディーラーの API について説明します。AWS AppSync におけるそのような API の部分的なスキーマは次のようになります。 type Car { id: ID! model: String! make: String! year: Int! color: String! price: Int! } type Query { # Gets all the cars for sale in your dealership listCars: [Car!]! } プロダクションスキーマはより多くの型を提供し、 mutation 操作 を含み、フィールド呼び出しに期待されるパラメータを持つことができる。上記のGraphQLスキーマでは、定義によって、車の色、年式、価格をすべて取得するクエリーリクエストは次のように記述できることが明確になっています。 query { listCars { color year price } } コメントはスキーマ定義自体の一部でさえあり、各フィールドの存在理由や各フィールドの用途について FM にガイダンスを提供することができます。最も優れている点は、GraphQL には特別な イントロスペクション 操作があり、FM が必要に応じてスキーマ定義を問い合わせることができることです。 簡単に言うと、GraphQL API は人間が読めるように設計されているため、FM も読むことができます。FMがプライベート API を理解し、それらに対して query や mutation を構築するには、単純なイントロスペクションクエリーで十分です。 組み込みタイプセーフと自然言語エラー AWS AppSync は、リクエスト受信時にスキーマに対して query を安全に解析します。フィールドを整数として定義した場合、AWS AppSync はそれが他のものであれば呼び出すことを許可せず、FM のクエリを特別に解析する必要性を取り除きます。 これはまた、不正なフォームや不正な型付けのリクエストは、何が間違っていたのかを説明する明確なエラーメッセージを返すことを意味します。存在しない値を要求した場合、AWS AppSync は FM が読めるエラーメッセージを返します。 query { listCars { colors id } } Validation error of type FieldUndefined: Field 'colors' in type 'Car' is undefined このような自然言語によるエラーメッセージは、FM を正しい query に導き、ミスを犯したときに FM が自ら誤りを取り消すことを可能にします。 デフォルトで認証 AWS AppSync はフィールド単位で認証を提供し、AWS Identity and Access Management (IAM), Amazon Cognito, OIDC, API Keys, そして AWS Lambda によるカスタム認証ロジックもサポートしています。FM がフィールドを呼び出したり、特定のデータを閲覧したりすることを防止または制限したい場合、他のユーザーが通常通り API を使用できるようにしながら、それを暗黙的に実現するために必要なすべてのオプションが用意されています。 特定の操作が呼び出されないようにしたい場合は、AWS AppSync が提供する認証モードのいずれかを使って権限を拒否できます。これは、バックエンドのデータグラフ全体に公開することなく、どのようなアクションが実行されるかを FM に洞察させることができます。 mutation { sendEmail( title: "Sample Email", to: "joe.schmo@amazon.com" body: "Hey this is a test of an AppSync send-email resolver!" ) } Not Authorized to access sendEmail on type Mutation AWS AppSync GraphQL API は 1 つまたは複数のデータストアを組み合わせることができるため、FM がプライベートデータに対してどのような操作を行うことができ、どのような操作を行うことができないかを 1 か所で設定し、制御することができます。FM は、このようなエラーメッセージをアプリケーションユーザーに伝えたり、エラーの原因にならない別のアプローチを試したりすることができます。また、FM が実行できるアクションを定義、制限するために、呼び出すユーザーの権限を使用することもできます。このようにすることで、FM は起動ユーザーの権限以上の昇格権限を持たないので、混乱した代理攻撃への露出を制限することができる。 設定可能なログソリューション AWS AppSync には、メトリクス、API からのログストリーム、リゾルバロジックに書き込まれたカスタムロギングオプションを含む、カスタマイズ可能な 詳細なロギングレベル も付属しています。これにより、FM がどのクエリ、フィールド、リゾルバ、データにアクセスできたか、またはアクセスを拒否されたかを明確に可視化できます。これにより、開発者は FM のアクションを完全に可視化し、監査することができます。 AWS AppSync と GraphQL によるデータフローの例 以下の図は、FM がバックエンド API に対して抽象的な問題を解決するように要求されたときに、サンプルリクエストが取る経路です。 順を追って説明すると、以下のようになります。 上の例では、Lambda 関数の LangChain を使って reAct ソルバーを実装していますが、このアーキテクチャはどんなコンピューティングサービスにも使えます。今回はシンプルにするために Lambda を選択しました。 AWS AppSync は イントロスペクションクエリ を通してユーザにスキーマをネイティブに公開しているので、このスキーマを FM プロンプトのアクションスペース定義として使うことができます。プロンプトのエンジニアリングは必要ありませんが、スキーマの GraphQL フィールドに説明を追加することで、API の直感的でないルートをスムーズに処理することができます。 FM モデルの最初の呼び出しです。FM は理由 (Reason) とアクション (Action) 出力ステップの両方を提供するよう促されます。ストップワードを使用することで、この結果以外で応答しないようにすることができます。 AWS AppSync リアルタイム subcription を使用すると、呼び出しの理由とアクションがエンドユーザーアプリケーションですぐに利用できるようになり、FM エージェントの中間アクションを実行しながらリアルタイムでユーザーが対話できるようになります。この機能がなければ、ユーザはフィードバックもなく、何分も結果を待つことになるかもしれません。 生成されたアクションで、AWS AppSync API が呼び出され、FM によって要求された結果を取得します。これはタイプセーフで、IAM セキュリティによってバックアップされ、可観測性のために Amazon CloudWatch ロギングを含みます。 データは最終的に接続された AWS AppSync データソースから引き出されます。AWS AppSync は、Amazon DynamoDB、Amazon Relational Database Service (Amazon RDS)、AWS Lambda、 その他多くの AWS サービス との接続をネイティブにサポートしてます。これらのデータ接続は JavaScript リゾルバを通して行われ、追加の認証やデータ変換のニーズに対して追加のロジックを提供することができます。 FM モデルは query の結果を持っており、2 回目のプロンプトが表示されます。FM は “最終的な答え” を出力することができ、その結果はユーザーに公開されるか、”理由＋アクション” の結果を出力することができます。 まとめ 本記事では、AWS AppSync とGraphQLが、FM とプライベートデータ間の接続レイヤーとしてどのように自然にフィットするかを説明しました。このように、AppSync を活用することで、FM に必要なデータを提供し、ネイティブの機能を超えて拡張することができます。 本記事は、「 Connect Amazon Bedrock to your data with AWS AppSync and GraphQL 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

データ保持ポリシーへのコンプライアンスを強化するために、個々の Amazon Elastic Block Store (Amazon EBS) スナップショットをロックできるようになりました。ロックされたスナップショットは、ロックの有効期限が切れるか、またはロックが解除されるまで削除できないため、意図しない削除や、ランサムウェア攻撃などの悪意のある削除から、重要なバックアップを安全に維持できます。 ロックの必要性 AWS のお客様は、バックアップ、ディザスタリカバリ、データ移行、コンプライアンスのために EBS スナップショットを使用しています。金融サービスやヘルスケア分野のお客様は多くの場合、所定の保持期間にわたって特定のコンプライアンス要件を満たす必要があるほか、スナップショットが真に Write Once Read Many (WORM) であるようにする必要もあります。これらの要件を満たすために、お客様は、複数の AWS アカウントを使用し、それらの間に一方向の「エアギャップ」を備えたソリューションを実装しました。 EBS スナップショットロック 新しい EBS スナップショットロック機能は、カスタムソリューションを必要とせずに、保持とコンプライアンスの要件を満たすのに役立ちます。1 日から約 100 年の範囲で設定できるロック期間を使用して、新規および既存の EBS スナップショットをロックできます。スナップショットは指定された期間にわたってロックされ、削除することはできません。 次の 2 つのロックモードが用意されています。 [ガバナンス] – このモードは、すべてのユーザーによる削除からスナップショットを保護します。ただし、適切な IAM 許可がある場合は、ロック期間の延長または短縮、ロックの削除、[ガバナンス] モードから [コンプライアンス] モードへのモード変更が可能です。 [コンプライアンス] – このモードは、ルートユーザーおよびすべての IAM ユーザーによるアクションからスナップショットを保護します。最大 72 時間のクーリングオフ期間が経過した後は、ロック期間が経過するまでスナップショットとロックのいずれも削除できず、モードを変更することもできません。適切な IAM 許可がある場合、ロック期間を延長することはできますが、短縮することはできません。 どちらのモードでも、スナップショットを共有またはコピーすることはできます。これらは、低コストの Amazon EBS Snapshots Archive 層にアーカイブできます。また、既にアーカイブされたスナップショットにロックを適用できます。 スナップショットロックの使用 EBS コンソールからスナップショット (Snap-Monthly-2023-09) を選択し、 [アクション] メニューの [スナップショットの設定] から [スナップショットロックを管理] を選択します。 これは月次スナップショットであり、私はこれを 1 年間ロックしたいと考えています。 [ガバナンス] モードを選択し、期間を選択してから、 [ロックの設定を保存] をクリックします。 このスナップショットを削除しようとすると、次のように削除が失敗します。 次に、 [コンプライアンス] モードを使用して、年次スナップショットの 1 つを 5 年間ロックしたいと思います。 考えが変わった場合に備えて、クーリングオフ期間を 24 時間に設定します。おそらく、スナップショットを 5 年間保持することを確定する前に、スナップショットに対して何らかの監査や最終日付の検証を実行する必要があるでしょう。 EBS スナップショットのロックを確立および制御するために、プログラムで新しい API 関数を使用できます。 LockSnapshot – ガバナンスモードまたはコンプライアンスモードでスナップショットをロックするか、または既にロックされているスナップショットの設定を変更します。 UnlockSnapshot – ガバナンスモードのスナップショット、またはコンプライアンスモードに設定されているが、クーリングオフ期間内のスナップショットのロックを解除します。 DescribeLockedSnapshots – ロックの状態に基づくオプションのフィルタリングを使用して、スナップショットのロックステータスに関する情報を取得します。 これらの機能を使用するには、適切な許可 ( ec2:lockSnapshot 、 ec2:UnlockSnapshot 、 ec2:DescribeLockedSnapshots ) が IAM ユーザーに付与されている必要があります。 知っておくべきこと この新機能に関して留意すべき点がいくつかあります。 AWS Backup – AWS Backup は、作成したスナップショットの保持を独立して管理します。これらをロックすることは推奨されていません。 料金 – この機能の使用には追加料金はかかりません。スナップショットおよびアーカイブされたスナップショットのストレージの通常料金はお支払いいただきます。 リージョン – EBS スナップショットロックは、すべての商用 AWS リージョンでご利用いただけます。 KMS キーの保持 – EBS ボリュームとスナップショットの暗号化にカスタマーマネージド AWS Key Management Service (AWS KMS) キーを使用している場合は、スナップショットの存続期間中、キーが有効であり続けるようにする必要があります。 – Jeff ; 原文は こちら です。

本記事では、私たちがロードマップを公開している自動車会社であると想像してみましょう。私たちには世界中のユーザーがいて、車載エンターテイメントシステムにどのような機能が提供されたかを定期的にチェックしています。 ここでは、プロダクトマネージャーがログインしてロードマップを更新し、ロードマップページに反映させるための管理ページを構築します。 ロードマップページは世界中の多くの読者が閲覧し、更新頻度が低いため、Incremental Static Regeneration (ISR) を用いた Static Site Generator (SSG) の最適な候補になります。 本記事では、「 Deploy a Next.js 13 app with authentication to AWS Amplify 」を基に開発し、プロジェクトの初期化、Amazon Cognito 認証の実装、Amplify Hosting へのデプロイを行います。 GraphQL API のデプロイ プロジェクトのルートディレクトリで以下のコマンドを実行し、データを保存する GraphQL API を追加します。 amplify add api Amplify CLI のプロンプトには以下のように答えます。 ? Select from one of the below mentioned services: (Use arrow keys) ❯ GraphQL REST ? Here is the GraphQL API that we will create. Select a setting to edit or continue (Use arrow keys) Name: testamplify Authorization modes: API key (default, expiration time: 7 days from now) Conflict detection (required for DataStore): Disabled ❯ Continue ? Choose a schema template: Single object with fields (e.g., “Todo” with ID, name, description) One-to-many relationship (e.g., “Blogs” with “Posts” and “Comments”) ❯ Blank Schema ? Do you want to edit the schema now? (Y/n) › Y 次に、 schema.graphql の内容を以下のように書き換えます。 type Feature @model @auth(rules: [{ allow: owner }, { allow: public, operations: [read] }]) { id: ID! title: String! released: Boolean! description: String internalDoc: String } 最後に、以下のコマンドを実行し、API をデプロイします。 amplify push 次に、プロダクトマネージャがロードマップを作成、更新、削除するための管理画面を作成します。 pages/admin.js ファイルを作成し、以下のコードを追加して、このシリーズの 最初の投稿 で行ったように、Amplify の withAuthenticator コンポーネントを使用し、Cognito で認証を行うページを作成します。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; function Admin() { // define state to be used later const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> <Flex justifyContent={"space-between"}> <Link href={"/admin"}> <Heading level={2}>AmpliCar Roadmap Admin</Heading> </Link> <Flex alignItems={"center"}> <Button type="button" onClick={() => Auth.signOut()}> Sign out </Button> </Flex> </Flex> <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex></Flex> </View> ); } export default withAuthenticator(Admin); ここでは、管理ページ用の React コンポーネント Admin を作成します。 aws-amplify/ui-react パッケージの withAuthenticator コンポーネントを使用して、認証機能をコンポーネントに追加します。 また、このコンポーネントは Amplify UI の Button 、 Divider 、 Flex 、 Heading 、 View コンポーネントをインポートして使用し、サインアウトボタン、ディバイダー、後で使用するレイアウト要素を含むトップナビゲーションバーをレンダリングします。 サインアウトボタンがクリックされると、 Auth.signOut() メソッドが呼び出され、ユーザーがサインアウトします。 最後に、状態を管理するための React の useState フックを使って、 activeFeature と setActiveFeature で状態を追加します。 ブラウザで http://localhost:3000/admin にアクセスすると以下のような画面が表示されます。 アカウントを作成してサインインすると、ヘッダーにサインアウトボタンが表示されます。 ロードマップの機能を作成・更新するためのフォームを作成します。 プロジェクトのルートディレクトリに components ディレクトリを作成し、 FeatureForm.js 作成し、以下のコードに置き換えます。 // components/FeatureForm.js import { Button, Flex, Heading, SwitchField, Text, TextField, View, } from "@aws-amplify/ui-react"; import { API } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { createFeature, updateFeature } from "../src/graphql/mutations"; function FeatureForm({ feature = null, setActiveFeature }) { const [id, setId] = useState(undefined); const [title, setTitle] = useState(""); const [description, setDescription] = useState(""); const [isReleased, setReleased] = useState(false); useEffect(() => { if (feature) { setId(feature.id); setTitle(feature.title); setDescription(feature.description); setReleased(feature.released); } }, [feature]); function resetFormFields() { setId(undefined); setTitle(""); setDescription(""); setReleased(false); } async function handleSaveFeature() { try { await API.graphql({ authMode: "AMAZON_COGNITO_USER_POOLS", query: feature ? updateFeature : createFeature, variables: { input: { id: feature ? id : undefined, title, description, released: isReleased }, }, }); feature && setActiveFeature(undefined); resetFormFields(); } catch ({ errors }) { console.error(...errors); throw new Error(errors[0].message); } } return ( <View> <Heading marginBottom="medium" level={5}> {feature ? "Edit" : "New"} Feature </Heading> <Flex direction={"column"} basis={"max-content"}> <TextField value={title} label="Title" errorMessage="There is an error" name="title" onChange={(e) => setTitle(e.target.value)} /> <TextField value={description} name="description" label="Description" errorMessage="There is an error" onChange={(e) => setDescription(e.target.value)} /> <SwitchField isChecked={isReleased} isDisabled={false} label="Released?" labelPosition="start" onChange={() => setReleased(!isReleased)} /> <Flex marginTop="large"> <Button onClick={() => { setActiveFeature(undefined); resetFormFields(); }} > Cancel </Button> <Button onClick={() => handleSaveFeature()}>Save</Button> </Flex> </Flex> </View> ); } export default FeatureForm; このコードでは、 FeatureForm という React コンポーネントを定義します。 FeatureForm コンポーネントは、 feature props と setActiveFeature props を受け取ります。これらは、フォームフィールドにデータを入力し、保存された後にフォームをリセットするために使用されます。コンポーネントは useState フックを使用して、機能のタイトル、説明、リリース済みかどうかを含むフォームフィールドの状態を追跡します。 コンポーネントがレンダリングされると、 feature props が渡されたかどうかをチェックし、渡された場合は useEffect フックを使ってフォームフィールドに機能を入力します。そうでなければ、フォームフィールドは空のままです。 このコンポーネントには、機能のタイトル、説明、リリースステータスを入力するためのいくつかのフォームと、保存ボタンとキャンセルボタンがあります。 save ボタンがクリックされると、コンポーネントは API.graphql を介して createFeature mutation を発行し、その機能を GraphQL API を使用して保存します。コンポーネントが feature props でレンダリングされた場合、 updateFeature mutation を使用してデータベース内の既存の機能を更新します。 機能が保存された後、コンポーネントはフォームフィールドをリセットし、オプションで setActiveFeature コールバック props を呼び出して Admin コンポーネントの activeFeature をリセットします。 pages/admin の Admin コンポーネントを更新して FeatureForm コンポーネントを追加し、ロードマップ管理画面に表示されるようにします。また、機能を編集しているかどうかを追跡するステート変数を追加します。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; function Admin() { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature**={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); ページを更新すると、新機能フォームが表示されます。 次に、機能の一覧を表示し、編集や削除を可能にするテーブルを作成しましょう。 components ディレクトリに新しく FeaturesTable コンポーネントを作成し、以下のコードを貼り付けます。 // components/FeaturesTable.js import { Button, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { API, graphqlOperation } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { deleteFeature } from "../src/graphql/mutations"; import { listFeatures } from "../src/graphql/queries"; function FeaturesTable({ initialFeatures = [], setActiveFeature }) { const [features, setFeatures] = useState(initialFeatures); useEffect(() => { const fetchFeatures = async () => { const result = await API.graphql(graphqlOperation(listFeatures)); setFeatures(result.data.listFeatures.items); }; fetchFeatures(); }, []); async function handleDeleteFeature(id) { try { await API.graphql({ authMode: "AMAZON_COGNITO_USER_POOLS", query: deleteFeature, variables: { input: { id, }, }, }); } catch ({ errors }) { console.error(...errors); } } if (features.length === 0) { return <View>No features</View>; } return ( <Table> <TableHead> <TableRow> <TableCell as="th">Feature</TableCell> <TableCell as="th">Released</TableCell> <TableCell></TableCell> </TableRow> </TableHead> <TableBody> {features.map((feature) => ( <TableRow key={feature.id}> <TableCell>{feature.title}</TableCell> <TableCell>{feature.released ? "Yes" : "No"}</TableCell> <TableCell> <Button size="small" onClick={() => setActiveFeature(feature)}> Edit </Button> <Button size="small" onClick={() => handleDeleteFeature(feature.id)} > Delete </Button> </TableCell> </TableRow> ))} </TableBody> </Table> ); } export default FeaturesTable; このコードでは、 FeaturesTable という React コンポーネントを定義し、機能のテーブルをレンダリングします。テーブルには、各機能のタイトルとリリース済みかどうかが表示され、各機能を編集および削除するためのボタンが用意されています。 このテーブルは、Amplify UI の Table 、 TableBody 、 TableCell 、 TableRow コンポーネントを使用してレンダリングされます。 FeaturesTable コンポーネントは、オプションで initialFeatures の配列と setActiveFeature 関数を props として受け取ります。 useState フックを使用して features ステート変数に features リストを格納し、 useEffect フックを使用してコンポーネントのマウント時に GraphQL API から features リストを取得します。 handleDeleteFeature 関数は、 deleteFeature mutation を呼び出して機能を削除するために使用します。 handleDeleteFeature 関数は、テーブル内の各機能の削除ボタンに props として渡され、ボタンがクリックされると、対応する機能が削除されます。 編集ボタンがクリックされると、クリックされた機能を引数として setActiveFeature 関数が呼び出されます。これにより、 Admin コンポーネントの activeFeature ステート変数が更新され、 FeatureForm コンポーネントが再レンダリングされます。これにより、ユーザーはフォームを使って選択した機能を編集できるようになります。 次に、 Pages/admin.js を更新して、 FeaturesTable コンポーネントを追加します。 // pages/admin.js import { // ... withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; import FeaturesTable from "../components/FeaturesTable"; function Admin() { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature={setActiveFeature} /> <FeaturesTable setActiveFeature={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); このコンポーネントを追加してリフレッシュすると、まだ機能を追加していないため、No features と表示されるはずです。 Server-Side Rendering（SSR）によるユーザー体験の向上 優れたユーザー体験を提供するために、Server-Side Rendering (SSR) を使って機能を取得するように管理ページを更新しましょう。SSR を使うことで、データなしでページをレンダリングし、別のネットワークリクエストが完了し、データが入力されるのを待つよりも優れたユーザー体験を提供することが出来ます。 // pages/admin.js import { Button, Divider, Flex, Heading, View, withAuthenticator, } from "@aws-amplify/ui-react"; import { Auth, withSSRContext } from "aws-amplify"; import Link from "next/link"; import React, { useState } from "react"; import FeatureForm from "../components/FeatureForm"; import FeaturesTable from "../components/FeaturesTable"; import { listFeatures } from "../src/graphql/queries"; export async function getServerSideProps({ req }) { const SSR = withSSRContext({ req }); const response = await SSR.API.graphql({ query: listFeatures }); return { props: { initialFeatures: response.data.listFeatures.items, }, }; } function Admin({ initialFeatures }) { const [activeFeature, setActiveFeature] = useState(undefined); return ( <View padding="2rem"> // ... <Divider marginTop={"medium"} marginBottom={"xxl"} /> <Flex> <FeatureForm feature={activeFeature} setActiveFeature={setActiveFeature} /> <FeaturesTable initialFeatures={initialFeatures} setActiveFeature={setActiveFeature} /> </Flex> </View> ); } export default withAuthenticator(Admin); このコードでは、 getServerSideProps を使用して、 listFeatures query で Amplify API.graphql を呼び出し、サーバー上の React コンポーネントに注入される props オブジェクトで初期の機能を返します。 Admin コンポーネントは initialFeatures を受け取り、 FeaturesTable コンポーネントに渡します。 新機能フォームで、機能を追加してページをリフレッシュすると、右側のテーブルに表示されます。 リアルタイム更新によるユーザー体験の向上 これまで構築したものは動作しますが、プロダクトマネージャーが最新の機能を見るためにページを更新する必要があり、最高のユーザー体験を提供するものではありません。 以下のコードでは、この機能を実装するために Amplify の GraphQL Subscription を使ってデータをサブスクライブします。 // components/FeaturesTable.js import { Button, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { API, graphqlOperation } from "aws-amplify"; import React, { useEffect, useState } from "react"; import { deleteFeature } from "../src/graphql/mutations"; import { listFeatures } from "../src/graphql/queries"; import { onCreateFeature, onDeleteFeature, onUpdateFeature, } from "../src/graphql/subscriptions"; function FeaturesTable({ initialFeatures = [], setActiveFeature }) { const [features, setFeatures] = useState(initialFeatures); useEffect(() => { const fetchFeatures = async () => { const result = await API.graphql(graphqlOperation(listFeatures)); setFeatures(result.data.listFeatures.items); }; fetchFeatures(); const createSub = API.graphql(graphqlOperation(onCreateFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => [...features, value.data.onCreateFeature]); }, }); const updateSub = API.graphql(graphqlOperation(onUpdateFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => { const toUpdateIndex = features.findIndex( (item) => item.id === value.data.onUpdateFeature.id ); if (toUpdateIndex === -1) { return [...features, value.data.onUpdateFeature]; } return [ ...features.slice(0, toUpdateIndex), value.data.onUpdateFeature, ...features.slice(toUpdateIndex + 1), ]; }); }, }); const deleteSub = API.graphql(graphqlOperation(onDeleteFeature)).subscribe({ next: ({ value }) => { setFeatures((features) => { const toDeleteIndex = features.findIndex( (item) => item.id === value.data.onDeleteFeature.id ); return [ ...features.slice(0, toDeleteIndex), ...features.slice(toDeleteIndex + 1), ]; }); }, }); return () => { createSub.unsubscribe(); updateSub.unsubscribe(); deleteSub.unsubscribe(); }; }, []); // remainder of FeaturesTable component unmodified } export default FeaturesTable; ここでは、 createSub 、 updateSub 、 deleteSub Subscription を useEffect に追加し、AppSync から onCreateFeature 、 onUpdateFeature 、 onDeleteFeature のいずれかの Subscription に対してプッシュされたデータの変更をリッスンします。 それぞれのクエリに対して、subscribe に渡されたオブジェクトの次の関数を介して、アプリケーションを更新するロジックを実装しなければなりません。 createSub は、 setFeatures を呼び出し、Subscription 経由で受け取ったレコードを渡すことで、 features に新しいレコードを追加します。 updateSub は、変更されたレコードを検索し、features 内のレコードを Subscription から返されたバージョンに置き換えるコールバックを実装します。 deleteSub は、変更されたレコードを検索し、 features から削除するコールバックを実装します。 最後に、Subscription をクリーンアップするために、それぞれの Subscription の unsubscribe メソッドへの呼び出しを返します。 管理画面でアイテムを作成したり編集したりすると、機能リストがすぐに更新されることがわかります。 本記事では、プロダクトマネージャーがロードマップに機能を追加するための管理インターフェイスを構築しました。次の記事では、ユーザー向けのページを実装し、その機能に関連する内部ドキュメントを保存する機能を追加します。 本記事は「 Build a Product Roadmap with Next.js and Amplify 」を翻訳したものです。

AWS Resource Explorer を利用すると、 AWS リージョン 全体で、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Kinesis データストリーム、 Amazon DynamoDB テーブルなどのリソースを検索および検出できます。11月14日より、 組織 内のアカウント全体も検索できるようになりました。 わずか数分で、組織全体または特定の組織単位 (OU) のために Resource Explorer をオンにして設定し、シンプルな自由形式のテキストとフィルター検索を使用して、アカウントおよびリージョン全体で関連する AWS リソースを見つけることができます。 マルチアカウント検索は、 Resource Explorer コンソール で、もしくは 統合検索バー (すべての AWS コンソールページの上部にある検索バー) を通じて AWS マネジメントコンソール のあらゆる場所で、または AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS Chatbot を使用してご利用いただけます。このような方法により、リソースを迅速に見つけ、適切なアカウントおよびサービスに移動して、アクションを実行できます。 Well-Architected な態様で運用する場合は、ビジネスアプリケーションとデータを分離して管理するのに役立つよう、複数の AWS アカウントが使用されます。Resource Explorer を利用して、アカウントをまたいでリソースを探索し、大規模に使用する方法を簡素化できるようになりました。例えば、Resource Explorer は、運用コストの増加の調査、パフォーマンスの問題のトラブルシューティング、セキュリティアラートに基づく是正を行う際に、組織全体で影響を受けるリソースを特定するのに役立ちます。 これが実際にどのように機能するのかを見てみましょう。 マルチアカウント検索の設定 次の 4 つのステップで組織のためにマルチアカウント検索を設定できます。 AWS アカウント管理 のために 信頼されたアクセス を有効にします。 検索する組織または OU 内のすべてのアカウントで Resource Explorer を設定します。これは、 AWS Systems Manager Quick Setup を使用して 、数回クリックするだけで実行できます。オプションで、 AWS CloudFormation または使い慣れた他の管理ツールを使用できます。 必須ではありませんが、AWS アカウント管理用の 委任された管理者アカウント を作成することをお勧めします。その後、マルチアカウントの作成に必要なすべての許可を一元化するために、委任された管理者アカウントを使用して Resource Explorer のマルチアカウントビューを作成することをお勧めします。 最後に、マルチアカウントビューを作成して、組織全体の検索を開始できます。 マルチアカウントビューの作成 前述のリストの最初の 3 つのステップは既に実施しました。委任された管理者アカウントを使用して、 Resource Explorer コンソール に移動します。コンソールの [リソースを詳しく見る] セクションで [ビュー] を選択し、ビューを作成します。 ビューの名前を入力し、 [組織全体のリソースの可視化] を選択します。これにより、組織全体または特定の OU 内のアカウントにあるリソースを表示できるようになります。このビューでは、組織全体を選択します。 [リージョン] で、アグリゲーターインデックスがあるリージョンを選択します。アグリゲーターインデックスには、Resource Explorer がオンになっている他のすべてのリージョンにあるローカルインデックスのレプリケートされたコピーが含まれています。オプションで、このビューに含めるリソースを制限するためにフィルターを使用できます。すべてのリソースと、タグなどの追加のリソース属性を含めることを選択します。 その後、ビューの作成を完了します。ビューに対するアクセスを許可することで、Resource Explorer で誰がどのリソース情報にアクセスできるかを制御できるようになりました。 マルチアカウント検索の使用 新しいマルチアカウントビューを試すには、ナビゲーション ペインの [リソースを詳しく見る] セクションから [リソースの検索] を選択します。私のクエリでは、古いバージョンの Redis 用の Amazon ElastiCache リソースがあるかどうかを確認したいと考えています。 [クエリ] フィールドに elasticache:* redis3.2 と入力します。 結果には、これらのリソースが存在するさまざまな AWS アカウントおよびリージョンが表示されます。私のアカウントのリソースについては、最初の列にリンクが含まれており、これをクリックするとコンソールでそのリソースが開きます。他のアカウントのリソースについては、適切なアカウントとサービスでコンソールを使用して、詳細情報を取得したり、アクションを実行したりできます。 知っておくべきこと マルチアカウント検索は、次の AWS リージョンでご利用いただけます: [[ リージョン ]]。 マルチアカウント検索を含め、AWS Resource Explorer の利用に追加料金はかかりません。 組織内の他のアカウントとビューを共有するには、委任された管理者アカウントを使用して、組織内のリソース、リージョン、アカウントに関して必要な表示設定を備えたビューを作成してから、 AWS Resource Access Manager を利用してビューに対するアクセスを共有することをお勧めします。例えば、特定の OU のビューを作成し、その後にその OU 内のアカウントとビューを共有できます。 AWS Resource Explorer を利用して、組織内のアカウント全体およびリージョン全体で関連するリソースを検索して見つけましょう。 – Danilo 原文は こちら です。

地理空間アプリケーションは、インタラクティブな地図から位置情報サービスまで、私たちの日常生活に欠かせないものとなっています。このようなアプリケーションの需要が高まる中、開発者は信頼性の高い地理空間ソリューションを構築するための強力で安全なツールを必要としています。Amazon Web Services (AWS) は最先端のサービスを提供すしており、最近では Amazon Location Service の API キーと認証ヘルパーを発表し、地理空間アプリ開発者にエキサイティングな機会をもたらしました。本記事では、 API キー 、 Amazon Location Service Auth Helper Library 、 Amazon Location Service Data Types Converter Library を活用して、機能豊富な地理空間アプリケーションを構築する方法を紹介します。 Amazon Location Service の新しいリリース 技術的な詳細に入る前に、 Amazon Location Service の最新の機能拡張について簡単に説明します。Amazon Location Service は最近、開発者が Amazon Location Service API に安全にアクセスするための追加オプションを提供する API キーを発表しました。API キーを利用することで、地理空間データやサービスへのアクセスを制御しやすくなり、許可されたユーザーのみがアプリケーションとやり取りできるようになり、より幅広いアプリケーションやツールへのアクセスが可能になります。 さらに、 Amazon Location Service Auth Helper Library をリリースしました。これは、開発者の認証エクスペリエンスを合理化するための貴重なリソースです。このライブラリは、 Amazon Location Service の認証のユースケースを合理化するように設計されており、データの保護と開発者のスムーズな体験を保証します。 API キーは、API への認証とアクセス制御に使用される一意の識別子です。この機能を使用することで、特定のドメインや特定の Amazon Location Service リソースへのアクセスを制限するなど、きめ細かなレベルでアクセスを管理することができます。 この機能は、セキュリティを強化し、アプリケーションのパフォーマンスを向上させるために設計されています。Amazon Location Service API キーは、アプリケーションのユーザーに対して特定のアクションへの読み取り専用アクセスを可能にします。アプリケーションのフロントエンドにキーを埋め込むことで、他の認証方法に関連する複数の呼び出しを削除し、待ち時間を改善することができます。このアプローチは API の使用状況を監視し、クォータとキーのローテーションを使用して、リソースの消費を管理し、乱用を防ぐことを可能にします。API キー機能は Amazon Location Service Auth Help Library に統合され、プレースやルートの機能へのアクセス管理がより簡単になりました。 本記事では、API キーと新しい Auth Helper Library の機能をデモンストレーションし、地理空間アプリケーションの構築プロセスを紹介します。 APIキーの作成 API キーを作成する前に、 Amazon Location リソースを作成します。 マップ 、 プレース 、 ルート のガイドに従って、本記事で使用するリソースを作成します。Amazon Location リソースの作成中に、各リソースの API キーを設定するようプロンプトが表示されることに注意してください。API キーを作成してからリソースをリンクするので、この設定ステップは省略できます。 Amazon Location リソースを作成したら、API キーを作成します。今回は、マップ、プレース、ルート で使用できる 1 つの API キーを作成します。 Amazon Location コンソールに移動し、 API Keys を選択します。 ここで Create API key を選択します。 API キーに名前を付け、前のステップで作成したリソースを選択します。 次に、権限とその他の API キー設定オプションを定義します。 キーがアクセスできる読み取り専用の API アクションを定義することができます。今回のケースでは、 Amazon Location Service の主要な機能を利用できるように、マップ、プレース、ルート API 内の特定のリソースへのアクセスを許可します。これらのリソースには関連コストがかかるため、使用量の急増を監視するために課金アラートを設定し、定期的なキーローテーションプロセスの一環としてAPI キーの有効期限を設定することをお勧めします。 最後に、特定のドメインで使用するために API キーをロックダウンしたい場合は、キーが有効な URL を制限する Referer ドメインを設定することができます。 ここで、 Create API key を選択して API キーを作成します。 Show API key value を選択すると、API キーが表示されます。 これで API Key が作成できたので、アプリケーションで API キーを使い始めることが出来ます。これらのデモコードでは、API キーを変数としてハードコードしています。本番環境にデプロイする場合は、Referrer などのセキュリティ機能を使用することに加えて、アプリケーションの認証情報を保存・取得するために AWS Secrets Manager を使用することを推奨します。 API キーを使ったマップアプリケーションの構築 本記事では、地図と検索ボックスを含むシンプルなデモを構築します。人気のある MapLibre GL JS レンダリングライブラリを使って地図を表示することから始めます。MapLibre はスタイル URL の提供をサポートしているので、Auth Helper Library を使用する必要はなく、API エンドポイントを直接設定することができます。 まず index.html ファイルを作成し、 region と apiKey に利用するリージョンと API キーを、 mapName には前のステップで作成したマップリソースに置き換えて以下の内容を追加します。 <!-- index.html --> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <!-- Map container --> <div id="map" /> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3"></script> <script> const apiKey = "<Your API Key>"; // API key const region = "<Your Region>"; // Region const mapName = "<Your Map Resource>"; // Map name // URL for style descriptor const style = `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${apiKey}`; // Initialize the map const map = new maplibregl.Map({ container: "map", style, center: [-123.1187, 49.2819], zoom: 11, }); map.addControl(new maplibregl.NavigationControl(), "top-left"); </script> </body> </html> これを index.html として保存し、ブラウザで開いてください。ブリティッシュコロンビア州バンクーバーの地図が表示されるはずです。 地図を表示できたら、次にアプリケーションに位置検索ウィジェットを追加します。 地図に位置情報検索ボックスを追加する 検索ボックスには、 Amazon Location Service プレースインデックス を使用します。プレースインデックスを使うと、ジオコーディング/リバースジオコーディングができます。この例では、 Amazon Location Service と MapLibre ジオコーダー を使用します。 コードスニペットをコピーする代わりにこのアプリケーションをクローンしたい場合は、このコードは amazon-location-sample-map-with-geocoder GitHubリポジトリで利用可能です。 アプリケーションを作成するために、 index.html ファイルに加えて 2 つのファイルを作成します。 まず、 index.html を編集してマップを削除し、依存関係をダウンロードします。 <!DOCTYPE html> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <meta charset="utf-8"> <title>Basic Map with Geocoder</title> <!-- Styles --> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <main> <div id="map"></div> </main> <!-- JavaScript dependencies --> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <!-- Load the `maplibre-gl-geocoder` plugin. --> <script src="https://unpkg.com/@maplibre/maplibre-gl-geocoder@1/dist/maplibre-gl-geocoder.min.js"></script> <link rel="stylesheet" href="https://unpkg.com/@maplibre/maplibre-gl-geocoder/dist/maplibre-gl-geocoder.css" type="text/css" /> <!-- JavaScript for the app --> <script src="main.js"></script> </body> </html> 次に、 main.js という新しいファイルを作成し、以下のコードを貼り付けます。 region と apiKey に利用するリージョンと API キーを、 mapName には前のステップで作成したマップリソースに置き換えて以下の内容を追加します。 const { GetPlaceCommand, LocationClient, SearchPlaceIndexForSuggestionsCommand, SearchPlaceIndexForTextCommand } = amazonLocationClient; // Amazon Location Service Resources: const apiKey = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const placeIndex = "<Amazon Location PlaceIndex resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; // Add Geocoder control to the map via callbacks that are called by maplibre-gl-geocoder. // forwardGeocode: required for geocoding (Amazon Location SearchPlaceIndexForText API) // getSuggestions + searchByPlaceId: required for autosugget (Amazon Location SearchPlaceIndexForSuggestions + GetPlace APIs) async function addGeocoder(map, authHelper, client) { const amazonLocationGeocoderApi = { forwardGeocode: async (config) => { try { // Set up command to call SearchPlaceIndexForText API const { Results } = await client.send(new SearchPlaceIndexForTextCommand({ IndexName: placeIndex, Text: config.query })); // Convert the results to Carmen GeoJSON (<link>) to be returned to the MapLibre Geocoder const features = Results.map((result) => ({ type: 'Feature', geometry: { type: 'Point', coordinates: result.Place.Geometry.Point, }, place_name: result.Place.Label, properties: { id: result.Place.PlaceId, }, text: result.Place.Label, place_type: ['place'], center: result.Place.Geometry.Point, })); return { features }; } catch (error) { console.error(`Failed to forwardGeocode with error: ${error}`); } }, getSuggestions: async (config) => { try { // Set up a command to call SearchPlaceIndexForSuggestions API; const { Results } = await client.send(new SearchPlaceIndexForSuggestionsCommand({ IndexName: placeIndex, Text: config.query })); // Iterate over data.Results and return all suggestions and their place ids const suggestions = Results.map((result) => ({ text: result.Text, placeId: result.PlaceId, })); return { suggestions }; } catch (error) { console.error(`Failed to getSuggestions with error: ${error}`); } }, searchByPlaceId: async (config) => { try { // Set up command to call GetPlace API with a place Id of a selected suggestion const { Place } = await client.send(new GetPlaceCommand({ IndexName: placeIndex, PlaceId: config.query, })); const place = { type: 'Feature', geometry: { type: 'Point', coordinates: Place.Geometry.Point, }, place_name: Place.Label, text: Place.Label, center: Place.Geometry.Point, }; return { place }; } catch (error) { console.error(`Failed to searchByPlaceId with error: ${error}`); } }, }; // Add Geocoder control to the map map.addControl(new MaplibreGeocoder(amazonLocationGeocoderApi, { maplibregl, showResultsWhileTyping: true })); } // Initialize a map async function initializeMap() { const map = new maplibregl.Map({ container: 'map', // HTML element ID of map element center: [-123.1187, 49.2819], // Initial map centerpoint zoom: 16, // Initial map zoom style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${apiKey}`, // Defines the appearance of the map and authenticates using an API key }); // Add navigation control to the top left of the map map.addControl(new maplibregl.NavigationControl(), 'top-left'); return map; } async function main() { // Create an authentication helper instance using an API key const authHelper = await amazonLocationAuthHelper.withAPIKey(apiKey); const client = new LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); // Initialize map and add a geocoder to it. const map = await initializeMap(); addGeocoder(map, authHelper, client); } main(); すべてのファイルが作成されたら、 index.html をブラウザで開き、右上にある検索ボックスがある地図を見ることができます。 これでジオコーディングをテスト出来るようになりました。画像は、 Amazon Location Service プレースインデックスの自動補完と前方ジオコーディング機能を試してみたものです。 Auth Library を理解する さて、アプリケーションを作成しました。Amazon Location Service Auth Helper Library がどのように動作するのかを理解するために、コードを詳しく見ていきましょう。 最初に行うことは、認証方法を定義することです。これには Amazon Cognito Identity Pools 、もしくは API キーを使用します。 API キーの場合、次のように Auth メソッドを使用します。 const authHelper = await amazonLocationAuthHelper.withAPIKey(apiKey); Amazon Cognito Identity Pools を使用する場合、次のように使用します。 const authHelper = await withIdentityPoolId(identityPoolId); 次に、Amazon Location Service Client をインスタンス化する際に、Auth Helper を読み込みます。Auth Helper は、前のステップで設定した認証のタイプに基づいて、クライアントに追加のプロパティを含めます。 const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); 最後に、Amazon Location Service API を呼び出します。プレースインデックスを使って Seattle, WA を検索するとてもシンプルな例では、Auth Helper と Client を使って SearchPlaceIndexForText API を呼び出します。 <!-- index.html --> <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> </head> <body> <pre id="place_index_results" ></pre> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script> const Key = "<Amazon Location API key>"; // API key const region = "<Amazon Location PlaceIndex resource name>"; // Region const IndexName = "<AWS Region, e.g., eu-central-1>"; async function placeIndexSearch(){ const authHelper = await amazonLocationAuthHelper.withAPIKey(Key); const { LocationClient, SearchPlaceIndexForTextCommand } = amazonLocationClient; // Instantiate the Amazon Location Service Client using the Auth Helper configuration const client = new LocationClient({ region, ...authHelper.getLocationClientConfig() // Provides configuration required to make requests to Amazon Location using either API Keys or Cognito }); // Call the SearchPlaceIndexForText API using the Amazon Location client const data = await client.send(new SearchPlaceIndexForTextCommand({ IndexName, Text: "Seattle, WA", MaxResults: 1, })); document.getElementById("place_index_results").innerHTML = JSON.stringify(data['Results'], null, 4); } placeIndexSearch(Key) </script> </body> </html> この例では、結果は JSON としてブラウザに表示されます。 ご覧の通り、新しい Auth Helper は Amazon Location リソースの認可設定をより簡単にします。 Python での利用 JavaScript によるフロントエンドアプリケーションの構築に加えて、API キーは Amazon Location SDK がサポートするすべての言語でサポートされています。バックエンドアプリケーションで API キーを使用することで、アプリケーションをホストするインフラ上で IAM ロールや一時的な認証情報を設定するために必要なオーバーヘッドを削減することができます。例えば、次の例は、コマンドラインで住所を受け取り、API キーを使用してジオコーディングするシンプルな Python スクリプトです。単純な Python アプリケーションを作成するには、新しい Python ファイルを作成し、以下のコードを貼り付けます。 #Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. #SPDX-License-Identifier: MIT-0 import boto3from botocore import UNSIGNEDfrom botocore.config import Config client = boto3.client("location", region_name='<AWS Region, e.g., eu-central-1>', config=Config(signature_version=UNSIGNED)) text = input() response = client.search_place_index_for_text( IndexName='<Amazon Location PlaceIndex resource name>', Key='<Amazon Location API key>', MaxResults=1, Text=text) print(response['Results']) コードを実行する際、検索語を入力してください。この場合、ニューヨークを検索します。 Enter を押すと、Amazon Location Service プレースインデックスの検索結果が表示されます。 データ型変換ライブラリ Auth Helper Library に加えて、JavaScript 用の Amazon Location Utilities – データ型ライブラリもリリースしました。これらのライブラリは、Amazon Location Service API からの出力を一般的な GeoJSON データフォーマットに変換し、ジオフェンスの作成、プレースインデックス検索などのためにこれらのフォーマットからの入力を受け取ります。この例では、ユーザーからの入力を受け取り、 Amazon Location Service プレイスインデックスを検索し、結果を GeoJSON フォーマットで返す非常にシンプルなアプリを構築します。そして、この サンプルアプリケーション を使ってポイントを表示します。まず、新しいHTMLファイルを開き、リージョン、プレイスインデックス、API キーを先ほど作成した値に置き換えて、以下を貼り付けます。 <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl@3/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <pre id="jsonText" ></pre> <body> <div id="map" /> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script src="https://www.unpkg.com/@aws/amazon-location-utilities-datatypes@1/dist/amazonLocationDataConverter.js"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script> async function initializeMap() { const key = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; const IndexName = "<Amazon Location PlaceIndex resource name>"; const searchTerm = prompt("Search for a Location"); // Create an authentication helper instance using credentials from Cognito const authHelper = await amazonLocationAuthHelper.withAPIKey(key); const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); const searchResults = await client.send( new amazonLocationClient.SearchPlaceIndexForTextCommand({ IndexName, Text: searchTerm, MaxResults: 1, }) ); // Initialize the map const map = new maplibregl.Map({ container: "map", // Set the map centerpoint based on the geojson coordinates center: featureCollection.features[0].geometry.coordinates, // Initial zoom level zoom: 14, style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${key}`, }); // Add navigation controls map.addControl(new maplibregl.NavigationControl(), "top-left"); map.on("load", () => { // Convert search results into a GeoJSON FeatureCollection const featureCollection = amazonLocationDataConverter.placeToFeatureCollection(searchResults); // Add a data source containing GeoJSON produced from the Amazon Location Service プレースインデックス output. map.addSource("place-index-results", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points. map.addLayer({ id: "place-index-results", type: "circle", source: "place-index-results", paint: { "circle-radius": 8, "circle-color": "#0080ff", }, }); map.on('click', 'place-index-results', (e) => { const coordinates = e.features[0].geometry.coordinates.slice(); const description = JSON.stringify(featureCollection, null, 4);; new maplibregl.Popup() .setLngLat(coordinates) .setHTML(description) .addTo(map); }); }); } initializeMap(); </script> </body> </html> HTML ページをロードすると、検索を入力するプロンプトが表示されます。お近くの市町村や、よく行かれるお店を検索してみてください。”OK” をクリックすると、地図とアイコンが表示されます。マーカーをクリックすると、データ型変換ライブラリが提供する GeoJSON 出力が表示されます。 また、データ型変換ライブラリをルーティングに使うことで、Amazon Location Service が提供するルートを開発者が簡単に地図上に描くことができる。この例は上記と非常に似ていますが、今回は先に作成したルート計算機を含みます。 まず、新しい HTML ファイルを開き、 region と CaluculatorName に利用するリージョンと計算機を、Key に先ほど作成した API キーの値に置き換えて、以下を貼り付けます。ルートを描くために DeparturePosition と DestinationPosition を設定します。 <!-- Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. --> <!-- SPDX-License-Identifier: MIT-0 --> <html> <head> <link href="https://unpkg.com/maplibre-gl/dist/maplibre-gl.css" rel="stylesheet" /> <style> body { margin: 0; } #map { height: 100vh; } </style> </head> <body> <div id="map" /> <script src="https://unpkg.com/maplibre-gl@3"></script> <script src="https://unpkg.com/@aws/amazon-location-utilities-auth-helper@1/dist/amazonLocationAuthHelper.js"></script> <script src="https://www.unpkg.com/@aws/amazon-location-utilities-datatypes@1/dist/amazonLocationDataConverter.js"></script> <script src="https://unpkg.com/@aws/amazon-location-client@1/dist/amazonLocationClient.js"></script> <script> async function initializeMap() { const key = "<Amazon Location API key>"; const mapName = "<Amazon Location Map resource name>"; const region = "<AWS Region, e.g., eu-central-1>"; const IndexName = "<Amazon Location PlaceIndex resource name>"; const CalculatorName = "<Amazon Location Route Calculator resource name>"; const DeparturePosition = "[Departure Longitude, Departure Latitude]" const DestinationPosition = "[Destination Longitude, Destination Latitude]" // Create an authentication helper instance using credentials from Cognito const authHelper = await amazonLocationAuthHelper.withAPIKey(key); const client = new amazonLocationClient.LocationClient({ region, ...authHelper.getLocationClientConfig(), // Provides configuration required to make requests to Amazon Location }); const route = await client.send( new amazonLocationClient.CalculateRouteCommand({ CalculatorName, DeparturePosition, DestinationPosition, IncludeLegGeometry: true, }) ); // Initialize the map const map = new maplibregl.Map({ container: "map", // Set the map centerpoint based on the geojson coordinates center: DeparturePosition, // Initial zoom level zoom: 11, style: `https://maps.geo.${region}.amazonaws.com/maps/v0/maps/${mapName}/style-descriptor?key=${key}`, }); // Add navigation controls map.addControl(new maplibregl.NavigationControl(), "top-left"); map.on("load", () => { // Convert Amazon Location Service route to GeoJSON const featureCollection = amazonLocationDataConverter.routeToFeatureCollection(route); // Add a data source containing GeoJSON produced from the Amazon Location Service プレースインデックス output. map.addSource("route", { type: "geojson", data: featureCollection, }); // Add a new layer to visualize the points. map.addLayer({ id: "route", type: "line", source: "route", layout: { "line-join": "round", "line-cap": "round", }, paint: { "line-color": "#00b0ff", "line-width": 8, }, }); }); } initializeMap(); </script> </body> </html> その他のデータ型変換については、GitHub の aws-geospatial/amazon-location-utilities-datatypes-js リポジトリで、これらのユーティリティの使い方や提供されているその他の変換の詳細をご覧ください。 クリーンアップ 以下のリンクを使用して、 マップ 、 プレースインデックス 、 ルート計算 リソースを削除します。本記事で作成した API キーを削除するには、 こちら の手順に従ってください。 まとめ 新しい Amazon Location Service Auth Helper Library は、Amazon Location Service API キーおよび Amazon Cognito Identity Pools とのシームレスな統合を提供することで、地理空間アプリケーションの構築を簡素化します。Auth Helper Library を使用することで、開発者はアプリケーションで Amazon Location Service マップ、プレース、ルートと簡単に連携することができます。 また、GeoJSON のような Amazon Location Service と互換性のある異なるデータ型間で変換する機能も開発者に提供しました。これらのユーティリティを使うことで、開発者は GeoJSON を受け取ってジオフェンスを作成したり、プレースインデックス、ジオフェンス、ルートから GeoJSON 出力を得たりすることができます。 これにより、地理空間アプリケーション用の MapLibre などの一般的なライブラリの開発が容易になります。 より多くのサンプルアプリケーションについては、GitHub にホストされている aws-geospatial リポジトリを訪問し、Amazon Location Service が提供する機能をインタラクティブに見るためには location.aws.com デモサイトをチェックしてください。 本記事は「 Build a Geospatial Application with Amazon Location Service API Keys 」を翻訳したものです。 著者について Zach Elliott Zach Elliott は、AWS で Amazon Location Service にフォーカスしたソリューションアーキテクトとして働いています。彼は、お客様が AWS 上で地理空間ソリューションを構築するのを支援することに情熱を注いでいます。彼はまた、AWS の IoT Subject Matter Expert コミュニティの一員でもあり、顧客がユニークな IoT ベースのソリューションを開発するのを支援するのが大好きです。 Anand Vijayan Anand Vijayan は AWS で Amazon Location Service にフォーカスしたシニア・プロダクト・マネージャーとして働いている。地理空間テクノロジーに興奮し、クラウドのパワーを活用して顧客が複雑な問題を大規模に解決できるよう支援することに喜びを感じています。彼は熱心な天文学者であり、あらゆる宇宙に強い関心を持っています。 Seth Fitzsimmons Seth は Amazon Location Service をサポートするプリンシパルエンジニアです。余暇には、太平洋岸北西部の川や山で水遊びをしています。 Oren Weiss Oren Weiss は Amazon Web Service でソリューションアーキテクトとして働いている。それ以前は、Amazon Location Service を含む複数のチームでソフトウェア開発マネージャーを務めていた。お客様が AWS 上で革新的でスケーラブルかつコスト効率の高いソリューションを構築できるよう支援することに情熱を注いでいます。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

テキストによる指示から様々なタスクを高精度に行えるのは生成系 AI の特徴の一つです。メールのドラフトを作成したり、アイデアについて意見を求めたり、ちょっとした資料に使うイラストを作成するのは生成系 AI の代表的なユースケースです。 PartyRock は生成系 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。テキストによる指示と画面操作のみで生成系 AI を組み込んだアプリケーションを作り、共有することができます。次の画面ショットは、私が作成したテキストから資料に使うクリップアートを生成するアプリケーションです。 PartyRock は作ったアプリケーションの共有ができると書きましたが、 こちらのリンク から実際に利用いただくことができます。 PartyRock の背後ではもちろん Amazon Bedrock が使用されています。 Amazon Bedrock では複数の基盤モデルが選択でき、 PartyRock はそれらを組み合わせるインターフェースを提供します。 PartyRock を利用するのに AWS アカウントやクレジットカードは必要ありません。エンジニアの方はもちろん、プログラミングの経験がない方でも簡単かつ無料で使うことができます。 1. PartyRock でアプリケーションを作る partyrock.aws にアクセスしましょう。画面右上の “Sign in” からログインをします。 PartyRock ではソーシャルログインが可能です。お好きな方法でアカウントの作成・認証を行ってください。 ログインするとトップページに戻ってきます。 “Build your own app” を押しましょう。 App builder が立ち上がります。どんなアプリケーションを作りたいか入力し、 “Generate app” を押します。 ( 日本語への対応は明言されていませんが、試したところある程度解釈できるようです ) 。ゼロベースで作成したい場合は “Start from an empty app” を押します。ここでは「入力されたテキストからプレゼン資料で使えるクリップアートを生成するアプリケーション」と入力しました。 アプリケーションが出来上がりました。要望に沿いある程度自動的に作成してくれます。 input にテキストを入れると Generated Image に画像が作成され、 Prompt に代替テキストが出力されました。日本語で作成しましたが、おおむね意図に沿った内容になっていると思います。 もちろん、自動作成されたアプリケーションを編集したいこともあるでしょう。次のセクションでは PartyRock のアプリケーションをカスタマイズする方法をご紹介します。 2. PartyRock のアプリケーションをカスタマイズする Edit のボタンを押すことでカスタマイズができます。 PartyRock のアプリケーションは、ウィジェットを組み合わせるように作成します。各ウィジェットには、①プロンプトやモデルなどの詳細設定をするための Edit ボタン、②大きさを調整する角が付属しています。ウィジェットは、次の図 ③ のように “+Add Widget” のメニューか空きスペースの “Create Widget” のテキストを押すことで作成できます。 ウィジェットの種類は次の通りです User Input : ユーザーのテキスト入力を受け付ける。必ず 1 つは必要。 Static Text : 事前入力されたテキストを表示する。アプリケーションの説明文を書くときなどに使用。 Text Generation : テキストを生成する。 Image Generation : 画像を生成する。 Chatbot : チャットボットとの対話を行う。 ウィジェット同士を連携させるにはどうしたらよいでしょうか ? 例えば、 “User Input” をもとに “Image Generation” をしたいなどです。その際は、ウィジェットの右上にある Edit ボタンを押すことでウィジェットの編集メニューを開き、プロンプトの編集ボックスで “@” をつけることで他ボックスの入力を参照してプロンプトを作成できます。 公開時点では、テキストモデルについてモデルの設定ができます。後述する通り、高性能なモデルほど多くのクレジットを消費します ( 後述しますが、クレジット = 課金額ではないためご安心ください ) 。たとえば、下図では Cohere Command より Claude が 3 倍のクレジットを使用することになります ( 画面は執筆時点のものです ) 。 このように、様々なウィジェットを組み合わせながらアプリケーションを作ることができます。 3. PartyRock でアプリケーションを公開する アプリケーションを作ったら誰かに使ってほしいものです。 “Make public and Share” を押すことでアプリケーションの公開リンクを取得することができます。リンクを共有することで Bedrock してもらうことができます。 ぜひいろいろなアプリケーションを作ってみてください！ PartyRock する際の注意事項 最後に、 PartyRock を利用する際の注意事項を記載しておきます。 オプトアウトポリシー PartyRock へ入力するデータはデフォルトで PartyRock の開発と改善、またサービスを運用するためのモニタリングに利用されます。これを許容しない場合、 My Apps の画面 からオプトアウトができます。詳細は FAQ を参照ください。 クレジット PartyRock は無料で使えますが無限に使えるわけではありません。アカウントごとクレジットが割り当てられており、入出力したトークンの量に応じ消費されていきます。現状クレジットを回復する手段は提供されていないのでご注意ください。一方で、安心頂きたいのは公開したアプリが使われてもクレジットは消費されません。自分自身が使った場合のみ消費されます。 おわりに PartyRock により、プログラミング不要で生成系 AI を用いたアプリケーションを作成し他の人に提供できるようになりました。 AWS では AI/ML のユースケースを発見する “ ML Enablement Workshop ” の資料をすでに無料で公開しており、  PartyRock と組み合わせることで簡単なユースケースであれば発見から検証までを迅速に行うことができるようになりました。 PartyRock は今後使えるモデルやウィジェットが増えていくと “ Build AI apps with PartyRock and Amazon Bedrock ” にてアナウンスされています。生成系 AI によるサービスや業務の改革をより一層進めていくために役立てていただければ幸いです。 著者プロフィール 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。

データ量とユーザー数が増えるにつれて、アプリケーションのパフォーマンスと応答時間を改善する一方で、データベースのコストを最適化しなければならないという課題に直面することがよくあります。大量のデータとスループットを持つインターネット規模のアプリケーションには、マイクロ秒単位のレイテンシーをサポートできる基盤となるデータアーキテクチャが必要です。アプリケーションのパフォーマンスを向上させることで、お客様は応答時間を短縮し、外部および内部のユーザーにより良いサービスを提供できるようになります。インメモリキャッシュは、アプリケーションのパフォーマンスを向上させると同時に、お客様が費用対効果の高い方法でビジネスを成長させ、市場を拡大できるようにします。 データベースに分散結果セットキャッシュを追加することは、アプリケーションのパフォーマンスを向上させ、コストを削減するための一般的な方法です。 Grab、Wiz、DBS Bank は、 Amazon ElastiCache for Redis をプライマリデータソースと組み合わせて使用し、リアルタイムアプリケーションのパフォーマンスニーズをコスト効率よく実現している多くのお客様の一例です。ElastiCacheはフルマネージド型のRedis互換のサービスで、最新のアプリケーションにリアルタイムで最適化されたパフォーマンスを提供します。ElastiCacheは、マイクロ秒の応答時間で毎秒数億オペレーションまでスケールし、エンタープライズグレードのセキュリティと信頼性を提供します。お客様はElastiCacheを、アプリケーションやデータベースのパフォーマンスを高速化するため、あるいはデータの耐久性を必要としないユースケース（例えばセッションストア、ゲームリーダーボード、ストリーミング、データ分析、ML推論用のフィーチャストアなど）のプライマリデータストアとして使用しています。このブログ記事では、Amazon ElastiCache をクエリキャッシュとして利用することでリレーショナルデータベースのコストを最適化する方法を解説します。ここで使用されたデータは、インスタンスタイプdb.r6g.xlargeの Amazon RDS for MySQL バージョン8.0.28で実行したベンチマークテストに基づいています。ベンチマークテストでは、Amazon ElastiCacheでクエリ結果をキャッシュしています。 Amazon ElastiCache for Redis Amazon ElastiCache は AWS が提供する目的別キャッシュサービスです。 ElastiCache はプライマリデータソースを補完し、わずかなコストで全体的なパフォーマンスを最適化し、迅速なスケーリングを可能にします。 ElastiCache は、次のような機能を備えたフルマネージド型の AWS サービスです。 非常に高速 — ミリ秒未満の応答時間でインメモリキャッシュとして機能します。 ワークロードのニーズに合わせて、中断することなく垂直方向と水平方向の両方に拡張できます。 エンジンのマイナーバージョンアップを含む、ハードウェアとソフトウェアの管理をフルマネージドで行えます。 サービス中断時の自動フェイルオーバーや自動インスタンス復旧など、マルチ AZ 機能により高い可用性を実現しています。 さまざまなワークロードに対応する自動スケーリング機能を備え、データ階層化やリザーブドインスタンスタイプもサポートしています。 オープンソースの Redis と互換性があります。 Amazon ElastiCache によるAmazon RDS for MySQLのコスト最適化 Oracle、SQL Server、Amazon RDS などのリレーショナルデータベースにキャッシュソリューションとして ElastiCache を実装すると、アプリケーションのパフォーマンスを向上させ、コストを削減することができます。 ElastiCache を RDS for MySQL と組み合わせて使用することにより、RDS for MySQL を単独で利用した場合と比較して、コストを最大 55% 節約し、読み取りパフォーマンスを最大 80 倍高速化することができます。 ElastiCache は結果セットをキャッシュし、データベース I/O をオフロードすることで、コストを削減し、データベースとアプリケーションの両方のパフォーマンスを向上させることができます。 プライマリデータソースの前にキャッシュレイヤーを追加する方が、データベースインスタンスのキャパシティを大きくするよりも費用対効果が高くなります。 1 つの ElastiCache ノードは 1 秒あたり 250,000 件を超えるリクエストを処理できます。 同じ結果セットを返す共通のデータベースクエリを使用する読み取り負荷の高いワークロードでは、クエリ結果をキャッシュすることで大きなメリットが得られます。 一方、すべてのデータベースワークロードでキャッシュサービスを追加してもメリットがあるわけではありません。ほとんどのトランザクションが挿入または更新である書き込み負荷の高いデータベースは適していません。ストアドプロシージャやトリガーによるカスケードアップデートのようなデータベースレベルの処理を必要とするアプリケーションも、キャッシュの恩恵を受けません。 ElastiCache は、以下のようなアプリケーションによく適合します。 大量のスループットを処理する必要があるアプリケーション 短い間隔でトラフィックピークが増加するようなアプリケーション データベース更新の前にメモリ内の大量のデータをリアルタイムで処理して統合するアプリケーション 即時のユーザー応答をサポートする必要があるアプリケーション ElastiCache + プライマリデータソース ElastiCache は、MySQL、Oracle、PostgreSQL、SQL Server などのリレーショナルデータベースや、 Amazon DynamoDB や Amazon DocumentDB (with MongoDB compatibility) などの NoSQL データベース、 Amazon Simple Storage Service (Amazon S3)で使用できます。また、マイクロサービス間のようなデータベース層でなくても使用できます。 図 1 — Amazon ElastiCache により、様々なデータソースをキャッシュ ElastiCache により、リードレプリカの使用量を削減し、コストを節約する 下の図では、RDS for MySQLリードレプリカをElastiCache クラスターの読み取りキャパシティに置き換えました。分散された ElastiCache クラスターを追加する方が、リードレプリカを追加するよりもコストがかかりません。同等のレベルの読み込みキャパシティを低コストで実現でき、パフォーマンスも向上します。キャッシュは専用のメモリ、ネットワーク、CPU を提供するため、レイテンシーが大幅に改善し、スループットが大幅に向上します。 ここでデータベースの全てのデータをキャッシュに複製しているわけではないことを覚えておく必要があります。 キャッシュする必要があるのはクエリの結果だけなので、データベースを完全に複製する必要はありません。 図 2 — Amazon ElastiCache を利用して、RDS レプリカの必要量を減らす キャッシュ — アプリケーション実装戦略 以下は、データをキャッシュするためにアプリケーション実装戦略です。 レイジーロードキャッシュ レイジーロード 戦略は、レイジーポピュレーションまたはキャッシュアサイド戦略とも呼ばれ、お客様に最もよく利用されているキャッシュ戦略です。 基本的な考え方は、アプリケーションが実際にオブジェクトを要求したときにのみキャッシュにデータを入力することです。 全体的なアプリケーションフローは次のようになります。 例えば最新のニュース記事の上位10件など、アプリケーションがクエリを受け取ります。 アプリケーションはキャッシュをチェックし、オブジェクトがキャッシュ内にあるかどうかを確認します。 その場合 (キャッシュヒット)、キャッシュされたオブジェクトが返され、コールフローが終了します。 そうでない場合 (キャッシュミス)、データベースにオブジェクトを問い合わせます。 データベースからロードされたデータは、次回のためにキャッシュに入力され、クエリの結果としてオブジェクトが返されます。 図 3 — レイジーロードまたはキャッシュアサイド戦略 ライトスルーキャッシュ 一貫性を必要とするワークロードでは、ソースデータストア内のデータが変更されたときに、 ライトスルー 戦略を使用してキャッシュを更新できます。 ライトスルーでは、ソースデータストアの更新時に変更を検出しキャッシュを更新するメカニズムか、データが変更されたときにお客様がキャッシュとソースの両方に二重書き込みプロセスを実装することが必要です。 ライトスルーを実装するクライアントアプリケーションはデータベースを更新し、書き込みが成功するとデータベースからデータを読み取り、新しいクエリ結果を同期的にキャッシュします。 図 4 — ライトスルー戦略 アプリケーションは Redis クライアント API を介して ElastiCache で構成されるキャッシュレイヤーを呼び出します。 レイジーロード戦略はデータをキャッシュに読み込むのに役立ちますが、その主な目的は、データが存在する場合にプライマリデータソースにアクセスせずキャッシュからデータを読み取ることです。 ライトスルー戦略はデータをデータベースと同期させるのに役立ちますが、一般的にはレイジーローディング戦略とライトスルー戦略の両方を実装し、データが存在する場合はキャッシュから読み取り、キャッシュに書き込んでデータを最新の状態に保ちます。 ElastiCache for Redis のキャッシュ戦略の詳細については、 こちら を参照してください。 RDS for MySQL + ElastiCache – Better Together の例 読み取りと書き込みの比率が80:20で、読み取られたデータの 80% がキャッシュされている場合 キャッシュのパフォーマンス上の利点、コスト上の利点、アプリケーション実装戦略について説明したところで、コスト削減とパフォーマンス向上の例を見てみましょう。 30,000 クエリ/秒 (QPS) のスループットを実現する必要があるとしましょう。 この要件を満たすには、RDS for MySQL のリードレプリカを利用する方法と、RDS + ElastiCache を利用する方法があります。 ElastiCache を利用せずに RDS だけを利用する場合、スループット要件を満たすには RDSの リードレプリカが 4 つ必要になり、そのコストは 1 か月あたり 1,740 USD ( db.r6g.xlarge )になります。 RDS + ElastiCache を使用する場合、リードレプリカを排除し、代わりに 1 つの ElastiCache ノードとそのリードレプリカノードで同じスループットを実現できます。 RDSのリードレプリカの代わりに ElastiCache を利用すると、1 か月あたり 780 USD の費用がかかります。 ElastiCache と RDS のコストは、リードレプリカに RDS だけを使用する場合と比べて 55% のコスト削減につながります。 以下の表は、使用するノードとそのコストの詳細を示しています。 メトリクス RDS プライマリのみ RDS プライマリ + リードレプリカ RDS プライマリ + 4 リードレプリカ RDS プライマリ + 2 ElastiCache node 平均待機時間 200 ミリ秒 80 ミリ秒 80 ミリ秒 1 ミリ秒 平均読取QPS 8,000 QPS 16,000 QPS 30,000 QPS 32,000 QPS コスト $/月 348 $/月 696 $/月 1,740 $/月 780 $/月 使用ノード 1 read/write db.r6g.xlarge 1 writer 1 reader = 2x db.r6g.xlarge 1 writer 4 reader = 5x db.r6g.xlarge 1x db.r6g.xlarge + 2x cache.m6g.xlarge RDS for MySQLの設定とデータベースサイズ: データセットサイズ：~80GB ストレージ：300GB RDS ノード：MySQL version 8.0.28, db.r6g.xlarge テストSQL： SELECT firstname, lastname, from_airport FROM booking WHERE passenger_id = <passenger id> より高いスループットでのコスト削減 – 100% のデータをキャッシュし、さらなるコスト削減を行う キャッシュを実装すると、アプリケーションのスループット要件が高ければ高いほど、コスト削減効果も大きくなります。 以下の例では、キャッシュが完全にウォームアップされる (つまり、読み取られるすべてのデータが ElastiCache によって処理される)と、読み取り容量は 250,000 QPS に達します。RDS だけでは、このスループットをサポートするコストは 87% 高くなります。 スループットの高い、読み取り量の多いアプリケーションにキャッシュを実装することで、コストを大幅に削減できます。 メトリクス 1 RDS + 9 RDS read replicas 1 RDS + 1 RDS read replica + 1 ElastiCache + 1 EC read replica 平均待機時間 80 ms 9 ms 平均読取QPS 250,000 250,000 コスト $/月 7,840 $/月 784 $ (RDS) + 432 $ (EC) /月 使用ノード 10 x db.r6g.xlarge 2 x db.r6g.xlarge + 2 x cache.m6g.xlarge 結論 RDS などのプライマリリレーショナルデータベースに ElastiCache を実装することで得られるコスト削減は、アプリケーションに必要な読み取りスループットに比例します。 必要な読み取りスループットが高ければ高いほど、コスト削減量も大きくなります。 これは、スループットが増加するにつれて、リレーショナルデータベースのスケーリングにかかるコストが高くなるためです。 一方、各 ElastiCache ノードは 1 秒あたり最大 400,000 件(*1)のクエリのスループットをサポートできます。 ElastiCache をアプリケーションアーキテクチャに追加することで、パフォーマンスを向上させ、コストを削減できます。 (*1 訳注：Amazon ElastiCache for Redis 7.1の登場により、さらに最大スループットが向上しました。例えばr7g.4xlargeを用いたテストではRedis 7.0と比較してスループットが100%以上向上し、1 秒あたり1,000,000 件以上のリクエストを処理しました。詳細は こちら のブログをご覧下さい) Amazon ElastiCache を使い始めるには、 入門ガイド 、 自習型学習コース 、または オンデマンド学習パス を参照してください。 Amazon ElastiCache 製品ページにアクセスして、その他のリソースを検索したり、詳細を確認したりすることもできます。 より詳細なガイダンスについては、AWS アカウントチームに連絡して Amazon ElastiCache スペシャリストによる詳細なセッションをスケジュールしてください。 このブログで説明されているキャッシュ戦略を実装するサンプルコードを Github リポジトリ からダウンロードすることもできます。 本記事は、Sashi Varanasi, Steven Hancz, Roberto Luna Rojas らの「 Optimize cost and boost performance of RDS for MySQL using Amazon ElastiCache for Redis 」を翻訳したものです。翻訳は ソリューションアーキテクトの 堤 勇人が担当しました。

セキュリティはAWS にとって、また多くのお客様にとって最優先事項となります。 AWS では、2021年3月に 日本の政府調達におけるクラウドサービスの評価制度である「政府情報システムのためのセキュリティ評価制度（Information system Security Management and Assessment Program: ISMAP（以下、ISMAPと表記）」に登録されました。本制度において最初から登録されたクラウドサービス事業者のうちの一つとなります。そして、このたび、2023年に登録された内容を踏まえたISMAP Customer Packageの更新版が掲載されました。 ISMAP Customer Packageの入手は、AWS マネジメントコンソール上のAWS Artifactから行います。AWS Artifactの”View reports” より、”ISMAP Customer Package”　を検索すると日本語版および英語版が表示されますので、Artifact NDA に合意の上、ダウンロードしてください。 また、今回の発行にともない、ISMAPに関して特にいただくお問い合わせをご紹介いたします。 ISMAPに関してよくあるお問い合わせ：AWSの〇〇というサービスはISMAPに登録されていますか まず、お答えとしては、 ISMAPに登録された”サービス”は”Amazon Web Services”です。 ISMAPに関連して頂くお問い合わせとして、”AWSの〇〇というサービスはISMAPに登録されているか”といったお問い合わせがあります。ISMAPにおける定義において、私たちが登録しているサービスは”Amazon Web Services”というサービスであり、 ISMAP Portal に掲載されています。クラウドサービス事業者によっては、複数のサービスをISMAPのサービスとして登録しているケースがありますが、何らかの形で同質性に違いがある場合、別のサービスとして登録することが必要になります。AWSのサービスにおける同質性の考え方は こちらのBlog をご参照ください。 一方、監査を行うタイミングにおいて適切な運用機関に基づく証跡を確認した対象範囲として、”AWSのサービス”を登録時に掲載しています。制度上、どの程度の粒度として対象範囲を記述するかはクラウドサービス事業者に依存するものとなりますが、同質性を担保できるうえでは登録されたサービスにおける機能一覧といった位置づけに近いものとなり、以後のアップデートも機能の追加に近しいものとなります。制度の性質上、新しく発表されたAWSのサービスが直ちに対象範囲に反映されることは困難ですが、原則として新たに登録されたAWSのサービスにおいても、同等の水準のセキュリティとして運用を行っています。継続的な統制はSOC等の様々なコンプライアンスプログラムによっても評価することが可能です。 調達等において、”〇〇というサービスがクラウドサービス事業者の対象範囲にない”場合は、上記の理解を前提に、そもそもISMAPが対象としているサービスなのか（ISMAP Portalのサービスリストに掲載されるレベルなのか）、そのうえで評価対象がどのような水準で運用されているかを確認する、というステップになります。 ISMAPに関してよくあるお問い合わせ：AWS上で提供される他のサービスに対する責任共有モデルはどう考えたらよいか AWSが提供している様々なサービスの中では、AWSが単独で提供するものではなく、他のサービス事業者が提供しているものや、AWS上でソフトウェア等が提供され、お客様が利用するケースがあります。具体的には、 AWS Market place でお客様が利用可能な様々なサービス、 VMware Cloud on AWS などの他の事業者が提供するサービス、 基盤モデル やOSSのテンプレートやソリューション等が該当します。このような場合、責任共有モデルに基づきAWSが提供する範囲と他の事業者、お客様が有する責任の範囲は異なることにご留意ください。また、OSSのテンプレートや基盤モデル、ソフトウェアパッケージなど、クラウドサービスという定義に該当しない多様なケースが存在することにもご留意ください。 ISMAP Customer Package は、日本語および英語にて提供されます。AWS のお客様、政府調達に関わる関係者の皆様、今後の様々なコンプライアンスの推進を行う上でISMAPの理解を深めたい様々なお客様、ISMAP に登録を考えておられるAPN パートナーの皆様は、ISMAP Customer Package を通じて責任共有モデルおよびISMAP に基づくAWS とお客様自身の責任範囲の理解が容易になります。さらにはISMAP に限らずAWSのコンプライアンスを理解したいお客様に対しても様々な情報を提供するものとなりますので、ご活用いただければ幸いです。 このブログの著者 松本　照吾（Matsumoto, Shogo） セキュリティ アシュアランス本部 本部長

はじめに コンタクトセンターのスーパーバイザー、マネージャー、コンプライアンス、ワークフォースアナリストなどは、Amazon Connect コンソールのリアルタイムメトリックスダッシュボードを使用して、エージェント、キュー、ルーティングプロファイルのパフォーマンスを含む、コンタクトセンターのリアルタイムパフォーマンスを監視します。 さらに、 以前のブログ記事 で述べたように、今日の組織は、地域・業界、またビジネスニーズによって異なる、プライバシーや規制の課題に直面しています。こうしたプライバシー規制に準拠するために、コンタクトセンターの管理者は、コンタクトセンター内で使用される機密リソース、特にリアルタイムメトリクスに対して、最小アクセス権限の実装を求められることが頻繁にあります。 コンタクトセンターでは、多くの場合、個別の事業部門または組織毎のアクセスコントロールが必要です。 タグベースのアプローチ は、コンタクトセンターのこのような動的なアクセスコントロールの要望をサポートするための柔軟性とスケーラビリティを提供します。 このブログ記事では、架空の会社 Octank 社の管理者が、ライブモニタリングやエージェントへの割り込みなど、エージェント、キュー、ルーティングプロファイルのリアルタイムメトリクスへのユーザーアクセスを制限する方法について説明します。Octank 社が運用を継続し、ビジネス上の意思決定を行う中で、より細かいアクセスコントロールの要件も変化します。3 つの段階のそれぞれについて、より細かいアクセスコントロールの要件を満たすためのタグベースのアクセスコントロールの柔軟性を実証します。 ソリューション概要 各段階でのソリューションのデプロイには、次の手順が含まれます。 リソースタグを使用してエージェント、キュー、ルーティングプロファイルを設定します コンタクトセンターのさまざまなペルソナを表す、アクセスコントロールタグを使用したセキュリティプロファイルを設定します コンタクトセンターのペルソナのユーザーを設定し、セキュリティプロファイルに関連付けます 次の図は、Amazon Connect のタグベースのアクセスコントロールを示しています。リソースには リソースタグ が付けられています。セキュリティプロファイルにはアクセスコントロールタグが設定されます。これらのセキュリティプロファイルがユーザーに割り当てられると、そのユーザーのリソース、データ、およびメトリクスへのアクセスが アクセスコントロールタグ に基づいて制限されるようになります。アクセスコントロールタグが「LOB: Credit」のセキュリティプロファイルは、「LOB: Credit」のリソースタグでタグ付けされたリソース (Agent1) のみアクセスを許可します。アクセスコントロールタグが「LOB: Banking」のセキュリティプロファイルは、「LOB: Banking」のリソースタグでタグ付けされたリソース (Agent2) のみアクセスを許可します。 前提条件 このチュートリアルは、以下のリソースを理解し、アクセスできることを前提としています。 関連する以前のブログ記事「 リソースタグによる Amazon Connect のより細かいアクセスコントロールの実現 」 Amazon Connect の管理者アクセス権を持つ AWS アカウント 作成 済みの Amazon Connect インスタンス 管理者権限 (Admin) の セキュリティプロファイル を持つ Amazon Connect ユーザー AWS リソースのタグ付け に関する基本的な知識 チュートリアル シナリオとペルソナ Octank 社は、コンタクトセンターを運営する架空の金融サービス会社です ユーザーペルソナには、エージェント、スーパーバイザー、コンタクトセンターマネージャー、管理者が含まれます エージェント : 顧客からの電話等の問い合わせに応答・対応します スーパーバイザー : エージェントのグループを監視し、必要に応じて指導します コンタクトセンターマネージャー : コンタクトセンターとその従業員の日常業務を監督します コンタクトセンター管理者 : コンタクトセンターのセットアップと設定を管理します セキュリティプロファイルの管理は管理者のみ可能です ペルソナごとに最小限のサンプルユーザーが含まれ、ルーティングプロファイルとキューは 1 対 1 で対応しています 最小権限アクセスコントロール :各ペルソナは、最も近い境界内にあるリソースへのリアルタイムレポート、ライブモニタリング、およびバージインアクセスのみにアクセスできます 各段階は独立して実装できます 段階 1 Octank 社には、 クレジット と バンキング という 2 つの事業部門 (LOB) があります。各 LOB にはエージェント、スーパーバイザー、コンタクトセンターマネージャーがいます。Octank 社は、Credit LOB の担当者がバンキング LOB のエージェント、キュー、ルーティングプロファイルのリアルタイムメトリクスを見ることができないようにする必要があります。逆もまた同様です。例えば クレジット LOB のコンタクトセンターマネージャーは、クレジット LOB 内のエージェント、キュー、ルーティングプロファイルのみをリアルタイムメトリクスで見ることができます。コンタクトセンター全体の管理者は両方の LOB にアクセスできます。 アクセスコントロールの粒度は LOB に基づいているため、2 つの LOB ( LOB: Credit と LOB: Banking ) を表すリソースタグとアクセスコントロールタグを作成します。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ (キー:値のペア) Credit LOB: Credit Banking LOB: Banking ルーティングプロファイルの名前 リソースタグ Credit LOB: Credit Banking LOB: Banking エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ MJackson Mateo Jackson Agent(default) Credit LOB: Credit RRoe Richard Roe Agent(default) Banking LOB: Banking 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCredit と SupervisorBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit SupervisorBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking ここまでの手順で 4 つの異なるペルソナを表す合計 4 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、2 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCredit Basic Routing Profile LJuan Li Juan SupervisorBanking Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します 段階 2 ビジネスが成長し、Octank 社は英語とスペイン語の 2 つの言語で顧客をサポートすることにしました。Octank 社は米国とアルゼンチンに拠点を置いています。彼らは、米国に拠点を置くチームを使用して英語の顧客をサポートし、アルゼンチンに拠点を置くチームを使用してスペイン語の顧客をサポートするというビジネス上の決定をしました。LOB ごとに、米国とアルゼンチンのチームにはエージェントとスーパーバイザーがいます。コンタクトセンターのマネージャーは、LOB 内およびすべての国のチームを引き続き管理します。ただし、Octank 社では、各国のチームがエージェント、キュー、ルーティングプロファイルを含むリアルタイムのレポートをその国でのみ閲覧できるようにすることを義務付けています。段階 1 からの LOB レベルの制限は引き続き適用されます。 アクセスコントロールの粒度は LOB と国に基づいているため、2 つの LOB と 2 つの国 ( LOB: Credit 、 LOB: Banking 、 Country: UnitedStates 、 Country: Argentina ) を表すリソースタグとアクセスコントロールタグを作成します。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ リソースタグ CreditUS LOB: Credit Country: UnitedStates CreditArgentina LOB: Credit Country: Argentina BankingUS LOB: Banking Country: UnitedStates BankingArgentina LOB: Banking Country: Argentina ルーティングプロファイルの名前 リソースタグ リソースタグ CreditUS LOB: Credit Country: UnitedStates CreditArgentina LOB: Credit Country: Argentina BankingUS LOB: Banking Country: UnitedStates BankingArgentina LOB: Banking Country: Argentina エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ リソースタグ MJackson Mateo Jackson Agent(default) CreditUS LOB: Credit Country: UnitedStates JSouza Jorge Souza Agent(default) CreditArgentina LOB: Credit Country: Argentina RRoe Richard Roe Agent(default) BankingUS LOB: Banking Country: UnitedStates MMajor Mary Major Agent(default) BankingArgentina LOB: Banking Country: Argentina 各リソースに 2 つのリソースタグが使用されていることに注意してください。これは、LOB と国、 2 段階のアクセスコントロールの粒度の要件に対応するためです。 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCreditUS 、 SupervisorCreditArgentina 、 SupervisorBankingUS と SupervisorBankingArgentina の 4 つのセキュリティプロファイルを作成し、アクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCreditUS ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, Country:UnitedStates SupervisorCreditArgentina ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, Country:Argentina SupervisorBankingUS ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, Country:UnitedStates SupervisorBankingArgentina ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, Country:Argentina このステージでは、6 つの異なるペルソナを表す合計 6 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 リソースタグとアクセスタグを追加する必要があるのは、粒度が要求される場合のみであることに注意してください。この場合、アクセス要件が変わらなかったため、管理者は前の段階と同じセキュリティプロファイルを使用できました。スーパーバイザーは国内でのより細かいアクセスコントロールを必要としていたため、4 つのスーパーバイザーセキュリティプロファイルでは 2 つのアクセスコントロールタグが使用されています。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、4 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCreditUS Basic Routing Profile PCandella Pat Candella SupervisorCreditArgentina Basic Routing Profile LJuan Li Juan SupervisorBankingUS Basic Routing Profile TWhitlock Terry Whitlock SupervisorBankingArgentina Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します 段階 2 のシナリオの代替策：国レベルの粒度ではなく、2 つの LOB の Octank 社のスーパーバイザーは、グループ内のエージェントのみを確認する必要があります。2 番目のリソースタグは、スーパーバイザー名 ( Group:JStiles ) に変更できます。エージェント、キュー、ルーティングプロファイルに、所属するグループに基づいてリソースタグを割り当てることができます。Octank 社では、スーパーバイザーのセキュリティプロファイルの数はスーパーバイザーのグループの数と同じになります。各スーパーバイザーのセキュリティプロファイルには 2 つのアクセスタグ (LOB と Group) があります。 段階 3 Octank 社のバンキング LOB は、フィリピンを拠点とするビジネスプロセスアウトソーサー (BPO) と契約します。この BPO は、銀行顧客を扱う幅広い専門知識を持ち、より高いサービスレベルを提供します。今後、バンキング LOB は BPO を利用してスペイン語の銀行業務に関する問い合わせを処理することになりました。BPO は、BPO 内のエージェント、キュー、ルーティングプロファイルに関するリアルタイムレポートのみを表示できます。内部チームは BPO のリソースにアクセスできません。BPO メトリクスにアクセスできるのは、管理者とバンキング LOB のコンタクトセンターマネージャーだけです。LOB レベルと国レベルの制限は引き続き適用されます。 アクセスコントロールの粒度は、 LOB 、国、およびエージェントが社内の Octank チームに属しているか、 BPO に属しているかに基づきます。このシナリオでは、国をカプセル化し、エージェントが社内か BPO かを示す複合タグ CenterType の使用方法を示します。加えてその情報を表すリソースタグとアクセスコントロールタグである、 LOB: Credit 、 LOB: Banking 、 CenterType:UnitedStates_Internal 、 CenterType: Argentina_Internal 、 CenterType: Philippiness_BPO を作成します。CenterType タグに指定できる値の数は国の場所の数の 2 倍ですが、ステージ 3 のシナリオを表すのに必要な組み合わせは 3 つだけです。 手順 1: キュー、ルーティングプロファイル、エージェントおよびそのリソースタグの設定 キューの名前 リソースタグ リソースタグ CreditUS LOB: Credit CenterType: UnitedStates_Internal CreditArgentina LOB: Credit CenterType: Argentina_Internal BankingUS LOB: Banking CenterType: UnitedStates_Internal BankingArgentina LOB: Banking CenterType: Philippines_BPO ルーティングプロファイルの名前 リソースタグ リソースタグ CreditUS LOB: Credit CenterType: UnitedStates_Internal CreditArgentina LOB: Credit CenterType: Argentina_Internal BankingUS LOB: Banking CenterType: UnitedStates_Internal BankingBPO LOB: Banking CenterType: Philippines_BPO エージェントのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル リソースタグ リソースタグ MJackson Mateo Jackson Agent(default) CreditUS LOB: Credit CenterType: UnitedStates_Internal JSouza Jorge Souza Agent(default) CreditArgentina LOB: Credit CenterType: Argentina_Internal RRoe Richard Roe Agent(default) BankingUS LOB: Banking CenterType: UnitedStates_Internal PSantos Paulo Santos Agent(default) BankingBPO LOB: Banking CenterType: Philippines_BPO 手順 2: アクセスコントロールタグとセキュリティプロファイルの設定 コンタクトセンター管理者は、デフォルトの Admin セキュリティプロファイルを使用します。 管理者のログイン 名 姓 セキュリティプロファイル ルーティングプロファイル NWolf Nikki Wolf Admin(default) Basic Routing Profile コンタクトセンターマネージャー向けに、 ManagerCredit と ManagerBanking の 2 つのセキュリティプロファイルを作成し、アクセスコントロールタグを使用してアクセスをそれぞれの LOB に制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザー、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ ManagerCredit ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Credit ManagerBanking ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking スーパーバイザー向けに、 SupervisorCreditUSInternal 、 SupervisorCreditArgentinaInternal 、 SupervisorBankingUSInternal と SupervisorBankingPhilippinesBPO の 4 つのセキュリティプロファイルを作成し、アクセスをそれぞれの LOB およびコンタクトセンターの種別の組み合わせで制限します。リアルタイムレポート向けに、各セキュリティプロファイルには、ユーザ、ルーティングプロファイル、キューを表示する権限と、リアルタイムメトリクス、リアルタイムモニタリング、リアルタイムコンタクト割り込みの権限が必要です。 セキュリティプロファイル名 アクセス権限 アクセスコントロールリソース アクセスコントロールタグ SupervisorCreditUSInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, CenterType:United States_Internal SupervisorCreditArgentinaInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Credit, CenterType:Argentina_Internal SupervisorBankingUSInternal ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB: Banking, CenterType:United States_Internal SupervisorBankingPhilippinesBPO ルーティングプロファイル、キュー、ユーザー – 表示 リアルタイムメトリクス – すべて リアルタイムコンタクトモニタリング – すべて リアルタイムコンタクト割り込み – すべて ユーザー、ルーティングプロファイル、キュー LOB:Banking, CenterType:Philippines_BPO この段階では、6 つの異なるペルソナを表す合計 6 つのセキュリティプロファイルを作成しました。管理者はデフォルトの Admin セキュリティプロファイルを使用しました。 リソースタグとアクセスタグを追加する必要があるのは、粒度が要求される場合のみであることに注意してください。この場合、アクセス要件が変わらなかったため、管理者は前の段階と同じセキュリティプロファイルを使用できました。スーパーバイザーは国内および担当するエージェントのより細かいアクセスコントロールを必要としていたため、4 つのスーパーバイザーセキュリティプロファイルでは 2 つのアクセスコントロールタグが使用されています。アクセスコントロールのうちの1 つ (CenterType) は複合タグです。 手順 3: コンタクトセンターマネージャーの設定とセキュリティプロファイルの紐づけ 構成をテストおよび検証するために、コンタクトセンターマネージャーのユーザーを 2 つ作成します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 マネージャーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル MRivera Martha Rivera ManagerCredit Basic Routing Profile ADesai Arnav Desai ManagerBanking Basic Routing Profile 次に、4 人のスーパーバイザーユーザーを作成して構成をテストおよび検証します。各ユーザーを、前の手順で作成した適切なセキュリティプロファイルに関連付けます。 スーパーバイザーのログイン 名 姓 セキュリティプロファイル ルーティングプロファイル JStiles John Stiles SupervisorCreditUSInternal Basic Routing Profile PCandella Pat Candella SupervisorCreditArgentinaInternal Basic Routing Profile LJuan Li Juan SupervisorBankingUSInternal Basic Routing Profile TWhitlock Terry Whitlock SupervisorBankingPhilippinesBPO Basic Routing Profile 手順 4: テストと検証 より細かいアクセスコントロールを確認する手順は以下の通りです。 ブラウザのシークレットモードを利用して、Amazon Connect 管理コンソールに作成した管理者アカウント NWolf でサインインします ナビゲーションメニューの 分析 と 最適化 からリアルタイムメトリクスを選択します キューを選択して、前のステップで設定したすべてのキューのリアルタイムメトリクスを確認できることを確認します リアルタイムメトリクスページに戻ります。 ルーティングプロファイル を選択し、前の手順で設定したルーティングプロファイルがすべて表示されていることを確認します リアルタイムメトリクスページに戻ります。 エージェント を選択し、前のステップで設定したすべてのエージェントのリアルタイムメトリクスを確認できることを確認します 前の段階の手順で設定した 2 つのマネージャーのユーザー名と 2 つのスーパーバイザーのユーザー名を使用して、シークレットウィンドウで各ユーザーで Amazon Connect コンソールにログインします 各ユーザー名で以下を確認します 前述の検証ステップ 2 から 5 に従って、LOB (クレジットまたはバンキング) 内のキュー、エージェント、ルーティングプロファイルのみを確認できることを確認します すべてのエージェントのライブ会話またはライブチャットを リアルタイムで監視 できることを確認します 監視しているライブ会話で、エージェントとの 会話に割り込める ことを確認します クリーンアップ Amazon Connect 管理コンソールにログインし、このブログの手順で作成したセキュリティプロファイルと ユーザーを削除 します このブログのハンズオンの為に Amazon Connect インスタンスをセットアップした場合は、Amazon Connect AWS コンソールにアクセスして Amazon Connect インスタンスを削除 できます 結論 このブログ記事では、Amazon Connect のリソースタグとアクセスコントロールタグを使用して、リアルタイムメトリクス、リアルタイムライブモニタリング、リアルタイムコンタクト割り込みについて Amazon Connect リソースへのより細かいアクセスコントロールを行う方法について説明しました。この方法によって、Amazon Connect インスタンスの稼働中に要件が変化した場合でも、チーム、ロール、その他の基準で複数のグループを作成し、さまざまな Amazon Connect リソースに対してより複雑なアクセスコントロールの条件を設定することができます。 著者について Prashant Desai は AWS プロフェッショナルサービスのシニアコンサルタントです。彼は大規模なコンタクトセンターの設計とクラウドへの移行の経験があります。Prashant は、顧客体験をシンプルで革新的にする方法を常に模索しています。 Parind Poi は AWS プロフェッショナルサービスのシニアプラクティスリーダーです。彼は AWS のカスタマーエクスペリエンス (CX) に関する深い専門知識を持ち、専門業務をリードしています。Parind は、お客様がクラウド上でカスタマーエンゲージメントワークロードを最新化できるよう支援することに情熱を注いでいます。 Elaine は、Amazon Connect に特化した AWS シニアソリューションアーキテクトであり、20 年以上にわたって電話とコンタクトセンターの専門知識を持っています。また、次世代のクラウド基盤のビルダーを育成する Amazon Future Engineer Class Chat プログラムの熱心なサポーターです。 Mike Simpson は、Amazon Connect の技術担当シニアプロダクトマネージャーです。彼は、Amazon Connect のお客様の業務を向上させるための Amazon Connect 分析ソリューションの構築を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

AWS re:Invent 2023 直前セッションガイド – モニタリングとオブザーバビリティ、および運用管理について 11 月 27 日から 12 月 1 日までラスベガスで開催されるクラウドコンピューティングカンファレンス、AWS re: Invent 2023 で皆様にお会いできることをとても楽しみにしています。re: Invent に初めて行かれる方も、そうではない方も、AWS re: Invent の熱量と様々な機会にはきっと驚かされることでしょう。 AWS Cloud Operations トラックは、AWS クラウド運用を構成するソリューション分野 (モニタリングとオブザーバビリティ、運用管理、 コンプライアンスと監査 、 クラウドガバナンス ) を対象とする合計 96 のセッションで構成されています。AWS Cloud Operations トラックでは、豊富な洞察、ベストプラクティス、楽しい Kiosk を通じて、クラウドスキルを新たな高みに引き上げることができます。 このブログでは、組織がダウンタイムを最小限に抑え、信頼性の高い運用を維持し、コストを削減するのに役立つクラウド運用内の2つのソリューション分野である、 モニタリングとオブザーバビリティ と 運用管理 に焦点を当てます。AWS でのモニタリングとオブザーバビリティは、オンプレミス、ハイブリッド、コンテナ化、マルチクラウド、オープンソースを問わず、最新のアプリケーション、ワークロード、インフラストラクチャからの洞察を得るために、ログ、メトリクス、トレースを取り込み、コンテキスト化、視覚化、分析するエンドツーエンドのソリューションを提供します。AWS での一元化された運用管理は、マルチクラウド、ハイブリッド、またはオンプレミス環境にわたる日常業務のための豊富なツールセットを提供します。パッチ管理からインシデント管理まで、運用管理は、お客様が一元化されたハブからアプリケーションを大規模に運用できるようにすると同時に、AIOps やその他の機能によりアプリケーションの可用性を向上させます。 AWS Village の Cloud Ops Kiosk セッションへの参加に加えて、Venetian Expo のAWS Village にあるクラウドオペレーションとオブザーバビリティの Kiosk にもぜひお越しください（ マップ ）。ルーレットを回して賞品を獲得し、AWS の専門家に会い、楽しい VR 体験をして、クラウド運用の未来について学びましょう。 オブザーバビリティと運用管理について詳しく知りたい方は、以下の Kiosk とセッションをご覧ください。 セッションカタログ にある以下のセッションをお気に入りに追加してください。 実施されるセッション ビジネスのニーズや関心に応じて、他にも多くのセッションから選択できます。モニタリングとオブザーバビリティ関連で、ぜひご覧いただきたいセッションは次の通りになります。 Monitoring and Observability COP339 | AWS のオブザーバビリティと運用の最新情報 (What’s new with AWS observability and operations) – ブレイクアウトセッション クラウドで運用しているのか、運用を移行しているのかに関わらず、AWS は複数の環境にわたるアプリケーションとインフラストラクチャの管理と洞察の提供を支援します。このセッションに参加して、クラウド運用の向上と最適化に役立つ最新のイノベーションについて学びましょう。AWS IT 管理ツールとオブザーバビリティソリューションのデモで、最新のローンチを詳しく見てみましょう。 COP343 | 耐障害性を高めるためのオブザーバビリティの構築 (Building observability to increase resiliency) – ブレイクアウトセッション 耐障害性のあるシステムが計画どおりに動作することを証明するには、オブザーバビリティを効果的に使用することが不可欠です。オブザーバビリティを適切に適用することで、顧客に影響を与える前に問題の兆候を早期に発見し、影響を軽減するために迅速に対応できます。このセッションでは、オブザーバビリティのベストプラクティスを利用してAWSでの耐久性(レジリエンス)を改善する方法を学びます。現実世界の障害モードを深く掘り下げ、計測器とオブザーバビリティツールの適切な組み合わせを使用して問題を迅速に解決する方法をご覧ください。このセッションには、Amazon CloudWatch や AWS X-Ray などの AWS サービスを使用したこれらのテクニックとプラクティスのデモが含まれます。 COP319 | コンテナのオブザーバビリティのベストプラクティス (Best practices for container observability) – ブレイクアウトセッション コンテナ化されたアプリケーションや環境のペースの速い世界では、最適なパフォーマンス、信頼性、ユーザーエクスペリエンスを確保するためには、包括的なオブザーバビリティを実現することが不可欠です。このセッションに参加して、コンテナのオブザーバビリティのベストプラクティスを掘り下げてみましょう。AWS オブザーバビリティを利用して、Amazon EKS と Amazon ECS 環境を効果的にモニタリング、分析、トラブルシューティングする方法をご覧ください。コンテナ化されたワークロードに関する洞察を得ながら、エージェントの手動管理を排除し、リソース割り当てを最適化するのに役立つベストプラクティスについて説明します。 COP322 | アプリケーションオブザーバビリティの実装(Implementing application observability) – ブレイクアウトセッション オブザーバビリティは、問題を迅速に診断し、より早く問題を解決するのに役立ちます。このセッションでは、Amazon CloudWatch を使用してアプリケーションのすべてのレイヤーにオブザーバビリティを実装する方法を学びます。これにより、ユーザーからバックエンドシステムに至るまで、アプリケーションのパフォーマンスを理解できます。 COP325 | 効果的なオブザーバビリティ戦略の構築(Building an effective observability strategy) – ブレイクアウトセッション オブザーバビリティの成熟度を高め、顧客に満足してもらうためには、戦略を立てることが重要です。このセッションでは、オブザーバビリティが重要である理由、何をどのように観察すべきか、そしてどのオブザーバビリティ指標がビジネス成果を最もサポートできるかを探ります。Amazon CloudWatch や AWS X-Ray などのサービスを使用して、さまざまなテクニックやプラクティスを深く掘り下げてみましょう。 COP326 | Amazon CloudWatch Logs から実用的な洞察を得る(Get actionable insights from Amazon CloudWatch Logs) – ブレイクアウトセッション Amazon CloudWatch Logs の価値を最大限に引き出していますか?このセッションに参加して、適切なインサイトを得るために最適化を行い、CloudWatch Logs をさらに活用してください。CloudWatch Logs の最新機能を使用してオブザーバビリティ体制を改善する方法をご覧ください。データにコンテキストを追加して、すでに取り込んだログの使い方を学びましょう。機械学習によるパターン検出から、EMF の高解像度機能、リアルタイムのインタラクティブ分析まで、ログから実用的な洞察を得る方法をご覧ください。 COP306 | Amazon CloudWatch と AWS X-Ray を実際に使ってみる (Hands-on experience with Amazon CloudWatch and AWS X-Ray) – ワークショップ 企業のアジリティ、顧客満足度、ビジネスの成長は、優れたオブザーバビリティの設定にかかっています。高性能で信頼性の高いアプリケーションを構築するために、AWS ではさまざまな AWS オブザーバビリティサービスとソリューションを提供しています。このワークショップでは、Amazon CloudWatch と AWS X-Ray を使用して AWS サービスをモニタリングする方法、最も一般的なユースケースを実際に体験する方法、利用可能な最新機能について学び、実装する方法を学びます。参加するにはラップトップを持参する必要があります。 COP309 | Amazon CloudWatch によるエンドユーザーエクスペリエンスのモニタリング (Monitor end user experience with Amazon CloudWatch) – ビルダーズセッション AWS デジタルエクスペリエンスモニタリングは、アプリケーションパフォーマンスモニタリングをエンドユーザーとフロントエンドエクスペリエンスにまで拡張することで、すべてのユーザータッチポイントにおけるアプリケーションパフォーマンスの外部からの視点で顧客体験を向上させます。このようなユーザーエクスペリエンスデータは全体像を完成させ、組織がフロントエンドのパフォーマンス、ユーザー行動、APIをリリース速度、運用率、コンバージョンなどの実用的なKPIに変えるのに役立ちます。このビルダー向けセッションでは、ISP と AWS からのデータを使用し、バックエンドのインフラストラクチャとデバイス、およびユーザーメトリクスから洞察を得て、実際のユーザーと仮想のユーザーの、アクティビティと振る舞いの両方を監視することで、アプリケーションの動作について学びます。参加するにはラップトップを持参する必要があります。 COP401 | コンテナのオブザーバビリティのためのコーディング (Coding for container observability) – コードトーク このセッションに参加して、OpenTelemetry SDK と AWS Distro for OpenTelemetry (ADOT) Collector を使用してさまざまな環境から信号を収集する方法について学びましょう。また、負荷の高いコンテナ環境で堅牢で可用性の高い ADOT パイプラインを設計して、大規模な運用をサポートする方法についても説明します。 一元的な運用管理 COP320 | 運用の一元化 (Centralize your operations) – ブレイクアウトセッション クラウドへの移行またはクラウドでの運用のプロセスのどの段階にあっても、AWS は、AWS、オンプレミス、ハイブリッド環境、エッジでのアプリケーションの管理と運用に使用できる一元化された運用管理ソリューションを提供します。このセッションでは、AWS Systems Manager を使用して、パッチ適用やリソースの変更などのプロアクティブなプロセスを自動化し、何百ものランブックを使用して問題を解決する方法を学びます。自動化を使用すると、サービスの中断を最小限に抑え、時間のかかるプロセスを簡素化し、繰り返しの多いタスクを回避してオペレーション効率を高めることが容易になります。 COP325 | 効果的なオブザーバビリティ戦略の構築(Building an effective observability strategy) – Breakout Session オブザーバビリティの成熟度を高め、顧客に満足してもらうためには、戦略を立てることが重要です。このセッションでは、オブザーバビリティが重要である理由、何をどのように観察すべきか、そしてどのオブザーバビリティ指標がビジネス成果を最もサポートできるかを探ります。Amazon CloudWatch や AWS X-Ray などのサービスを使用して、さまざまなテクニックやプラクティスを深く掘り下げてみましょう。 COP314 | All things patch:AWS、オンプレミス、その他のクラウドでのパッチ適用を管理 (All things patch: Manage patching on AWS, on premises and on other clouds) – チョークトーク このチョークトークでは、AWS Systems Manager を使用して、AWS 組織内の AWS アカウントと AWS リージョン全体で、大規模なパッチ処理を迅速に有効化する方法をご紹介します。他のクラウド環境の Amazon EC2 インスタンス、エッジデバイス、オンプレミスサーバー、仮想マシン (VM) のパッチ処理を管理する方法を学びます。最後に、Amazon Athena と Amazon QuickSight を使用してパッチコンプライアンスレポートをセットアップし、パッチコンプライアンスを作成する方法を見てみましょう。 COP316 | インシデントマネージャーによるインシデント対応の自動化 (Automating incident response with Incident Manager) – チョークトーク このチョークトークでは、インシデントに備える方法と、Amazon CloudWatch アラームまたは Amazon EventBridge イベントによって重大な問題が検出されたときに自動的にアクションを実行する方法を学びます。また、AWS での数十年にわたるインシデント対応と分析の経験に基づいて、インシデント後の分析を実行する方法についても検討してください。 COP330 | AIOpsで業務を加速 (Accelerate your operations with AIOps) – チョークトーク アプリケーションの運用時間を減らし、イノベーションにより多くの時間を費やしたいですか?このチョークトークでは、AIOps（IT運用のための人工知能）がどのようにオペレーションワークフローを簡素化および自動化し、最も重要なときに混乱を解消するのに役立つかを学びます。また、Amazon CloudWatch と Amazon DevOps Guru を使用して AWS での AIOps のベストプラクティスについて学び、それらを使用して時間を節約する方法についても学びます。 COP403 | 効率性の向上:インシデント修復の自動化 (Efficiency unleashed: Automating incident remediation) – コードトーク AWS Well-Architected Framework が推奨する設計原則である、操作をコードとして実行することで、組織は運用をより効率的に実行し、ヒューマンエラーを制限し、予測可能な結果を達成できます。このコードトークでは、操作をコードとして実装する方法を学びます。また、AWS Systems Manager の機能である自動化を使用して、AWS Config および Amazon CloudWatch のアラームとインシデントにあるコンプライアンス違反リソースの修復を自動化する方法についても説明します。 Cloud Ops セッションの種類: re: Invent では、イノベーショントークや EXPO の Kiosk などのさまざまなセッションを通じて、AWS クラウドの運用についてさらに学び、対象分野の専門家 (SME) と交流することができます。 ブレイクアウトセッションは、1 人以上のスピーカーが多数の聴衆にコンテンツを発表することで構成されます。ワークショップは、参加者が少人数のグループで AWS を使用して問題の解決策を構築するインタラクティブなセッションです。チョークトークは双方向に対話する形式で、AWS の専門家による短い講義から始まり、その後に 45 ～ 50 分のホワイトボードと Q&A セッションが続きます。ビルダーズセッションは、1 人の AWS エキスパートが主導する小グループセッションで、参加者がフォローアップして AWS エキスパートと一緒に実験や構築を行う短いデモンストレーションから始まります。Re: Invent 2023 で開催される AWS クラウドオペレーションで、今年の AWS クラウドオペレーションに関するすべての学習機会をぜひ活用してください。 本記事は、Tiffany Chen, Winnie Chen らの「 Know Before You Go – AWS re:Invent 2023 Monitoring and Observability, and Centralized Operations Management | AWS Cloud Operations & Migrations Blog 」を翻訳したものです。翻訳は ソリューションアーキテクトの 伊藤が担当しました。

AWS Amplify JavaScript Library の v6 の一般公開を発表できることを嬉しく思います。このリリースには、コミュニティから要望の多かった改善点や機能が多数含まれています。このリリースでは、バンドルサイズが大幅に縮小され、TypeScript のカバレッジと型サポートが強化され、セキュアランタイムトークンのサポートが強化され、Next.js App Router と Server Actions が完全にサポートされます。 より速いアプリのロード時間とより小さいバンドルサイズ スピードは贅沢品ではなく、必需品です。そのため、依存関係の削減、 Tree shaking 機能の向上、アーキテクチャの最適化に投資してきました。バンドルが小さいほどアプリケーションの読み込みが速くなり、高速ブロードバンド接続でも接続が不安定でも、ユーザーの関心と満足度を維持できます。これらの変更により、Amplify は最も一般的に使用されるフレームワークとビルドツールに最適化されました。 create-react-app を使用して新しい React アプリを構築し、カテゴリ内のすべての API のバンドルサイズを比較すると、v5 と比較してバンドルサイズが次のように減少していることがわかります。 Auth: 55kb to 32kb (42%) Storage: 38kb to 21kb (45%) Analytics (Pinpoint): 31kb to 18kb (42%) Notifications and Analytics: 39kb to 23kb (41%) API REST & GraphQL: 91kb to 38kb (58%) 注意: バンドルサイズ数値は、gzip 圧縮した最終的なバンドルサイズを計測したものです。削減後の結果は Amplify JavaScript v6.0.2 を使用しており、削減前の結果は、軽量クライアントが導入された Amplify JavaScript v5.3.4 を使用しています。これらの改善以前の例として、グラフには Amplify JavaScript v5.2.4 の生成結果も合わせて表記しています。 Amplify JS v6 では、機能単位の API 導入とツリーシェイク機能の改善により、アプリにインポートした API のみがバンドルサイズに影響し、未使用の機能は Tree Shake から除外されます。例えば、アプリで Auth パッケージのいくつかの API のみを使い ( signInWithRedirect , signOut , fetchAuthSession 、 getCurrentUser ) ストレージでは ( uploadData , downloadData )のみを使った場合、v6 ライブラリでは v5 ライブラリと比較して 59% のバンドルサイズを削減します（77kb→31kb）。 TypeScript エクスペリエンスの向上 TypeScript は、大規模で複雑なプロジェクトを管理しやすくする型安全性を提供しており、多くのチームの開発ワークフローに欠かせないものとなっています。Amplify の JavaScript Library における全ての公開 API に、使いやすく直感的な型が追加されました。これらの TypeScript 機能強化により、テキストエディタのシンタックスハイライトとコード補完がより充実したものになります。型チェックは、アプリを実行する前にいくつかのバグを特定するのに役立ちます。 それでは、新しい GenerateClient API を使用して、AWS AppSync API から製品をクエリする方法を見てみましょう。この例では、 GenerateClient API を使用して mutation を実行し、アプリ内の To Do を更新します。graphql API に対して型を設定する必要がなくなったことに気付くかもしれません。データ項目は自動的に推論されるようになっています。 我々は、ログインしているユーザーに対してはもっと良い型定義が必要だというフィードバックをいただきました。そこで、完全な user オブジェクトを返す新しい getCurrentUser API を作成しました。これを使って、 signInDetails の下にある loginId を取得してみましょう。 Next.js の App Router, API routes, そして middleware のサポート Amplify JavaScript Library は、新しい Next.js アダプター により Next.js 機能をすべてサポートするようになりました。これにより、サーバーサイドレンダリングや、App Router で React Server Components を使用したり、middleware で API ルートを使用して認証されたユーザーのみへのアクセスを制御したりすることができます。Amplify JavaScript v6 を使用すると、任意の Next.js ランタイムで Amplify を実行し、任意のレンダリングオプション (SSR、ISR、または静的出力) を使用できます。 Next.js アダプターを使用すると、「Amplify サーバーコンテキスト」内で Amplify Library を実行できます。これにより、クラウドで Amplify Library の各機能を安全に使用できます。Amplify の機能の実行が終了した場合、コンテキストは完全に破棄され、クロスリクエスト汚染を排除することで、アプリのセキュリティ体制を強化します。 Next.js の App Router と Pages Router を使用するシナリオをいくつか見てみましょう。 前提条件 Next.js アダプターを含む最新の Amplify Library をインストールして開始します。 npm i aws-amplify @aws-amplify/adapter-nextjs Amplify getting started guide をまだ読んでいない場合、まずはこのガイドを読んでください。 このチュートリアルの終了までに、GraphQL API と auth API のセットアップをしておく必要があります。 App Router 最初のシナリオでは、Next.js の App Router を利用することを想像しましょう。我々は、サーバーコンポーネント のうち 1 つを AWS AppSync API と接続し、いくつかのデータを一覧します。 まず、 serverClient 関数を含む新しいユーティリティファイルを作成して、サーバー側で Amplify API と通信できるようにします。 // utils/server-utils.ts import { cookies } from "next/headers"; import { generateServerClientUsingCookies } from "@aws-amplify/adapter-nextjs/api"; import config from "../../amplifyconfiguration.json"; export const serverClient = generateServerClientUsingCookies({ config, cookies, }); GenerateServerClientUsingCookie 関数は、動的レンダリング機能を備えた Next.js サーバーコンポーネントで使用できる API を生成します。これにより、サーバー側の Amplify API に安全にアクセスできるようになります。 serverClient 関数はエクスポートされ、API を呼び出すユーティリティ関数として使用できます。 page.tsx ファイルにこの関数をインポートし、それを使用して ToDo アプリ用のデータを一覧表示します。 // page.tsx import { serverClient } from "@/utils/server-utils"; import * as query from "@/graphql/queries"; export default async function Home() { const { data, errors } = await serverClient.graphql({ query: query.listTodos, }); if(errors){ // handle errors } return ( <div> {data.listTodos.items.map((post) => { return ( <li key={post.id}> <div>Name: {post.name}</div> <span>Description: {post.description}</span> </li> ); })} </div> ); ユーザーが投稿を削除できるように、削除機能を追加してみましょう。 // page.tsx import * as mutations from "@/graphql/mutations"; import { serverClient } from "@/utils/server-utils"; ... async function deletePost(formData: FormData) { "use server"; const id = formData.get("postId")?.toString(); if (id) { const { errors } = await serverClient.graphql({ query: mutations.deleteTodo, variables: { input: { id, }, }, }); if (errors) { // handle errors } } } この削除アクションは、 Server Actions を使用して postID を取得し、それを削除します。これにより、サーバー上でフォームを送信し、ID を取得して入力変数に渡すことができます。 TypeScript の正しい推論を行うために、型生成に言及する必要があります。これには、 src フォルダーに生成される api.ts ファイルと、 graphql フォルダーにある mutations ファイルが含まれます。これを行うには、ルートフォルダで amplify add code コマンドを実行します。 Pages Router もし、Next.js の Pages Router を使う場合は、 createServerRunner 関数と generateServerClientUsingReqRes 関数を使い、サーバー上でクエリを実行する必要があります。 まず、2 つの関数を含む utils ファイルを作成することから始めましょう。 runWithAmplifyServerContext 関数は、Amplify API をサーバー上で独立して実行するために使用されます。 serverGraphQLClient middleware, API routes, getServerSideProps もしくは getStaticProps で GraphQL API と通信するために使用されます // utils/server-utils.ts import { createServerRunner } from "@aws-amplify/adapter-nextjs"; import config from "../../amplifyconfiguration.json"; import { generateServerClientUsingReqRes } from "@aws-amplify/adapter-nextjs/api"; export const { runWithAmplifyServerContext } = createServerRunner({ config, }); export const serverGraphQLClient = generateServerClientUsingReqRes({ config, }); それでは、 GetServerSideProps を使ってこれがどのように機能するのかを見てみましょう。サインインしているユーザーの情報を取得するシナリオを想定します。 // index.tsx import { runWithAmplifyServerContext } from "@/utils/server-utils"; import { getCurrentUser } from "@aws-amplify/auth/server"; export const getServerSideProps: GetServerSideProps = async ({ req, res }) => { const currentUser = await runWithAmplifyServerContext({ nextServerContext: { request: req, response: res }, operation: async (contextSpec) => getCurrentUser(contextSpec), }); return { props: { currentUser } }; }; 上記のように、クライアント側で getCurrentUser を使用してサインインしたユーザー情報を取得できます。ただし、インポートパスが "aws-amplify/auth/server" という少し異なるバージョンを使用して、サーバー側でもこれと同じ情報を取得できます。このサーバーバージョンの GetCurrentUser では、 contextSpec を渡す必要があります。 別のシナリオでは、 ServerGraphQLClient 関数を使ってタスクのリストを取得することもできます。 // index.tsx import { listTodos } from "@/graphql/queries"; import { runWithAmplifyServerContext, serverGraphQLClient, } from "@/utils/server-utils"; export const getServerSideProps: GetServerSideProps = async ({ req, res }) => { const todoList = await runWithAmplifyServerContext({ nextServerContext: { request: req, response: res }, operation: (contextSpec) => serverGraphQLClient.graphql(contextSpec, { query: listTodos, }), }); return { props: { todoList } }; }; ServerGraphQLClient は ContextSpec を取り込む graphql API を使用します。ここでは、todo のリストを gql 形式で渡すこともできます。 Middleware Amplify は Next.js の middleware もサポートするようになりました。ミドルウェア内の RunWithAmplifyServerContext を使用して、Amplify API を操作することができます。 ユーザーが認証されていないときはいつでも login ルートにリダイレクトしたいアプリを作ってみましょう。以下は App Router を使った例です。まず、 utils フォルダーに新しい server-utils ファイルを作成します。 // utils/server-utils.ts import { createServerRunner } from "@aws-amplify/adapter-nextjs"; import config from "../../amplifyconfiguration.json"; export const { runWithAmplifyServerContext } = createServerRunner({ config, }); これにより、middleware で使用する RunWithAmplifyServerContext 関数 が作成されます。 // middleware.ts import { runWithAmplifyServerContext } from "@/utils/server-utils"; // The fetchAuthSession is pulled as the server version from aws-amplify/auth/server import { fetchAuthSession } from "aws-amplify/auth/server"; import { NextRequest, NextResponse } from "next/server"; export async function middleware(request: NextRequest) { const response = NextResponse.next(); // The runWithAmplifyServerContext will run the operation below // in an isolated matter. const authenticated = await runWithAmplifyServerContext({ nextServerContext: { request, response }, operation: async (contextSpec) => { try { // The fetch will grab the session cookies const session = await fetchAuthSession(contextSpec, {}); return session.tokens !== undefined; } catch (error) { console.log(error); return false; } }, }); // If user is authenticated then the route request will continue on if (authenticated) { return response; } // If user is not authenticated they are redirected to the /login page return NextResponse.redirect(new URL("/login", request.url)); } // This config will match all routes accept /login, /api, _next/static, /_next/image // favicon.ico export const config = { matcher: [ /* * Match all request paths except for the ones starting with: * - api (API routes) * - _next/static (static files) * - _next/image (image optimization files) * - favicon.ico (favicon file) */ "/((?!api|_next/static|_next/image|favicon.ico|login).*)", ], }; 新しい FetchAuthSession API を使用していることがわかります。これにより、トークンを取得してユーザーがログインしているかどうかを確認できます。ユーザーがサインインしていない場合は、 login ページにリダイレクトされます。 Amplify JavaScript v6 をお試しください Amplify community からのリクエストに応えて、このリリースを提供できることを嬉しく思います。バンドルサイズを最適化することで、Amplify はユーザーの接続環境に関係なく、すべてのユーザーに高速な読み込みを提供することを目指しています。TypeScript サポートの改善により、コーディングエクスペリエンスが向上し、エラーが減少します。Next.js インテグレーションでは、利用可能なすべての Next.js ランタイムを使用できます。 皆さんがこれらの新機能を使って何を構築するのか楽しみです！JS v6 のすべての機能を確認するには、 Amplify JavaScript documentation をご覧ください。 本記事は Building fast Next.js apps using TypeScript and AWS Amplify JavaScript v6 を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。