12 月 1 日は、 Amazon GuardDuty の高度な AI/ML 脅威検出機能を紹介できることを嬉しく思います。この新機能では、AWS の広範なクラウド可視性とスケールを利用して、アプリケーション、ワークロード、およびデータの脅威検出を強化します。GuardDuty Extended Threat Detection は、高度な AI/ML を使用して既知の攻撃シーケンスと未知の攻撃シーケンスの両方を識別し、クラウドセキュリティへのより包括的でプロアクティブなアプローチを提供します。この強化により、現代のクラウド環境における複雑さの増大と進化するセキュリティ脅威への対応が可能になり、脅威の検出と対応が簡素化されます。 多くの組織は、クラウド環境全体で発生する大量のセキュリティイベントを効率的に分析して対応するという課題に直面しています。セキュリティ脅威の頻度と巧妙さが増すにつれて、経時的に一連のイベントとして発生する攻撃を効果的に検出して対応することがますます困難になっています。セキュリティチームはしばしば大規模な攻撃の一部である可能性のある関連アクティビティをつなぎ合わせるのに苦労し、潜在的に重大な脅威を見逃したり、重大な影響を防ぐには対応が遅すぎたりすることがあります。 これらの課題に対処するために、GuardDuty の脅威検出機能を拡張し、セキュリティシグナルを相互に関連付けて AWS 環境内のアクティブな攻撃シーケンスを特定する新しい AI/ML 機能を追加しました。これらのシーケンスには、権限発見、API 操作、永続アクティビティ、データ漏洩など、攻撃者が実行する複数の手順が含まれる場合があります。これらの検出は、重大度が極めて高い GuardDuty の新しいタイプの攻撃シーケンスの検出結果として表されます。これまで GuardDuty では「クリティカル」な重要度を使用したことはなく、機密で極めて緊急性が高い検出結果のためにこのレベルを保留していました。このような新しい検出結果ではクリティカルな重要度が導入され、脅威の性質と重要性を自然言語で要約したもの、MITRE ATT&CK® フレームワークの戦術と技法にマッピングされた観察されたアクティビティ、AWS のベストプラクティスに基づく規範的な修復のレコメンデーションなどが含まれます。 GuardDuty Extended Threat Detection では、新しい攻撃シーケンスの検出結果が導入され、認証情報の漏洩、権限昇格、データ漏洩などの領域において既存の検出の実用性が向上します。今回の機能強化により、GuardDuty はアカウント内の複数のデータソース、期間、リソースにわたる複合検出が可能になり、高度なクラウド攻撃をより包括的に理解できるようになります。 新しい機能がどのように機能するかをお見せしましょう。 Amazon GuardDuty で新しい AI/ML 脅威検出機能を使用する方法 GuardDuty で新しい AI/ML 脅威検出機能を体験するには、 Amazon GuardDuty コンソール にアクセスして、 [Summary] (概要) ページの新しいウィジェットを確認してください。概要ウィジェットは、受けている攻撃シーケンスの数を表示し、同攻撃シーケンスの詳細を検討するのに役立ちます。クラウド環境の検出結果から多段階攻撃が明らかになることがよくありますが、これらの高度な攻撃シーケンスは量が少なく、検出結果の総数に占める割合はごくわずかです。この特定のアカウントでは、クラウド環境でさまざまな検出結果を確認できますが、実際の攻撃シーケンスはほんの一握りです。大規模なクラウド環境では、数百または数千の検出結果が表示される場合がありますが、攻撃シーケンスの数は比較的少ないままである可能性があります。 また、検出結果を重要度別に表示できる新しいウィジェットも追加しました。これにより、関心のある特定の検出結果をすばやく絞り込んで調査することが容易になります。検出結果は 重要度 別にソートされるようになり、追加された クリティカル の重要度カテゴリーを含む最も重大な問題の概要が明示されるようになりました。これにより、最も緊急な検出結果にすぐに気づくことができます。また、 [Top attack sequences only] (トップアタックシーケンスのみ) を選択して、攻撃シーケンスのみをフィルタリングすることもできます。 この新機能はデフォルトで有効になっているため、使用を開始するために追加の手順を実行する必要はありません。この機能には、GuardDuty とそれに関連する保護プランの基本料金以外に追加費用はかかりません。追加の GuardDuty 保護プランを有効にすると、この機能により統合されたセキュリティ価値が高まり、より深いインサイトを得るのに役立ちます。 次の 2 種類の検出結果を確認できます。1 つ目はデータ侵害です。これは、大規模なランサムウェア攻撃の一環で起こる可能性のあるデータ侵害を示しています。データはほとんどのお客様にとって最も重要な組織のアセットであり、重要な懸念事項となっています。2 つ目の検出結果は、侵害された認証情報のタイプです。これは、通常、クラウド環境における攻撃の初期段階で、侵害された認証情報の悪用を検出するのに役立ちます。 データが侵害された検出結果の 1 つについて詳しく見ていきましょう。「アカウント内のユーザーに関連する複数のシグナルに対する一連のアクションを含む、1 つ以上の S3 バケットのデータ侵害の可能性」に焦点を当てます。この検出結果は、複数の関連シグナルにより、複数の Amazon Simple Storage Service (Amazon S3) バケットでデータが侵害されていることを確認したことを示しています。 この検出結果に含まれる概要には、アクションを実行した特定のユーザー (プリンシパル ID で識別)、影響を受けたアカウントとリソース、アクティビティが発生した長期の期間 (ほぼ 1 日) などの重要な詳細が表示されます。この情報は、潜在的な侵害の範囲と重大度をすばやく理解するのに役立ちます。 この検出結果には、ほぼ 24 時間にわたって観察された 8 つの異なるシグナルがあり、MITRE ATT&CK® フレームワークにマッピングされた複数の戦術と手法が使用されていることが示されています。認証情報へのアクセスから、発見、回避、永続性、さらには影響や流出に至るまで、攻撃チェーン全体にわたって広範囲に及んでいることから、これが本当にポジティブなインシデントであった可能性が示されています。この検出結果は、特に憂慮すべきデータ破壊の手法も浮き彫りにしています。 さらに、GuardDuty は、ユーザーが AWS CloudTrail トレイルを削除したときなど、機密性の高い API コールを強調表示することで、セキュリティコンテキストをさらに強化します。このような回避行動は、Amazon S3 オブジェクトを対象とする新しいアクセスキーとアクションの作成と相まって、インシデントの重大度と潜在的な範囲をさらに拡大します。この検出結果で提示された情報に基づいて、このインシデントをさらに徹底的に調査する必要があるでしょう。 検出結果に関連する ATT&CK 戦術 を確認することで、それが単一の戦術であろうと複数の戦術であろうと、関連する特定の戦術を把握できます。GuardDuty には、アクティビティに疑わしいというフラグが立てられ、クリティカルの重大度が割り当てられた理由を説明するセキュリティインジケーターも用意されています。これには、呼び出された高リスク API や実行された戦術が含まれます。 さらに深く掘り下げると、責任があるアクターの詳細を確認できます。この情報には、ネットワークの場所など、ユーザーがこれらのアクションにどのように接続して実行したかが含まれます。この追加のコンテキストは、調査と対応に不可欠なインシデントの全範囲と性質をよりよく理解するのに役立ちます。AWS のベストプラクティスに基づいた規範的な是正レコメンデーションに従うことで、特定された検出に迅速に対処して解決するための実用的なインサイトを得ることができます。これらのカスタマイズされたレコメンデーションは、クラウドセキュリティ体制を改善し、セキュリティガイドラインとの整合性を確保するのに役立ちます。 [Signals] (シグナル) タブは、新しい順または古い順に並べ替えることができます。アクティブな攻撃に対応する場合は、状況をすばやく把握して軽減するために、最新のシグナルから始めることをお勧めします。インシデント後のレビューでは、最初のアクティビティから遡ることができます。各アクティビティを詳しく見ると、特定の検出結果に関する詳細情報が得られます。また、 インジケーター 、 アクター 、 エンドポイント を通じてすばやく表示して、何が起きて誰がアクションを起こしたかの概要を見ることができます。 詳細を確認するもう 1 つの方法は、 [Resources] (リソース) タブにアクセスすることです。このタブでは、関連するさまざまなバケットとアクセスキーを確認できます。リソースごとに、どのような戦術やテクニックが行われたかを確認できます。開いているリソースを選択して、関連するコンソールに直接移動し、詳細を確認できます。 GuardDuty の検出結果の全ページビューが導入され、すべてのコンテキストデータを 1 か所で容易に確認できるようになりました。ただし、特定の検出結果の詳細をすばやく表示するレイアウトを希望する場合は、サイドパネル付きの従来の検出結果ページも引き続き使用できます。 GuardDuty Extended Threat Detection は、リージョン内のすべての GuardDuty アカウントで自動的に有効になり、追加の保護プランを必要とせずに基本的なデータソースを活用できます。追加の保護計画を有効にすると、分析されるセキュリティシグナルの範囲が広がり、複雑な攻撃シーケンスを特定するサービスの能力が向上します。GuardDuty では、Amazon S3 バケット内の潜在的なデータ漏洩を検出するために S3 保護 を有効にすることを特に推奨しています。S3 保護を有効にしないと、GuardDuty は S3 固有の検出結果を生成したり、S3 リソースに関連する攻撃シーケンスを特定したりできず、Amazon S3 環境におけるデータ侵害シナリオを検出する能力が制限されます。 GuardDuty Extended Threat Detection は、 AWS Security Hub 、 Amazon EventBridge 、サードパーティーのセキュリティイベント管理システムなど、既存の GuardDuty ワークフローと統合されます。 今すぐご利用いただけます Amazon GuardDuty Extended Threat Detection は、複雑な攻撃シーケンスの分析を自動化し、実用的なインサイトを提供することでクラウドセキュリティを大幅に強化します。これにより、ユーザーは最も重要な脅威に効率的に対処することに集中でき、手動分析に必要な時間と労力を低減できます。 これらの機能は、 GuardDuty がサポートされている すべての商用 AWS リージョン で、GuardDuty の新規および既存のすべてのお客様に追加費用なしで自動的に有効になります。 これらの新機能の詳細を確認し、活用し始めるには、 Amazon GuardDuty のドキュメントをご覧ください。 – Esra 原文は こちら です。

2023 年、 Amazon CloudWatch Container Insights におけるオブザーバビリティの強化 を発表しました。これは、 Amazon Elastic Kubernetes Service (Amazon EKS) のオブザーバビリティを向上させるための新機能です。この機能は、詳細なパフォーマンスメトリクスとログを提供することで、コンテナの問題をより迅速に検出して修正するのに役立ちます。 この機能を拡張して、12 月 1 日、 Amazon Elastic Container Service (Amazon ECS) で実行されるコンテナワークロードのオブザーバビリティの強化を開始します。この新機能により、アプリケーション全体の平均検出時間 (MTTD) と平均修復時間 (MTTR) が短縮され、ユーザーエクスペリエンスに悪影響を及ぼす可能性のある問題を防ぐことができます。 Amazon ECS のオブザーバビリティが強化された Container Insights を簡単に見てみましょう。 オブザーバビリティが強化された Container Insights は、コンテナモニタリングにおける重大なギャップを解消します。以前は、メトリクスをログやイベントに関連付けるには時間がかかり、多くの場合、手動での検索とアプリケーションアーキテクチャの専門知識が必要でした。この機能により、CloudWatch と Amazon ECS は、タスクレベルとコンテナレベルの両方で CPU 使用率などの詳細なパフォーマンスメトリクスを自動的に収集すると同時に、視覚的にドリルダウンして根本原因の分析を簡単に行うことができます。 この新機能により、次のユースケースが可能になります。 詳細なリソース使用パターンを確認し、テレメトリデータを関連付けることで、根本原因を迅速に特定できます。 AWS ベストプラクティスに基づいて厳選されたダッシュボードを使用して ECS リソースをプロアクティブに管理します。 最新のデプロイとデプロイ失敗の根本原因をトラッキングし、一致するインフラストラクチャの異常を特定することで、より迅速に問題を検出し、必要に応じて迅速なロールバックを行えます。 手動で設定しなくても、複数のアカウントのリソースを簡単に監視できます。組み込みのクロスアカウントサポートにより、一元的なオブザーバビリティを得て運用上のオーバーヘッドを削減できます。 Application Signals や CloudWatch Logs といった他の CloudWatch サービスと統合することで、インフラストラクチャと実行中のサービスを相互に関連付け、影響を受けるサービスを特定するシームレスな体験が得られます。 Amazon ECS でオブザーバビリティが強化された Container Insights を使用する オブザーバビリティが強化された Container Insights を有効にするには、次の 2 つの方法があります。 クラスターレベルのオンボーディング – 特定のクラスターに対して個別に有効化できます。 アカウントレベルのオンボーディング – アカウントレベルで有効にすることもできます。これにより、アカウントで作成されたすべての新しいクラスターでオブザーバビリティが自動的に有効になります。この方法では、新しいクラスターごとに手動で有効化する必要がなくなるため、時間と労力を節約できます。 この機能をアカウントレベルで有効にするには、Amazon ECS コンソールに移動して [Account settings] (アカウント設定) を選択します。 [CloudWatch Container Insights observability] (CloudWatch Container Insights のオブザーバビリティ) セクションで、現在無効になっていることがわかります。 [Update] (更新) をクリックします。 このページには、 [Container Insights with enhanced observability] (オブザーバビリティが強化された Container Insights) という新しいオプションがあります。このオプションを選択し、 [Save changes] (変更を保存) を選択します。 クラスターレベルでこの機能を有効にする必要がある場合は、新しいクラスターを作成するときに有効にできます。 既存のクラスターでもこの機能を有効にできます。そのためには、 [Update cluster] (クラスターを更新) を選択し、オプションを選択します。 有効にすると、クラスター概要コンソールの [Metrics] (メトリクス) タブに移動すると、タスクレベルのメトリクスを確認できます。クラスター全体の状態およびパフォーマンスメトリクスにアクセスするには、 [View Container Insights] (Container Insights を表示) を選択します。これにより、Container Insights ページにリダイレクトされます。 さまざまなクラスターにわたるすべてのワークロードの全体像を把握するには、Amazon CloudWatch に移動してから Container Insights に移動します。 このビューは、クラスターの状態を直感的かつ高レベルで要約できるハニカムビジュアライゼーションを提供することで、クラスター、サービス、タスク、およびコンテナを効果的に監視するという課題に対処します。ダッシュボードはデュアルステートモニタリングアプローチを採用しています。 アラーム状態 (赤または緑) – お客様が定義したしきい値とアラートを反映し、チームが特定の要件に基づいて監視を設定できるようにします 使用状況 (濃い青または水色) – CloudWatch に組み込まれているベストプラクティスを使用して、コンテナ全体のリソース使用パターンを監視します。濃い青色はクラスターの使用率が高いことを示しているため、チームはパフォーマンスに影響が出る前に潜在的なリソースの制約を事前に特定できます クラスターの 1 つに問題があるとしましょう。クラスターにカーソルを合わせると、そのクラスターの下に作成されたすべてのアラームが、クラスターレイヤーからコンテナレイヤーまで、さまざまなレイヤーで表示されます。 また、すべてのクラスターをリスト形式で表示することもできます。アカウント ID とクラスター所有権のラベルを表示するリスト形式は、アカウント間のオブザーバビリティに不可欠です。これにより、DevOps エンジニアは潜在的なアプリケーションの問題をすばやく特定してアカウント所有者と協力して解決できます。 では、さらに詳しく見ていきましょう。クラスターリンクを選択すると、Container Insights の詳細ダッシュボードビューにリダイレクトされます。ここで、このクラスターのメモリ使用率が急上昇していることがわかります。 コンテナレベルの詳細を詳しく調べることができるため、この問題の原因となっているサービスをすばやく特定できます。 便利だと思われるもう 1 つの機能は、 フィルター オプションです。これは、このクラスター内のコンテナ、サービス、またはタスクについてより詳細な調査を行うのに役立ちます。 この問題の根本原因を理解するためにアプリケーションログを詳しく調べる必要がある場合は、タスクを選択し、[Actions] (アクション) を選択し、表示するログを選択できます。 AWS X-Ray トレースを使用する以外に、ここでは別の 2 種類のログを調べることができます。まず、パフォーマンスログ (メトリクスデータを含む構造化されたログ) を使用して、コンテナレベルの根本原因を掘り下げて特定できます。次に、収集したアプリケーションまたはコンテナのログを調べます。これらのログにより、コンテナ内のアプリケーションの動作に関する詳細なインサイトが得られ、問題の原因となった一連のイベントを追跡するのに役立ちます。 ここでは、アプリケーションログを使用します。 これにより、アプリケーションのトラブルシューティング過程が効率化されます。この場合、問題はサードパーティーアプリケーションへのダウンストリームの呼び出しにあり、タイムアウトが返されます。 この拡張機能も Amazon CloudWatch Application Signals と連携して、アプリケーションを自動的にインストルメント化します。現在のアプリケーションの状態を監視し、 サービスレベル目標 に対する長期的なアプリケーションパフォーマンスを追跡できます。 [Application Signals] タブを選択します。 この Amazon CloudWatch Application Signals との統合により、エンドツーエンドの可視性が得られ、コンテナのパフォーマンスをエンドユーザーエクスペリエンスと関連付けるのに役立ちます。 グラフでデータポイントを選択すると、関連するトレースが表示され、相関しているすべてのサービスとその影響が表示されます。関連するログにアクセスして根本原因を理解することもできます。 その他の情報 ここで、重要な点をいくつかご紹介します。 利用できるリージョン – ECS 向けのオブザーバビリティが強化された Container Insights が、中国リージョンを含むすべての AWS リージョンでご利用いただけるようになりました。 料金 – ECS 向けのオブザーバビリティが強化された Container Insights には、メトリクスの定額料金がかかります。 Amazon CloudWatch の料金 ページをご覧ください。 今すぐ始めて、コンテナワークロードのオブザーバビリティの向上をご体験ください。詳細については、 Amazon CloudWatch のドキュメント ページをご覧ください。 監視がうまくいきますように。 – Donnie Prakoso 原文は こちら です。

12 月 1 日、 AWS Clean Rooms のデータコラボレーションの新しいソースとして Snowflake と Amazon Athena のサポートを発表しました。AWS Clean Rooms を使用すると、お客様とパートナーが互いの基礎データを共有したりコピーしたりすることなく、集合データセットをよりシームレスかつ安全に分析できます。この機能強化により、ソースデータを移動したり公開したりすることなく、Snowflake に保存されているデータセット、または AWS Lake Formation アクセス許可や AWS Glue データカタログビュー などの Athena 機能を使用してクエリ可能なデータセットを操作できます。 研究開発、投資、マーケティングや広告キャンペーンのためのインサイトを得るには、多くの場合、パートナーと協力してデータセットを分析する必要があります。パートナーのデータセットが Amazon Simple Storage Service (Amazon S3) の外部に保存または管理されている場合があり、企業はデータの移動やコピーにまつわる複雑さ、コスト、コンプライアンスリスク、遅延を軽減または排除したいと考えています。企業はまた、データをコピーすると古い情報が使用され、得られるインサイトの質が低下する可能性があることにも気付きました。 今回の発表は、企業が抽出、変換、ロード (ゼロ ETL) で、AWS Clean Rooms コラボレーションで最新の集合データセットを共同作業するのに役立ちます。これにより、既存の環境からのデータセットの移行に伴うコストと複雑さが解消されます。例えば、Amazon S3 にデータを保存している広告主と、Snowflake に保存されているデータを持つメディアパブリッシャーは、ETL データパイプラインを構築したり、基礎となるデータを互いに共有したりしなくても、オーディエンスの重複分析を実行して、集合データセットに存在するユーザーの割合を判断できます。コラボレーションプロセス中、外部データソースからの基礎データが AWS Clean Rooms に永続的に保存されることはなく、AWS Clean Rooms 分析環境に一時的に読み込まれたデータは、クエリの完了時に削除されます。データの保存場所に関係なくパートナーと連携できるようになり、インサイトを生成するプロセスが合理化されます。 この機能の使い方をお見せしましょう。 AWS Clean Rooms で複数のクラウドとデータソースを使用する方法 この機能を説明するために、広告主である A 社とパブリッシャーである B 社の間のシナリオを使用します。A 社は、広告キャンペーンを実施する前に、B 社のウェブサイトで価値の高いユーザーのうち何人にリーチできるかを知りたいと考えています。A 社は自社のデータを Amazon S3 に保存しています。B 社はデータを Snowflake に保存しています。AWS Clean Rooms を使用するには、両当事者がそれぞれ独自の AWS アカウントを持っている必要があります。 このデモでは、広告主である A 社がコラボレーションの作成者です。A 社は AWS Clean Rooms コラボレーションを作成し、Snowflake でデータをホストしている B 社をコラボレーションに招待します。 AWS Clean Rooms の一般提供開始のお知らせブログ記事 を読むと、具体的な手順に従ってコラボレーションを作成できます。 次に、パブリッシャーの B 社が AWS Clean Rooms で設定済みのテーブルを作成し、データソースとして Snowflake を指定し、Secrets Manager の Amazon リソースネーム (ARN) を指定する方法を示します。 AWS Secrets Manager は、ライフサイクル全体にわたってデータベース認証情報などのシークレットを管理、取得、更新するのに役立ちます。シークレットには、コラボレーションしたいデータへの読み取り専用許可を持つ Snowflake ユーザーの認証情報が含まれている必要があります。AWS Clean Rooms はこれを使用してシークレットを読み取り、Snowflake に保存されているデータにアクセスします。シークレットを作成するステップバイステップの手順については、 Secrets Manager のドキュメント を参照してください。 B 社の AWS アカウントを使用して、 AWS Clean Rooms コンソール に移動し、 [Configured resources] (設定済みリソース) で [Tables] (テーブル) を選択します。 [Configure new table] (新しいテーブルを設定) を選択します。 [Third-party clouds and data sources] (サードパーティーのクラウドとデータソース) で [Snowflake] を選択します。コラボレーションしたい Snowflake に保存されているデータセットへの読み取りアクセス権を持つロールの Snowflake 認証情報を含むシークレットの シークレット ARN を入力します。これらは、Snowflake テーブルとスキーマにアクセスしようとしているエンティティの身元を確認するために使用する認証情報です。シークレット ARN がない場合は、 [Store a new secret for this table] (このテーブルに新しいシークレットを保存) オプションを使用して新しいシークレットを作成できます。 テ ーブルとスキーマの詳細 を定義するには、 [Import from file] (ファイルからインポート) オプションを使用し、Snowflake からエクスポートした列表示情報スキーマ CSV ファイルを選択すると情報が入力されます。情報を手動で入力することもできます。 このデモでは、 [Columns allowed in collaborations] (コラボレーションで許可された列) にある [All columns] (すべての列) を選択します。次に、 [Configure new table] (新しいテーブルを設定) を選択します。 設定したテーブルに移動して、クエリの作成を許可されている AWS アカウントやクエリに使用できる列など、テーブルの詳細を確認します。このページでは、テーブル名、説明、分析ルールを編集できます。 AWS Clean Rooms でコラボレーション分析に使用するテーブルの設定の一環として、分析ルールを設定する必要があります。分析ルールは、各データ所有者が設定済みテーブルに設定するプライバシーを強化するコントロールです。分析ルールは、設定済みテーブルをどのように分析できるかを決定します。 [Configure analysis rule] (分析ルールを設定) を選択して、設定済みテーブルでカスタムクエリを実行できるカスタム分析ルールを設定します。 ステップ 1 では、選択を進めていきます。 JSON エディタ を使用して、JSON 形式の分析ルール定義を作成、貼り付け、またはインポートできます。 [Next] (次へ) を選択します。 ステップ 2 では、 [Analyses for direct querying] (ダイレクトクエリの分析) で、 [Allow any queries created by specific collaborators to run without review on this table] (特定の共同作業者が作成したすべてのクエリをこのテーブルでレビューなしで実行できるようにする ) を選択します。このオプションでは、許可されたアカウントのリストで指定した AWS アカウントが提供したクエリのみをテーブルで実行できます。許可されたアカウントによって作成されたすべての分析テンプレートは、レビューを必要とせずに自動的にこのテーブルで実行できます。 [AWS account ID] (AWS アカウント ID) で許可されたアカウントを選択し、 [Next] (次へ) を選択します。 ステップ 3 では、選択を進めていきます。クエリ出力にすべての列が表示されるように、 [Columns not allowed in output] (出力では列が許可されていません) で [None] (なし) を選択します。 [Additional analyses applied to output] (追加分析が出力に適用されました) で [Not allowed] (許可されていません) を選択して、このテーブルで追加解析を実行できなくします。 [Next] (次へ) を選択します。 最後のステップでは、設定を確認して [Configure analysis rule] (分析ルールを設定) を選択します。 次に、このテーブルを [Associate to Collaboration] (コラボレーションに関連付ける) を使用して作成した広告主であるコラボレーションの A 社に関連付けます。 ポップアップウィンドウで、アクティブなメンバーシップを持つコラボレーションからコラボレーションを選択し、 [Choose collaboration] (コラボレーションを選ぶ) を選択します。 次のページで、 [Configured table name] (設定済みのテーブル名) を選択し、 [Table associations details] (テーブルの関連付けの詳細) に 名前 を入力します。AWS Clean Rooms がテーブルをクエリする許可を付与する方法を選択します。 [Associate table] (テーブルを関連付ける) 選択します。 広告主である A 社とパブリッシャーである B 社は、オーディエンス重複分析を実行して、互いの未加工データにアクセスすることなく、集合データセットに存在するユーザーの割合を判断できるようになりました。この分析は、パブリッシャーが広告主のオーディエンスにどの程度リーチできるかを判断するのに役立ちます。重複を評価することで、広告主はパブリッシャーが独自のリーチを提供しているのか、それともパブリッシャーのオーディエンスが広告主の既存のオーディエンスと主に重複しているのかを判断できます。どちらの当事者もソースデータを移動したり共有したりする必要はありません。A 社のアカウントに切り替えて、 AWS Clean Rooms コンソールに移動します。作成したコラボレーションを選択し、次のクエリを実行してオーディエンスの重複分析結果を取得します。 select count (distinct emailaddress) from customer_data_example as advertiser inner join synthetic_customer_data as publisher on 'emailaddress' = 'publisher_hashed_email_address' この例では、Snowflake をデータソースとして使用しました。 AWS Lake Formation の許可に従い、Athena を使用してこのデータに対してクエリを実行することもできます。これにより、Lake Formation のきめ細かいアクセス制御で行レベルと列レベルのフィルタリングを行い、データセットをコラボレーションに関連付ける前に AWS Glue データカタログビューを使用してデータを変換できます。 お客様とパートナーの声 「世界初の旅行者向けメディアネットワークである Kinective Media by United Airlines での業務には、データセキュリティとプライバシーが不可欠です」と、 Kinective Media by United Airlines の Strategic Partnerships 部門 Director の Khatidja Ajania 氏 は言います。「AWS Clean Rooms は複数のクラウドと AWS ソースのソースデータをサポートしているため、より多くのブランドと安全かつシームレスに連携して、クローズドループ測定やその他の主要なユースケースを実現できます。この強化により、プライバシーが強化された広告主やパートナーとのコラボレーションを通じて、パーソナライズされたエクスペリエンス、コンテンツ、関連サービスを何百万人もの United の旅行者に安全に提供できるようになります」。 「Snowflake では、データクリーンルームテクノロジーを使用する際に、テクノロジースタック間のソースデータの相互運用性に課題があることを認識しています。ユーザーが選択したソリューションを通じて、安全かつ効果的にデータパートナーシップの可能性を最大限に引き出せるようにするという共通の目標に向けた進展と新たな一歩を踏み出したことを嬉しく思います」– Snowflake Data Clean Rooms の General Manager、Kamakshi Sivaramakrishnan 氏 今すぐご利用いただけます AWS Clean Rooms のデータソースとして Snowflake と Athena がサポートされることは、クロスクラウドコラボレーションに大きなメリットをもたらします。今回の発表により、クラウドやデータソース間でのデータ移動が不要になり、コラボレーションプロセスが簡素化されます。これは、データの保存場所に関係なく、機密情報を保護しながら、お客様があらゆるパートナーと安全に連携できる方法を拡大するための取り組みの第一歩です。 AWS Clean Rooms を今すぐ始めましょう。複数のデータソースとのコラボレーションの詳細については、 AWS Clean Rooms のドキュメント をご覧ください。 – Esra 原文は こちら です。

