AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3668ä»¶

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 原文は こちら です。