AWS リージョン 全体で低レイテンシーの読み取りと書き込みを維持しながら、可用性の高いアプリケーションを提供することは、多くのお客様が直面している一般的な課題です。同じリージョンのデータにアクセスする場合には遅延がマイクロ秒単位であるのに対して、異なるリージョンのデータにアクセスすると数百ミリ秒の遅延が発生する可能性があります。デベロッパーはデータレプリケーションと競合解決のために複雑なカスタムソリューションを生み出す必要があり、これにより、運用上のワークロードが増加し、潜在的なエラーが発生する可能性があります。マルチリージョンレプリケーションに加えて、これらのお客様は、手動のデータベースフェイルオーバーの手順を実装し、データ整合性とリカバリを提供して、可用性の高いアプリケーションとデータの耐久性を実現する必要があります。 12 月 1 日、 Amazon Web Services (AWS) は、 Amazon MemoryDB マルチリージョン の一般提供の開始を発表しました。これは、複数の AWS リージョンにわたって最大 99.999% の可用性、マイクロ秒単位の読み取り、および 1 桁ミリ秒の書き込みレイテンシーを提供するアプリケーションの構築に使用できる、フルマネージドのアクティブ/アクティブマルチリージョンデータベースです。MemoryDB マルチリージョンは、 Linux Foundation が管理する Redis Open Source Software (OSS) のドロップインリプレースメントである Valkey で使用できます。この新しい機能は、マルチ AZ の耐久性や複数の AWS リージョンにわたる高スループットなど、 Amazon MemoryDB の既存の利点を拡張するものであり、多くのお客様が直面しているこれらの一般的な課題に対処します。 この記事では、MemoryDB マルチリージョンの利点について説明し、 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) で使用を開始する方法を示します。 MemoryDB マルチリージョンの利点 MemoryDB マルチリージョンは、お客様に次の利点を提供します: 高可用性とディザスタリカバリ – MemoryDB マルチリージョンを使用すると、最大 99.999 % の可用性を備えたアプリケーションを構築できます。また、アプリケーションがローカルリージョンの MemoryDB に接続できない場合でも、そのアプリケーションはデータに対する読み取りおよび書き込みのフルアクセスを使用して、別の AWS リージョンのエンドポイントから MemoryDB に接続できます。アプリケーションが元の MemoryDB リージョンレベルのエンドポイントに再接続すると、MemoryDB マルチリージョンはすべての AWS リージョンにわたってデータを自動的に同期します。 マルチリージョン分散アプリケーションのためのマイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシー – MemoryDB マルチリージョンはアクティブ/アクティブレプリケーションを提供するため、その規模にかかわらず、マイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーで、顧客に最も近いリージョンからローカルに読み取りと書き込みの両方を提供できます。AWS リージョン間でデータを非同期的かつ自動的にレプリケートします。データは通常 1 秒未満で伝播されます。 特定の地域にデータが存在する必要があるコンプライアンスおよび規制要件に準拠 – ある地理的な場所内にデータが存在することを要求するコンプライアンスおよび規制要件があります。MemoryDB マルチリージョンは、お客様がデータを保存したいリージョンを選択することを可能にするため、これらの要件を満たすのに役立ちます。 Amazon MemoryDB マルチリージョンの開始方法 MemoryDB マルチリージョンの設定は簡単で、AWS マネジメントコンソール、AWS SDK、または AWS CLI を通じて実行できます。 コンソールを使用した MemoryDB マルチリージョンの開始方法 コンソールを使用して MemoryDB マルチリージョンクラスターを設定するには、次のステップを実行します: MemoryDB コンソールのナビゲーションペインで [クラスター] を選択し、 [クラスターを作成] を選択して、 [クラスタータイプ] で [マルチリージョンクラスター] を、 [クラスターの作成方法] で [新しいクラスターを作成] を選択します。 マルチリージョンクラスターを設定する際に、ワークロードの要件に基づいて [ノードタイプ] と [シャードの数] を選択できます。 適切なクラスター設定を使用して、マルチリージョンクラスター内にリージョンレベルのクラスターを作成します。 マルチリージョンクラスターと最初のリージョンレベルのクラスターを設定した後、 [AWS リージョンを追加] を選択することで、マルチリージョンクラスターに 2 番目のリージョンレベルのクラスターを追加できます。 クラスター作成ワークフローが正常に終了すると、マルチリージョンクラスター内に 2 つのリージョンレベルのクラスターがあることがわかります。 AWS CLI の使用を開始するためのステップ まず、新しい MemoryDB マルチリージョンクラスターを作成します: aws memorydb create-multi-region-cluster \ --multi-region-cluster-name-suffix testmrrlp \ --endpoint-url https://elasticache-qa.us-east-1.amazonaws.com \ --description "testdescription" \ --node-type db.r7g.xlarge \ --region us-east-1 \ --no-verify-ssl 次に、マルチリージョンクラスターにリージョンレベルのクラスターを作成します: aws memorydb create-cluster \ --cluster-name testmrrlp-member1 \ --multi-region-cluster-name ldgnf-testmrrlp \ --node-type db.r7g.xlarge \ --num-replicas-per-shard 1 \ --snapshot-retention-limit 10 \ --endpoint-url <value> \ --acl-name open-access \ --region us-east-1 \ --no-verify-ssl 最初のクラスターが正常に作成されたことを確認したら、別のリージョンに 2 番目のクラスターを作成します: aws memorydb create-cluster \ --cluster-name testmrrlp-member2 \ --multi-region-cluster-name ldgnf-testmrrlp \ --node-type db.r7g.xlarge \ --num-replicas-per-shard 1 \ --snapshot-retention-limit 10 \ --endpoint-url https://elmo-qa.fra.aws-border.com \ --acl-name open-access \ --region eu-central-1 \ --no-verify-ssl マルチリージョンクラスターのステータスを確認します: aws memorydb describe-multi-region-clusters \ --multi-region-cluster-name ldgnf-testmrrlp \ --region us-east-1 \ --show-member-cluster-details \ --endpoint-url https://elasticache-qa.us-east-1.amazonaws.com \ --no-verify-ssl 今すぐご利用いただけます Amazon MemoryDB マルチリージョンは、Valkey および次の AWS リージョンで利用可能です: 米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、および欧州 (フランクフルト、アイルランド、ロンドン)。 詳細については、 MemoryDB の特徴ページ および ドキュメント にアクセスしてください。料金については、「 Amazon MemoryDB の料金 」をご覧ください。 – Betty 原文は こちら です。

こんにちは、AWS ソリューションアーキテクト の大南です。 2024 年 6 月 27 日に「【教育委員会様向け】クラウド化で実現する校務支援システムの共同利用とゼロトラスト」というタイトルでウェビナーを開催しました。開催報告として、ウェビナーの内容と当日の資料や収録映像を紹介します。 開催の概要 統合型校務支援システム共同利用（ゼロトラストモデル）の実現に取り組まれている教育委員会や支援を担っているベンダーから具体的な取り組みや事例をご紹介いただきます。また、関連するソリューションを提供しているベンダーや Amazon Web Services (AWS) からもゼロトラストの実現を支援するサービスや構成等をご紹介いたします。 セミナー内容紹介 / 収録映像 タイトル : 【教育委員会様向け】クラウド化で実現する校務支援システムの共同利用とゼロトラスト 開催日 : 2024 年 6 月 27 日 (木) 資料 : 資料ダウンロード 動画視聴 : こちら (必要情報を入力後に視聴可能となります) 岩手県域における統合型校務支援システム共同利用（ゼロトラストモデル）の取り組み 岩手県域における統合型校務支援システムの共同利用について、岩手県教育委員会様から、共同利用に踏み切った背景やゼロトラストモデルの採用に至った背景や、プロジェクトを振り返って、クラウド化によるメリットや課題について紹介しています。また、システムディ様から、岩手県域における統合型校務支援システムの共同利用を通して、システムディ のサービスやクラウド環境のメリットのご紹介と次世代校務に関する情報を解説しています。 岩手県教育委員会 教育企画室 学校教育情報化担当課長 門脇 優行 氏 岩手県教育委員会では、県と市町村が連携して学校教育のさまざまな課題を共有しながら ICT 化に取り組んでいます。令和元年時点の統合型校務支援システムの整備率が全国平均より低かったことから、共同調達と共同利用を目指し、2021年2月に協議会の枠組みを利用することでワーキンググループを設置し着手しました。 共同利用の実現には、県がイニシャルコストを全額負担し市町村の参加を促進したこと、教育長の理解を得て業務の標準化を進めたことが重要でした。またゼロトラストモデルを採用したクラウド環境での構築により、セキュリティ強化と費用対効果の向上を図ることとしました。 プロポーザル方式で選定したシステムは、教職員の業務効率化や生体認証の導入など、様々な機能を備えています。今後の課題は、運用開始時の初期トラブル対応、効果的な運用に向けたモニタリングと改善、教職員の業務負担軽減と教育の質の向上であるとし、県と市町村が連携しながらこの取り組みを推進していくとのことです。 株式会社システムディ 公教育ソリューション事業部課長 中村 岳志 氏 株式会社システム ディは、校務支援システム「School Engine (スクールエンジン)」を提供しており、これまで全国5団体にて共同利用での統合型校務支援システムを導入しています。校務支援システムの共同利用クラウド化のメリット、岩手県教育委員会と取り組んでいる内容と AWS をクラウド基盤に採用した経緯について解説しています。 岩手県のように都道府県単位での共同利用を行うことで、コストの割り勘効果が得られることや、学習システムとのデータ連携、業務の標準化などのメリットをあげられています。また、実際の構築においては、短期間での稼働が実現できおおむね満足できる結果となったとのことです。今後は AWS のサービスアップデートに追従する体制作りの必要性や、生成 AI との連携を取り組んでいきたいとのことです。 校務 DX ・ゼロトラストを支える ID 基盤とは教職員と児童生徒のアカウントの一元管理と認証 セキュリティの強化は、校務 DX ・ゼロトラストを考えていく上で重要な課題となっています。エクスジェン・ネットワークスが提供する Extic は ID の統合管理を支援するサービスです。実際のお客様のユースケースを交えて解説しています。 エクスジェン・ネットワークス株式会社 専務取締役 引間 賢太 氏 エクスジェン・ネットワークス株式会社 引間氏より、校務 DX とゼロトラスト基盤を支える ID 基盤について解説しています。 ID 管理製品を扱う専業メーカーであるエクスジェン・ネットワークスは、統合 ID 管理パッケージソフトウェア「LDAP Manager」とクラウドサービス「Extic」を提供しています。ギガスクール構想における校務 DX の推進に伴い、ID とアクセス権限の一元管理が重要になると説明しています。Extic は認証管理と ID 管理の機能を備え、児童生徒や教職員のアカウントを一元管理し、各アプリケーションへのシングルサインオンを実現します。また、アクセス権限を所属や役職に応じて制御することで、ゼロトラストセキュリティを実現できるとしています。最後に製品の機能概要と価格モデルを紹介し、教育委員会の課題解決に貢献できると解説しています。 ダイワボウ情報システムが展開する、教育 ICT 環境におけるクラウド化の取り組み ダイワボウ情報システムが教育委員会向けに提供するプリペイドチャージや、ハンズオントレーニング等のソリューションをご紹介します。 ダイワボウ情報システム株式会社 クラウドサービス推進グループ 西崎 豪 氏 ダイワボウ情報システム株式会社では、国内初の AWS ディストリビューターとして、約1,300社の AWS ディストリビューションセラーを通じて AWS サービスを提供しています。DIS クラウドエコノミクスライトによるクラウド移行の効果分析、プリペイドチャージ for AWS による予算内での利用教育機関向けのクラウド移行を支援するメニューを用意しており、全国の教育機関の情報化、教育 DX 推進を支援していくとの解説をしています。 AWS とパートナー製品で実現する校務支援システムのゼロトラスト構成 AWS サービスとパートナー製品を組み合わせた実践的なゼロトラスト構成についてご紹介します。 アマゾンウェブサービスジャパン合同会社 パブリックセクター 技術統括本部 大南 賢亮 AWSサービスとパートナー製品による、校務支援システムのゼロトラスト構成を実現するための対応方法を解説しています。 校務支援システムを取り巻く状況、ゼロトラストの概念を解説し、文科省による教育情報セキュリティポリシーガイドラインを紹介しています。AWS サービスとパートナー製品を組み合わせることで、セキュリティ、安定性、コスト、使い勝手に優れた構成が可能であること、また、アーキテクチャとともにガイドラインを満たすためのパートナーソリューションの具体例を紹介しています。最後に AWS の採用事例と、AWS ソリューションアーキテクトによる技術支援の内容について触れ、校務支援システムの設計において、実践的な内容が示されています。 おわりに 本セミナーの内容が、校務支援システムの共同利用やゼロトラストモデルの活用の一助になれば幸いです。AWS の活用や提案に関する相談、要望がありましたら、担当営業、もしくは公式サイトの お問い合わせ よりお問い合わせください。 このブログは、2024 年 11 月 26 日時点の情報に基づいて ソリューションアーキテクト 大南賢亮 が執筆しました。

Amazon Web Services (AWS) では、新機能の大部分がお客様からの直接のフィードバックを踏まえて実現されています。 2 年前、Jeff は追加のチェックサムアルゴリズムと、オプションのクライアント側でのチェックサム計算を発表しました 。これにより、Amazon S3 に保存されているオブジェクトが、送信したオブジェクトとまったく同じであることについて、確実を期すことができます。この追加の検証により、保存されているオブジェクトが、送信したオブジェクトであると確信できるため、この追加の検証機能を愛用しているという声をお寄せいただきました。また、この追加の検証が自動的に有効になり、追加のコードを開発する必要をなくしてもらいたいという声もいただきました。 12 月 1 日より、オブジェクトをアップロードする際の Amazon Simple Storage Service (Amazon S3) のデフォルト動作を更新します。高い耐久性を実現するための既存の体勢をさらに強化するため、Amazon S3 は、データがアプリケーションから S3 バケットにネットワーク経由で正しく送信されていることを自動的に検証するようになりました。 Amazon S3 は、99.999999999% のデータ耐久性 ( イレブンナイン ) を実現するように設計されています。Amazon S3 は、オブジェクトが複数のストレージデバイスに書き込まれる前に、サーバーに到達したときにチェックサムを計算することによって、オブジェクトアップロードの整合性を常に検証してきました。データが Amazon S3 に保存されると、保管中のデータの整合性チェックが定期的に実行され、時間が経過する中でデータの耐久性が継続的にモニタリングされます。また、Amazon S3 は、オブジェクトが複数のストレージデバイスの同時障害に耐えられることを検証するのに役立つよう、データの冗長性をアクティブにモニタリングします。 ただし、データはパブリックインターネットを通過してからサーバーに到達するため、整合性のリスクに直面する可能性があります。当社が管理していないネットワーク上のハードウェアの障害や、クライアントソフトウェアのバグなどの問題により、Amazon S3 が検証する前にデータが破損またはドロップされる可能性があります。以前は、 PutObject または UploadPart リクエストで独自の事前計算済みチェックサムを提供することで、整合性保護を拡張できました。ただし、これにはチェックサムを生成して追跡するためのツールとアプリケーションの設定が必要であり、Amazon S3 にオブジェクトをアップロードするすべてのクライアントアプリケーションで一貫して実装するのは複雑になる可能性があります。 新しいデフォルト動作は、アプリケーションを変更することなく、既存のデータ整合性保護を強化します。さらに、新しいチェックサムはオブジェクトのメタデータに保存されるため、いつでも整合性検証のためにアクセスできます。 クライアント側の自動整合性保護 Amazon S3 は、デフォルトでデータ整合性保護をクライアント側のアプリケーションまで拡張するようになりました。最新バージョンの AWS SDK は、アップロードごとに 巡回冗長検査 (CRC) ベースのチェックサム を自動的に計算し、Amazon S3 に送信します。Amazon S3 は、サーバー側でチェックサムを独自に計算し、指定された値に照らして検証してから、高い耐久性をもって、オブジェクトとそのチェックサムをオブジェクトのメタデータに保存します。 クライアントアプリケーションが CRC チェックサムを送信しない場合 (古いバージョンの SDK を使用しているか、アプリケーションのカスタムコードがまだ更新されていないことが原因である可能性があります)、Amazon S3 は CRC ベースのチェックサムを計算し、将来の参照用にオブジェクトのメタデータに保存します。後で、保存された CRC と、ユーザー側で計算された CRC を比較して、ネットワーク送信が正しかったことを検証できます。 この新しい機能により、最新バージョンの AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) 、および AWS マネジメントコンソール からの新しいアップロードについてのチェックサムの自動計算と検証が提供されます。また、オブジェクトのメタデータに保存されているチェックサムをいつでも検証できます。新しいデフォルトのデータ整合性保護は、既存の CRC32 および CRC32C アルゴリズム、または新しい CRC64NVME アルゴリズム を使用します。また、Amazon S3 は、シングルパートアップロードとマルチパートアップロードで一貫したフルオブジェクトチェックサムをデベロッパーに提供します。 マルチパートでファイルをアップロードする場合、SDK は各パートについてチェックサムを計算します。Amazon S3 はこれらのチェックサムを使用して、 UploadPart API を通じて各パートの整合性を検証します。さらに、 CompleteMultipartUpload API を呼び出すと、S3 はファイル全体のサイズとチェックサムを検証します。 CreateMultiPartUpload API では、使用するチェックサムのタイプを指定できるようにする、新しい HTTP ヘッダー x-amz-checksum-type が導入されています。完全なオブジェクトチェックサム (すべての個々のパーツのチェックサムを組み合わせて計算されます) または複合チェックサムのいずれかを選択できます。 完全なオブジェクトチェックサムは、将来の参照用にオブジェクトメタデータとともに保存されます。この新しい保護は、 サーバー側の暗号化 とシームレスに連携します。アップロード、マルチパートアップロード、ダウンロード、暗号化モード全体での一貫性のある動作により、クライアント側の整合性チェックが簡素化されます。完全なオブジェクトチェックサムを使用して整合性を検証し、後で使用するために保存する機能は、アプリケーションの効率化に役立ちます。 実際の動作 この追加の整合性保護の使用を開始するには、最新バージョンの AWS SDK または AWS CLI に更新します。新しい整合性保護を有効にするためにコードを変更する必要はありません。 ケース 1: チェックサムなしでオブジェクトがアップロードされた場合、Amazon S3 はサーバー側でオブジェクトにチェックサムをアタッチするようになりました S3 バケットとの間でコンテンツをアップロードおよびダウンロードするためのシンプルな Python スクリプトを記述しました。Amazon S3 との間で送受信される実際の HTTP ヘッダーを確認するために、ログ記録の詳細度を最大にしました。 import boto3 import logging BUCKET_NAME="aws-news-blog-20241111" CONTENT='Hello World!' OBJECT_NAME='test.txt' # boto3 および botocore のデバッグログ記録を有効にして stdout に設定します (これは冗長です !!!) logging.basicConfig(level=logging.DEBUG) # S3 クライアントを作成します client = boto3.client('s3') # オブジェクトを配置します client.put_object(Bucket=BUCKET_NAME, Key=OBJECT_NAME, Body=CONTENT) # オブジェクトを取得します response = client.get_object(Bucket=BUCKET_NAME, Key=OBJECT_NAME) print(response['Body'].read().decode('utf-8')) このデモの最初のステップでは、クライアント側で CRC チェックサムを計算しない古い AWS SDK for Python を使用します。それにもかかわらず、ここでは Amazon S3 はオブジェクトの受信時に計算したチェックサムで応答するようになったことがわかります。 S3 RESPONSE: { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } ケース 2: 手動で事前計算された CRC64NVME チェックサム (新しいチェックサムタイプ) を使用してアップロードします 最新バージョンの AWS SDK を使用するオプションがない場合、または独自のコードを使用してオブジェクトを S3 バケットにアップロードする場合は、チェックサムを計算して、 PutObject API リクエストで送信できます。Amazon S3 に送信する前にコンテンツのチェックサムを計算する方法を次に示します。このコードが短くなるよう、新しい AWS SDK for Python で使用できる checksums パッケージを使用します。 from awscrt import checksums import base64 checksum = checksums.crc64nvme("Hello World!") checksum_bytes = checksum.to_bytes(8, byteorder='big') # CRC64 is 8 bytes checksum_base64 = base64.b64encode(checksum_bytes) print(checksum_base64) これを実行すると、CRC64NVME チェックサムが、前のステップで Amazon S3 によって返されたものと同じであることがわかります。 $ python crc.py b'AuUcyF784aU=' このチェックサムは、 PutObject API コールの一部として提供できます。 response = s3.put_object( Bucket=BUCKET_NAME, Key=OBJECT_NAME, Body=b'Hello World!', ChecksumAlgorithm='CRC64NVME', ChecksumCRC64NVME=checksum_base64 ) ケース 3: 新しい SDK がクライアント側でのチェックサムを計算します ここで、アップロードおよびダウンロードスクリプトを再度実行します。今回は、最新バージョンの AWS SDK for Python を使用します。SDK がリクエストで CRC ヘッダーを送信するようになったことがわかります。レスポンスにもチェックサムが含まれています。リクエストとレスポンスのバージョンを簡単に比較して、受信したオブジェクトが、送信したオブジェクトであることを確認できます。 REQUEST: { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } いつでも、 HeadObject または GetObject API を使用して、ローカルコピーの整合性を検証するためにオブジェクトチェックサムをリクエストできます。 get_response = s3.get_object( Bucket=BUCKET_NAME, Key=OBJECT_NAME, ChecksumMode='ENABLED' ) レスポンスオブジェクトには、 HTTPHeaders フィールドにチェックサムが含まれています。 { ... "x-amz-checksum-crc64nvme": "AuUcyF784aU=", "x-amz-checksum-type": "FULL_OBJECT", ... } ケース 4: 新しい CRC ベースのオブジェクト全体のチェックサムを使用したマルチパートアップロード CreateMultipartUpload 、 UploadPart 、および CompleteMultipartUpload API を使用して大きなオブジェクトをアップロードする場合、最新バージョンの SDK はチェックサムを自動的に計算します。 既知のコンテンツチェックサムを使用することによってデータの整合性を検証する場合は、マルチパートアップロードの CRC ベースのオブジェクト全体のチェックサムを事前に計算して、クライアント側のツールを簡素化できます。マルチパートアップロードのために完全なオブジェクトチェックサムを使用すると、オブジェクトをアップロードするときにパートレベルのチェックサムを追跡する必要がなくなります。 # フルオブジェクトについての事前計算済み CRC64NVME チェックサム full_object_crc64_nvme_checksum = 'Naz0uXkYBPM=' # マルチパートアップロードを開始します create_response = s3.create_multipart_upload( Bucket=BUCKET_NAME, Key=OBJECT_NAME, ChecksumAlgorithm='CRC64NVME', ChecksumType='FULL_OBJECT' ) upload_id = create_response['UploadId'] # パートをアップロードします uploaded_parts = [] # パート 1 data_part_1 = b'0' * (5 * 1024 * 1024) # 最小パートサイズ upload_part_response_1 = s3.upload_part( Body=data_part_1, Bucket=BUCKET_NAME, Key=OBJECT_NAME, PartNumber=1, UploadId=upload_id, ChecksumAlgorithm='CRC64NVME' ) uploaded_parts.append({'PartNumber': 1, 'ETag': upload_part_response_1['ETag']}) # パート 2 data_part_2 = b'0' * (5 * 1024 * 1024) upload_part_response_2 = s3.upload_part( Body=data_part_2, Bucket=BUCKET_NAME, Key=OBJECT_NAME, PartNumber=2, UploadId=upload_id, ChecksumAlgorithm='CRC64NVME' ) uploaded_parts.append({'PartNumber': 2, 'ETag': upload_part_response_2['ETag']}) # FULL_OBJECT CRC64NVME チェックサムを使用してマルチパートアップロードを完了し、オブジェクト全体の整合性を検証します。 complete_response = s3.complete_multipart_upload( Bucket=BUCKET_NAME, Key=OBJECT_NAME, UploadId=upload_id, ChecksumCRC64NVME=full_object_crc64_nvme_checksum, ChecksumType='FULL_OBJECT', MultipartUpload={'Parts': uploaded_parts} ) print(complete_response) 知っておくべきこと 既存のオブジェクトの場合、コピー時にチェックサムが追加されます。 CopyObject API を更新したので、宛先オブジェクトのために必要なチェックサムアルゴリズムを選択できます。 この新しいクライアント側のチェックサム計算は、最新バージョンの AWS SDK に実装されています。チェックサムを事前に計算しない古い SDK またはカスタムコードを使用する場合、Amazon S3 は受信したすべての新しいオブジェクトのチェックサムを計算し、マルチパートアップロードでもオブジェクトのメタデータに保存します。 料金と利用可能なリージョン この拡張チェックサム計算とストレージは、すべての AWS リージョン で追加コストなしでご利用いただけます。 今すぐ AWS SDK と AWS CLI を更新して、転送中のデータのために、この追加の整合性保護の恩恵を自動的に享受しましょう。 Amazon S3 のデータ整合性保護の詳細については、「Amazon S3 ユーザーガイド」の「 オブジェクトの整合性をチェックする 」にアクセスしてください。 — seb 原文は こちら です。

12 月 1 日より、 AWS Database Migration Service Schema Conversion (AWS DMS SC) に、最大 90% のスキーマオブジェクトを商用データベースから PostgreSQL 移行に自動的に変換することで、データベーススキーマ変換エクスペリエンスを改善する新しい機能が導入されます。 AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、および他の種類のデータストアの移行を可能にするクラウドサービスです。 AWS DMS を使用して、 Amazon Web Services (AWS) クラウドにデータを移行したり、クラウドおよびオンプレミスの設定の組み合わせの間でデータを移行したりできます。 現在、100 万を超えるデータベースが AWS Database Migration Service を使用して移行されています。 AWS DMS は、あるデータベースシステムから別のデータベースシステムへのデータの移行に役立ちます。また、異なるデータベースエンジン間で移行する場合、AWS DMS SC はソースデータベースのスキーマとプロシージャをターゲットデータベースシステムに変換するのに役立ちます。 ただし、AWS DMS SC はこれらの移行の多くのステップを自動化しますが、特定の複雑なデータベースコード要素には依然として手動介入が必要です。これにより、移行のタイムラインが延び、コストが増える可能性があります。これは特に、PostgreSQL に直接対応するものが必ずしも存在しない独自のシステム関数またはプロシージャ、およびデータ型変換の場合に当てはまります。 AWS DMS SC の新しい 生成 AI 機能は、時間がかかるスキーマ変換タスクの一部を自動化することで、これらの課題に対処するように設計されています。この新しい機能は、 Amazon Bedrock でホストされている 大規模言語モデル (LLM) を使用して、既存の変換機能を拡張します。複雑な手順や関数など、従来のルールベースの手法ではサポートされていなかったソースデータベース内のコードスニペットを変換します。 生成 AI を利用したコード変換は、移行コストを削減し、プロジェクトのタイムラインを短縮するのに役立ちます。AWS DMS SC はスキーマ変換プロセスの多くを自動化するため、手動での変換ギャップの解決ではなく、移行後のアプリケーションの改良や最適化など、より価値の高いタスクに注力できます。ベータ版のお客様は、AWS DMS SC で AI を活用したこれらの機能を使用して既に成功を収めており、コスト削減と移行の高速化を実現しています。 仕組みを見てみましょう この新しい生成 AI 機能の使いやすさを示すために、AWS DMS SC のスキーマ変換プロセスについて説明します。  AWS DMS SC は、テーブル、ビュー、ストアドプロシージャ、関数など、ソースデータベースの構造をターゲットデータベースと互換性のある形式に自動的に変換することで、データベースの移行を簡素化します。自動的に変換できないオブジェクトには、手動で対処するようにフラグが付けられます。 まず、 Amazon Elastic Compute Cloud (Amazon EC2) で実行されているセルフマネージド型の商用データベースから始めます。 AWS マネジメントコンソール を使用して、 インスタンスプロファイル と データプロバイダー を定義します。ここで、レプリケーションインスタンスのネットワークの詳細、データベースエンジンとそのエンドポイント、データベースパスワードが安全に保存されるシークレットなどを設定します。移行プロジェクトも作成します。これらのステップは新しいものではありません。詳細については、AWS データベースブログの「 Accelerate your database migration journey using AWS DMS Schema Conversion 」をご覧ください。 プロジェクトを作成したら、それを選択し、 [スキーマ変換] タブで [スキーマ変換を起動] を選択します。変換ツールを初めて起動するには、数分かかります。 生成 AI を使用した AWS DMS SC はオプトイン機能です。まず、このオプションをアクティブ化します。 [設定] タブで、 [変換用の生成 AI 機能を有効にする] をオンにします。 変換の詳細に進む前に、移行の複雑さの全体的な評価を取得したいと思います。移行するスキーマを選択します。その後、メニューで [評価] を選択します。 数分後、高レベルの [概要] が使用可能になります。 [アクション項目] タブに詳細が表示されます。 [結果をエクスポート] を選択し、 [PDF] を選択して、同僚と共有するレポートを受け取ります。レポートは S3 バケットから生成され、使用可能になります。 概要の画面には、ルールベースの方法によって変換できる [データベースストレージオブジェクト] と [データベースコードオブジェクト] の割合が表示されます。この例では、 [100%] と [57%] です。生成 AI ベースの変換によって、この割合がどのように変化するかを見てみましょう。 PDF には、エグゼクティブサマリー、移行するオブジェクトの数に関するさまざまな統計、生成 AI を使用した変換の実現可能性、移行の複雑さが含まれています。 レポートを読むと、ストアドプロシージャの移行を妨げる要因は検出されていないことがわかります。移行するストアドプロシージャ ( PRC_AIML_DEMO6 ) を選択します。その後、ソースデータベース (左側) の [アクション] メニューを選択し、 [変換] を選択します。 1～2 分後に、左側のペインには元のプロシージャコードが表示され、右側のパネルには提案された移行バージョンが表示されます。 概要の画面が更新されました。これで、 コードの 100% が自動的に変換できることが示されるようになりました 。 必要に応じてコードを編集して変更を加えることができます。提案された新しいバージョンに問題がなければ、ターゲットデータベース側 (右側) の [アクション] メニューを選択し、 [変更を適用] を選択します。 この新しい生成 AI 機能により、AWS DMS SC は、商用データベースのスキーマオブジェクトの最大 90% を PostgreSQL に自動的に変換できます。 コンプライアンス要件をサポートするために、この機能は最初はオフになっていますが、必要に応じて有効にすることができます。AWS DMS SC で生成 AI 機能を使用する場合は、変換するオブジェクトの複雑さに基づいて、従来のルールベースの方法と生成 AI のいずれを使用するのかが柔軟に決定されます。生成 AI に対して厳格なポリシーを持つお客様は、ルールベースのアプローチのみに引き続き依拠できます。変換されていないオブジェクトや部分的に変換されたオブジェクトは手動で調整する必要があります。 利用可能なリージョンと料金 この新しい機能は現在、次の AWS リージョン でご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト)。 生成 AI を使用した AWS DMS スキーマ変換は、より高速な移行パスをお客様に提供するほか、AWS への移行を加速するのに役立ちます。 使用を開始するには、 AWS DMS スキーマ変換 のドキュメントにアクセスし、この生成 AI 機能が次のデータベース移行をどのように簡素化できるのかをご覧ください。 原文は こちら です。 — seb

12 月 1 日、宣言型ポリシーを発表しました。これは、組織全体で特定の AWS サービスのために必要な設定を宣言して強制適用するのに役立つ新しい機能です。 クラウドリソースの設定方法について、組織内で標準を作成することは、お客様にとってよくあることです。例えば、Amazon EBS スナップショットについてのパブリックアクセスをブロックする必要がある場合があります。お客様は、これらの標準を一度だけ一元的に定義し、将来組織に参加するアカウントを含むすべてのアカウントに強制適用したいと考えています。さらに、クラウドオペレーターが標準を満たさない態様でリソースを設定しようとするたびに、そのオペレーターが、設定を是正する方法を説明する、有益で実用的なエラーメッセージを受け取るようにしたいと考えています。 宣言型ポリシーは、数回のクリックまたはコマンドで AWS サービスのために必要な設定を定義および強制適用できるようにすることで、これらの課題に対処します。「VPC についてのパブリックアクセスをブロック」などの必要な設定を選択でき、ポリシーをアタッチすると、AWS は自動的にマルチアカウント環境全体 (またはその一部) で、お客様が希望する状態を強制適用します。このアプローチにより、お客様が希望する設定を実現する際の複雑さが軽減されます。設定が完了すると、新機能や新しい API が追加されても、その設定は維持されます。さらに、宣言型ポリシーを使用すると、管理者は環境全体のサービス属性の現在の状態を把握できます。また、許可のないユーザーに情報を漏らすことのないアクセスコントロールポリシーとは異なり、エンドユーザーには組織の管理者が設定したカスタムエラーメッセージが表示され、内部リソースまたはサポートチャネルにリダイレクトされます。 「ABSA Group は規制の厳しい環境で事業を展開しており、より多くのサービスを導入するようになる中で、アクションを制限するために SCP ポリシーの除外を使用し、違反を検出するために Config ルールを使用しています。しかし、新しい API や機能ごとに例外を作成する必要があります。宣言型ポリシーを使用すると、VPC ブロックパブリックアクセスを true に設定するだけで、いかなるユーザー、サービスにリンクされたロール、または将来の API も、当社の AWS Organizations でパブリックアクセスを促進できないことについて安心できます」と南アフリカのヨハネスブルグに拠点を構える多国籍銀行および金融サービスの複合企業である ABSA の Lead Product Engineer である Vojtech Mencl 氏は説明します。 「カスタムエラーメッセージを使用すると、エンドユーザーを内部ポータルに簡単にリダイレクトして、アクションが失敗した理由の詳細を提供できます。これにより、ガバナンスの運用上の複雑さが大幅に軽減され、AWS への移行が加速されます」と ABSA の Principal Engineer である Matt Draper 氏は述べています。 今回のリリースでは、宣言型ポリシーは、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Virtual Private Cloud (Amazon VPC) 、および Amazon Elastic Block Store (Amazon EBS) サービスをサポートしています。使用可能なサービス属性には、IMDSv2 の強制適用、シリアルコンソールを通じたトラブルシューティングの許可、 Amazon マシンイメージ (AMI) 設定の許可、ならびに Amazon EBS スナップショット、Amazon EC2 AMI、および VPC のパブリックアクセスのブロックが含まれます。新しいアカウントが組織に追加されると、それらのアカウントは、組織、組織単位 (OU)、またはアカウントレベルで適用された宣言型ポリシーを継承します。 宣言型ポリシーは、 AWS Organizations コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、または AWS Control Tower を通じて作成できます。ポリシーは、組織、OU、またはアカウントレベルで適用できます。宣言型ポリシーをアタッチすると、作成した AWS Identity and Access Management (IAM) ロールを使用して呼び出されたか、 サービスにリンクされたロール を使用する AWS サービスによって呼び出されたかにかかわらず、非準拠のアクションが防止されます。 宣言型ポリシーの開始方法 宣言型ポリシーのデモンストレーションのために、例を挙げて説明します。数百の AWS アカウントを持つ大企業のセキュリティ管理者として、組織の厳格なセキュリティ体制を維持する責任があるとします。当社には、いくつかの重要なセキュリティ要件があります。すなわち、すべてのネットワークでインターネットアクセスに対する厳格なコントロールを維持し、特定の信頼できるプロバイダーからの AMI のみを許可するとともに、VPC リソースが誤ってパブリックインターネットに公開されないようにする必要があります。宣言型ポリシーを使用すると、これらの要件を効率的に実装できます。私の環境でこれをどのように設定したかを説明します。 AWS Organizations コンソール に移動し、ナビゲーションペインで [ポリシー] を選択します。 [サポートされているポリシータイプ] で [EC2 の宣言型ポリシー] を選択します。 [EC2 の宣言型ポリシーを有効にする] を選択して、機能を有効にします。 宣言型ポリシーを有効にすると、AWS Organizations 内のすべてのアカウントで EC2 のために必要な設定を定義して強制適用できます。 宣言型ポリシーを作成する前に、組織の管理者として、宣言型ポリシーの機能であるアカウントステータスレポートを使用して、AWS 環境の現在のステータスを理解したいと考えています。レポートは、選択した組織の範囲内のすべてのアカウントと AWS リージョンをカバーする概要ビューと詳細な CSV ファイルの両方を提供します。ポリシーをアタッチする前に準備状況を評価するのに役立ちます。 次のページで、 [ステータスレポートを生成] を選択します。 [レポート S3 URI] の下の Amazon Simple Storage Service (Amazon S3) バケットを選択し、レポートの範囲に含めるアカウントと OU を選択します。 ステータスレポートを保存するには、S3 バケットに次のポリシーがアタッチされている必要があることに留意してください: { "Version": "2012-10-17", "Statement": [ { "Sid": "DeclarativePoliciesReportBucket", "Effect": "Allow", "Principal": { "Service": [ "report.declarative-policies-ec2.amazonaws.com" ] }, "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::<bucketName>/*", "Condition": { "StringEquals": { "aws:SourceArn": "arn:<partition>:declarative-policies-ec2:<region>:<accountId>:*" } } } ] } [送信] を選択します。 完了すると、レポートは指定した Amazon S3 バケットに保存されます。 [アカウントステータスレポートを表示] ページで、 [レポート] ドロップダウンから複数のレポートを選択して、さまざまな属性の現在のステータスを確認できます。 詳細な準備状況レポートを提供する CSV ファイルを保存するために指定した Amazon S3 バケットを確認します。さまざまなリージョンにわたる組織単位全体の現在の状態を確認します。 アカウントのステータスを評価した後、ポリシーの作成を続行します。 [EC2 の宣言型ポリシー] ページで、 [ポリシーを作成] を選択します。 次のページで、 [ポリシー名] を入力し、オプションで [ポリシーの説明] を入力します。 このデモでは、 ビジュアルエディタ を使用して、サービス属性を追加する方法を示します。これらの属性には、[シリアルコンソールアクセス]、[インスタンスメタデータのデフォルト]、[イメージブロックパブリックアクセス]、[スナップショットブロックパブリックアクセス]、[VPC ブロックパブリックアクセス]、および [許可されたイメージ設定] が含まれます。 JSON エディタ を使用して手動で追加することも、 ビジュアルエディタ を使用して追加したポリシーを確認することもできます。まず、 [VPC ブロックパブリックアクセス] を選択して、インターネットゲートウェイから VPC 内のリソースについてのインターネットアクセスを制御します。 [インターネットゲートウェイの状態] で [受信をブロック] を選択します。有効にすると、リソースを変更せずにパブリックアクセスが即座に防止され、ロールバックできます。 2 つ目の属性として、AMI の許可されたイメージの基準を制御するために、 [許可されたイメージ設定] を選択します。これは、すべてのインスタンスの起動で、組織内のアカウントまたはアカウントセットによって生成されたゴールデン AMI、または Amazon や Ubuntu などのベンダーによって提供されるゴールデン AMI が使用されるようにできるため便利です。 [許可されたイメージ設定] で [有効] を選択します。 [プロバイダー] で [amazon] を選択します。宣言型ポリシーは、カスタマイズ可能なエラーメッセージで透明性を提供し、エンドユーザーのフラストレーションを軽減するのに役立ちます。オプションで、制限されたアクションを組織のメンバーが実行できない場合に表示される [カスタムエラーメッセージ] を追加できます。ポリシー生成プロセスを完了するために、 [ポリシーを作成] を選択します。 次に、ポリシーを組織または特定の OU にアタッチする必要があります。 [アクション] で [ポリシーをアタッチ] を選択します。 組織または特定の OU を選択し、 [ポリシーをアタッチ] を選択します。 アカウントが組織または OU に参加すると、アタッチされた宣言型ポリシーがすぐに有効になり、その後のすべての非準拠アクションは失敗します (パブリックアクセスをすぐに制限する VPC ブロックパブリックアクセスを除く)。アカウント内の既存のリソースは削除されません。 今すぐご利用いただけます 宣言型ポリシーは、ポリシーのメンテナンスのオーバーヘッドを削減し、複数のアカウントで一貫した強制適用を提供して、管理者とエンドユーザーに透明性を提供することで、AWS のお客様のためにガバナンスを合理化します。 宣言型ポリシーは、AWS 商用リージョン、中国リージョン、AWS GovCloud (米国) リージョンでご利用いただけるようになりました。 宣言型ポリシーの詳細を確認し、組織で強制適用を開始するには、 宣言型ポリシー のドキュメントにアクセスしてください。 – Esra 原文は こちら です。

AWS Verified Access は、仮想プライベートネットワーク (VPN) なしで、企業のアプリケーションとリソースへの安全なアクセスを提供します。 当社は 2 年前の re:Invent で、企業アプリケーションへの VPN なしの安全なアクセスを提供するための手段として、プレビュー版の Verified Access をリリースしました 。これを利用することで、組織は IP アドレスではなく ID とデバイスのセキュリティに基づいてネットワークアクセスを管理できるため、アプリケーションアクセスのコントロールとセキュリティが強化されます。 12 月 1 日、 Verified Access は、非 HTTP(S) アプリケーションおよびリソースへの VPN なしの安全なアクセス機能のプレビューをリリースしました。これを利用することで、Secure Shell (SSH) や Remote Desktop Protocol (RDP) などのプロトコルを介して企業リソースへの ゼロトラスト アクセスを実現できます。 組織では、データベース、リモートデスクトップ、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの内部リソースに対する安全なリモートアクセスがますます求められています。従来の VPN ソリューションは、ネットワークアクセスでは効果的ですが、多くの場合、広範な特権を付与するものであり、きめ細かいアクセスコントロールをサポートしていないため、機密データを含むインフラストラクチャが公開される可能性があります。一部の組織はアクセスを仲介するために踏み台ホストを使用していますが、このアプローチでは、HTTP(S) アプリケーションと非 HTTP(S) アプリケーション間で複雑さとポリシーの不一致が生じる可能性があります。ゼロトラストアーキテクチャの台頭により、これらのギャップは、すべてのアプリケーションとリソースにわたって一貫したアクセスポリシーを拡張する安全なアクセスソリューションの必要性を浮き彫りにしています。 Verified Access は、企業のアプリケーションとリソース向けにゼロトラストのアクセスコントロールを提供することで、これらのニーズに対応します。SSH、RDP、Java Database Connectivity (JDBC)、Open Database Connectivity (ODBC) などのプロトコルをサポートすることで、 Verified Access はセキュリティオペレーションを簡素化します。今後は、企業のアプリケーションとリソース全体で、統一されたコンテキスト対応のアクセスポリシーを確立できるようになりました。 Verified Access は、各アクセスリクエストをリアルタイムで評価し、特定の ID およびデバイスセキュリティ要件を満たすユーザーにのみアクセスが付与されるようにします。さらに、個別の VPN や踏み台ホストが不要になるため、運用が効率化され、過剰な特権が付与された状態でのアクセスのリスクが軽減されます。 私のお気に入りの機能の 1 つは、一度に 1 つのリソースをオンボーディングするのではなく、IP Classless Inter-Domain Routing (CIDR) とポートを指定することによってリソースのグループをオンボーディングする機能です。 Verified Access は、指定された CIDR 範囲内のアクティブなリソースごとに DNS レコードを自動的に作成します。これにより、手動での DNS 設定が不要になり、ユーザーは新しいリソースに即座に接続できます。 非 HTTPS アクセスのための Verified Access の使用 非 HTTPS アクセスのために Verified Access を設定することは、現在のものとそれほど変わりません。開始方法については、 2 年前にプレビューをリリースしたときに書いたブログ記事 または「 Verified Access の使用を開始する 」チュートリアルをお読みください。 Verified Access は、1 つの単一リソースのターゲットと複数のリソースのターゲットという 2 つの新しいタイプのエンドポイントターゲットを提案します。 ネットワークインターフェイス、ロードバランサー、または RDS エンドポイントターゲット を使用すると、 Amazon Relational Database Service (Amazon RDS) インスタンスや、 Network Load Balancer または Elastic Network Interface の背後にある任意の TCP アプリケーションなどの個別のリソースへのアクセスを提供できます。このタイプのターゲットエンドポイントは、ターゲットタイプ (ロードバランサーやネットワークインターフェイスなど) と、TCP ポートの範囲の組み合わせによって定義されます。 Verified Access は、エンドポイントの作成時に各エンドポイントの DNS 名を提供します。各ターゲットには、 Verified Access DNS 名が割り当てられます。これは、エンドユーザーがリソースに安全にアクセスするために使用する名前です。 ネットワーク CIDR エンドポイントターゲット では、リソースは IP CIDR とポート範囲を使用して定義されます。このタイプのエンドポイントターゲットを使用すると、SSH や RDP などのプロトコルを介して、EC2 インスタンスなどのエフェメラルリソースへの安全なアクセスを簡単にプロビジョニングできます。これは、リソースが追加または削除されるたびにエンドポイントターゲットを作成または削除するなどのアクションを実行することなく行われます。定義された CIDR から IP アドレスがこれらのリソースに割り当てられている限り、 Verified Access は、定義された CIDR で検出されたアクティブな IP ごとに一意のパブリック DNS レコードを提供します。 このデモの設定の図を以下に示します。 パート 1: Verified Access 管理者として Verified Access 管理者として、Verified Access インスタンス 、 信頼プロバイダー 、 アクセスグループ 、 エンドポイント 、および アクセスポリシー を作成し、エンドユーザーが SSH サーバーにアクセスできるようにします。 このデモでは、 Verified Access ネットワーク CIDR エンドポイントターゲットを設定します。 [プロトコル] として [TCP] を選択し、 [エンドポイントタイプ] として [ネットワーク CIDR] を選択します。 [CIDR] の範囲が、ターゲットリソースが存在している VPC の 1 つに収まっているようにします。VPC 内の TCP [ポート範囲] と [サブネット] を選択します。 これは、足を伸ばしてコーヒーをお代わりするのに最適な瞬間です。エンドポイントの作成には数分かかります。 ステータスが [アクティブ] になったら、プライベート Amazon Virtual Private Cloud (Amazon VPC) で EC2 インスタンスを起動します。SSH を有効にして、VPC からのリクエストにのみアクセスするようにインスタンスのセキュリティグループを設定します。数分後、インスタンス IP が検出され、 Verified Access クライアントアプリケーションから接続するための DNS 名が割り当てられます。 また、設定中に、 secure.mycompany.com などの独自の DNS サブドメインを委任するオプションがあり、 Verified Access はそのサブドメイン内のリソースのために DNS 名を割り当てます。 アクセスポリシーを作成する この段階では、Verified Access エンドポイントでポリシーは定義されていません。デフォルトではあらゆるリクエストが拒否されます。 [Verified Access グループ] ページで、 [ポリシー] タブを選択します。その後、 [Modify Verified Access endpoint policy] (Verified Access エンドポイントポリシーを変更) ボタンを選択してアクセスポリシーを作成します。 認証されており、メールアドレスが @amazon.com で終わるすべてのユーザーを許可するポリシーを入力します。これは、 AWS IAM アイデンティティセンター で定義されたユーザーのために使用したメールアドレスです。 context の後の名前は、 [Verified Access 信頼プロバイダー] を作成した際に [ポリシー参照名] として入力した名前であることに留意してください。 ドキュメントページ には、使用できるポリシー構文、属性、演算子の詳細が記載されています。 permit(principal, action, resource) when { context.awsnewsblog.user.email.address like "*@amazon.com" }; 数分後、Verified Access はポリシーを更新し、再び [アクティブ] になります。 クライアントに設定を配布する Verified Access 管理者としての最後のタスクは、クライアントアプリケーションの JSON 設定ファイルを抽出することです。 クライアントアプリケーション設定ファイルは、 AWS コマンドラインインターフェイス (AWS CLI) を使用して取得します。システム管理者として、この設定を各クライアントマシンに配布します。 aws ec2 export-verified-access-instance-client-configuration \ --verified-access-instance-id "vai-0dbf2c4c011083069" { "Version": "1.0", "VerifiedAccessInstanceId": "vai-0dbf2c4c011083069", "Region": "us-east-1", "DeviceTrustProviders": [], "UserTrustProvider": { "Type": "iam-identity-center", "Scopes": "verified_access_test:application:connect", "Issuer": "https://identitycenter.amazonaws.com/ssoins-xxxx", "PkceEnabled": true }, "OpenVpnConfigurations": [ { "Config": "Y2...bWU=", "Routes": [ { "Cidr": "2600:1f10:4a02:8700::/57" } ] } ] } 接続するリソースと Verified Access インフラストラクチャの準備が整ったので、ネットワークエンドポイントにアクセスするためのエンドユーザーエクスペリエンスを皆様にご紹介します。 パート 2: エンドユーザーとして エンドユーザーとして、 Verified Access Connectivity Client アプリケーションをダウンロードしてインストール するためのリンクを受け取ります。この記事の執筆時点では、Windows および macOS クライアントがサポートされています。 管理者から受け取った設定ファイルをインストールします。ファイル名として ClientConfig1.json を使用し、Windows の場合は C:\ProgramData\AWSPylon 、macOS の場合は /Library/Application Support/com.aws.pylon.client にそのファイルをコピーします。 これはすべてのユーザーについて同じ設定ファイルであり、システム管理者はエンドポイント管理ツールを使用してすべてのクライアントマシンにそのファイルをプッシュする場合があります。 Connectivity Client アプリケーションを起動します。認証シーケンスを開始するには、 [サインイン] を選択します。 認証により、ウェブブラウザが開き、ID プロバイダーの認証ページが表示されます。実際の画面とログインシーケンスはプロバイダーによって異なります。認証されると、Connectivity Client は、リソース (このデモでは EC2 インスタンス) にアクセスするための安全なトンネルを作成します。 ステータスが [接続済み] になると、 Verified Access によって提供される DNS 名を使用して、リソースに安全に接続できます。ターミナルアプリケーションで、 ssh コマンドを入力して接続を開始します。 このデモでは、Verified Access のために委任された DNS ドメイン secure.mycompany.com を設定しました。EC2 インスタンス用に受け取った DNS アドレスは 10-0-1-199.awsnews.secure.mycompany.com です。 $ ssh -i mykey.pem ec2-user@10-0-1-199.awsnews.secure.mycompany.com , #_ ~\_ ####_ Amazon Linux 2023 ~~ \_#####\ ~~ \###| ~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023 ~~ V~' '-> ~~~ / ~~._. _/ _/ _/ _/m/' Last login: Sat Nov 17 20:17:46 2024 from 1.2.3.4 $ 利用可能なリージョンと料金 Verified Access は、次の 19 の AWS リージョン でパブリックプレビューとしてご利用いただけます: 米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (ジャカルタ、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、イスラエル (テルアビブ)、南米 (サンパウロ)。 非 HTTP(S) Verified Access エンドポイントがアクティブな間、各接続について 1 時間ごとに課金されます 。各 Verified Access エンドポイントにおいて、1 か月あたり最初の 100 件の接続は無料です。詳細については、「 AWS Verified Access の料金 」をご覧ください。 HTTP(S) および非 HTTP(S) アプリケーションのために Verified Access を使用すると、プライベートアプリケーションとシステムに対するアクセスコントロールを統合し、すべてのアプリケーション、SSH、RDP、HTTP(S) リソースに対してゼロトラストポリシーを一様に適用できます。これは、ネットワークインフラストラクチャの複雑さを軽減するとともに、アプリケーションとリソースに対するゼロトラストアクセスを実装するのに役立ちます。最後に、成長し続けるインフラストラクチャに適応して、DNS 設定を自動化するとともに、リソース固有の登録なしで大規模なデプロイをサポートします。 今すぐ Verified Access をお試しいただき、チームとフィードバックをご共有ください。 — seb 原文は こちら です。

12 月 1 日は、最新の AWS Transfer Family リソースである AWS Transfer Family ウェブアプリケーション をご紹介します。認証されたユーザーが特定の Amazon Simple Storage Service (Amazon S3) バケット内のファイルを一覧表示、アップロード、ダウンロード、コピー、削除できるようにする、フルマネージドノーコードウェブアプリケーションを作成できます。組織内外の非デベロッパーの Line Of Business ユーザーは、デスクトップクライアント、スクリプト、付箋に書かれた消えかかっている指示、またはローカル IT のヘルプを必要とせずに、ファイルデータを簡単に交換できます。 ウェブアプリケーション管理者は、認証、アクセス、および許可を完全に制御でき、ページタイトルと ファビコン を使用してウェブアプリケーションをカスタマイズできます。このブログ記事を書いている間に作成したウェブアプリケーションを次に示します: ファイルをクリックしてダウンロードしたり、フォルダをクリックして開いたり、列をクリックして並べ替えたりできます。縦の三点リーダーのメニューには、追加のオプションがあります: 各ウェブアプリケーションは、最大 160 GiB のファイルのアップロードとダウンロードをサポートし、大きなファイルには マルチパートアップロード を使用します。ファイルは、TLS によって保護された HTTPS 接続を介して転送され、自動再試行と CRC32 エンドツーエンド完全性チェックが行われます。 Transfer Family ウェブアプリケーションのすべて 独自のウェブアプリケーションを作成する方法をわずか 1 分ほどでご説明します。しかし、まずは重要な機能と利点をいくつか見てみましょう… セキュリティ – Transfer Family ウェブアプリケーションは AWS IAM アイデンティティセンター を使用するため、既存の SAML または OIDC ID プロバイダー、または組み込みの Identity Store を使用できます。いずれの場合でも、 S3 Access Grants を使用すると、ファイルの表示、ダウンロード、削除、アップロード、およびディレクトリの作成が許可されているユーザーとグループを完全にきめ細かく制御できます。また、組織は、AWS Transfer Family の SOC、PCI DSS、FedRAMP、HIPAA などのプログラムへの コンプライアンス の恩恵も享受できます。 カスタマイズ – 各 Transfer Family ウェブアプリケーションをページタイトルと ファビコン でカスタマイズできます。また、ウェブアプリケーションの前に Amazon CloudFront ディストリビューションを配置し、HTTPS アクセスと パブリック証明書 を使用してカスタムドメイン名でホストすることもできます。 AWS エコシステム – Transfer Family ウェブアプリケーションは AWS でホストされるため、スケーラブルで可用性に優れています。すべてのファイルは指定された S3 バケットに保存され、耐久性はイレブンナイン (99.999999999%) です。 S3 バージョニング 、 S3 サーバーアクセスログ記録 、 S3 イベント通知 などの S3 の機能 を活用できます。また、 Amazon EventBridge を使用して、アップロード後の複雑なワークフローをオーケストレートすることもできます。 Transfer Family ウェブアプリケーションの作成 Transfer Family ウェブアプリケーションを作成するステップを見ていきましょう。各ウェブアプリケーションは特定の AWS リージョン に存在するため、 AWS Transfer Family コンソール を開き、目的のリージョン (この記事では us-east-2 ) を選択し、左側で [ウェブアプリケーション] を選択します: その後、 [ウェブアプリケーションを作成] をクリックして続行します: 必要に応じて IAM アイデンティティセンター に接続し、Transfer Family ウェブアプリケーションが S3 および S3 Access Grants にアクセスすることを許可する IAM サービスロール ( 詳細 ) を作成または選択します: [名前] タグを追加し、同時ウェブアプリケーションユーザーの最大数を設定して、 [次へ] をクリックします。 次に、ウェブアプリケーションを設計し、ページタイトルとロゴ (両方ともオプション) を設定してから、 [次へ] をクリックします: 次のページで設定を確認し、 [作成] をクリックして先に進みます: これでウェブアプリケーションが作成され、使用する準備はほとんど整いました (まだ許可とユーザーを設定する必要があります): ウェブアプリケーションに関連付けられたバケットのために間もなく作成する CORS ポリシーで [アクセスエンドポイント] を使用するので、コピーして保存します。 許可とユーザーの設定 ウェブアプリケーションを通じてアクセスできる S3 バケットに必要な読み取りおよび書き込み許可を提供する IAM カスタム信頼ポリシーを作成します ( 詳細 )。このポリシーは、この後すぐに作成する S3 Access Grant で参照されます: それから、IAM アイデンティティセンターでユーザーとグループの初期セットを作成します (後で追加できます): 次に、ウェブアプリケーションと同じリージョンに S3 バケットを作成し、S3 Access Grant を作成します。各 S3 Access Grant は、特定の IAM アイデンティティセンター ID (ユーザーまたはグループ) が、読み取りおよび/または書き込みのために特定のスコープ (バケットまたはバケットのプレフィックス付き部分) にアクセスすることを許可します: また、ウェブアプリケーションがブラウザからバケットにアクセスできるように、CORS ポリシー ( 詳細 ) をバケットにアタッチする必要があります: 最後のステップは、新しいウェブアプリケーションにユーザーを関連付けることです。AWS Transfer Family の [ウェブアプリケーション] ページに戻り、自分のアプリケーションを見つけて、 [ユーザーとグループを割り当てる] をクリックします: 自分のディレクトリに新しいユーザーを追加するか、または既存のユーザーを選択できます: まずは自分自身を追加します: 割り当てが完了すると、 [アクセスエンドポイント] (上記参照) をユーザーと共有でき、ユーザー (ここでは自分) はウェブアプリケーションにログインできます: [ウェブアプリケーションエンドポイント] と [アクセスエンドポイント] は、デフォルトでは同じです。ウェブアプリケーションのために CloudFront ディストリビューションを設定 すると、 [アクセスエンドポイント] にエンドポイントの URL が反映されます。 設定プロセスを通じた高速パスをご紹介しました。お気づきかもしれませんが、個人レベルおよびグループレベルで読み取りおよび書き込みアクセスを制御するオプションが多数あります。本番ウェブアプリケーションを設定する前に、これらのオプションをすべて調べて完全に理解してください。 知っておくべきこと S3 Transfer Family ウェブアプリケーションについて知っておくべきことがいくつかあります: リージョン – ウェブアプリケーションは 9 つの AWS リージョンで作成できます。最新のリストについては、 ウェブアプリケーションのドキュメント をご覧ください。 料金 – 料金はウェブアプリケーション/時間単位です。 API と CLI – create-web-app 、 describe-web-app 、他の AWS Transfer Family アクションを使用することで、プログラムでウェブアプリケーションを作成および管理できます。 Storage Browser for S3 – Transfer Family ウェブアプリケーションは、 Storage Browser for Amazon S3 を使用して構築され、フルマネージドオファリングで同じエンドユーザー機能を提供します。 開始方法 – Transfer Family ウェブアプリケーションは、 Transfer Family コンソール で使用を開始できます。 – Jeff ; 原文は こちら です。

12 月 1 日、 Amazon OpenSearch Service と Amazon Security Lake のゼロ ETL 統合の一般提供の開始を発表しました。この統合により、組織はセキュリティデータを効率的に検索および分析し、実用的なインサイトを得ることができるため、複雑なデータエンジニアリング要件が合理化され、セキュリティデータの潜在能力が最大限に引き出されます。これは、Security Lake でログをインプレースでクエリおよび分析する新しい方法であり、データの重複を最小限に抑え、カスタムデータパイプラインの管理にかかる運用オーバーヘッドを削減します。Security Lake データを直接クエリできるため、データの移動コストを節約できます。 OpenSearch Service と Security Lake のゼロ ETL 統合により、OpenSearch Dashboards の豊富な分析機能を使用して、Security Lake のデータをクエリおよび視覚化できます。また、単一のツールと単一のスキーマ ( Open Cybersecurity Schema Framework (OCSF) スキーマ) 内で複数のデータソースを分析して、脅威ハンティングと調査のシナリオに役立てることもできます。 時間が重要な要素となる調査とモニタリングでは、データのサブセットに迅速かつ頻繁にアクセスする必要がある場合に、Amazon OpenSearch Service でインデックス付きビューやダッシュボードなどの追加のアクセラレーションを有効にすることで、オプションでクエリパフォーマンスを改善できます。これらの機能により、ログの量にかかわらず、Security Lake に保存されているすべてのデータを完全に可視化できるため、セキュリティ調査をサポートし、セキュリティ体制をより良く理解するとともに、セキュリティ関連のインサイトを得ることができます。 Amazon Security Lake でのダイレクトクエリの開始方法 数ステップで使用を開始できます。まず、Security Lake サブスクライバーを作成して Security Lake を有効にする必要があります。その後、Amazon OpenSearch Service でデータ接続を有効にします。これにより、ダイレクトクエリの結果とインデックスを保存するための OpenSearch Serverless コレクションが自動的に作成されます。 1.Security Lake を有効にし、データレイクの許可を設定する AWS マネジメントコンソール で Security Lake を有効にするには、収集するデータソース ( Amazon Route 53 DNS クエリ、 AWS CloudTrail ログ、 Amazon VPC フローログ、 AWS Security Hub の検出結果など) と AWS リージョンを指定します。私は複数のリージョンを選択し、 Amazon Simple Storage Service (Amazon S3) ストレージクラスとロールアップリージョンを設定してデータを統合しました。 必要なデータソースを使用して組織全体にデプロイし、組織に固有のコストを見積もることができるよう、Security Lake は 15 日間の無料トライアルを提供しています。 有効化が完了すると、収集されたすべてのデータがアカウントの Amazon Simple Storage Service (Amazon S3) バケットに取り込まれます。 Security Lake の委任された管理者アカウント以外のアカウントから Security Lake データにアクセスするには、Security Lake に関連付けられた AWS Glue テーブルのデータにアクセスしてクエリするために AWS Lake Formation サブスクライバーを作成する必要があります。Security Lake へのアクセスが認可されている AWS アカウントと外部 ID を入力し、アクセスするデータソースを選択します。Lake Formation は、セキュリティアナリストがレイク内のデータにアクセスするためのクロスアカウント許可を提供します。 クエリサブスクライバーを作成したら、OpenSearch リソースをデプロイする予定のアカウントに移動し、Security Lake の委任された管理者アカウントによって共有されている AWS Resource Access Manager (AWS RAM) 共有を受け入れることができます。サブスクライバーアカウントは、手動で受け入れられるまで、共有ステータスを保留中として表示します。 詳細については、「Amazon Security Lake ユーザーガイド」の「 Enabling Security Lake using the console 」および「 Create query subscriber procedures 」にアクセスしてください。 2.OpenSearch Service とのデータ接続を作成する ゼロ ETL 統合は、数ステップで作成できます。サブスクライバーのアカウントの OpenSearch Service コンソール で、左側のナビゲーションペインの [データ接続] セクションで [接続されたデータソース] を選択します。その後、データソースのタイプとして [Security Lake] を選択できます。 次のステップでは、ゼロ ETL 統合を使用して Security Lake データソースにアクセスするための IAM 許可を設定できます。また、OpenSearch Serverless コレクションと OpenSearch アプリケーションが自動的に作成されます。 接続が作成されたら、Security Lake のデータを定期的にクエリしてビジュアライゼーションを作成する、事前構築済みの OpenSearch ダッシュボードのいずれかを選択できます。Security Lake で VPC フローログ、WAF ログ、CloudTrail データソース用のテンプレートを使用してダッシュボードを作成できます。 VPC フローログ用の事前構築済みのダッシュボードの例を次に示します。 データ接続の詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「 Data connections and permissions 」にアクセスしてください。 3.OpenSearch ダッシュボードで Security Lake データをクエリする OpenSearch ダッシュボードで Security Lake データを直接クエリするには、 [検出] ページに移動します。 [検出] ページで、データピッカーワークフローを使用して、クエリする特定の Security Lake テーブルを見つけることができます。Security Lake ログソースごとに 1 つのテーブルがあります。 選択後、使用するクエリ言語 (PPL (Piped Processing Language) または SQL (Structured Query Language) のいずれか) を選択し、クエリを記述して実行できます。PPL のサンプル結果を次に示します: クエリを開始するために、事前構築済みのクエリテンプレートを検索して実行することを選択することもできます。Security Lake で使用可能なすべての AWS ログソースをカバーする 200 を超える SQL および PPL クエリがあります。検索ボックスを使用して、興味のあるクエリを見つけることができます。例えば、「VPC Flow」と検索すると、VPC フローログに関連するすべてのクエリが表示されます。各クエリと、その使用が推奨される場合についての説明があります。 セキュリティ調査をサポートするためなど、同じデータセットに対して複数のクエリを実行する場合は、ダイレクトクエリの結果についてオンデマンドのインデックス付きビューを作成できます。結果が OpenSearch インデックスに取り込まれた後、OpenSearch の分析機能を使用して、低レイテンシーの後続のクエリと分析を実行できます。 インデックス付きビューを作成するには、 [インデックス付きビューを作成] を選択し、指定したクエリ、インデックス名、および時間範囲を選択します。ビューが作成されると、クエリ結果が取り込まれ、使用可能なインデックス付きビューの下に新しく作成されたインデックスの一部としてクエリできるようになります。 詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「 Searching data 」にアクセスしてください。 今すぐご利用いただけます Amazon OpenSearch Service と Amazon Security Lake のゼロ ETL 統合は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパウロ)、およびカナダ (中部) の AWS リージョンでご利用いただけるようになりました。 OpenSearch Service では、OpenSearch Service でのインデックスの維持に加えて、外部データのクエリに必要なコンピューティング (OpenSearch Compute Units として) についてのみ別途料金が発生します。詳細については、「 Amazon OpenSearch Service の料金 」をご覧ください。 お試しいただき、 AWS re:Post for Amazon OpenSearch Service 、または通常の AWS サポート窓口までフィードバックをお送りください。 – Channy 原文は こちら です。

12 月 1 日、オンプレミスおよびエッジインフラストラクチャをクラウド内の EKS クラスターに対するノードとしてアタッチするために使用できる新機能である Amazon Elastic Kubernetes Service (Amazon EKS) ハイブリッドノード の一般提供の開始を発表しました。 Amazon EKS ハイブリッドノードを使用すると、クラウド環境とオンプレミス環境全体で Kubernetes 管理を統合し、アプリケーションを実行する必要があるすべての場所で Amazon EKS のスケールと可用性を活用できます。既存のオンプレミスハードウェアを使用しながら、Kubernetes コントロールプレーンの管理責任を EKS にオフロードし、ワークロードのためのオンプレミスキャパシティを節約できます。Amazon EKS ハイブリッドノードを使用すると、クラウド環境とオンプレミス環境全体で一貫した運用慣行とツールを採用できます。 以前に導入した Amazon EKS on AWS Outposts と Amazon EKS Anywhere に加えて、Amazon EKS ハイブリッドノードは、ハイブリッド Kubernetes デプロイのサポートを拡張します。各 EKS ハイブリッドデプロイオプションで Kubernetes とハードウェアコンポーネントがどのように管理されるかを比較できます。 コンポーネント EKS on Outposts EKS ハイブリッドノード EKS Anywhere ハードウェア AWS によって管理 お客様によって管理 Kubernetes コントロールプレーン AWS によってホストおよび管理 お客様によってホストおよび管理 Kubernetes ノード Amazon EC2 カスタマーマネージド型の物理マシンまたは仮想マシン Amazon EKS ハイブリッドノードを使用してオンプレミスおよびエッジインフラストラクチャを EKS クラスターにアタッチすると、 Amazon EKS アドオン 、 ポッド ID 、 クラスターアクセスエントリ 、 クラスターインサイト 、Kubernetes バージョンの拡張サポートなど、Amazon EKS の他の機能と統合を使用できます。Amazon EKS ハイブリッドノードは、一元的なモニタリング、ログ記録、および ID 管理のために、 AWS Systems Manager 、 AWS IAM Roles Anywhere 、 Amazon Managed Service for Prometheus 、 Amazon CloudWatch 、 Amazon GuardDuty などの AWS サービスと本質的に統合します。 Amazon EKS ハイブリッドノードの使用を開始する Amazon EKS ハイブリッドノードを使用するステップは次のとおりです。まず、EKS クラスターを作成し、オンプレミスのノードとポッドのサブネットを指定します。オンプレミス環境のネットワーク接続と AWS Identity and Access Management (AWS IAM) 許可を設定したら、クラスターに参加する各ホストで Amazon EKS ハイブリッドノード CLI ( nodeadm ) を実行します。ハイブリッドノードがクラスターに参加すると、kube-proxy や CoreDNS などの必要なネットワーキングコンポーネントが自動的にインストールされます。ハイブリッドノードがアプリケーションを提供する準備が整う前に、互換性のある Container Network Interface (CNI) ドライバーをインストールする必要があります。Cilium および Calico CNI ドライバーは、Amazon EKS ハイブリッドノードでの使用がサポートされています。 1.前提条件 オンプレミスインフラストラクチャをハイブリッドノードとして EKS クラスターに参加させるには、次を含む特定の前提条件を満たす必要があります: オンプレミス環境と AWS 間のハイブリッドネットワーク接続 ( AWS Site-to-Site VPN 、 AWS Direct Connect 、または別の仮想プライベートネットワーク (VPN) ソリューションを使用) オンプレミスノードのルーティングテーブルにルートがあり、オプションでポッドネットワークがあり、ターゲットとして仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイ (TGW) が設定されている仮想プライベートクラウド (VPC) 物理マシンまたは仮想マシンの形式のインフラストラクチャ ハイブリッドノードと互換性のあるオペレーティングシステム コントロールプレーンでハイブリッドノードを認証するように設定された AWS IAM Roles Anywhere または AWS Systems Manager のいずれか EKS クラスター IAM ロール と EKS ハイブリッドノード IAM ロール ハイブリッドノードのノードオペレーティングシステムとして、Amazon Linux 2023、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04、または Red Hat Enterprise Linux (RHEL) 8 および 9 を使用できます。AWS は、これらのオペレーティングシステムとのハイブリッドノード統合をサポートしていますが、オペレーティングシステム自体のサポートは提供していません。オペレーティングシステムのプロビジョニングと管理はお客様の責任です。 詳細については、「Amazon EKS ユーザーガイド」の「 Prerequisites for EKS Hybrid Nodes 」にアクセスしてください。 2.EKS クラスターを作成し、ハイブリッドノードを有効にする Amazon EKS コンソール に移動し、EKS クラスターの作成を開始します。 [ステップ 2 ネットワーキングを指定] 画面で、 [ハイブリッドノードを有効にするようにリモートネットワークを設定] オプションの [ハイブリッドノードに使用するオンプレミス環境のために CIDR ブロックを指定] をオンにします。 リモートノードとポッドの Classless Inter-Domain Routing (CIDR) は、RFC-1918 IPv4 IPv4 アドレスである必要があり、VPC CIDR または EKS クラスター Kubernetes サービス CIDR と重複することはできません。さらに、リモートノード CIDR とリモートポッド CIDR は重複できません。ノードでウェブフックを実行する場合、またはポッドトラフィックがノードを離れるときに CNI がポッドアドレスのために NAT を使用しない場合は、ポッド CIDR ブロックを指定する必要があります。 また、 AWS コマンドラインインターフェイス (AWS CLI) 、 eksctl 、および AWS CloudFormation を使用して EKS クラスターを作成することもできます。Amazon EKS ハイブリッドノードのためにクラスターを有効にするには、 remote-network-config フラグを使用してリモートノードを指定し、オプションでリモートポッド CIDR ブロックを指定します。 $ aws eks create-cluster --name channy-hybrid-cluster --region=us-east-1 \ --role-arn arn:aws:iam::012345678910:role/eks-cluster-role \ --resources-vpc-config subnetIds=subnet-1234a11a,subnet-5678b11b \ --remote-network-config \ {"remoteNodeNetworks":[{"cidrs":["10.80.0.0/16"]}],"remotePodNetworks":[{"cidrs":["10.85.0.0/16"]}]}} クラスターは、 API または API_AND_CONFIG_MAP クラスターアクセス認証モードで設定されている必要があります。EKS ハイブリッドノード IAM ロールのために Amazon EKS アクセスエントリを作成して、ノードがクラスターに参加できるようにします。 $ aws eks create-access-entry \ --cluster-name my-hybrid-cluster \ --principal-arn arn:aws:iam::012345678910:role/eksHybridNodesRole \ --type HYBRID_LINUX Amazon EKS ハイブリッドノードは、AWS Systems Manager ハイブリッドアクティベーションまたは AWS IAM Roles Anywhere によってプロビジョニングされた一時的な IAM 認証情報を使用して、EKS クラスターで認証します。オンプレミスノードを接続する前に、AWS Systems Manager ハイブリッドアクティベーションを作成するか、または AWS IAM Roles Anywhere で使用するためにノードに証明書とキーを追加する必要があります。詳細については、「Amazon EKS ユーザーガイド」の「 Prepare credentials for EKS Hybrid Nodes 」にアクセスしてください。 3.ハイブリッドノードを EKS クラスターに接続する これで、Amazon EKS ハイブリッドノードを EKS クラスターに接続する準備が整いました。Amazon EKS ハイブリッドノード CLI ( nodeadm ) を使用すると、ハイブリッドノードとしてのホストのインストール、設定、登録を簡素化できます。 nodeadm は、 nodeadm install コマンドを実行すると、必要な AWS Systems Manager または IAM Roles Anywhere コンポーネントを自動的にインストールします。 実行中の各ホストで nodeadm install プロセスを実行するか、またはオペレーティングシステムのビルドパイプラインの一部として nodeadm install を実行して、ホストを EKS クラスターに参加させるために必要なコンポーネントを含むイメージを生成できます。 $ nodeadm install 1.31 --credential-provider <ssm, iam-ra> {"level":"info","ts":...,"caller":"...","msg":"Loading configuration","configSource":"file://nodeConfig.yaml"} {"level":"info","ts":...,"caller":"...","msg":"Validating configuration"} {"level":"info","ts":...,"caller":"...","msg":"Validating Kubernetes version","kubernetes version":"1.30"} {"level":"info","ts":...,"caller":"...","msg":"Using Kubernetes version","kubernetes version":"1.30.0"} {"level":"info","ts":...,"caller":"...","msg":"Installing SSM agent installer..."} {"level":"info","ts":...,"caller":"...","msg":"Installing kubelet..."} {"level":"info","ts":...,"caller":"...","msg":"Installing kubectl..."} {"level":"info","ts":...,"caller":"...","msg":"Installing cni-plugins..."} {"level":"info","ts":...,"caller":"...","msg":"Installing image credential provider..."} {"level":"info","ts":...,"caller":"...","msg":"Installing IAM authenticator..."} {"level":"info","ts":...,"caller":"...","msg":"Finishing up install..."} EKS クラスターに接続するために必要な情報を含む nodeConfig.yaml ファイルを各ホストで作成します。AWS Systems Manager ハイブリッドアクティベーションを使用する nodeConfig.yaml の例を次に示します。 apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig metadata: name: hybrid-node spec: cluster: name: my-cluster region: us-east-1 hybrid: roleArn: arn:aws:iam:012345678910:role/eksHybridNodesRole ssm: activationCode: <activation-code> activationId: <activation-id> 次に、各ホストで nodeadm を実行します。 $ nodeadm init -c file:/// nodeConfig.yaml 前述のコマンドが正常に完了した場合、ハイブリッドノードは EKS クラスターに参加しています。これは、Amazon EKS コンソールまたは kubectl get nodes コマンドで確認できます。ハイブリッドノードのステータスが [準備完了] になる前に、互換性のある CNI をインストールする必要があります。詳細については、「Amazon EKS ユーザーガイド」の「 Install CNI for EKS Hybrid Nodes 」にアクセスしてください。 4.EKS コンソールで接続されたハイブリッドノードを表示および管理する ノードの準備が整ったので、EKS コンソールでハイブリッドノードとそこで実行されているリソースを表示できます。 ハイブリッドノードの管理と、それらが実行するソフトウェアの更新は、お客様の責任です。Amazon EKS ハイブリッドノード CLI の最新バージョンに更新して、最新の修正プログラムと更新を取得し、Kubernetes バージョンをアップグレードできます。詳細については、「Amazon EKS ユーザーガイド」の「 Upgrade EKS Hybrid Nodes 」にアクセスしてください。 今すぐご利用いただけます Amazon EKS ハイブリッドノード は、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS リージョンでご利用いただけるようになりました。 前払いの義務や最低料金はなく、EKS クラスターと EKS ハイブリッドノードは使用した時間に応じて時間単位でお支払いいただきます。ハイブリッドノードを含む EKS クラスターのクラスターあたりの時間単位のコストは、標準サポートと拡張サポートの両方において AWS クラウドで実行されているノードを含む EKS クラスターと同じです。さらに、ハイブリッドノードを含む EKS クラスターでは、ハイブリッドノード vCPU ごとに時間単位の料金が発生します。詳細については、「 Amazon EKS の料金」ページ にアクセスしてください。 Amazon EKS コンソール で EKS ハイブリッドノードをぜひお試しください。詳細については、 EKS ハイブリッドノードのドキュメント にアクセスしてください。また、 AWS re:Post for EKS に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

12 月 1 日、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の一般提供の開始を発表しました。これは、プロビジョニングから継続的なメンテナンスまで、コンピューティング、ストレージ、ネットワークについての Kubernetes クラスター管理を 1 回のクリックで効率化する新しい機能です。 Amazon Web Services (AWS) で本番グレードの Kubernetes アプリケーションを大規模に実行するために必要なクラスターインフラストラクチャの管理の運用オーバーヘッドを排除することで、俊敏性とコスト効率を高め、パフォーマンスを改善できます。 お客様が Amazon EKS を選択するのは、Kubernetes の標準および移植性を、AWS クラウドのセキュリティ、スケーラビリティ、可用性と合わせて活用できるためです。Kubernetes は高度な知識を備えたお客様にアプリケーションオペレーションに対する詳細なコントロールを提供しますが、他のお客様は、本番グレードの Kubernetes アプリケーションに必要なコンポーネントの管理が複雑で手間がかかると感じています。 EKS Auto Mode を使用すると、最適なコンピューティングインスタンスの選択、リソースの動的なスケール、コストの継続的な最適化、コアアドオンの管理、オペレーティングシステムへのパッチ適用、AWS セキュリティサービスとの統合が行われるため、Kubernetes の深い専門知識がなくてもクラスター管理を自動化できます。AWS は、EKS クラスター内のカスタマーマネージドインフラストラクチャと比較して、EKS Auto Mode でより大きな運用上の責任を負います。EKS コントロールプレーンに加えて、AWS は、アプリケーションの実行に必要な EKS クラスター内の AWS インフラストラクチャを設定、管理、保護します。 すぐに使用を開始して、パフォーマンスを改善し、オーバーヘッドを削減できるため、クラスター管理タスクではなく、イノベーションを推進するアプリケーションの構築に注力できます。また、EKS Auto Mode は、コスト効率の高い GPU アクセラレーテッドインスタンスを取得して実行するために必要な作業を削減するため、必要なときに必要なキャパシティを 生成 AI ワークロードのために確保できます。 Amazon EKS Auto Mode の使用を開始する 使用を開始するには、 Amazon EKS コンソール に移動して、EKS クラスターの作成を開始します。 [クイック設定 (EKS Auto Mode を使用)] と [カスタム設定] の 2 つのオプションがあります。 クイック設定を選択したら、クラスター名と Kubernetes バージョン、IAM ロール、VPC サブネットを入力します。クラスターの作成後に編集できるかどうかにかかわらず、EKS Auto Mode で設定のデフォルトの値を表示できます。 EKS Auto Mode では、EKS クラスターで Kubernetes の次の機能が有効になります: コンピューティングの自動スケーリングと管理 アプリケーションの負荷分散管理 ポッドとサービスのネットワーキングとネットワークポリシー クラスター DNS と GPU のサポート ブロックストレージボリュームのサポート [作成] を選択すると、Auto Mode の EKS クラスターが 1 回のクリックで数分でデプロイされます。 カスタム設定オプションを選択した場合は、クラスターの他の側面をカスタマイズできます。このオプションでも EKS Auto Mode を使用できます。 AWS コマンドラインインターフェイス (AWS CLI) 、 eksctl 、および AWS CloudFormation を使用して EKS Auto Mode クラスターを作成することもできます。新しい EKS Auto Mode クラスターを作成するには、次の eksctl コマンドを実行します: $ eksctl create cluster --name=<cluster-name> --enable-auto-mode 詳細については、「Amazon EKS ユーザーガイド」の「 Create cluster with EKS Auto Mode 」にアクセスしてください。 既存の EKS クラスターで EKS Auto Mode を有効にする場合は、EKS クラスターの詳細ページの [概要] タブの [EKS Auto Mode] セクションで [管理] を選択します。 EKS Auto Mode を有効にするには、 [EKS Auto Mode を使用] の横にあるボックスを選択します。クラスターで設定される EKS Auto Mode の選択を解除できます。デフォルトでは、システムとデフォルトのノードプールの両方とノードクラスが作成されます。 また、 Karpenter 、 EKS マネージドノードグループ 、EKS Fargate から、EKS Auto Mode に移行することもできます。詳細については、「Amazon EKS ユーザーガイド」の「 Enable EKS Auto Mode on existing EKS clusters 」にアクセスしてください。 ワークロードの要件を満たすために、EKS Auto Mode クラスターの特定の側面を設定できます。EKS Auto Mode はほとんどのインフラストラクチャコンポーネントを自動的に管理しますが、自動化されたインフラストラクチャ管理の利点を維持しながら、 ノードネットワーキングの設定 、 ノードコンピューティングリソース 、 ストレージクラスの設定 、および アプリケーションの負荷分散動作 をカスタマイズできます。詳細については、「Amazon EKS ユーザーガイド」の「 Change EKS Auto cluster settings 」にアクセスしてください。 これで、EKS Auto Mode で実行されている Amazon EKS クラスターにさまざまな種類のワークロードをデプロイできるようになりました。主要なワークロードパターンとして、 サンプルアプリケーション 、 負荷分散されたウェブアプリケーション 、 永続ストレージを使用したステートフルワークロード 、および 特定のノード配置要件のあるワークロード が用意されています。各例には、完全なマニフェストとステップバイステップのデプロイ手順が含まれており、独自のアプリケーションのテンプレートとして使用できます。詳細については、「Amazon EKS ユーザーガイド」の「 Run workloads in EKS Auto Mode clusters 」にアクセスしてください。 今すぐご利用いただけます Amazon EKS Auto Mode は、Amazon EKS が利用可能なすべての商用 AWS リージョン (中国リージョンを除く) でご利用いただけるようになりました。Kubernetes 1.29 以降を実行している任意の EKS クラスターで、初期費用や確約なしで EKS Auto Mode を有効にできます。通常の EC2 コストに加えて、プロビジョニングされたコンピューティングリソースの管理についての料金をお支払いいただきます。詳細については、「 Amazon EKS の料金ページ 」にアクセスしてください。 2024 年 12 月 12 日のオンラインウェビナー「 Simplifying Kubernetes operations with Amazon EKS Auto Mode 」に登録して、EKS Auto Mode によってワークロードを本番にデプロイする時間を短縮し、Kubernetes の運用上のオーバーヘッドを削減する方法についての詳細をご覧ください。詳細については、「Amazon EKS ユーザーガイド」の「 Automate cluster infrastructure with EKS Auto Mode 」にアクセスしてください。 Amazon EKS コンソール で EKS Auto Mode をお試しいただき、 AWS re:Post for EKS に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

来年の小売業界のトレンドに関して、様々な論客が予測を競い合っています。 去年 は小売業界のトップテクノロジー動向をリストアップしましたが、今年は生成 AI に焦点を当て、注目すべきトレンドを取り上げたいと思います。2023 年が生成 AI が登場した年で、2024 年がその試験運用的な期間だったとすれば、2025 年はこのテクノロジーがさらに成熟する年になるでしょう。Gartner の言う「啓発期」に近づいていますが、まだそこには達していません。 生成 AI の話に飽き飽きしている人もいるでしょう。生成 AI というと、Nirvana というグランジ系ロックバンドを思い出します。それ以前にも多くのグランジ系ロックバンドが登場していましたが、Nirvana はそうした他の素晴らしいバンドを引き離し、圧倒的な注目を集めました。Nirvana がそうであったように生成 AI が世界に大きな影響を与えたことは誰も否定できません。 そこで、2025 年に注目すべき、小売業向けの 3 つのユースケースと 3 つのテクノロジーを紹介します。 バーチャルショッピングアシスタント（ユースケース） ハイパーパーソナライゼーション（ユースケース） バーチャル試着（ユースケース） AI エージェント（テクノロジー） ドメイン固有の基盤モデル（テクノロジー） Computer Use（テクノロジー） バーチャルショッピングアシスタント このソリューション開発のコンセプトはシンプルです。店舗での買い物であれば、何を買ったらよいかわからなければ店員に専門的なアドバイスを求めることができます。では、オンラインショッピングの場合はどうすればよいのでしょうか? そこで登場するのが、スプリンクラーの配管から、デジタルネットワーク、寒い日のファッションコーディネートなどさまざまなトピックに精通した AI を駆使したバーチャルショッピングアシスタントです。地中に埋め込まれたスプリンクラーシステムの修理に必要なツールは? 屋外で最もうまく機能する Wi-Fi ルーターは? スタイリッシュなスキーグローブを選ぶ際には何を考慮すべき? こうした質問への回答を得られるようにすること、それが Amazon が立ち上げたバーチャルショッピングアシスタント Rufus の開発の背景です。 Rufus を特に便利にしているのは、会話形式であることです。これにより買い物客が回答に満足するまで会話を続けることができます。店舗にいる店員のように、バーチャルショッピングアシスタントは買い物客のニーズと好みを理解しようと問いかけを行います。これを会話型検索と考える人もいるでしょう。 これは確かに従来の検索を置き換えるものではありません。小売業者はまず Search & Product Discovery ソリューションをモダナイズし、次に Chatbots & Virtual Assistants が自社にとって意味があるかどうかを判断する必要があります。それでもこうしたソリューションを使用することで、買い手はその商品の購入をさらに納得できるとともに売上向上と返品の減少につながるでしょう。 ハイパーパーソナライゼーション 機械学習を用いたパーソナライゼーションは、似通った顧客の嗜好に基づいて個々の顧客の嗜好を予測する 協調フィルタリングを Amazon がはじめて使用 してから25 年が経過しています。次のトレンドは、機械学習と生成 AI を組み合わせることで買い物客ひとりひとりに個別の体験をもたらすことです。これには、マーケティングコミュニケーション、検索結果、商品詳細ページ、さらにはチャットボットの会話まで、個人の嗜好に合わせて ハイパーパーソナライズする ことが含まれます。 最終的には、各ウェブストアセッションを個々の買い物客のためにカスタマイズできるようになり、魅力的なテーマ、カスタマイズされた商品構成、そして各個人の嗜好に基づいた選りすぐったサービスを提供して商品を表示できるようになるでしょう。このようなきめ細かなケアを提供するホワイトグローブサービスはかつて富裕層に限られていましたが、一般の買い物客にも広がっていくことでしょう。小売業者は、過去の販売データ、商品データ、第三者の顧客データなどを活用し、個々の買い物客とのすべてのインタラクションをその人に合わせてベストにハイパーパーソナライズする方法を検討する必要が出てくるでしょう。 バーチャル試着 オンライン販売は、特にファッションの分野では伸び悩んでいました。というのも、買い物客がオンライン上の商品に対してこれでいいと購入に踏み切る確信を持ちにくかったからです。商品が自分のイメージどおりかどうかわからないと、購入をためらう可能性が高く、色やサイズが違うものをそれぞれ注文して合わなかったものを返品することがあります。生成 AI によって商品をコンテキストに合わせて視覚的に描写でき、買い物客が商品を バーチャルに試着 できるようになります。これは、人物とセーター、椅子と居間といった 2 つの画像を組み合わせることで再現されます。買い物客はそれを見て購入するか否かを判断できます。 Stable Diffusion や Amazon Titan Image Generator などの AI モデルは、インテリジェントに画像を組み合わすことで、買い物客にそれが期待に合ったものであるかどうかを示し、確信をもって購入できるようにします。アパレル、ファッション、アクセサリー、家具やビジュアル化の恩恵を受けるその他の商品を販売する小売業者は、この機能の導入を検討する必要が出てくるでしょう。 AI エージェント チャットボットやバーチャルアシスタントと会話することで情報は得られますが、ほとんどの場合、次のアクションへと導くことなく終了してしまいます。一方、エージェントは目標達成に能力を発揮します。通常、自律的であり、特定のタスクの達成を可能にするツールを用意しています。目標達成に貢献し、案件を前に進めてくれるので、エージェントをチームの一員とさえ考える人もいます。 Amazon Bedrock Agents などのサービスでは、連鎖的な推論を使用して、複雑な問題を切り分けて解決できます。たとえば、価格設定エージェントは、競合他社のウェブサイトをスクレイピングして価格を探り、商品マージンを調べ、定義されたルールに基づいてベストな価格を提案します。 例えば、需要予測ソフトウェアに予測エージェントが組み込まれていて、必要に応じてあなたの予測を更新および配布できるとしましょう。そうすると、小売業者としてはチーム全体の生産性を高めるために自動化できるタスクを探したくなるにちがいありません。 ドメイン固有の基盤モデル ほとんどの基盤モデル (FM) や大規模言語モデル (LLM) は、一般知識を会得できるように公開データのコーパスで訓練されていますが、特定のドメインに焦点を当てるモデルをゼロから構築することも可能です。Amazon Science チームは、購入体験の向上を目的として、膨大な商品カタログ、顧客レビュー、その他の類似データで訓練された、 Rufus が使用する小売業向けの LLM を作成しました。 小売業界に特化することで LLM が必要とするパラメータ数を抑え、運用コストを低くできるにも関わらず、優れたアウトプットをもたらすことが期待できます。 もちろん、LLM を構築することは途方もない取り組みであり、ほとんどの小売業者には手の届かないものです。したがって、ほとんどの小売業者は自社のデータを使って 既存のモデルを微調整する ことを選択するでしょう。小売業者は、このコスト効果の高いアプローチを使用して、生成 AI の出力を改善することを検討する必要が出てくるでしょう。 Computer Use まだ初期段階ですが、 Claude 3.5 などの FM を使ってコンピュータを制御し、自分がコンピュータを使うのと同じように FM を駆使させることが可能になりました。例えば、注文書を作成するように依頼すると、FM が画面を「見て」、マウスを操作して注文フォームに必要事項を入力します。生成 AI はリグレッションテストにも使用でき、ウェブストアを更新したあとに期待した通りに機能することを確認することができます。 消費者側からすると、例えば最も安い Apple AirPod Pro を見つけて購入するように依頼することができます。そうすると FM は調査を行い、最終的には購入する商品を選択してくれます。 FM がソフトウェア、特にブラウザの操作ができるよう訓練されるにつれ、一部のルーチン作業を自動化できるようになり、人間はより創造的な活動に時間を費やすことができるようになります。現在、このテクノロジーを採用するには少し早すぎますが、2025 年に一般提供されるかどうか注目しておきましょう。 NRF の AWS ブースにお越しください 2025 年に生成 AI を採用しようと意思決定を行うにあたって情報面でお手伝いできるよう、2025 年 1 月に開催される 全米小売業協会（NRF） イベントショーの AWS ブース にお立ち寄りください。こちらに立ち寄っていただければ、AWS、Amazon、当社パートナーの専門家と会話ができますし、エキサイティングな生成 AI デモを体験し、スマートストアテクノロジー、デジタルコマース、小売業務など、この分野の最新のアイデアを含む多くのイノベーションについて学ぶことができます。 さらに、以下のリソースから小売業界における生成 AI の素晴らしい発展を確認できます: Amazon Science Generative AI for Retail and Consumer Goods AWS Solution Library 著者について David Dorf は AWS のグローバルリテールソリューション部門をリードしています。そこでは、小売業向けの専用ソリューションを開発し、小売業のイノベーションを支援しています。AWS 入社前は、Infor Retail、Oracle Retail、360Commerce、Circuit City、AMF Bowling、Schlumberger の小売・銀行部門で、小売技術ソリューションを開発していました。数年間 NRF-ARTS と協力して技術標準化に取り組み、MACH Alliance のアドバイザリーボードに名を連ねる一方で、Retail Orphan Initiative のチャリティを支援しています。バージニア工科大学とペンシルベニア州立大学の学位保持者です。 本稿は PMO の村田が翻訳を担当しました。原文は こちら 。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先週は AWS re:Invent 2024 が開催されました。キーノートや多くのセッションで生成 AI に関する最新の取り組みやアップデートが発表されました。 Youtube に動画がアップロード されているので、見逃したセッションがある方はご覧ください。 発表された新サービスをサクッと確認されたい方向けには、12 月 6日 に開催された「 AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 」の資料と動画がアップロードされていますのでこちらをご覧ください。 また、2025 年 2 月には re:Invent で発表されたアップデートをより深掘って振り返る Recap イベントを開催します。以下のリンクからお申し込みいただけます。 AWS re:Invent Recap – Keynote 編 AWS re:Invent Recap – インダストリー編 AWS re:Invent Recap – ソリューション編 今週は特別号として re:Invent で特に注目を集めた生成 AI 関連の新サービスを、木村の独断でピックアップして紹介していきます。それでは見ていきましょう！ サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション Amazon Q Developer にて、ドキュメント生成 、 コードレビュー 、 ユニットテスト機能を提供開始 Amazon Q Developer は、ソフトウェア開発ライフサイクル全般で開発者を支援する生成 AI 搭載アシスタントです。今回のアップデートで、ドキュメント生成、コードレビュー、ユニットテスト機能といったコーディング以外のタスクを加速するための機能を提供開始しました。開発者は、IDE のチャットパネルを開いて /doc と入力すると、コードに関する readme やデータフロー図などのドキュメントを生成することができます。また、 /review と入力すると、コードレビューが開始され、命名規則違反やセキュリティ脆弱性などの問題を特定してコード修正案を生成します。そのままコードエディタ上で変更を適用することができます。また、 /test と入力すると、テストケースの特定からユニットテストの作成まで自動で行われます。開発者は生成されたユニットテストを受け入れるかを選択することができます。これらは Amazon Q Developer が利用可能なすべての AWS リージョンで利用可能です。詳細は こちらのブログ を参照ください。 Amazon Q Developer にて .NET 、 Mainframe 、 VMware ワークロード向け変換機能を発表 (プレビュー) Amazon Q Developer にて、大規模なエンタープライズワークロードのモダナイズを加速するための、3 つの変換機能のパブリックプレビューを発表しました。変換機能を提供する 専用の web ページ が用意されています。.NET 変換機能では、.NET Framework から .NET への自動変換をサポートします。Amazon Q Developer が移植処理を自動的に行い、変換後のコードを新しいブランチにコミットします。Mainframe 変換機能では、COBOL コードから Java コードへのリファクタリングをサポートします。変換では、まずコードの分析が行われドキュメントが作成されます。その後、ビジネスドメイン単位への分解と移行計画の作成を行い、 COBOL から Java への自動リファクタリングを行います。VMware 変換機能では、VMware 仮想マシンから Amazon EC2 への移行をサポートします。VMwareのネットワーク構成とファイアウォールルールをネイティブのAWSネットワーク構成に変換し、到達可能性を検証します。各処理の重要な決定ポイントでは、Amazon Q Developer がユーザーの入力を促進します。詳細は こちらのブログ を参照ください。 Amazon Q Developer に運用調査機能を追加 (プレビュー) Amazon Q Developer にて、AWS 環境全体の運用上の問題を調査・修正する機能がプレビューで追加されました。これにより運用負荷を下げ時間と労力を節約することが可能です。アラートがあがった Amazon CloudWatch アラームにて「調査」を選択すると、Amazon Q Developer が問題の仮説と修正のガイドを提示します。修正のガイドでは、問題を修正する AWS Systems Manager Automation ランブック が提案され、詳細を確認後そのまま実行することが可能です。詳細は こちらのブログ をご覧ください。 GitLab Duo with Amazon Q のプレビューを発表 開発者が慣れ親しんだ GitLab 環境内で、Amazon Q Developer の AI エージェント機能を有効化できる GitLab Duo with Amazon Q のプレビューを発表しました。これにより、GitLab 環境上で生成 AI を活用し、機能開発、コードレビュー、単体テスト、変換を加速することができます。例えば、Issue にて /q dev とコメントを追加すると、Issue の内容に基づいてコードを生成したり、マージリクエストページで /q review とコメントを送信すると、変更をスキャンし脆弱性などの検査を行ったりすることが可能です。詳細は こちらのブログ をご覧ください。 Amazon Q Index により ISV が生成AIエクスペリエンスを強化可能に ISV 向けの新しい Amazon Q Business 機能を発表しました。ISV は、アプリケーションと Amazon Q Index を統合することで、アプリケーション外の複数のソースからデータを取得しよりパーソナライズされた応答を顧客に提供できるようになります。Asana、Miro、PagerDuty、Zoom などの ISV は、Amazon Q Index をアプリケーションに統合しています。詳細は こちらのブログ を参照ください。 サービスアップデート – アプリケーション開発のためのツール Amazon Bedrockにて Amazon Nova 基盤モデルを提供開始 Amazon Bedrock で 最先端の知能と高いコストパフォーマンスを提供する 5 つの Amazon Nova 基盤モデルが利用できるようになりました。Nova Micro は、低コスト・低レイテンシーの応答を提供するテキストのみのモデルです。Nova Lite は、画像、動画、テキスト入力の処理が高速かつ低コストのマルチモーダルモデルです。Nova Pro は、幅広いタスクに対して精度、速度、コストの最適な組み合わせを持つ高性能マルチモーダルモデルです。これらのモデルは、特に RAG やエージェントアプリケーションで高い効果が出るよう最適化されています。日本語もサポートされています。またこれらに加え、Nova Canvas という画像生成モデルと、Nova Reel という動画生成モデルも提供開始しました。詳細は ブログ をご覧ください。 100 以上のモデルが用意されている Amazon Bedrock Marketplace を発表 Amazon Bedrock Marketplace は、従来から提供している Amazon Bedrock のサーバーレスモデルに加えて、100 以上の公開および独自の基盤モデルへのアクセスを提供する新機能です。Amazon Bedrock Marketplace のモデルは、Bedrockの統一 API を通じてアクセスでき、Converse API と互換性のあるモデルは、Amazon Bedrock エージェント、ナレッジベース、ガードレールなどのツールと共に使用できます。Amazon Bedrock Marketplace はアジアパシフィック（東京）含む 14 リージョンでサポートされています。詳細は ブログ を参照ください。 Amazon Bedrock Model Distillation (蒸留) が利用可能に（プレビュー） Amazon Bedrock Model Distillation により、お客様はより小型で高速かつコスト効率の高いモデルを使用できるようになりました。蒸留とはモデルの圧縮手法の1つです。これまで蒸留には、プロンプトと応答の作成、トレーニングパラメータの調整など多くのステップが必要でしたが、Model Distillation は応答データの生成・トレーニング・評価・ホスティングなどのプロセスを自動化します。Model Distillation は Anthropic、Meta、Amazon のモデルをサポートしています。詳細は ブログ を参照ください。 Amazon Bedrockにて、基盤モデルの低レイテンシー最適化推論機能を提供開始(ブリックプレビュー) Amazon Bedrockにて、基盤モデルの低レイテンシー最適化推論機能がパブリックプレビューで利用可能となりました。これにより、生成 AI アプリケーションでより速いレスポンスをユーザーに提供できるようになりました。現在こちらの新しい推論オプションは、Anthropic の Claude 3.5 Haiku と、Meta の Llama 3.1 405B および 70B をサポートしています。本機能は、米国東部（オハイオ）リージョンでクロスリージョン推論を通じて利用可能です。 コストとレイテンシーを削減する Amazon Bedrock Intelligent Prompt Routing と prompt cachingを提供開始（プレビュー） Amazon Bedrock は生成 AI アプリケーションのコストとレイテンシーを削減するための 2 つの機能をプレビューで発表しました。Amazon Bedrock Intelligent Prompt Routing は、ユーザーからのリクエストに対して、望ましい応答を低コストで提供する可能性が高いと予測されるモデルに動的にルーティングする機能です。これにより、お客様は応答の品質とコストの最適化を図りやすくなります。現在は、Claude Sonnet 3.5 と Claude Haiku 間、または Llama 3.1 8B と Llama 3.1 70B 間のルーティングをサポートしています。prompt caching は、頻繁に使用されるプロンプトをキャッシュすることで、モデルのコストを最大 90%、レイテンシーを最大 85% 削減可能な新機能です。キャッシュによりリクエスト処理の高速化だけでなく、出力の生成に必要な計算リソースが少なくなるためコスト削減にも繋がりやすくなります。Converse API で 対象のメッセージを cachePoint ブロック で指定して呼び出します。これらの詳細は ブログ を参照ください。 Amazon Bedrock Data Automation (プレビュー) 、 Knowledge Basesのマルチモーダルデータ処理 、 Knowledge BasesのGraphRAG対応 (プレビュー) 、 構造化データの検索機能、といったデータ処理と検索を強化する機能を提供開始 Amazon Bedrock はデータ処理を効率化するための 4 つの機能強化を発表しました。Amazon Bedrock Data Automation (DBA) は、文書、画像、動画、音声といった非構造化データの分析とインサイトの生成を自動化する機能です。例えば、ドキュメントの解析や動画の要約などが可能で、ブループリントを定義することで出力形式の指定も可能になっています。またKnowledge Bases のパーサーとして DBA を指定することで、より高い精度の RAG の構築が期待できます。次に、Amazon Bedrock Knowledge Basesにて、画像、図表などのマルチモーダルデータを処理できるようになりました。テキストとマルチモーダルの両方のデータに基づいて回答を生成することで、RAG で得られる回答の精度を向上させることができます。パーサーには DBA もしくは既存の基盤モデル (Claude 3.5 Sonnet もしくは Haiku 3) を指定することができます。Knowledge Bases の GraphRAG 対応は、RAG とグラフ DB を組み合わせて、より関連性が高い応答を提供するための新機能です。グラフ DB を使うことで、データ同士の関係性を考慮した検索が可能になります。Knowledge Bases のベクトルストアとして Amazon Neptune Analytics を選択すると GraphRAG を有効化できます。構造化データの検索機能は、自然言語クエリを SQL クエリに変換しソースから直接データを取得できるようにする機能です。現在、ソースとして Amazon Redshift と Amazon Sagemaker Lakehouse をサポートしています。これらの詳細は ブログ を参照ください。 Amazon Bedrockがマルチエージェントコラボレーションに対応 (プレビュー) Amazon Bedrock がマルチエージェントコラボレーションに対応し、複雑な多段階タスクに協力して取り組む複数の AI エージェントを構築、管理することができるようになりました。例えば SNS 投稿を生成するエージェントと、投稿内容と過去データから最適な投稿時間を予測するエージェントを活用してより効果の高い SNS キャンペーンを行うといったユースケースが挙げられます。セットアップが容易である点や複数エージェントのオーケストレーションを実現する機能がマネージドで提供されている点が嬉しいポイントとなります。詳細は ブログ を参照ください。 Amazon Bedrock Guardrails が Automated Reasoning Check (自動推論チェック) をサポート（プレビュー） Amazon Bedrock Guardrails に新しいセーフガードとして Automated Reasoning Check (自動推論チェック) がプレビューで追加されました。この機能により、LLM の出力の正確性が数学的に検証され、ハルシネーションの検出を行いやすくなりました。事前設定として、企業のガイドラインや仕様が書かれたドキュメントをアップロードすると自動推論ポリシーが作成されます。Amazon Bedrock Guardrails は、LLM の出力と自動推論ポリシーを照合して検証を行い、不正確な回答を特定します。事実の正確性と説明可能性が重要なユースケースに特に有用です。詳細は ブログ を参照ください。 サービスアップデート – 生成AI開発のためのインフラストラクチャー 次世代の Amazon SageMaker を発表 AWS の機械学習と分析機能を統合し、データへの統一されたアクセスとガバナンスを備えた統合プラットフォームサービスとして、次世代の Amazon SageMaker を発表しました。次世代の Amazon SageMaker には、 Amazon SageMaker Unified Studio (プレビュー) 、 Amazon SageMaker Lakehouse 、 Amazon SageMaker Data and AI Governance といった新サービスが含まれます。モデル開発、生成 AI アプリケーション開発、データ処理、SQL分析などを、単一の開発環境から実施することができるようになっています。これまでの Amazon SageMaker は Amazon SageMaker AI に名称変更されています。SageMaker AI は次世代 SageMaker に統合されています。詳細は こちらのブログ を参照ください。 AI/ML トレーニングと推論のための Amazon EC2 Trn2 インスタンスと Trn2 UltraServer が利用可能に AI/ML トレーニングと推論のための最も強力な EC2 コンピューティングオプションである Amazon EC2 Trn2 インスタンスと Trn2 UltraServer が利用可能になりました。Trn2 インスタンスは第 1 世代の Trn1 インスタンスと比較して 4 倍高速で、EC2 P5e および P5en インスタンスと比較して 30〜40% 優れた価格性能比を提供します。Trn2 UltraServer は 64 個の Trainium2 チップを、高帯域幅・低レイテンシの独自インターコネクトNeuronLink で接続しており、モデルトレーニングの速度向を実現します。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

本ブログは、2024/07/08 に公開された Secure access to Amazon QuickSight with Amazon WorkSpaces Secure Browser を翻訳したものです。 はじめに データ主導の意思決定に Amazon QuickSight を使用する組織が増える中、 Amazon WorkSpaces Secure Browser は、機密情報を含むダッシュボードへのセキュアなアクセスをエンドユーザーに提供します。WorkSpaces Secure Browser を使用することで、管理者はダッシュボードの作成者と閲覧者に保護されたブラウザ環境を提供すると同時に、機密データをエンドユーザのデバイスに残さないようにすることができます。 このブログのポストでは、WorkSpaces Secure Browser、 Virtual Private Cloud（VPC）エンドポイント（AWS PrivateLink による） 、および AWS IAM Identity Center を活用して、QuickSight へのセキュアで一元的なアクセスを提供するソリューションについて説明します。加えて、組織全体でセキュアなデータの可視化と分析を可能にするための実装ステップ、ベストプラクティス、および主な考慮事項について説明します。 本ブログのアーキテクチャの目標は以下のとおりです。 エンドユーザーデバイスからのデータ流出を防ぎ、セキュリティ体制を強化する。 VPC内のセキュアなブラウザ環境からの QuickSight アクセスを強制する。 高感度ダッシュボードを安全に構築するためのユーザーフレンドリーなエクスペリエンスを提供する。 次のアーキテクチャ図は、VPC エンドポイントから QuickSight ダッシュボードへのトラフィックを制限する方法を示しています。VPC 内の WorkSpaces Secure Browser は、作成者と読者が QuickSight ダッシュボードにアクセスするためのセキュアな Web 環境を提供します。 （訳者注）Amazon QuickSight の静的コンテンツを取得するために、WorkSpaces Secure Browser のインターネット接続が必須です。前述の静的コンテンツとは、Amazon QuickSight を構成する画像や JavaScript のことであり、ユーザーデータは含まれません。 前提条件 AWS Console とCLI（AWS CloudShell 経由）にアクセスできるIAMユーザー ユーザーとグループによる IAM Identity Center IAM Identity Center を設定したことがない場合は、 IAM Identity Center の前提条件を確認することを推奨します。 2 つのプライベートサブネットを持つ VPC – AWS Labs の既存のサンプルテンプレートの利用を推奨します。（訳者注）ご自身で最低 2 つのプライベートサブネットおよび NAT Gateway を持つ VPC を構築できる場合もしくは構築済みの場合は、この限りではありません。 注意 このブログでは、IAM Identity Center と統合された QuickSight と WorkSpaces Secure Browser の両方のアプリケーションを取り上げます。QuickSight IP および VPC エンドポイント制限機能は、組織が使用する認証方法に関係なく機能します。また、このブログでは US-West-2（オレゴン）を使用しています。異なる AWS リージョンを使用する場合は、エンドポイント名を変更してください。 AWS IAM Identity Center でのユーザーとグループの作成 このブログでは、1 つのユーザーと 1 つのグループのみが必要です。簡単にするために、管理ユーザー John Smith と QuickSight Administrators という名前のグループを作成します。 注意 組織ですでに Identity Center をデプロイしている場合は、これらの手順は必要ありません。既にユーザとグループがある場合は、「QuickSight の設定」まで読み飛ばしてください。 次に、AWS CLI を使用して、AWS IAM Identity Center 内にグループを作成します。または、既存の ID プロバイダを活用し、 Identity Center インスタンスをサポートされている IDP と同期することもできます。グループは、AWS IAM Identity Center と統合する際に QuickSight 内で割り当てに使用されます。 AWS IAM Identity Center 内でグループを作成するには、 CloudShell を起動し、コマンドを実行します。 aws identitystore create-group --identity-store-id [Your Identity Store ID] --display-name "QuickSight-Administrators" 注意 CLI オプションは、Identity Center 内の ID ストアを参照する必要があります。これは、Identity Center コンソールの 設定 → アイデンティティソース で確認できます。 デフォルトディレクトリ（コンソール）にユーザを作成するには IAM Identity Center を開きます。 サイドメニューから ユーザー を選択し、 ユーザーを追加 を選択します。 ユーザー名 に john.smith と入力します。 パスワード には、 「パスワードの設定手順が記載された E メールをこのユーザーに送信します。」 を選択します （推奨） 。 E メールアドレス に、アクセス可能なメールアドレスを入力します。 名 に John 、 姓 に Smith と入力します。 その他のオプションフィールドは空欄のまま、 次へ を選択します。 グループ で QuickSight-Administrators を選択します。 次へ を選択します。 詳細を確認し、 ユーザーを追加 を選択します。 完了したら、John Smith の一般情報とグループメンバーシップを確認します。 QuickSightの設定 ユーザーとグループを作成したら、QuickSight ダッシュボードを作成します。 注意 IAM Identity Center アプリケーションを使用して QuickSight Enterprise Edition アカウントにサインアップするには、適切な権限が必要です。この方法を使用するために必要な権限の詳細については、 Amazon QuickSight の IAM アイデンティティベースポリシー を参照してください。 QuickSightアカウントを作成するには（コンソール） AWS コンソールから QuickSight を開きます。 QUICKSIGHT にサインアップ を選択します。 アカウント通知用メールアドレス に、アクセス可能なメールアドレスを入力します。 認証方法 は AWS IAM アイデンティティセンターを使用 を選択します。 QuickSight アカウント名 には、 ユニークな名前（例えば、{yyyymmdd}-QuickSightDemo-{AWSアカウントID} など） を入力します。 設定 を選択します。 管理者グループ は、 QuickSight-Administrators を検索して選択します。 IAM ロール で、 QuickSight で管理されるロールを使用する (デフォルト) を選択します。 オプションのアドオン では、 ピクセルパーフェクトレポートを追加 の選択を解除します。 完了 を選択します。 QuickSight にリダイレクトされたら、このブログの次のセクションに進みます。 WorkSpaces Secure Browser の導入 WorkSpaces Secure Browser Web ポータル（コンソール）を作成する。 WorkSpaces Secure Browser コンソールを開きます。 ポータルを作成 を選択します。 ネットワーク接続の詳細 で、作成した VPC を選択します。 サブネット で、2つのプライベートサブネットを選択します。 セキュリティグループ では、 デフォルトの VPC セキュリティグループ を選択します。 次へ を選択します。 ポータルの詳細 で、 表示名 に WorkSpaces Secure Browser ポータルの名前を入力します。 インスタンスタイプの設定 で インスタンスタイプ で Standard Regular を選択します。 最大同時セッション数 に 5 を入力します。 ユースケースに基づくWorkSpaces Secure Browserポータルの推奨サイズは、 料金ページ に記載されています。 ユーザーアクセスログ では、 Kinesis Data Stream Name を空のままにします。 IP アクセス制御グループの詳細 については、 IP アクセス制御グループ を空のままにします。 ポリシーの設定 Startup URL – オプション には、IAM Identity Center コンソールから AWS アクセスポータルの URL を入力します。 IAM Identity Center コンソール → 設定 → アイデンティティソース から確認できます。 プライベートブラウジング は、 無効 を選択します。 履歴の削除 は、 無効 を選択します。 次へ を選択します。 ユーザー設定の詳細 シングルサインオンにWorkSpaces Secure Browser拡張機能を使用できるようにする で、 許可済み を選択します。 この設定により、ユーザーのローカルブラウザから WorkSpaces Secure Browser 管理ブラウザへのブラウザ Cookie を介したシングルサインオン（SSO）が可能になります。初めて WorkSpaces Secure Browser にログインするとき、ユーザーは拡張機能をローカルの Chrome または Firefox ブラウザに追加します。 ドメイン には awsapps.com を入力します。 クリップボードの許可 は、 リモートセッションにのみ貼り付ける を選択します。 ファイル転送の許可 で アップロードのみ を選択します。 ローカルデバイスに出力 は 許可されていません を選択します 注意 クリップボードの許可とファイル転送の許可によって、WorkSpaces Secure Browserセッションでユーザーが実行できるアクションが決まります。ユーザーが機密データをローカルデバイスにダウンロードできないようにするには、クリップボードの操作を制限して、ユーザーがセッションにコピーすることのみを許可するようにします。ユーザーがセッションにファイルをアップロードすることは許可できますが、ダウンロードすることはできません。この使用例としては、他のデータセットと一緒に分析するために CSV を QuickSight にアップロードすることが考えられます。 ユーザーセッションの詳細 を参照してください。 切断タイムアウト（分） に 60 を入力します。 アイドル切断タイムアウト（分） には、 15 を入力します。 次へ を選択します。 アイデンティティプロバイダーを設定します。 ID プロバイダ（IdP）の詳細 については、 AWS IAM アイデンティティセンター（AWS SSO の後継サービス） を選択します。 IAM アイデンティティセンターで続行 を選択します。 AWS IAM アイデンティティセンター (AWS SSO の後継サービス) の設定詳細 ユーザー john.smith または以前に作成したユーザーを選択します。 次へ を選択して詳細を確認し、 ポータルの起動 を選択します。 WorkSpaces Secure Browser ポータルのデプロイには約 10 分かかります。ステータスは WorkSpaces Secure Browser コンソールで確認できます。ポータルが作成されると、割り当てられたユーザの Identity Center アクセスポータルにアプリケーショ ンタイルが表示されます。 Route53 Aレコードによる VPC インタフェースエンドポイントの登録 QuickSight ダッシュボードへのすべてのアクセスが WorkSpaces Secure Browser から行われるようにするには、 VPC インターフェースエンドポイント をデプロイし、 Route53 Private Hosted ゾーン を作成し、エンドポイント用の A レコード を作成します。これにより、VPC 内のトラフィックが QuickSight VPC エンドポイントにルーティングされます。その後、VPC エンドポイントは QuickSight の IP/VPC 制限リストに登録されます。 QuickSight 用の VPC インターフェース・エンドポイントを作成する QuickSight 用の VPC インターフェース・エンドポイントを作成するには（コンソール） VPC コンソール を開きます。 仮想プライベートクラウド メニューの左側で、 エンドポイント を選択します。 エンドポイントの設定 で 名前タグ に QuickSightVPCe と入力します。 サービスカテゴリ で、 AWSサービス を選択します。 サービス で QuickSight を検索し、 amazonaws.us-west-2.quicksight-website を選択します。 VPC で、WorkSpaces Secure BrowserをデプロイしたVPCを選択します。 サブネット で WorkSpaces Secure Browserがデプロイされた すべてのアベイラビリティゾーン を選択します。 サブネット ID では、各アベイラビリティゾーンの プライベートサブネット を選択します。 Security Groups（セキュリティグループ） で、 デフォルト のセキュリティグループを選択します。 デフォルトのセキュリティ・グループを使用しない場合は、セキュリティ・グループがこのブログで後ほど作成する QuickSight VPC エンドポイントへのトラフィックを許可していることを確認してください。 エンドポイントを作成 を選択します。 作成後、 各エンドポイントの IPv4 アドレス と VPC エンドポイント ID をメモします。これらを Route53 のプライベートホストゾーンで参照し、QuickSight VPC エンドポイントにトラフィックを誘導します。 このステップで、各プライベートサブネットに QuickSight 用の VPC エンドポイントが作成されました。これにより、トラフィックはパブリックインターネットではなく、AWS ネットワークバックボーンを経由してルーティングされるようになります。 Route53 プライベートホストゾーン Route53 内にプライベートホストゾーンを作成します。プライベートホステッドゾーンは、Amazon VPC サービスを使用して作成した 1 つまたは複数の VPC 内のドメインとそのサブドメインの DNS クエリに Amazon Route 53 が応答する方法に関する情報を保持するコンテナです。Route53 プライベートホストゾーンの詳細については、 こちら をお読みください。 DNS A レコードは、ドメイン名を Web サーバなどの IPv4 アドレスに解決するために使用されます。QuickSight ドメイン名を特定の QuickSight VPC エンドポイントに解決するために A レコードを作成します。これにより、VPC 内のトラフィックは、パブリック QuickSight エンドポイントではなく、VPC エンドポイントにルーティングされます。 プライベートホスティングゾーンの A レコードには、[region].quicksight.aws.amazon.com というレコード名を入力します。（訳者注ここから）[region] の箇所に適切なリージョンを設定してください。本ブログのデフォルトのリージョンは、us-west-2（オレゴン） となりますので、A レコードには、us-west-2.quicksight.aws.amazon.com というレコード名を設定することになります。（訳者注ここまで）これにより、WorkSpace Secure Browser セッションから QuickSight を起動したときに、トラフィックが VPC エンドポイントに解決されるようになります。A レコードは、QuickSight サービス名を QuickSight VPC エンドポイントにマッピングするために使用されます。 Route53プライベートホストゾーン（PHZ）とAレコードを作成するには（コンソール） Route53 コンソール を開きます。 サイドメニューで、 ホストゾーン を選択します。 ホストゾーンの作成 で ドメイン名 に quicksight.aws.amazon.com と入力します。 タイプ で プライベートホストゾーン を選択します。 ホストゾーンに関連付ける VPC で リージョン には 米国西部 (オレゴン) を選択します。 VPC ID には、WorkSpaces Secure Browser が配置されている VPC を選択します。 ホストゾーンの作成 を選択します。 ゾーンが作成されたら、 レコードを作成 を選択します。 レコードをクイック作成 で レコード名 に us-west-2 と入力します。 レコードタイプ には、 「A – IPv4 アドレスと一部の AWS リソースにトラフィックをルーティングします。」 を選択します。 値 には、前のセクションでQuickSightエンドポイントを作成したときの 各エンドポイントの IPv4 アドレス を入力します。 レコードを作成 を選択します。 A レコードを作成すると、ホストされたゾーンのコンソールに新しいレコードが反映されます。このレコードの追加により、作成した VPC エンドポイントを経由して QuickSight ダッシュボードへのトラフィックが正しくルーティングされます。 WorkSpaces セキュアブラウザ VPC への QuickSight の制限 QuickSight では、管理者が特定の CIDR、VPC エンドポイント、または VPC ID からダッシュボードへのトラフィックを制限することができます。ローカルマシンの CIDR（開発目的）と WorkSpaces Secure Browser VPC の VPC エンドポイントを追加します。これにより、ローカルワークステーションまたは WorkSpaces Secure Browser ポータルのいずれからも発信されていないトラフィックがブロックされます。 QuickSight（コンソール）で IP および VPC エンドポイントの制限を追加するには QuickSight を開き、ページ右上のユーザーアイコンを選択します。 QuickSight を管理 を選択します。 セキュリティとアクセス許可 を選択します IP と VPC エンドポイントの制限 までスクロールダウンし、 管理 を選択します。 制限リスト に 2 つのエントリを入力します。 制限 に、 /32 が付加された 自分の IP アドレス を入力します。（訳者注：自身のIPアドレスは、画面に「ご利用の IP アドレスは 123.123.123.123 です」というように表示されています。） Local Laptop などの 説明 を入力します。 追加 を選択します。 制限 に、作成した VPC エンドポイント ID を入力します。 WorkSpaces Secure Browser VPC Endpoint などの説明を入力します。 追加 を選択します。 変更を保存 を選択します。 制限を強制 フィールドをオンに切り替えます。 制限を強制 を切り替えると、これらのソースから発信されたトラフィックのみが QuickSight ダッシュボードにアクセスできるようになります。 注意 ローカル・デバイスの CIDR を追加しないと、QuickSight へのアクセスが拒否されます。IP/VPC エンドポイントの制限をプログラムで変更するには、AWS CLI コマンドで制限リストを無効にします。 aws quicksight update-ip-restriction --account-id [YOUR AWS ACCOUNT ID] --enabled FALSE 制限リストが適用されると、次の手順で QuickSight ダッシュボードにアクセスできるようになります。 AWS IAM Identity Center アプリケーションランチャーに移動します。 WorkSpaces Secure Browser を起動します。 初回起動時は 1 分程度かかります。 WorkSpaces Secure Browser セッションで、IAM Identity Center アプリケーションタブから QuickSight を起動します。 さらに、別のデバイスを使用して、以下の手順に従って制限リストをテストすることができます。 AWS IAM Identity Center アプリケーションランチャーに移動します。 QuickSight を起動します。 ユーザーエクスペリエンスのウォークスルー ユーザー John Smith が組織の Identity Center AWS アクセスポータルに認証されました。 John は、アクセス権を付与されたアプリケーションを表示し、QuickSight を起動します。 QuickSight は、IP/VPC 制限を使用してダッシュボードへのアクセスを拒否します。 John は WorkSpaces Secure Browser を起動する。 John の管理者は、Identity Center AWS アクセスポータルをデフォルトのホームページとして設定し、シングル サインオンを設定している。John のローカルブラウザの Cookie が WorkSpaces Secure Browser セッションに同期されます。 John が WorkSpaces Secure Browser セッション内から QuickSight Dashboard を起動することができ、QuickSight の IP/VPC 制限によってブロックされません。 予想される動作を以下に示します。John Smith はローカルブラウザから QuickSight ダッシュボードにアクセスできませんが、WorkSpaces Secure Browser から起動するとアクセスできます。 その他の留意事項 VPCエンドポイントポリシー このブログでは、VPC エンドポイントポリシーを取り上げませんでしたが、本番ワークロードでは評価することをお勧めします。エンドポイントポリシーをアタッチすることで、特定の QuickSight アカウントまたは特定の AWS 組織配下のアカウントに利用を制限することができます。QuickSight の VPC エンドポイントポリシーの詳細については、 こちら を参照してください。 まとめ このブログでは、QuickSight ダッシュボードへのアクセスを特定のVPCに制限する方法について説明しました。その VPC にWorkSpaces Secure Browser を導入し、秘匿性や機密性の高いデータを扱うダッシュボードにアクセスする際にユーザーが実行できるファイル転送アクション/クリップボードコマンドを制限しました。実装されたコントロールにより、ユーザーは WorkSpaces Secure Browser セッションからローカルワークステーションにデータをダウンロードしたり、コピー/ペーストしたりできなくなります。その他のWorkSpaces Secure Browser の使用例については、 サービスの詳細ページ をご覧ください。 クリーンアップ このブログで作成したリソースを削除するには、各サービスの関連ドキュメントを参照してください。 QuickSight WorkSpaces Secure Browser Route53プライベートホストゾーン

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 先週は AWS re:Invent 2024 が開催されました。今週はre:Invent 2024特別号と題しており、本稿はそのPart2となります。Part1は こちら からご覧いただけますので、まだお読みでない方がいらっしゃればそちらもよろしくお願いします！ また、Part 1 にも記載していますが、re:Inventのアップデートに関しては12/6(金)に発表内容をほぼ全て網羅したセミナー「 AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 」も開催されています。こちらの資料と動画もすでにアップロードされていますのでぜひご確認ください。 それでは先週のアップデートを振り返りましょう。こちらでは以下のカテゴリについて取り扱います。 カテゴリリンク : Generative AI / Machine Learning | Contact Center | Management & Governance | Security, Identity, & Compliance AWS re:Invent 2024期間に発表された主要なアップデート Part 2 (2024/12/2週) Generative AI / Machine Learning Announcing Amazon Nova foundation models available today in Amazon Bedrock 最先端の基盤モデルであるAmazon Novaが発表されました。Amazon Bedrockでは5つのモデルを利用できます。Amazon Nova Microはテキストのみのモデルで、低コスト、低レイテンシー。Amazon Nova Liteは低コストで画像、動画、テキスト扱えるマルチモーダルのモデル。Amazon Nova Proは精度、速度、コストが最適な組み合わせの高性能なマルチモーダルモデル。Amazon Nova Canvasは画像生成、Amazon Nova Reelは動画生成に各々特化した安全で責任あるAI使用の仕組みが組み込まれたモデルとなっています。バージニア北部リージョンではこれら全てが利用できる他、オレゴン、オハイオの2つのリージョンでもクロスリージョン推論によりAmazon Nova Micro、Lite、Proの3つのモデルが利用可能です。詳細は ブログ や ドキュメント をご確認ください。 Amazon Bedrock Model Distillation is now available in preview Amazon Bedrock Model Distillationのプレビューが発表されました。小型のモデルを調整しユースケースに特化させることで、コスト効率や速いレスポンスを維持しつつ高性能なモデルと近しい精度を実現する方法をModel Distillation (モデル蒸留)と言います。Amazon Bedrock Model Distillation は、教師モデルと呼ばれる大規模言語モデルから特定のユースケースに合わせた合成データを生成するプロセスを自動化し、生成された応答を使って生徒モデルの小規模モデルのトレーニングと評価を行います。その結果出来上がる推論用の抽出モデルのホストし提供するものです。現時点ではバージニア北部とオレゴンでプレビュー利用可能です。詳細は ブログ と ドキュメント をご確認ください。 Amazon Bedrock Intelligent Prompt Routing is now available in preview Amazon Bedrock Intelligent Prompt Routingのプレビューが発表されました。この機能はリクエストに基づいて各モデルのパフォーマンスを予測することで回答の質を担保しつつ最もコストの低い応答が得られる可能性が高いモデルにリクエストを動的にルーティングするものです。今のところClaude 3.5 SonnetとClaude 3.5 Haikuの組み合わせ、もしくはLlama 3.1 8BとLlama 3.1 70Bの組み合わせでのルーティングを選択可能です。この機能はバージニア北部とオレゴンの2つのリージョンでプレビューとして利用できますが、現時点では英語のみサポートの点ご注意ください。詳細は ブログ と ドキュメント をご確認ください。 Amazon Bedrock announces preview of prompt caching Amazon Bedrockがプロンプトキャッシュをサポートしました。この機能は頻繁に入力されるプロンプトをキャッシュし、再処理を減らすものです。回答の処理速度を上げるだけでは無く、使用するリソースが減ることによりコスト削減も見込め、レイテンシーを最大85%、サポート対象モデルのコストを最大90%削減することが可能です。オレゴン、バージニア北部の2つのリージョンではClaude 3.5 Haiku と Claude 3.5 Sonnet v2 でクロスリージョン推論で利用可能な他、バージニア北部ではNova Micro、Nova Lite、Nova Proの各モデルで利用可能です。詳細は ブログ と ドキュメント をご確認ください。なおこの機能はプレビューのため、現時点では一部のお客様のみ利用可能です。プレビューの参加については 製品ページ からご確認ください。 Amazon Bedrock Model Evaluation now includes LLM-as-a-judge (Preview) ユースケースに最適な基盤モデルを評価、比較、選択できるAmazon Bedrock Model Evaluationに、新しい評価機能であるLLM-as-a-Judgeがプレビューとして追加されました。Amazon Bedrock Model Evaluationではこれまで、人間によるモデル評価か、文字列マッチングをはじめとしたNLPに関する評価が可能でした。今回追加されたLLMによる評価が可能になったことでより短い時間で、人が行うより低コストに、人間よる判断に近い評価を行うことが可能になりました。この機能は東京を含む13のリージョンでプレビューとして利用可能です。詳細については ブログ もご確認ください。 Amazon Bedrock Knowledge Bases now supports RAG evaluation (Preview) Amazon Bedrock Knowledge BasesがRAG評価機能のプレビューを発表しました。この機能はLLMによる評価(LLM-as-a-Judge)が採用されており、Bedrock Knowledge Basesで構築されたRAGアプリケーションに対して、コンテキストの関連性や対象範囲を検索に対して評価できる他、検索と生成に対して正確性や完全性、ハルシネーション検知などの品質指標およびAmazon Bedrock Guardrailsを評価に組み込んで有害性、回答拒否などの責任あるAIに関する指標を評価できます。LLMによる評価によって人が実施する場合に近しい精度でコストや期間を短縮でき、アプリケーションのリリースや改善に有効です。この機能は東京を含む11のリージョンでプレビュー利用可能です。詳細については ブログ もご確認ください。 Amazon Bedrock Marketplace brings over 100 models to Amazon Bedrock 100以上のモデルをBedrockで利用可能にするAmazon Bedrock Marketplaceが発表されました。この中には日本企業であるPreferred Networks、Stockmark、KARAKURIのモデルも含まれています。MarketplaceにあるモデルはSageMaker エンドポイントにデプロイし、BedrockのAPIを介してアクセスすることができます。これによりアプリ開発者はさまざまなモデルを独自の実装を最小限で組み込むことが可能になります。また、Converse APIと互換性のあるモデルはAgents, Knowledge Bases, GuardrailsなどのBedrockの機能も活用できます。この機能は東京を含む14のリージョンで利用可能です。詳細は ブログ や ドキュメント をご確認ください。 Amazon Bedrock Knowledge Bases now supports streaming responses Amazon Bedrock Knowledge Basesがストリーミングレスポンスをサポートしました。Amazon Bedrock Knowledge Basesは検索拡張生成(RAG)を構築する為のフルマネージド型の検索機能です。RAGの処理フローではデータストアへのクエリ、関連情報の収集、LLMによる要約などいくつかのステップを行うためレスポンスに時間がかかるケースがあります。今回新たにRetrieveAndGenerateStream APIが提供されたことで、完全な回答を待たずに、生成された応答を順次利用者にレスポンスすることができるようになり最初の応答までの待ち時間を減らし利用体験をより良くすることが可能になります。この機能はAmazon Bedrock Knowledge Basesがサポートされるすべてのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon Bedrock Knowledge Bases now processes multimodal data Amazon Bedrock Knowledge Basesがマルチモーダルデータをサポートし、画像、グラフ、表などを含めて洞察を得られる生成AIアプリケーションの構築ができるようになりました。今回のサポートによりBedrock Knowledge Basesはテキストとビジュアルデータの両方からコンテンツを抽出し、Embeddingsモデルを使用して生成した情報をベクトルストアに保存します。これにより、テキストだけでなくビジュアルデータからも導き出された質問に対する回答を取得して生成するのが容易になります。また、取得した結果にはビジュアルデータのソース属性が含まれるため、生成された出力の透明性と信頼性を高めます。構文解析にはプレビュー中のAmazon Bedrock Data Automation、もしくはClaude 3.5 SonnetやClaude 3 Haikuなどの基盤モデルのいずれかを選択できます。この機能はオレゴンリージョンでプレビューとして利用可能です。詳細は ドキュメント をご確認ください。 Amazon Bedrock Knowledge Bases now supports GraphRAG (preview) Amazon Bedrock Knowledge BasesのGraphRagサポートがプレビューとして発表されました。GraphRAGとは従来のベクトルデータベースの代わりに、ナレッジグラフを使用してドキュメントの知識を表現する手法です。Bedrock Knowledge Basesを作成時にベクトルデータの保存先としてAmazon Neptune Analyticsを選択することで、エンティティとその関係のグラフ表現とともに、ベクター埋め込みが自動的に生成され、保存されます。この機能は東京リージョンを含め、Amazon Bedrock Knowledge BasesとAmazon Neptune Analytics の両方が利用できるAWS リージョンで利用できます。詳細については ドキュメント もご確認ください。 Contact Center Amazon Connect launches generative AI-powered self-service with Amazon Q in Connect Amazon Q in Connectがエンドカスタマーと直接会話し、事前定義されていない曖昧なシナリオでもお客様に正確な回答を提供することができるようになりました。Q&Aサポートをはじめとして旅行の予約やローンの申し込み、病院の予約などのアクションを実行することが可能です。必要情報を聞き出すだけで無く、フォローアップ質問をして正しい答えを判断することも対応しています。Amazon Q in Connectは東京をはじめとする9つのリージョンでご利用いただけますが、現時点では英語のみ対応の点ご注意ください。詳細は ドキュメント をご確認ください。 Amazon Connect now supports external voice transfers Amazon Connectが他の音声システムと統合され、公衆電話網を使わずに音声通話やメタデータを直接転送できるようになりました。これにより既存コンタクトセンターや企業の音声システムを使いつつ、自動音声応答(IVR)の機能はAmazon Connectを使うことでパーソナライズや効率化により顧客体験を向上できます。この機能はバージニア北部とオレゴンの2つのリージョンで利用できます。詳細は ドキュメント をご確認ください。 Amazon Connect launches simplified conversational AI bot creation Amazon ConnectのUIから直接Amazon Lexの設定、設計ができるようになり、対話型AIボットの作成、編集、改善が容易になりました。ドラッグ&ドロップによりコーディング不要でボットを作成することが可能です。タッチトーンメニューをアップグレードして、顧客に名前で挨拶したり、追加のサポートオプションを提供したりするボットを簡単に作成可能です。機能はAmazon ConnectとAmazon Lexが利用できるすべてのAWSリージョンでご利用可能です。詳細については ドキュメント をご確認ください。 Amazon Connect Contact Lens launches built-in dashboards to analyze conversational AI bot performance Amazon Connect Contact Lensに、対話型AIボットのパフォーマンスをモニタリングするダッシュボードが追加されました。Amazon LexとQ in Connectのボット分析が可能で、顧客からの問い合わせ内容、理由、会話の結果などを確認できます。このダッシュボードから管理画面に移動し、即座に更新を行えるので精度向上のプロセスが簡素化されます。この機能はAmazon ConnectとAmazon Lexが利用できるすべてのAWSリージョンでご利用可能です。詳細については、 ドキュメント をご確認ください。 Amazon Connect now provides the ability to record audio during IVR and other automated interactions Amazon Connectが自動音声応答(IVR)やその他自動音声対話を行った時の音声録音をサポートしました。これによりセルフサービス対応の顧客体験の品質評価や監視、監査が容易になる他、コンプライアンス・ポリシー目的での記録も容易になります。この機能はフローデザイナー経由のGUIで簡単に設定することができるので、例えばクレジットカード番号などの機微な情報の入力を自動応答される際は、フローの設定で前後で一時停止・再開することも簡単に可能です。この機能はAmazon Connectが利用可能なすべてのAWS リージョンで利用できます。詳細については ドキュメント をご確認ください。 Management & Governance Amazon Web Services announces declarative policies AWS Organizationsが新しい管理ポリシータイプとして宣言型ポリシー(declarative policies)の一般提供を発表しました。宣言型ポリシーは、ポリシーに準拠しないアクションを防止するためのもので、例えば特定のプロバイダーが提供するAMIの未使用できるようにすることや、VPCのパブリックアクセスをブロックする等の設定を行えます。これらの適用状況は管理者が組織全体の設定を把握するためのステータスレポートから確認が可能です。また、カスタムエラーメッセージを設定できるので、利用者がポリシーでブロックされた操作を行った際に社内wikiやチケットシステムにリダイレクトすることも可能です。この機能は現時点ではEC2,EBS,VPCをサポートしており、他のサービスも今後サポートが予定されています。詳細については ブログ と ドキュメント をご確認ください。 Security, Identity, & Compliance AWS announces AWS Security Incident Response for general availability セキュリティイベントの準備、対応、復旧を支援する新しいサービス、AWS Security Incident Responseの一般提供が発表されました。このサービスはAmazon GuardDutyやAWS Security Hubの情報を元にセキュリティアラートを確認し、優先度の高い検出結果をお客様のセキュリティチームにエスカレーション、許可を得た上で封じ込めのアクションを実施するものです。これによりお客様のセキュリティ対応チームの時間を節約しより戦略的なミッションに注力いただけます。また、専門的な知識が必要な場合は24時間365日AWS Customer Incident Response Team (CIRT)に連絡できる他、コンソール上からセキュリティインシデントのケースの確認や対応数、解決までの時間などのメトリクスを確認可能です。現時点では英語のみサポートですが、東京を含む12のリージョンでご利用可能です。詳細については ドキュメント をご確認ください。 Amazon GuardDuty introduces GuardDuty Extended Threat Detection Amazon GuardDuty Extended Threat Detectionの一般提供が発表されました。この機能はAWS全体の規模でトレーニングされた人工知能と機械学習アルゴリズムを使用して、複数のリソース、データソースにわたる網羅的な攻撃検知を提供するものです。例えば認証情報の漏洩とそれに続くデータ漏洩などの攻撃の流れを特定して検出結果を表示します。検出結果にはインシデントの概要、詳細な時系列、MITRE ATT&CK®の戦術と手法へのマッピング、修復に際する推奨事項が含まれます。この機能はGuardDutyが利用可能なすべてのAWSリージョンで利用可能で、GuardDutyを利用するお客様に追加費用なしで自動的に有効になります。 AWS announces access to VPC resources over AWS PrivateLink AWS PrivateLinkがAWS Resource Access Manager(AWS RAM) を使用した任意のVPC リソース共有をサポートしました。これまでVPC リソースをAWS PrivateLinkで共有するにはNLBやGWLBを使用する必要がありました。今回の対応でRDSやドメイン名、IPアドレスなどを指定して共有が可能です。この機能は東京、大阪を含む21のリージョンでご利用いただけます。詳細については ブログ や ドキュメント をご確認ください。 最後に Part1 でもご紹介しましたが、re:Capイベントが予定されています。 週刊AWSでは扱えなかったアップデートも含めキャッチアップするチャンスですので、ぜひお申し込みください！ AWS re:Invent Recap – Keynote 編 2024 年 12 月 17 日（火）10:00-11:30 2024 年 12 月 19 日（木）14:00-15:30 2024 年 12 月 20 日（金）19:00-20:30 ※各日程で内容は同じです。いずれかをお選びください。 AWS re:Invent Recap – インダストリー編 2025 年 1 月 28 日（火）〜 1 月 30 日（木） ※期間内で業界ごとに時間帯が分かれています。 AWS re:Invent Recap – ソリューション編 2025 年 2 月 4 日（火）〜 2 月 7 日（金） ※期間内でソリューション領域ごとに時間帯が分かれています。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 先週は AWS re:Invent 2024 が開催されました。週刊AWSは、毎週の新発表を発表日ごとに纏めるというのがコンセプトなのですが、今週は re:Invent 2024 特別号として、サービスのカテゴリごとにまとめる形にしました。非常に多くのアップデートがあったので、できる限りお届けしたく今回は Part 1 （本稿）と、 Part 2 の二本立てになります。 re:Invent のアップデートに関しては12/6(金)に発表内容をほぼ全て網羅したセミナー「AWS Black Belt Online Seminar 2024年 AWS re:Invent 速報」も開催されています。こちらの 動画 と 資料 はすでに公開されていますので、ぜひご確認ください。 また、年明けの 2025年2月に re:Invent で発表された多くのアップデートを振り返る Recap イベントも開催いたします。以下のリンクからすでにお申し込みいただけますので是非ご参加ください！ AWS re:Invent Recap – Keynote 編 AWS re:Invent Recap – インダストリー編 AWS re:Invent Recap – ソリューション編 それでは まずは Part 1 を見ていきましょう。こちらでは以下のカテゴリについて取り扱います。 カテゴリリンク :  Analytics  |  Application Integration |  Compute |  Container |   Database  |  Developer Tools |  Storage AWS re:Invent 2024 期間に発表された主要アップデート Part 1 (2024/12/2週) Analytics Introducing the next generation of Amazon SageMaker データ、分析、AI の統合プラットフォームである次世代 Amazon SageMaker が発表されました。次世代 SageMaker には、 Amazon SageMaker Unified Studio (プレビュー) 、 Amazon SageMaker Lakehouse 、 Amazon SageMaker Data and AI Governance といった AI と分析に関する新機能が１つのプラットフォームに統合されています。SageMaker Lakehouse は複数のデータソースにまたがる統一するデータアーキテクチャを提供し、SageMaker Unified Studio でユースケースに最適なツールを使ってデータを発見し活用することができます。また、SageMaker Data and AI Governance によりデータと AI ワークフロー上にデータガバナンスを効かせながらデータコラボレーションが可能です。 Introducing AWS Glue 5.0 AWS Glue 5.0 の一般提供が開始されました。AWS Glue 5.0 では、Apache Spark 3.5.2、Python 3.11、Java 17 にエンジンがアップグレードされ、パフォーマンスとセキュリティの改善が行われています。また、Apache Hudi 0.15.0、Apache Iceberg 1.6.1、Delta Lake 3.2.0 へのオープンテーブルフォーマットのサポートもされており、データレイクにおけるコスト、ガバナンス、プライバシーに関する高度な要件のユースケースにも対応が望めます。そして、AWS Glue 5.0 は AWS Lake Formation との統合により、Amazon S3 データレイクでテーブル、列、行、セルレベルのアクセス制御の適用も可能となっています。 AWS Glue Data catalog now automates generating statistics for new tables AWS Glue Data Catalog でテーブルに対する統計情報を自動生成が可能になりました。これまで、AWS Glue Data Catalog の Apache Iceberg テーブルの統計情報を作成するには、テーブルの構成を継続的に監視し、更新する必要がありました。今回のアップデートにより、Lake Formation コンソールでテーブル統計情報を有効にし、AWS Glue Data Catalog のカタログ設定を行うと、新しいテーブルの統計情報が自動で生成されるようになります。新しいテーブルが作成されたり、既存のテーブルが更新されると、すべての列の行のサンプルを使って統計情報が生成され、定期的に更新されます。 Amazon OpenSearch Service zero-ETL integration with Amazon Security Lake Amazon OpenSearch Service は、Amazon Security Lake との統合により、セキュリティデータを直接クエリ分析できるようになりました。従来は分析コストが高額になりがちだった大量データソースへのクエリ分析でしたが、この統合により、効率的なセキュリティ調査、そしてセキュリティ環境の包括的な可視化が可能となります。データの選択的な取り込みも可能で、複雑なデータパイプラインを管理する必要がないため、セキュリティオペレーションにより集中でき、分析の効率とコストを最適化できます。 AWS Clean Rooms now supports multiple clouds and data sources AWS Clean Rooms が、Snowflake や Amazon Athena に保存されているデータセットとの連携をサポートしました。このアップデートにより、企業のデータセットの移動、公開、コピーといった作業をすることなく、AWS (Athena経由) や Snowflake を利用している企業のデータセットを、シームレスに連携できるようになります。例えば、Amazon S3 にデータを保存しているメディア出版社と、Snowflake にデータを保存している広告主は、 抽出、変換、ロード不要 (zero-ETL)でコラボレーションできるようになり、既存の環境からデータセットを移行する際のコストと複雑さが排除されます。 Announcing scenarios analysis capability of Amazon Q in QuickSight (preview) Amazon Q in QuickSight でシナリオ分析の新機能がプレビューとして利用可能になりました。自然言語で質問したり、目標を入力すると、Amazon Q in QuickSight が高度なデータ分析をわかりやすくガイドします。分析アプローチを提案、データを自動的に分析、関連する洞察を提示し、そしてそれらの対応策とともに結果をまとめるというフローをステップごとに Amazon Q が対応します。この新機能により、AI アシストによる効率的なデータ分析体験を提供し、ビジネスユーザーが複雑なシナリオ分析する際、スプレッドシートの最大10倍の速さでの分析を可能とし、そして意思決定を行えるようにサポートします。このシナリオ分析機能は Amazon QuickSight のダッシュボードから利用できます。より詳細な情報は ユーザガイド や ブログ記事 をご参照ください。 Application Integration Amazon SageMaker Lakehouse and Amazon Redshift support for zero-ETL integrations from eight applications Amazon SageMaker Lakehouse と Amazon Redshift は、Salesforce、SAP、ServiceNow、Zendesk などの 8 つのアプリケーションからの zero-ETL 統合をサポートしました。この新しい zero-ETL 統合により、カスタマーサポート、CRM、ERP 等のアプリケーションからデータを効率的に抽出してデータレイクとデータウェアハウスで分析を行うことができます。また、データパイプラインの設計、構築、テストに必要な数週間の工数を節約でき、アプリケーションデータの分析に集中できます。 Compute Amazon EC2 Trn2 instances are generally available AWS Trainium2 チップを搭載した Amazon EC2 Trn2 インスタンスの一般提供と、Trn2 UltraServers のプレビューを発表しました。Trn2 インスタンスには16個の Trainium2 チップが搭載されており、最大20.8ペタフロップスの FP8 演算性能 により、大規模言語モデル(LLM)、マルチモーダルモデル、拡散トランスフォーマーなどの要求が高い基盤モデルをトレーニング、デプロイして、幅広い AI アプリケーションを構築に活用できます。Trn2インスタンスは、 EC2 Capacity Blocks for ML を介した US East (オハイオ)リージョンで、trn2.48xlarge サイズが一般提供されています。Trn2 UltraServers には64個のTrainium2 チップが搭載されており、最大83.2ペタフロップスの FP8 演算性能により、リアルタイムでの優れた応答時間を実現します。UltraServers はスタンドアロンインスタンスと比較して、トレーニングにおけるモデル並列化のための集合通信を高速化することで、モデルトレーニングの速度と効率を向上させます。 Announcing Amazon Elastic VMware Service (Preview) Amazon Elastic VMware Service (Amazon EVS) のプレビューを発表しました。Amazon EVS は、AWS 上で使用可能な VMware Cloud Foundation (VCF) 環境を提供し、デプロイを自動化・簡素化します。これにより、オンプレミス環境ですでに使用している同じ VCF ソフトウェアとツールを使用することができ、VMware ベースの仮想マシンを AWS に迅速に移行できます。Amazon EVS は現在、選定された顧客とパートナー向けにプレビュー提供となっております。Amazon EVS の詳細は こちらのサービスページ をご確認ください。 Announcing Amazon EC2 I8g instances Amazon Elastic Compute Cloud (Amazon EC2) のストレージ最適化インスタンスI8g の一般提供が開始されました。I8gインスタンスは、前世代の I4gインスタンスと比較して最大60%の高いコンピューティングパフォーマンスを実現する AWS Graviton4 プロセッサを搭載しており、Amazon EC2 でのストレージ集約型ワークロードに対して 最高のパフォーマンスを提供します。また、最新の第3世代 AWS Nitro SSD を使用しており、TB あたり最大65%の高いストレージパフォーマンスを提供しながら、ストレージI/Oレイテンシを最大50%、ストレージI/Oレイテンシの変動を最大60%低減します。I8gインスタンスは、米国東部(バージニア北部)と米国西部(オレゴン)のAWSリージョンで利用可能です。 Amazon EC2 introduces Allowed AMIs to enhance AMI governance AWS アカウント内における Amazon Machine Image (AMI) の検出と使用を制御する「Allowed AMIs」設定が追加されました。これまで、信頼性や出所に関係なく公開されている AMI を使用できたため、組織のコンプライアンス要件を満たさない AMI を誤って使用するリスクがありました。Allowed AMIs の設定により、管理者は AWS アカウント内で利用許可の対象となる AMI の所有者アカウント、もしくは所有者エイリアスを指定することできます。それにより指定された所有者の AMI のみが表示され、許可されたAMIを利用して、EC2 インスタンスを起動することができます。許可されていない AMI を使用して起動された EC2 インスタンスを特定するための監査モード機能もあり、設定を適用する前に非準拠のインスタンスを特定することもできます。 Container Announcing Amazon EKS Auto Mode AWSはAmazon Elastic Kubernetes Service (Amazon EKS) Auto Mode が発表されました。EKS Auto Modeによって、Kubernetes クラスターのコンピューティング、ストレージ、ネットワーク管理を自動化することができます。EKS Auto Mode では、新規もしくは既存のEKSクラスターに対して、Kubernetes に準拠したマネージドのコンピューティングリソース、ネットワーク、ストレージを利用するため、最適なコンピューティングインスタンスを選択し、リソースを動的にスケーリングし、継続的にコストを最適化します。また、AWS セキュリティサービスと統合し、オペレーティングシステムにパッチを適用したりと、継続的なメンテナンスの作業効率を高めることもできます。ただし、EKS Auto Mode によって管理されるインスタンスに直接アクセスしたり、ソフトウェアをインストールしたりすることはできまませんのでご注意ください。EKS Auto Mode に関するより詳細な情報は ユーザガイド や ブログ記事 をご参照ください。 Announcing Amazon EKS Hybrid Nodes Amazon Elastic Kubernetes Service (Amazon EKS) Hybrid Nodes の一般提供を開始しました。Amazon EKS Hybrid Nodes を使用すると、オンプレミスおよびエッジ環境で実行される Kubernetes アプリケーションを、AWS 上の Amazon EKS クラスターのノードとして管理することができます。 それにより、アプリケーションが実行される場所に関わらず、Amazon EKS の効率性、スケーラビリティ、可用性をもたらし、さらに低レイテンシー、ローカルデータ処理、規制、ポリシーといった要件を満たすこと可能となります。2024年12月現在、Amazon EKS Hybrid Nodes は新規の Amazon EKS クラスターでご利用いただけます。Amazon EKS Hybrid Nodes に関するより詳細な情報は ユーザガイド や ブログ記事 をご参照ください。 Database Announcing Amazon Aurora DSQL (Preview) アクティブ・アクティブの高可用性を備えたサーバーレスの分散SQLデータベース、Amazon Aurora DSQL (プレビュー)を発表しました。Aurora DSQLは、PostgreSQL と互換性があり、独立してスケーリングする読み取り処理、書き込み処理、コンピューティング、ストレージを提供することで、無制限の水平スケーリングを実現します。アクティブ・アクティブの分散アーキテクチャは、シングルポイントの障害がなく、自動フェイルオーバーの復旧により、シングルリージョンで99.99%、マルチリージョンで99.999%の可用性を実現するよう設計されています。これにより、どのリージョンのエンドポイントに対する読み取りも書き込みも強力な一貫性と耐久性が保証されます。現在、Aurora DSQL は、米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)の AWSリージョンでプレビューとして提供しています。Amazon Aurora DSQL に関するより詳細な情報は サービスページ や ユーザガイド をご参照ください。 Amazon DynamoDB global tables previews multi-Region strong consistency Amazon DynamoDB グローバルテーブルがマルチリージョンにおける強い一貫性をプレビューとしてサポートしました。このマルチリージョンの強い一貫性の設定により、グローバルテーブルの任意のリージョンから常に最新のデータを読み取ることができ、複数のリージョンにまたがる整合性の管理に関する無駄な作業が不要になります。また、リカバリポイント目標(RPO)ゼロでの高可用性のマルチリージョンアプリケーションを構築できるようになり、最高レベルの回復力を実現できます。DynamoDB グローバルテーブルのマルチリージョン強い一貫性の設定は、米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)のリージョンでプレビューとして利用可能です。より詳細な情報は ユーザガイド をご参照ください。 Oracle Database@AWS is now in limited preview Oracle Database@AWS がリミテッドプレビューとして提供開始しました。このサービスにより、 AWS データセンター内の Oracle Cloud Infrastructure (OCI) 管理下の Exadata インフラストラクチャ上で Oracle Database サービスにアクセスできるようになります。また、Oracle Real Application Clusters (RAC) ワークロードを含む Oracle Database ワークロードを、最小限の変更で AWS 内の Oracle Exadata Database Service に簡単かつ迅速に移行することが可能です。Oracle Database@AWS は、米国東部 (バージニア北部) でリミテッドプレビューとして利用可能で、2025年内に追加の AWS リージョンでも利用可能になる予定です。Oracle Database@AWS に関するより詳細な情報は サービスページ や ユーザガイド をご参照ください。 Amazon Aurora now available as a quick create vector store in Amazon Bedrock Knowledge Bases Amazon Aurora PostgreSQL Serverless が Amazon Bedrock Knowledge Bases のクイック作成対象のベクトルストアとして選択できるようになりました。新しいクイック作成の Aurora オプションにより、生成 AI アプリケーションを構築する開発者やデータサイエンティストは、ワンクリックで Aurora PostgreSQL をベクトルストアとして選択し、pgvector が事前設定された Aurora Serverless クラスターを数分で展開できます。Aurora Serverless はオンデマンドの自動スケーリング構成で、アプリケーションの需要に基づいて容量が自動調整されるため、開発者向けベクトルストアとして理想的です。より詳細な情報については ユーザガイド をご参照ください。 Developer Tools Amazon Q Developer can now automate code reviews , generate unit tests , and generate documentation within your source code Amazon Q Developer でコードレビューの実行、ユニットテストの自動生成、コードのドキュメント化が可能になりました。コードレビューは、IDEでコードにコメントを自動的に付与し、疑わしいコードパターンをフラグ付けし、利用可能なパッチの提供、さらにはデプロイリスクを評価することで、コードに対するフィードバックを迅速に得ることができます。また、単体テストの生成プロセスを自動化するエージェントは、”/test” プロンプトを使用して簡単に開始でき、プロジェクトの知識を使用して自動的にテストを生成し、プロジェクトに追加して、コード品質を迅速に向上させます。自動ユニットテスト生成機能は、Visual Studio Code および JetBrains の統合開発環境(IDE) で一般提供、そして新しい GitLab Duo with Amazon Q ではプレビュー機能として提供され、Amazon Q Developer が利用可能なすべての AWS リージョンで利用できます。そして、プロジェクト内のコードリポジトリよりReadme ファイルやデータフロー図など自動生成してくれるドキュメント化の機能を活用することで、機能開発に集中できます。それぞれの機能の詳細は ブログ記事 をご参照ください。 Announcing Amazon Q Developer transformation capabilities for VMware (Preview) , for .NET porting (Preview) , and for mainframe modernization are now available (Preview) Amazon Q Developer で VMware、.NET porting、そして メインフレームにおける変換機能をプレビューとして発表しました。Transformation capabilities for VMware は VMware ワークロードを Amazon Elastic Compute Cloud (EC2) に移行、モダナイズするための生成 AI アシスタントで、複雑な VMware の変換タスクを合理化し、VMware ワークロードをクラウドに移行するために必要な時間と労力を削減できます。米国東部(バージニア北部)のAWSリージョンでプレビューとして利用可能です。Transformation capabilities for .NET porting は .NETFramework アプリケーションを Linux のクロスプラットフォーム .NET に移植できる変換機能です。従来の方法に比べて、最大1/4の時間での Windows の .NET アプリケーションを Linux へのモダナイズ、そしてライセンスコストの最大40%削減が期待できます。Transformation capabilities for mainframe modernization は自動的にアプリケーションアセットを分類・整理し、包括的なコード文書を作成して、組織の知識ベースを理解・拡張します。エージェントは生成 AI とモダナイゼーションの専門知識を使って推論を行い、コードベースと変換目標に合わせたモダナイゼーション計画を立案します。計画を承認すると、Amazon Q Develope エージェントは自動的に COBOL コードをビジネスロジックを保ったまま、クラウド最適化された Java コードにリファクタリングします。それぞれの機能の詳細は ブログ記事 をご参照ください。 Storage Announcing Amazon S3 Tables – Fully managed Apache Iceberg tables optimized for analytics workloads Apache Iceberg が標準サポートのデータ分析用途に最適化された Amazon S3 Tables が発表されました。S3 Tables は分析ワークロードにおいて、自己管理型のテーブルと比較して最大3倍の高速なクエリスループットと最大10倍の高いトランザクション/秒を実現します。Apache Iceberg を標準サポートしているため、Iceberg をサポートしている AWS のAnalytics サービスおよびサードパーティのクエリエンジンで利用することができます。S3 Tables はデータレイクの規模が拡大・進化しても、継続的なテーブル保守を行い、クエリの効率とストレージコストを自動的に最適化するよう設計されています。Amazon S3 Tables は現在、米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)リージョンで利用可能です。より詳細な情報は ユーザガイド や ブログ記事 をご参照ください。 Announcing Amazon S3 Metadata (Preview) – Easiest and fastest way to manage your metadata Amazon S3 Metadata (プレビュー)が発表されました。Amazon S3 バケットにオブジェクトを配置すると、そのオブジェクトのメタデータを自動的にキャプチャし、S3 Tables に格納することでクエリ応答に利用できようになります。これまで、S3 inventory を取得して、そこから情報をAthenaで抽出したり、別途 DynamoDB などに仕組みを作ってメタデータを管理する必要がありましたが、この機能によって、メタデータの管理を自動化し、作業の効率化が可能です。バケットのデータが変更されると、S3 Metadata はテーブルを数分以内に更新して最新の変更を反映します。現在、米国東部(バージニア北部)、米国東部(オハイオ)、米国西部(オレゴン)リージョンでプレビュー提供中です。より詳細な情報は ユーザガイド をご参照ください。 Amazon S3 Access Grants now integrate with AWS Glue Amazon S3 Access Grants が AWS Glue 5.0と統合されました。S3 Access Grants は、Entra ID や Okta などの IDプロバイダー (IdP) または AWS Identity and Access Management (IAM) プリンシパルからの ID を、Amazon S3 に保存されているデータセットにマッピングし、S3 バケットやプレフィックスを使った権限管理とアクセス取得が可能となるものです。この統合により、バケットポリシーや個別の IAMロールを作成および管理する必要がなく、IdPを軸に Glue データカタログを利用するユーザのビジネス上の役割分担と、オブジェクトへのアクセスを揃えた権限管理が可能となります。Amazon S3 Access Grants は、AWS Glue 5.0 以降を使用する場合に利用でき、AWS Glue 5.0 および AWS IAM Identity Center が提供されているすべての商用AWS リージョンで利用可能です。 Storage Browser for Amazon S3 is now generally available S3 に保存されているデータに対してユーザーが容易に Web アプリケーションを通してアクセスできるようにするオープンソースコンポーネント「Storage Browser for S3」の一般提供を発表しました。Storage Browser for S3 により、お客様、パートナー、従業員といった認可されたエンドユーザーに、自社アプリケーションから直接 S3 内のデータの参照、ダウンロード、アップロードを簡単に行えるようになります。Storage Browser for S3 は、AWS Amplify React および JavaScript クライアントライブラリで利用可能です。さらに、Storage Browser for S3 は、エンドユーザーがアップロードするデータのチェックサムを自動計算し、この耐久性チェックを通過しない要求をブロックします。より詳細な情報は ブログ記事 をご参照ください。 それでは、引き続き Part 2 もお楽しみください。 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

Amazon Aurora データベースの監視がはるかに簡単になりました。テレメトリの設定、ダッシュボードの構築、アラームの設定に時間を費やす代わりに、必要なのは Amazon CloudWatch Database Insights を開いて確認することだけです。それ以上設定することなく、選択したリージョンのすべての Amazon Aurora MySQL および PostgreSQL インスタンスの正常性をモニタリングできます: 各セクションには豊富な詳細が含まれており、すぐに言及します (これは究極の「 But Wait, There’s More! 」(でも待ってください、まだあります) 記事かもしれません)。このビューから、左側のフィルターコントロールを開いて、いくつかの方法でインスタンスのセットをフィルタリングできます。例えば、Amazon Aurora MySQL を実行しているすべてのインスタンスをフィルタリングすると、そのようなインスタンスが 66 個あり、アラームが 3 つ発生していることがわかります: フィルターをフリートとして保存できます (フリートはデータベースインスタンスの特定のプロパティとタグによって定義されるため、本質的に動的です): その後、クリックすると、フリートの全体的な状態を確認できます。ページ全体が更新されてフリートが反映されるので、概要を確認します: 舞台裏では、Database Insights は DBInstanceIdentifier ディメンションを含む CloudWatch アラームを探し、これらのアラームを使用してデータベースインスタンスとアラームの相関関係を確立します。これと他の組み込みヒューリスティックおよび相関関係のステップにより、Database Insights は、ユーザーがフリートの全体的な状態をより良く理解し、ボトルネックや他の問題を見つけるために深く掘り下げるのに役立つ、整理された有益な情報を提供できます。 インスタンス (六角形で表されます) をクリックすると詳細が表示されます。インスタンス名 ( demo-mysql-reader0 ) をクリックすると詳細が表示されます: インスタンスごとのビューでも、さまざまな詳細を確認できます: 下部にある各タブは、データベースインスタンス内で何が起こっているのかについての追加のインサイトを提供します。例えば、 [DB 負荷分析] / [上位の SQL] / [SQL メトリクス] を選択すると、最も負荷の高い SQL ステートメントと、29 個の追加メトリクス (表示されていません) が表示されます: 私は過去の経験から、スロークエリを見つけて理解することは面倒ではあるものの、重要な作業であることを知っています。Database Insights を使用すると、スロークエリに共通するパターンと実際のクエリを確認できます: AWS X-Ray 、 Application Signals 、および AWS Distro for OpenTelemetry SDK の助けを借りて、データベースインスタンスに対するクエリの発信元となるサービスとオペレーションを確認できます: 赤い X は、このオペレーションが、関連付けられた サービスレベル目標 (SLO) を満たしていないことを示しています。SLO は、 Application Signals のアプリケーションパフォーマンスモニタリングの側面です。SLO は、顧客の期待に対するサービスの信頼性を定義し、サービスを選択して [SLO を作成] をクリックすることで設定できます。いくつかのステップと非常に役立つオプションがありますが、基本的に SLO は、一定期間にわたる成功したリクエストの割合として測定されます: データベースインスタンスが CloudWatch Logs にログを送信するように設定されている場合、選択した期間で、かつ、特定のロググループ内でフィルタリングされたログを表示および検索できます: フリートレベルでは、さらに詳しく調べることができます。例えば、最も高い DB 負荷を発生させる 10 個の呼び出しサービスを確認できます (繰り返しになりますが、これは、 AWS X-Ray 、 Application Signals 、および AWS Distro for OpenTelemetry SDK ) を利用しています: また、8 つの異なるメトリクスのいずれかに関して、上位 10 個のインスタンスを確認できます: 1 日中説明し続けることもできますが、残りは皆さんご自身で探索していただくことにしましょう。何度もお伝えしますが、この機能は今すぐ使用可能であり、今日から使用を開始できます。 知っておくべきこと Database Insights についていくつか知っておくべきことを次に示します: サポートされているデータベース – Database Insights は、Amazon Aurora MySQL および Amazon Aurora PostgreSQL データベースインスタンスで使用できます。 料金 – 使用される vCPU の平均数 (プロビジョンドインスタンスの場合) またはモニタリングされる Aurora Capacity Units (Serverless v2 データベースの場合) に基づいて、1 時間あたり、データベースインスタンスごとに課金されます。データベースログの取り込みと保存には別途料金がかかります。詳細については、「 CloudWatch の料金 」ページをご覧ください。 リージョン – この機能は、すべての商用 AWS リージョンでご利用いただけます。 – Jeff ; 原文は こちら です。

12 月 1 日、 Amazon Web Services (AWS) は、 Amazon CloudWatch と Amazon OpenSearch Service 間の新しい統合分析エクスペリエンスとゼロ ETL 統合を発表しました。この統合により、ログデータの分析とビジュアライゼーションがデータの重複なしで簡素化され、ログ管理が合理化されるとともに、技術的なオーバーヘッドと運用コストが削減されます。CloudWatch Logs をご利用のお客様は、 CloudWatch Logs Insights QL に加えて 2 つの追加クエリ言語にアクセスできるようになりました。一方、OpenSearch をご利用のお客様は、別の抽出、変換、ロード (ETL) パイプラインを作成することなく、CloudWatch ログをインプレースでクエリできます。 組織では、ログデータのためにさまざまな分析機能が必要になることがよくあります。一部のチームは、すべてのシステム、アプリケーション、 AWS サービス からのログを一元化する際のスケーラビリティとシンプルさを理由として、CloudWatch Logs を好みます。高度な分析とビジュアライゼーションを理由として OpenSearch Service を必要とするチームもあります。以前は、これらのサービス間の統合では、個別の取り込みパイプラインを維持するか、または ETL プロセスを作成する必要がありました。この新しい統合は、データのコピーなしで OpenSearch 分析の力を CloudWatch Logs に直接もたらすことで複雑さを排除するため、お客様は両方のサービスを最大限に活用するのに役立ちます。 Amazon CloudWatch Logs は、 OpenSearch Piped Processing Language (PPL) と OpenSearch SQL を CloudWatch Logs Insights コンソール内で直接サポートするようになりました。SQL を使用してデータを分析し、JOIN を使用してログを相関させることができます。直感的なログ分析のために、SQL 関数 (JSON 関数、数学関数、日時関数、文字列関数など) を使用できます。また、OpenSearch PPL を使用して、データをフィルタリング、集計、分析することもできます。数回クリックするだけで、 Amazon Virtual Private Cloud (VPC) 、 AWS CloudTrail 、 AWS WAF などの、Vended Logs 用のすぐに使用できる事前構築済みダッシュボードにアクセスできます。 これらのダッシュボードを使用すると、個々のウィジェットを設定したり、特定のクエリを作成したりすることなく、時間の経過に伴うフロー、トップトーカー、メガバイト、時間の経過に伴う転送パケットの分析などのビジュアライゼーションを通じて、より迅速なモニタリングとトラブルシューティングが可能になります。時間の経過に伴う VPC フローの分析、トップトーカーの特定、ネットワークトラフィックのメトリクスの追跡、AWS WAF でのウェブリクエストの傾向のモニタリング、AWS CloudTrail での API アクティビティパターンの分析を行うことができます。 さらに、OpenSearch Service のユーザーは、OpenSearch Discover を使用して CloudWatch ログを分析し、SQL と PPL を実行できるようになりました。これは、 Amazon Simple Storage Service (Amazon S3) でデータを分析する方法に似ています。また、ETL オペレーションや個別の取り込みパイプラインなしで、インデックスを構築してダッシュボードを直接作成できます。 この統合の仕組みを詳しく見てみましょう CloudWatch の新しい OpenSearch SQL および PPL クエリ機能のデモを行うために、 CloudWatch コンソール から始めます。ナビゲーションペインで、 [ログ] 、 [Logs Insights] の順に選択します。 クエリのためにロググループを選択した後、追加の設定や統合なしで、 OpenSearch PPL または OpenSearch SQL クエリ言語を CloudWatch Logs Insights 内で直接使用できるようになりました。この新しい機能を使用すると、使い慣れた SQL 構文または OpenSearch PPL を使用して複雑なクエリを記述できるため、ログ分析がより直感的で効率的になります。 [クエリコマンド] メニューには、使用を開始するのに役立つ サンプルクエリ があります。 この例では、SQL JOIN を使用して、ペットの譲り受けとペットの譲受可能性という 2 つのロググループのデータを結合する方法を示します。特定の顧客 ID でフィルタリングすることで、トラブルシューティングのために関連するログレコードとトレース ID を分析できます。 CloudWatch Logs のお客様向けのこの統合の強力な機能の 1 つは、Amazon VPC フロー、AWS CloudTrail、AWS WAF ログ用の事前構築済みダッシュボードを作成できることです。AWS WAF ログ用のダッシュボードを作成することで、これを詳しく見てみましょう。 [OpenSearch で分析] タブで、 [設定] を選択し、ステップに従います。 数分後、統合の準備が整います。 [OpenSearch ダッシュボードを作成] に進みます。 [自動ダッシュボードタイプを選択] オプションで、AWS WAF ログを選択します。 [ダッシュボードデータ設定] タブの [データ同期頻度] で、15 分ごとに実行するように選択できます。 [ロググループを選択] し、 [選択したロググループのログサンプルを表示] します。最後に、 [ダッシュボードを作成] を選択します。 ダッシュボードを作成したら、ログを調べることができます。AWS WAF ログダッシュボードは、ウェブアプリケーションファイアウォールのメトリクスとイベントを包括的に可視化し、セキュリティパターンのモニタリングと分析に役立つ自動設定されたビジュアライゼーションを提供します。 同様に、CloudTrail ダッシュボードは、AWS 環境全体の API アクティビティに関する詳細なインサイトを提供します。API アクティビティのモニタリング、アクションの監査、潜在的なセキュリティまたはコンプライアンスの問題の特定に役立ちます。 VPC フローログダッシュボードは、ネットワークトラフィック分析のために、ログからの主要なメトリクスの詳細なビジュアライゼーションを提供します。ネットワークトラフィックを分析し、異常なパターンを検出して、リソースの使用状況をモニタリングできます。ダッシュボードは現在、VPC v2 フィールド (デフォルト形式) のみをサポートしています。カスタム形式のフィールドはサポートされていません。 OpenSearch Services から CloudWatch データにアクセスするためにゼロ ETL を使用すると、ETL プロセスを構築して維持することなく、 OpenSearch Service コンソール から OpenSearch ダッシュボードを構築することもできます。そのためには、 [一元管理] に移動し、新しい [接続されたデータソース] メニューを選択して、 [接続] をクリックして新しい接続されたデータソースを作成し、 [CloudWatch Logs] を選択します。 次のステップでは、データソースに名前を付け、 [新しいロールを作成] を選択します。このロールには、OpenSearch Service でアクションを実行するために必要な許可が必要です。これらは、 [サンプルカスタムポリシー] で確認できます。 [OpenSearch を設定] ステップで、 [新しいコレクションを作成] を選択することで、CloudWatch Logs のために OpenSearch データ接続を設定します。CloudWatch Logs ソースの設定の一環として、インデックス付きビューを保存し、CloudWatch Logs データを分析するためのユーザーインターフェイスを提供する新しい OpenSearch Service サーバーレスコレクションと OpenSearch UI アプリケーションが作成されます。新しいコレクションを作成して名前を付け、アプリケーション内で OpenSearch アプリケーションとワークスペースを設定します。 [データ保持] 日数を設定したら、 [次へ] を選択し、 [確認して接続] で終了します。 CloudWatch との統合の準備ができたら、 [データをインデックス化せずにログを詳しく見る] (これを選択すると、Discover のクエリインターフェイスに移動します) または (Amazon VPC Flows、CloudTrail、AWS WAF ログのためにダッシュボードを作成することによって) [Vended Logs を詳しく見る] を選択できます。 [ログを詳しく見る] を選択すると、OpenSearch UI によって、データソースの設定中に作成したアプリケーションワークスペースの Discover に移動します。 [Discover] で、データピッカーを選択し、CloudWatch Logs データソースとロググループにアクセスするために [使用可能なすべてのデータを表示] を選択します。 ロググループを選択すると、アプリケーションを切り替えることなく、Discover で直接 OpenSearch SQL と PPL を使用して CloudWatch ログを分析できます。 ダッシュボードを作成するには、コンソールの [接続されたデータソース] の概要ページに戻ります。そこから [ダッシュボードを作成] を選択します。これにより、CloudWatch コンソールで以前行ったように、クエリを定義したり、ビジュアライゼーションを構築したりすることなく、CloudWatch データを視覚的に分析できます。 ダッシュボードが作成された後、 OpenSearch リソースに移動すると、新しく作成されたインデックスに [コレクション] のデータが入力されていることを確認します。データを取得したら、設定で選択した CloudWatch ログのデータを含むダッシュボードに移動できます。さらにデータが取得されると、OpenSearch ダッシュボードにほぼリアルタイムで表示されます。 このゼロ ETL 統合により、データ整合性を維持し、運用オーバーヘッドを削減しながら、強力なクエリ機能とビジュアライゼーション機能を使用してデータを直接 OpenSearch に取り込むことができます。 統合のハイライト CloudWatch をご利用のお客様の場合: クエリ機能 – CloudWatch Logs Insights コンソール内で直接 OpenSearch SQL および PPL クエリを使用することによって、ログ調査を効率化します。 分析機能 – 数回クリックするだけで、VPC、AWS WAF、CloudTrail ログなどの Vended Logs 用の、すぐに使用できる事前構築済みダッシュボードにアクセスできます。これらのダッシュボードを使用すると、個々のウィジェットを設定したり、特定のクエリを作成したりすることなく、時間の経過に伴うフロー、トップトーカー、メガバイト、時間の経過に伴う転送パケットの分析のためのビジュアライゼーションを通じて、より迅速なモニタリングとトラブルシューティングが可能になります。 CloudWatch ユーザー向けの開始方法 – CloudWatch Logs から OpenSearch Service への統合を設定します。詳細については、 Amazon CloudWatch Logs のクエリ機能 および Amazon CloudWatch Logs の Vended ダッシュボード のドキュメントをご覧ください。 OpenSearch Service をご利用のお客様の場合: ゼロ ETL 統合 – ETL プロセスを構築または維持することなく、OpenSearch Service から直接 CloudWatch データにアクセスして分析します。この統合により、個別の取り込みパイプラインが不要になり、データ管理が簡素化され、データの重複がなくなるため、ストレージコストと運用オーバーヘッドが削減されます。 OpenSearch ユーザー向けの開始方法 – OpenSearch Service からデータソースとして CloudWatch を選択してデータ接続を作成します。詳細については、「 Amazon OpenSearch Service デベロッパーガイド 」をご覧ください。 利用可能なリージョンと料金 この統合は、 Amazon OpenSearch Service ダイレクトクエリ が使用可能な AWS リージョン でご利用いただけるようになりました。料金の詳細と無料トライアルに関する情報については、「 Amazon CloudWatch 料金表 」および「 Amazon OpenSearch Service の料金 」ページにアクセスしてください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。本記事においては、スクリーンショット、技術ガイダンス、両サービスの専門知識の共有といった寛大なご協力をいただいた Joshua Bright 、 Ashok Swaminathan 、 Abeetha Bala 、 Calvin Weng 、 Ronil Prasad に感謝の意を表します。これらのご協力により、この統合の概要についての記事を作成することができ、包括的なものとなりました。 – Eli 原文は こちら です。