TECH PLAY

AWS

AWS の技術ブログ

å…š3139ä»¶

12 月 3 日、デヌタ、分析、AI の統合プラットフォヌムである、次䞖代の Amazon SageMaker に぀いおお知らせしたす。たったく新しい SageMaker には、デヌタ探玢、準備ず統合、ビッグデヌタ凊理、高速 SQL 分析、 機械孊習 (ML) モデルの開発ずトレヌニング、 生成 AI アプリケヌション開発に必芁なほずんどすべおのコンポヌネントが含たれおいたす。 珟圚の Amazon SageMaker は Amazon SageMaker AI に名称倉曎されたした。SageMaker AI は次䞖代 SageMaker に統合されるだけでなく、AI および ML モデルの倧芏暡な構築、トレヌニング、デプロむに特に泚力したいず考えおいるナヌザヌ向けのスタンドアロンサヌビスずしおも利甚できたす。 新しい Amazon SageMaker のハむラむト 䞭栞ずなるのは、単䞀のデヌタおよび AI 開発環境である SageMaker Unified Studio (プレビュヌ) です。珟圚の Amazon Athena 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (MWAA) 、既存の SageMaker Studio の幅広いスタンドアロンの「スタゞオ」、ク゚リ゚ディタ、ビゞュアルツヌルの機胜ずツヌルがたずめられおいたす。たた、生成 AI アプリケヌションを構築およびカスタマむズするために、Amazon Bedrock Studio のアップデヌトバヌゞョンである Amazon Bedrock IDE (プレビュヌ) を統合したした。さらに、 Amazon Q は SageMaker のワヌクフロヌ党䜓にわたっお AI による支揎を提䟛したす。 䞻な機胜は次のずおりです。 Amazon SageMaker Unified Studio (プレビュヌ) – 分析ず AI のためのすべおのデヌタずツヌルを単䞀の環境で構築できたす。 Amazon SageMaker Lakehouse – Amazon SageMaker Lakehouse を䜿甚しお、 Amazon Simple Storage Service (Amazon S3) デヌタレむク、Amazon Redshift デヌタりェアハりス、サヌドパヌティヌずフェデレヌテッドデヌタ゜ヌスのデヌタを統合したす。 デヌタず AI ガバナンス – Amazon DataZone 䞊に構築された Amazon SageMaker Catalog を䜿甚しお、デヌタず AI を安党に発芋、管理し、共同䜜業を行うこずができたす。 デヌタ凊理 – Amazon Athena、Amazon EMR、AWS Glue のオヌプン゜ヌスフレヌムワヌクを䜿甚しお、分析ず AI のためのデヌタを分析、準備、統合したす。 モデル開発 – Amazon SageMaker AI でフルマネヌゞド型のむンフラストラクチャ、ツヌル、ワヌクフロヌを䜿甚しお、ML ず 基盀モデル (FM) を構築、トレヌニング、デプロむしたす。 生成 AI アプリケヌション開発 – Amazon Bedrock を䜿甚しお、生成 AI アプリケヌションを構築およびスケヌルしたす。 SQL 分析 – 最もコストパフォヌマンスに優れた SQL ゚ンゞンである Amazon Redshift を䜿甚しお、むンサむトを埗るこずができたす。 この投皿では、新しい SageMaker Unified Studio ゚クスペリ゚ンスず、デヌタ凊理、モデル開発、生成 AI アプリ開発を開始する方法を簡単にご玹介したす。 Amazon SageMaker Unified Studio (プレビュヌ) での䜜業 SageMaker Unified Studio では、䜿い慣れた AWS ツヌルを䜿甚しおデヌタを発芋し、掻甚するこずで、デヌタ分析、デヌタ凊理、モデルトレヌニング、生成 AI アプリ構築などの゚ンドツヌ゚ンドの開発ワヌクフロヌを、単䞀の管理環境で完了できたす。 統合型の SQL ゚ディタでは、耇数の゜ヌスからデヌタをク゚リできたす。たた、芖芚的な抜出、倉換、ロヌド (ETL) ツヌルにより、デヌタ統合ず倉換のワヌクフロヌの䜜成が簡玠化されたす。新しい統合型 Jupyter Notebook によっお、さたざたなコンピュヌティングサヌビスやクラスタヌ間でのシヌムレスな䜜業が可胜になりたす。新たに組み蟌たれたデヌタカタログ機胜により、組織党䜓のデヌタや AI アセットの怜玢、アクセス、ク゚リが可胜になりたす。Amazon Q は開発ラむフサむクル党䜓のタスクを合理化するために統合されおいたす。 個々の機胜をさらに詳しく芋おいきたしょう。 デヌタ凊理 SageMaker は SageMaker Lakehouse ず統合されおおり、統䞀された゚クスペリ゚ンスでデヌタを分析、準備、統合、調敎するこずができたす。 æäŸ›ã•れた接続オプションを䜿甚しお、さたざたな゜ヌスからのデヌタを統合および凊理できたす。 たず、SageMaker Unified Studio でプロゞェクトを䜜成し、 SQL 分析 たたは デヌタ分析ず AI-ML モデル開発 のプロゞェクトプロファむルを遞択したす。プロゞェクトは、同僚ず共同䜜業したり、デヌタを共有したり、ツヌルを䜿甚しお安党な方法でデヌタを操䜜したりする堎所です。SageMaker のプロゞェクトプロファむルは、新しいプロゞェクトを䜜成するずきにプロビゞョニングされる事前蚭定枈みのリ゜ヌスずツヌルのセットを定矩したす。プロゞェクトの巊偎のメニュヌで [デヌタ] を遞択し、デヌタ゜ヌスの远加を開始したす。 組み蟌みの SQL ク゚リ゚ディタを䜿甚するず、デヌタレむク、デヌタりェアハりス、デヌタベヌス、およびアプリケヌションに保存されおいるデヌタを SageMaker Unified Studio 内で盎接ク゚リできたす。SageMaker Unified Studio のトップメニュヌで [ビルド] を遞択し、 [ク゚リ゚ディタ] を遞択しお開始したす。たた、その際には Amazon Q で自然蚀語を䜿甚しお SQL ク゚リを䜜成しおみおください。 たた、組み蟌みのビゞュアル ETL ツヌルを確認し、芖芚的なドラッグアンドドロップむンタヌフェむスを䜿甚しお、デヌタ統合ず倉換のワヌクフロヌを䜜成するこずもおすすめしたす。トップメニュヌで [ビルド] を遞択し、 [ビゞュアル ETL フロヌ] を遞択しお開始したす。 Amazon Q が有効になっおいる堎合は、生成 AI を䜿甚しおフロヌを䜜成するこずもできたす。Visual ETL には、デヌタワヌクフロヌを合理化するためのさたざたなデヌタコネクタヌ、事前構築枈みの倉換、およびスケゞュヌリング、モニタリング、デヌタプレビュヌなどの機胜が備わっおいたす。 モデルの開発 SageMaker Unified Studio には、ML ラむフサむクル党䜓のむンフラストラクチャ、ツヌル、ワヌクフロヌを提䟛する SageMaker AI の機胜が含たれおいたす。トップメニュヌで [ビルド] を遞択するず、デヌタ準備、モデルトレヌニング、実隓远跡、パむプラむン䜜成、オヌケストレヌション甚のツヌルにアクセスできたす。これらのツヌルは、モデルのデプロむず掚論、機械孊習操䜜 (MLOps) の実装、モデルのモニタリングず評䟡、ガバナンスずコンプラむアンスにも䜿甚できたす。 モデル開発を開始するには、 デヌタ分析ず AI-ML モデル開発 プロゞェクトプロファむルを䜿甚しお、SageMaker Unified Studio でプロゞェクトを䜜成し、新しい統合 Jupyter Notebook を詊しおみおください。トップメニュヌで [ビルド] を遞択し、 [JupyterLab] を遞択したす。新しい統合ノヌトブックを䜿甚するず、さたざたなコンピュヌティングサヌビスやクラスタヌ間でシヌムレスに䜜業できたす。これらのノヌトブックでは、ワヌクスペヌスを離れるこずなく環境を切り替えるこずができるため、モデル開発プロセスが合理化されたす。 Amazon Q Developer を䜿甚しお、モデル開発プロセス党䜓を通しおコヌド生成、デバッグ、最適化などのタスクを支揎するこずもできたす。 生成 AI アプリ開発 新しい Amazon Bedrock IDE を䜿甚しお、Amazon SageMaker Unified Studio 内で生成 AI アプリケヌションを開発したしょう。Amazon Bedrock IDE には、FM および Amazon Bedrock Knowledge Bases 、 Amazon Bedrock Guardrails 、 Amazon Bedrock Agents 、 Amazon Bedrock Flows などの高床な機胜を䜿甚しお、生成 AI アプリケヌションを構築およびカスタマむズするためのツヌルが含たれおおり、お客様の芁件ず責任ある AI ガむドラむンに沿った、カスタマむズされた゜リュヌションを䜜成できたす。 SageMaker Unified Studio のトップメニュヌで [Discover] を遞択するず、Amazon Bedrock のモデルを閲芧したり、モデルのプレむグラりンドをテストしたりできたす。 生成 AI アプリケヌション開発 プロファむルを䜿甚しおプロゞェクトを䜜成し、生成 AI アプリケヌションの構築を開始したす。 SageMaker Unified Studio のトップメニュヌで [ビルド] を遞択し、 [チャット゚ヌゞェント] を遞択したす。 Amazon Bedrock IDE では、数回クリックするだけで独自のデヌタ゜ヌスからチャット゚ヌゞェントを構築し、ナレッゞベヌスを䜜成できるため、 怜玢拡匵生成 (RAG) が可胜になりたす。ガヌドレヌルを远加しお安党な AI むンタラクションを促進し、あらゆるシステムず統合する関数を䜜成できたす。組み蟌みのモデル評䟡機胜により、チヌムず協力しながら AI アプリケヌションのパフォヌマンスをテストしお最適化できたす。確定的な 生成 AI を掻甚したワヌクフロヌのフロヌを蚭蚈し、準備ができたら、アプリケヌションやプロンプトをドメむン内で共有したり、゚クスポヌトしおどこにでもデプロむしたりできたす。その間、プロゞェクトやドメむンアセットの管理を維持できたす。 Amazon SageMaker のすべおの機胜の詳现に぀いおは、「 SageMaker Unified Studio ナヌザヌガむド 」を参照しおください。 開始方法 SageMaker Unified Studio の䜿甚を開始するには、管理者はいく぀かのセットアップのステップを完了する必芁がありたす。これには、 AWS IAM アむデンティティセンタヌ のセットアップ、必芁な仮想プラむベヌトクラりド (VPC) や AWS Identity and Access Management (IAM) ロヌルの蚭定、SageMaker ドメむンの䜜成、Amazon Q Developer Pro の有効化が含たれたす。IAM Identity Center の代わりに、IAM フェデレヌションを通じお SAML を蚭定しお、ナヌザヌ管理を行うこずもできたす。 環境が蚭定されるず、ナヌザヌは提䟛された SageMaker Unified Studio ドメむン URL を䜿甚しおシングルサむンオンでサむンむンしたす。さたざたなナヌスケヌスに合わせお事前蚭定されたプロゞェクトプロファむルを遞択しお、チヌムメンバヌず共同䜜業するプロゞェクトを䜜成できたす。各プロゞェクトは Git リポゞトリに接続しおバヌゞョン管理を行いたす。たた、すぐに開始できるように統合された Jupyter Notebook の䟋も含たれおいたす。 詳现なセットアップ手順に぀いおは、「 SageMaker Unified Studio 管理者ガむド 」を参照しおください。 今すぐご利甚いただけたす 次䞖代の Amazon SageMaker は、珟圚、米囜東郚 (バヌゞニア北郚、オハむオ)、米囜西郚 (オレゎン)、アゞアパシフィック (東京)、欧州 (アむルランド) の AWS リヌゞョンでご利甚いただけたす。Amazon SageMaker Unified Studio ず Amazon Bedrock IDE は珟圚、これらの AWS リヌゞョンでプレビュヌ版ずしおご利甚いただけたす。今埌の曎新に぀いおは、 党リヌゞョンのリスト をご確認ください。 䟡栌情報に぀いおは、 Amazon SageMaker の料金 ず Amazon Bedrock の料金 をご芧ください。詳现に぀いおは、 Amazon SageMaker 、 SageMaker Unified Studio 、 Amazon Bedrock IDE をご芧ください。 既存の Amazon Bedrock Studio プレビュヌドメむンは 2025 幎 2 月 28 日たで利甚できたすが、新しいワヌクスペヌスを䜜成するこずはできたせん。Bedrock IDE の高床な機胜を䜓隓するには、「 管理者ガむド 」の手順に沿っお新しい SageMaker ドメむンを䜜成しおください。 新しい Amazon SageMaker を今すぐ コン゜ヌル で詊しお、ご意芋をお聞かせください。 ぜひお詊しいただき、 AWS re:Post for Amazon SageMaker 宛おに、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをお寄せください。 –  Antje 原文は こちら です。
Amazon Q Business は、さたざたなビゞネスアプリケヌションの生産性を向䞊させるように蚭蚈された生成 AI 搭茉アシスタントで、2024幎の初めに 䞀般提䟛 が開始されたした。Amazon Q Business はリリヌス以来、埓業員の生産性向䞊の課題に取り組むお客様を支揎しおきたした。 この蚘事では、Amazon Q Business に関する発衚が 2 ぀ありたす。 Amazon Q Business での AI を掻甚したワヌクフロヌの自動化 (近日公開予定) 50 以䞊のアクション統合のサポヌト (䞀般提䟛枈み) たず、Amazon Q Business からのこれらの新しい発衚を確認したしょう。 Amazon Q Business での AI を掻甚したワヌクフロヌの自動化 (近日公開予定) 組織は、正確で反埩可胜な実行を必芁ずする耇雑なワヌクフロヌを、数千ずは蚀わないたでも、䜕癟件も凊理しおいたす。これらのワヌクフロヌの自動化は、倚くの堎合数か月もの時間がかかるプロセスで、専門知識が必芁でした。その結果、朜圚的に䟡倀のあるビゞネスプロセスの倚くがいただに手䜜業で凊理されおおり、非効率化や機䌚の逞倱に぀ながっおいたす。 Amazon Q Business では近日䞭に、耇雑なビゞネスワヌクフロヌの䜜成ず保守を簡玠化する新機胜が登堎したす。 この機胜を䜿甚するず、必芁な䜜業内容を自然蚀語で説明したり、暙準操䜜手順 (SOP) をアップロヌドしたり、実行䞭のプロセスのビデオを録画したりするだけで枈みたす。Amazon Q Business は生成 AI を䜿甚しお、入力内容から詳现なワヌクフロヌプランを数分で自動的に䜜成したす。次に、掚奚ワヌクフロヌを䜿甚しお、レビュヌ、テスト、倉曎、たたは承認を行うこずができたす。 自動車保険請求凊理の䟋に぀いお考えおみたしょう。このプロセスでは通垞、手動で請求メヌルを読み、添付ファむルを確認し、システムで請求を䜜成したす。Amazon Q Business の新機胜によっお、このワヌクフロヌをより効率的に䜜成できるようになり、ワヌクフロヌの䜜成に通垞䌎う時間ず耇雑さが軜枛されたす。 たず、関連する SOP をアップロヌドしたす。 ワヌクフロヌ䜜成プロセス䞭に、Amazon Q Business は、ワヌクフロヌ蚭蚈を完了するために必芁な远加情報を明確化および収集するために質問するこずがありたす。 提䟛された入力に基づいお、Amazon Q Business は初期ワヌクフロヌテンプレヌトを生成したす。自動化の䜜成者ずしお、芖芚的なドラッグアンドドロップむンタヌフェむスを䜿甚しおこのワヌクフロヌをカスタマむズし、サポヌトされおいるサヌドパヌティヌアプリケヌションず統合しおテストするこずができたす。ワヌクフロヌには、API コヌル、自動 UI アクション、実行ロゞック、AI ゚ヌゞェント、ヒュヌマンむンザルヌプステップなどを含めるこずができ、幅広い業界やビゞネス機胜にわたるあらゆるビゞネスプロセスの固有のニヌズに応えるこずができたす。 完了したら、ワヌクフロヌを公開しお、スケゞュヌルどおりに実行するか、特定のトリガヌに応じお実行するように蚭定できたす。公開したら、機胜豊富なモニタリングダッシュボヌドを䜿甚しお、パフォヌマンスを積極的に远跡できたす。このダッシュボヌドには分析機胜が組み蟌たれおおり、公開されおいるすべおのワヌクフロヌの実行ず効率に関する詳现なむンサむトを提䟛したす。 Amazon Q Business は、ワヌクフロヌを実行する際、䜕千ものりェブサむトやデスクトップアプリケヌションでトレヌニングを受けた UI ゚ヌゞェントを䜿甚しお、ペヌゞレむアりトの倉曎や予期しないポップアップりィンドりに、リアルタむムか぀シヌムレスに察応したす。Amazon Q Business では、UI 自動化、API 統合、ワヌクフロヌオヌケストレヌションが 1 ぀のシステムに組み蟌たれおいるため、完党な゚ンタヌプラむズワヌクフロヌ自動化システムを䜜成するために耇数の補品やサヌビスを統合する必芁がなくなりたす。 50 以䞊のアクション統合のサポヌト Amazon Q Business プラグむンを䜿甚するず、サヌドパヌティヌのアプリに接続し、サポヌトされおいるサヌドパヌティヌのサヌビスに関連する特定のタスクを、りェブ゚クスペリ゚ンスチャット内で盎接実行する柔軟性が埗られたす。これらのプラグむンには、Amazon Q Business の機胜である Amazon Q Apps からアクセスできたす。この機胜は、タスクを合理化しお生産性を高める AI 搭茉アプリの制䜜に圹立ちたす。さらに、ワヌクフロヌ自動化機胜が起動するず、これらのプラグむンをワヌクフロヌに盎接統合できるようになりたす。 この発衚では、50 以䞊のアクション統合ず 11 の人気のあるビゞネスアプリケヌションを備えた、すぐに䜿えるプラットフォヌムラむブラリを玹介したす。これらのビゞネスアプリケヌションには、Microsoft Teams、PagerDuty Advance、Salesforce、ServiceNow などが含たれたす。 新しい統合を開始するには、既存のアカりントから Amazon Q Business にアクセスし、新しいプラグむンずアクション統合をご確認ください。 これらの統合により、Amazon Q Business りェブアプリケヌション内の耇数のアプリケヌションでさたざたなタスクを実行できたす。 Salesforce で新しい商談を䜜成する必芁があるずしたす。たず、Amazon Q Business りェブアプリケヌションを開きたす。 次に、Amazon Q Business プラグむンを起動しお、 [商談を䜜成] アクションを遞択したす。 次に、Amazon Q Business に商談レコヌドの䜜成を䟝頌したす。 アクションプラグむンでさらに情報が必芁な堎合は、さらに情報を収集するように求められたす。 Amazon Q Business プラグむンは、Salesforce アクションプラグむンを䜿甚しお自動的にレコヌドを䜜成したす。 ここから、商談レコヌドを取匕先に関連付けるなど、远加のタスクを実行できたす。 Amazon Q Business の䜿甚を今すぐ開始する 珟圚、新しい Amazon Q Business プラグむンは、Amazon Q Business を利甚できるすべおの AWS リヌゞョンでご利甚いただけたす。Amazon Q Business のワヌクフロヌをオヌケストレヌションする新機胜は、間もなくプレビュヌ版で利甚可胜になりたす。 Amazon Q Business で組織の生産性ずむノベヌションを向䞊させたしょう。開始方法の詳现に぀いおは、 Amazon Q Business のドキュメント ペヌゞをご芧ください。 構築がうたくいきたすように。 –  Donnie 原文は こちら です。
Amazon Q Business は、リリヌス以来、䌁業のデヌタや情報に基づいおより良い意思決定を行えるように支揎する生成 AI 搭茉アシスタントを䜿甚しお、埓業員の生産性を向䞊させおいたす。たた、埓業員は独立系゜フトりェアベンダヌ (ISV) が提䟛するさたざたな゜フトりェアアプリケヌションを䜿甚しお、タスクを実行しおいたす。倚くの ISV はナヌザヌの生産性を高めるこずを目的ずしお独自の生成 AI 機胜を開発しおいたすが、倚くの堎合、ISV は自瀟のアプリケヌション内のデヌタに限定されおいるため、゚ンドナヌザヌはタスクを完了するために䟝然ずしおアプリケヌション間を移動しおいたす。 12 月 3 日、ISV 向けの Amazon Q Business の新機胜を発衚できたこずを嬉しく思いたす。ISV は Amazon Q むンデックスず統合しお、単䞀の API を通じお耇数の゜ヌスからデヌタを取埗し、Amazon Q 埋め蟌みアシスタントの蚭蚈をカスタマむズできるようになりたした。 これらの新機胜により、ISV やアプリケヌション開発者は、Amazon Q Business の機胜で生成 AI ロヌドマップを加速させながら、耇数の Software as a Service (SaaS) アプリケヌションにわたる゚ンタヌプラむズナレッゞずナヌザヌコンテキストの䞡方を掻甚し、パヌ゜ナラむズされた AI を掻甚した゚クスペリ゚ンスをアプリケヌションに迅速にデプロむできたす。 Amazon Q むンデックスを䜿甚しお、远加デヌタで生成 AI 機胜を匷化 この新機胜により、ISV はアプリケヌションの倖郚からコンテンツやコンテキストにアクセスできるようになり、垌望の倧芏暡蚀語モデル (LLM) を䜿甚しお既存の生成 AI ず怜玢拡匵生成 (RAG) ワヌクフロヌを補完しながら、より豊かな䜓隓を構築し、゚ンゲヌゞメントずリテンションを向䞊させるこずができたす。重芁なのは、顧客がむンデックスの完党な所有暩を維持し、どのアプリケヌションがデヌタにアクセスできるかを完党に制埡できるこずです。 ゜フトりェアプロバむダヌは、Amazon Q Business にアプリケヌションを登録しお、むンデックス化されたデヌタぞのアクセスを顧客に蚱可できるようにしたす。怜蚌埌、゜フトりェアプロバむダヌはこの远加デヌタを䜿甚しお組み蟌みの生成 AI 機胜を匷化し、よりパヌ゜ナラむズされた顧客察応を提䟛できたす。詳现に぀いおは、 ゜フトりェアプロバむダヌ向けの Amazon Q むンデックス のりェブペヌゞをご芧ください。 ISV が Amazon Q むンデックスずの統合を完了したら、この新しいクロスアプリケヌション゚クスペリ゚ンスを䜿甚するよう顧客を誘導する方法が 2 ぀ありたす。 ISV のアプリケヌションを通じたオンボヌディング – 顧客は ISV のプラットフォヌムを通じおプロセスを開始したす。ISV は、各顧客に代わっお Amazon Q Business アプリケヌションずむンデックスを䜜成したす。次に、顧客は ISV に認蚌情報を提䟛しお、远加のデヌタ゜ヌスを接続したす。このシナリオでは、ISV がオンボヌディング゚クスペリ゚ンスずナヌザヌむンタヌフェむスを完党に制埡できるものずしたす。 AWS マネゞメントコン゜ヌルによるオンボヌディング – 顧客は AWS コン゜ヌルから Amazon Q Business アプリケヌションを盎接䜜成し、そこでデヌタ゜ヌスを接続しお、ISV にむンデックスぞのアクセス蚱可を付䞎できたす。認蚌枈みの ISV は、Amazon Q Business コン゜ヌルで「デヌタアクセサヌ」ずしお䞀芧衚瀺されたす。この怜蚌ステヌタスは、ISV が䞊蚘の必芁な怜蚌プロセスを完了し、カスタマヌ゚クスペリ゚ンスを開始する準備ができたずきに付䞎されたす。 次に、顧客が怜蚌枈みの ISV に既存のむンデックスぞのアクセス蚱可を付䞎するプロセスの抂芁を説明したす。 顧客がアプリケヌションを䜜成しおむンデックスを远加するず、怜蚌枈みの ISV にアクセス蚱可を付䞎できたす。これを行うには、巊偎のナビゲヌションパネルで [デヌタアクセサヌ] を遞択し、 [デヌタアクセサヌを远加] を遞択したす。 [デヌタアクセサヌを远加] ペヌゞには、怜蚌枈みのすべおの ISV アプリケヌションのリストが衚瀺されたす。 ISV アプリケヌションを遞択したら、顧客は ISV がアクセスできるデヌタを蚭定したす。たた、顧客は、どのナヌザヌに ISV の曎新枈み機胜ぞのアクセスを蚱可するかも遞択できたす。 アクセス暩を付䞎したら、顧客は ISV の管理コン゜ヌルで Amazon Q Business アプリケヌションをリンクしお、蚭定を完了する必芁がありたす。完了するず、ISV は SearchRelevantContent API を䜿甚しお指定されたむンデックスからデヌタの取埗を開始し、むンデックスからデヌタを取埗するこずで生成 AI 機胜を匷化できたす。この API を䜿甚するサンプルコヌドスニペットを次に瀺したす。 import boto3 import pprint qbiz = boto3.client("qbusiness", region_name="us-east-1", **credentials) Q_BIZ_APP_ID = ${Q_BIZ_APP_ID} Q_RETRIEVER_ID = ${Q_RETRIEVER_ID} Q_DATA_SOURCE_ID = ${Q_DATA_SOURCE_ID} search_params = { 'applicationId': Q_BIZ_APP_ID, 'contentSource': { 'retriever': { 'retrieverId': Q_RETRIEVER_ID } }, 'queryText': 'Order coffee API', 'maxResults': 5, 'attributeFilter': { 'documentAttributeFilter': { 'andAllFilters': [{ 'equalsTo': { 'name': '_data_source_id', 'value': { 'stringValue': DATA_SOURCE_ID } } }] } } } search_response = qbiz.search_relevant_content(**search_params) 埋め蟌みアシスタントのデザむンのカスタマむズ Amazon Q 埋め蟌み は、ナヌザヌむンタヌフェむスに AI 搭茉アシスタントを組み蟌むこずで、ISV が Amazon Q Business を゚ンドナヌザヌに展開できるようにするための機胜です。この機胜は、ISV ナヌザヌが文曞の芁玄や質問ぞの回答などのさたざたなタスクを完了するのに圹立ちたす。 ゜フトりェアプロバむダヌは、Amazon Q が埋め蟌たれた埋め蟌み可胜な生成 AI アシスタントのナヌザヌむンタヌフェむス (UI) を、自瀟のブランドに合わせおカスタマむズできるようになりたした。はじめに、巊偎のナビゲヌションパネルで [Amazon Q Embedded] を遞択し、 [りェブ䜓隓をカスタマむズ] を遞択したす。 このペヌゞで [テヌマ] を遞択し、アシスタント名、りェルカムメッセヌゞ、配色、ロゎの蚭定など、生成 AI アシスタント UI のルックアンドフィヌルのカスタマむズを開始したす。 今すぐご利甚いただけたす Amazon Q むンデックスずカスタマむズ可胜な UI が埋め蟌たれた Amazon Q は、珟圚、米囜東郚 (バヌゞニア北郚) ず米囜西郚 (オレゎン) の AWS リヌゞョンで䞀般提䟛されおおり、他の AWS リヌゞョンでも間もなく利甚できるようになりたす。 ISV は Amazon Q Business の機胜を䜿甚しお、匷力な AI 機胜でナヌザヌ゚クスペリ゚ンスを革新および匷化できるようになりたした。ISV がアプリケヌションを匷化できる方法に぀いお詳しくは、 ゜フトりェアプロバむダヌ向けの Amazon Q Business ペヌゞ をご芧ください。 コヌディングをお楜しみください! –  Donnie 原文は こちら です。
2023 幎の AWS re:Invent では、 Amazon Q Developer をプレビュヌ したした。Amazon Q Developer は、 Visual Studio 、 Visual Studio Code 、 JetBrains IDE 、 Eclipse (プレビュヌ)、 JupyterLab 、 Amazon EMR Studio 、たたは AWS Glue Studio などの統合開発環境 (IDE) 党䜓で゜フトりェアを蚭蚈、構築、テスト、デプロむ、保守するための 生成 AI 搭茉アシスタントです。 Amazon Q Developer は、 AWS マネゞメントコン゜ヌル 、 AWS コン゜ヌルモバむルアプリケヌション 、 Amazon CodeCatalyst 、 AWS サポヌト 、 AWS りェブサむト 、たたは AWS Chatbot が蚭定された Slack および Microsoft Teams 経由で䜿甚するこずもできたす。 むノベヌションのペヌスが迅速 だったため、4 月に Amazon Q Developer の 䞀般提䟛を発衚 し、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 Amazon SageMaker Studio 、 AWS CloudShell のサポヌトや、IDE での シヌムレスなコヌディング操䜜のためのむンラむンチャット などの機胜をさらに远加したした。たた、AWS は Gartner 初の Magic Quadrant for AI Code Assistants の リヌダヌに遞出 されたした。 Amazon Q Developer には、シンプルなプロンプトを䜿甚しお、コメントや既存のコヌドに基づくリアルタむムでのコヌドの提案、単䞀のプロンプト ( /dev ) からの新しいプロゞェクトのブヌトストラップ、Amazon Q Developer の倉換機胜 ( /transform ) を䜿甚したレガシヌ Java アプリケヌションのアップグレヌドず倉換プロセスの自動化、プラむベヌトリポゞトリからのカスタマむズされた掚奚コヌドの安党な生成、AWS アカりントで実行されおいるリ゜ヌスの迅速な把握を実行できる゚ヌゞェントがありたす。 12 月 3 日、Amazon Q Developer ゚ヌゞェントの機胜を拡匵したした。その目的は、1) コヌドベヌス内のドキュメント ( /doc ) の匷化、2) セキュリティずコヌド品質の問題を怜出しお解決するためのコヌドレビュヌのサポヌト (/review )、3) 目的の IDE たたは最も人気のある゚ンタヌプラむズ DevOps プラットフォヌムの 1 ぀である GitLab Duo with Amazon Q (プレビュヌ) での゜フトりェア開発ラむフサむクル党䜓にわたるナニットテストの自動生成ずテストカバレッゞの向䞊 ( /test ) です。 Amazon Q Developer Agent for Software Development 機胜の䜿甚を開始する すべおの新機胜の䜿甚を開始するには、お気に入りの IDE 甚の 最新の Amazon Q IDE 拡匵機胜 をむンストヌルしたす。Amazon Q Developer の無料利甚枠たたは Pro ティアにサむンむンし、IDE でプロゞェクトを開きたす。 AWS ビルダヌ ID で 無料利甚枠 の認蚌を行うこずも、 AWS IAM アむデンティティセンタヌ を䜿甚しお Pro ティア の認蚌を行うこずもできたす。 1.コヌドベヌスのドキュメントの匷化 これで、お䜿いの IDE のコヌドベヌスに関する readme やデヌタフロヌ図などの包括的なドキュメントを生成できるようになりたした。Amazon Q Developer が手間のかかる文曞化䜜業を凊理するため、゜フトりェア゚ンゞニアリングのベストプラクティスに基づいた品質を維持しながら、コヌドの蚭蚈ず䜜成に泚力できたす。 IDE でドキュメントを開始するには、チャットパネルを開いお「 /doc 」ず入力したす。 これで、プロゞェクト内の README を䜜成したり、既存の README を曎新したりできるようになりたした。゜ヌスファむルのスキャン、ナレッゞグラフの䜜成、゜ヌスファむルの芁玄、ドキュメントの生成を行いたす。完了したら、䜜成された REAME ファむルをチェックアりトし、 [承認] を遞択しおこのドキュメントをコヌド゚ディタで䜿甚したす。 2.コヌド品質問題の怜出ず解決のためのコヌドレビュヌのサポヌト コヌドスメル、アンチパタヌン、呜名芏則違反、朜圚的なバグ、論理゚ラヌ、コヌドの重耇、貧匱な文曞やセキュリティの脆匱性、IDE たたは GitLab リポゞトリ党䜓にわたる AWS のベストプラクティスなど、さたざたなコヌド品質の問題を特定しお解決できたす。 この自動コヌドレビュヌプロセスにより、開発チヌムは時間を倧幅に節玄し、生産性を向䞊させ、コヌド品質の䞀貫性を維持できるようになるため、最終的にはセキュリティ暙準ずベストプラクティスを順守しながら、より迅速な機胜リリヌスを実珟できたす。 IDE でコヌドレビュヌを開始するには、チャットパネルを開いお「 /review 」ず入力したす。 Amazon Q Developer は、コヌドをコミットする前に、プロゞェクトたたはお客様が遞択した特定のファむルを確認しお問題を特定し、怜出結果のリストを提䟛したす。お客様は Amazon Q でフォロヌアップしお解決策を芋぀け、オンデマンドのコヌド修正をむンラむンで生成したす。完了したら、コヌドの問題に察する掚奚コヌド修正を確認し、 [修正を承認] を遞択しお、コヌド゚ディタで倉曎を適甚したす。 3.ナニットテストの自動生成ずテストカバレッゞの向䞊 テストケヌスの特定からプロゞェクトファむル向けのナニットテストの䜜成たで、ナニットテストプロセスを自動化できたす。ナニットテストでは、境界条件、NULL 倀、off-by-1 のケヌス、耇数の入力タむプのチェックなどの基本的なケヌスを生成できたす。 IDE でナニットテストワヌクフロヌを開始するには、チャットパネルを開いお「 /test 」ず入力したす。 Amazon Q Developer は、特定の゜ヌスファむルでナニットテストを生成し、該圓のテストファむルに配眮しお、テスト゚ラヌをセルフデバッグしたす。完了したら、 [差分を衚瀺] を遞択しお、生成されたナニットテストをコヌド゚ディタで確認したす。その埌、生成されたナニットテストを承認たたは拒吊できたす。 今すぐご利甚いただけたす ゜フトりェア開発甚の 3 ぀の新しい Amazon Q Developer ゚ヌゞェント機胜が、Amazon Q Developer が利甚可胜なすべおの AWS リヌゞョンで利甚できるようになりたした。 詳现に぀いおは、 Amazon Q Developer の補品ペヌゞ ず、 AWS DevOps ず開発者の生産性ブログ チャンネルの最新のブログ蚘事をご芧ください。私のチヌムは、 Amazon Q デベロッパヌセンタヌ ず Community.aws で、゜フトりェア開発者のゞョブ理論 (Jobs-To-Be-Done) を盎接サポヌトし、生成 AI によっお実珟および匷化される、Amazon Q Developer 関連のコンテンツを䜜成するこずにも焊点を圓おおいたす。 AWS ビルダヌ ID を䜿甚しお、 お気に入りの IDE で Amazon Q Developer ゚ヌゞェントの新しい機胜を詊し、 AWS re:Post for Amazon Q Developer にフィヌドバックを送信するか、通垞の AWS サポヌトの連絡先を通じおフィヌドバックを送信しおください。 – Channy 原文は こちら です。
はじめに コンタクトセンタヌを運甚しおいる䌁業では、生成 AI の力を掻甚しお、ナヌザヌ䜓隓ず゚ヌゞェントの生産性を向䞊させるこずを怜蚎しおいるかもしれたせん。゚ヌゞェントアシストやむンテリゞェントボットなどの機胜は、コンタクトセンタヌの AI を掻甚した改革の結果ずしお泚目を集めおいたす。 圓瀟のお客様の倚くはすでに、解決たでの時間短瞮ず運甚効率の最適化のために、䞻芁なカスタマヌサポヌトチャネルずしお音声自動応答システム (IVR) やむンテリゞェント仮想アシスタント (IVA) を䜿甚しおいたす。そしお、AI 䞻導の顧客察応ず人間の゚ヌゞェント䞻導の察応ずのシヌムレスな統合を暡玢しおいるお客様も増えおいたす。これにより、自動化のスピヌドず人間の゚ヌゞェントによるパヌ゜ナラむズされた䜓隓の適切なバランスを保ちながら、匷力なカスタマヌケア゜リュヌションを提䟛するこずができたす。たすたす䞀般的になっおいるナヌスケヌスは、 Amazon Web Services (AWS) のクラりドコンタクトセンタヌ゜リュヌションである Amazon Connect を、AI ず人間の連携のために既存の IVA たたは IVR システムず統合するこずです。 このブログ蚘事では、 AI を掻甚した IVR システムず IVA を Amazon Connect ずシヌムレスに統合するこずで、䌁業が顧客䜓隓をさらに向䞊させる方法に぀いお探りたす。このような統合の䞻な利点や、AI を掻甚したアシスタントず人間の゚ヌゞェント間のシヌムレスな連携を可胜にするアヌキテクチャパタヌンに぀いお詳しく芋おいきたす。顧客により倚くの統合オプションを提䟛したいサヌドパヌティプロバむダヌの方も、既存のカスタマヌサヌビス業務をモダナむズしたいず考えおいる方も、この蚘事はコンタクトセンタヌにおける AI ず人間のコラボレヌション力を高めるための掞察ず戊略を提䟛したす。 Amazon Connect ず AI を掻甚した IVR/IVA の統合 以䞋は、むンテリゞェントアシスタントを Amazon Connect ず統合する際に䜿甚できる 2 ぀の䞀般的なパタヌンです AI ベヌスのアシスタントが必芁に応じおシヌムレスに音声通話を人間の゚ヌゞェントに匕き継ぐこずを可胜にしたす。これにより、顧客は基本的な問い合わせに察しお AI 仮想アシスタントずやり取りできる䞀方で、人間の゚ヌゞェントぞのスムヌズな移行が可胜になりたす。AI アシスタントから収集した完党なコンテキストず顧客情報をもっお、スムヌズな移行を確保し、繰り返しを避け、解決プロセスをさらに迅速化したす。 サヌドパヌティのアプリケヌションやツヌルを Amazon Connect Agent Workspace に統合したす。これは、サヌドパヌティの゜ヌスやカスタムビルドからの、カスタム機胜やむンサむトを Amazon Connect Agent Workspace にシヌムレスに統合し、远加の機胜や情報を提䟛したい堎合に圹立ちたす。CRM システム、ナレッゞベヌス、泚文管理プラットフォヌムなど、さたざたなアプリケヌションを統䞀されたむンタヌフェヌスに統合するこずができ、゚ヌゞェントが耇数のシステムを切り替えるこずなく効率的に䜜業できるようになりたす。 アヌキテクチャパタヌン AI を掻甚した IVR/IVA ず Amazon Connect 間のシヌムレスな統合に関わる䞻なアヌキテクチャパタヌンをいく぀か詳しく芋おいきたしょう。 パタヌン 1サヌドパヌティアシスタントから Amazon Connect ぞのむンタラクション移行 a. 䞻芁な機胜 䞻芁な統合パタヌンの 1 ぀は、音声ずチャットの䞡方で AI を掻甚したセルフサヌビスから人間の゚ヌゞェントぞのスムヌズな移行を促進するこずです。発信者が「゚ヌゞェントず話したい」ず芁求した堎合、圌らはシヌムレスで継続的なむンタラクションを期埅したす。䌚話を匕き継ぐ゚ヌゞェントに、顧客を最適にサポヌトするためのタむムリヌで実甚的な情報が提䟛されるこずが重芁です。効果的な匕き継ぎを確実にするために必芁な䞻芁な機胜は次のずおりです 仮想アシスタントをホストしおいるシステムから Amazon Connect の問い合わせを開始したす。 ゚ヌゞェントのワヌクスペヌスには、名前やアカりントデヌタなどの顧客情報が衚瀺されるべきです。アシスタントは移行時に識別情報を提䟛する必芁がありたす。できれば、゚ヌゞェントは Amazon Connect チャネルから問い合わせが発生した堎合ず同じレベルの顧客情報にアクセスできるようにすべきです。たた、ワヌクスペヌスには移行前のやり取りに関する掞察も提䟛されるべきです。最䜎限、これには䌚話の曞き起こし、メタデヌタ日付、時刻、所芁時間、および前凊理を通じお抜出された意味のあるデヌタが含たれるべきです。これには、䌚話のトヌン、顧客の問題の説明、提案された解決策などが含たれ、゚ヌゞェントが次のステップを玠早く特定し、発信者の䜓隓を向䞊させるこずができたす。 b. アヌキテクチャの抂芁 図サヌドパヌティの IVA/IVR から Amazon Connect ぞの移行 – ゜リュヌションアヌキテクチャ 以䞋はアヌキテクチャず情報の流れの説明です 顧客はサヌドパヌティの IVA/IVR アプリずやり取りしたす。顧客が゚ヌゞェントずの䌚話を芁求するず、その芁求は Amazon API Gateway に送信されたす。Amazon API Gateway は、䌚話のトランスクリプトを保存する API”/store”、トランスクリプトを凊理しお関連情報を抜出する API”/process”、Amazon Connect で新しいコンタクトを開始する API”/start-contact”にリク゚ストをルヌティングしたす。 “/store” API ゚ンドポむントは䌚話のトランスクリプトを受け取り、 AWS Lambda 関数を䜿甚しお Amazon S3 バケットに保存したす。 “/process” API ゚ンドポむントは、Amazon S3 に保存された䌚話トランスクリプトを凊理する別の Lambda 関数をトリガヌしたす。この AWS Lambda 関数は、 Amazon Bedrock 、 Amazon Transcribe 、 Amazon Comprehend などの AI サヌビスを利甚しお、トランスクリプトから関連情報を抜出するこずができたす。 抜出された情報は Amazon DynamoDB に保存されたす。ナヌスケヌスによっおは、他のタむプのデヌタストアが䜿甚される堎合もありたす。 䌚話のむンサむトデヌタが準備されるず、第䞉者アプリは “/start-contact” API ゚ンドポむントを呌び出し、これが Amazon Connect API を呌び出しお Amazon Connect むンスタンスを通じお顧客ずのラむブ゚ヌゞェントのやり取りを開始したす。この手順の詳现に぀いおは、以降のセクションで説明したす。 Amazon Connect むンスタンスは、新しいコンタクトテキストたたは音声を開始するリク゚ストを受け取りたす。 ゚ヌゞェントがサポヌトケヌスを確認し、自分に割り圓おるず、顧客の芁求に関連するすべおの情報にアクセスできるようになりたす。Amazon Connect Agent Workspace の柔軟な統合機胜を䜿甚しお、顧客はチャットや通話の芁玄、導き出されたむンサむトなどの重芁なデヌタを衚瀺できたす。 ゚ヌゞェントは䌚話の詳现ずトランスクリプトから抜出された関連情報を確認し、キュヌからサポヌトケヌスを取埗できたす。最初のチャネルに応じお、やり取りは新しい着信チャットたたは新しい音声通話になる可胜性がありたす。 音声ずチャットの党䜓的なアヌキテクチャは同等ですが、各チャネルには特有のニュアンスがあり、Amazon Connectの特城的な機胜を掻甚しおいたす。 c. 音声チャンネル 音声察応のアシスタントの堎合、シンプルな移行戊略はコヌルバックのスケゞュヌリングです。サヌドパヌティアプリケヌションは発信者からコヌルバックの詳现を収集し、リク゚ストを承認した埌、むンタラクションの移行フロヌを開始できたす。コヌルバックには耇数の利点がありたす サヌドパヌティアシスタントから Amazon Connect ぞの移行䞭の顧客の埅ち時間を最小限に抑えたす。音声トランスクリプトの生成ず凊理には時間がかかる可胜性があり、電話䞭に発信者が我慢できない可胜性があるためです。ケヌスを担圓する゚ヌゞェントが顧客ずやり取りする前に、利甚可胜な情報を確認する十分な時間を確保できたす。 これを実珟するために、Amazon Connect は CreateCallbackContact などの自動コヌルバックフロヌを構築するための倚数の Action API を提䟛しおいたす。サンプルのコヌルバック゜リュヌションに぀いおは、 発信者スケゞュヌルコヌルバックのブログ を参照しおください。 d. チャットチャネル チャットアシスタントの堎合、戊略はチャットボットの基盀ずなる゜リュヌションに倧きく䟝存したす。 カスタムビルドの AI 搭茉チャットボットを䜿甚する堎合 IVA がカスタムチャットプラットフォヌム䞊に構築されおいる堎合、䞊蚘の゜リュヌションで説明した API を䜿甚しお Amazon Connect のチャット機胜ず統合するこずができたす。この堎合、゜リュヌションの重芁なコンポヌネントの 1 ぀は StartChatContact API で、これによっお顧客ずの新しいチャットを開始するフロヌを開始できたす。フロヌでアクセス可胜なカスタム属性を枡すこずもできたす。䟋えば、顧客情報やチャット蚘録デヌタぞのアクセスを提䟛する䞀意の匕き継ぎ識別子を枡すこずができたす。 サンプルコヌドず技術アヌキテクチャに぀いおは、 Amazon Connect Chat UI Examples リポゞトリ を参照しおください。 Amazon Lex チャット UI を䜿甚する堎合 IVA が Amazon Lex にお構築されおいる堎合、Amazon Lex ず Amazon Connect の間のネむティブ統合を掻甚しお、統䞀されたチャット䜓隓を䜜成できたす。このアプロヌチでは、Amazon Lex の䌚話機胜を掻甚しながら、必芁に応じお人間の゚ヌゞェントにシヌムレスにチャットを移行するこずができたす。Amazon Lex のデフォルトむンテント機胜により、生成 AI でチャット䜓隓を匷化するこずができ、人間の゚ヌゞェントを関䞎させる前に自動化レむダヌを远加するこずができたす。 QnABot がこのような゜リュヌションの良い䟋です。 パタヌン 2: サヌドパヌティアプリケヌション3P アプリの統合 Amazon Connect Agent Workspace に、サヌドパヌティアプリケヌション3P アプリや独自のカスタムビルドされた生成 AI を掻甚した゜リュヌションを統合するこずで、゚ヌゞェントの䜓隓をさらに豊かにするこずができたす。 Agent Workspace にサヌドパヌティアプリケヌション3P アプリを統合するこずは、Amazon Connect のネむティブな機胜であり、゚ヌゞェントの生産性ず顧客䜓隓を向䞊させる匷力な方法です。重芁なビゞネスアプリケヌション、デヌタ、機胜を単䞀のむンタヌフェヌスに統合するこずで、゚ヌゞェントは耇数のシステムを切り替えるこずなく、必芁な情報にすべおアクセスできたす。このスムヌズなアクセスにより、問題解決の迅速化、䞀次解決率の向䞊、より良い顧客䜓隓に぀ながりたす。 Amazon Connect ず 3P アプリの統合には、いく぀かのアプロヌチがありたす。AWS Marketplace では、簡単に導入・蚭定できる事前構築された 3P アプリ統合を提䟛しおいたす。あるいは、カスタム統合を構築したい䌁業は、プラットフォヌムの安定した API を掻甚しお、倖郚アプリケヌションをプログラムで統合し、゚ヌゞェントむンタヌフェヌス内でその機胜を衚瀺するこずができたす。䟋えば、iframe を䜿甚しおサヌドパヌティの Web アプリケヌションを Agent Workspace に盎接埋め蟌み、シヌムレスな芖芚的統合を実珟できたす。 Amazon Connect ず統合される 3P アプリの䞀般的な䟋には、CRM システム、ナレッゞベヌス、泚文管理プラットフォヌム、カスタムの瀟内アプリケヌションなどがありたす。これらの重芁なツヌルずデヌタ゜ヌスを統合するこずで、䌁業は必芁なすべおの情報ずアクションに単䞀のワヌクスペヌスからアクセスできる、合理化された゚ヌゞェントワヌクフロヌを䜜成できたす。これにより、平均凊理時間や䞀次解決率などの䞻芁メトリクスに倧きな圱響を䞎えるこずができたす。 事前構築された統合以倖にも、䌁業は Amazon Connect の柔軟性を掻甚しお、独自ツヌルや AI を掻甚したアシスタントを含む、独自のカスタムアプリケヌションやサヌビスを構築・統合するこずができたす。これにより、ナニヌクなビゞネスニヌズやワヌクフロヌに合わせた真にカスタマむズされた゚ヌゞェント䜓隓を実珟し、生産性ず卓越した顧客サヌビスを新たなレベルに匕き䞊げるこずができたす。 図: Amazon Connect Agent Workspace からサヌドパヌティアプリケヌションにアクセス たずめずアクションの提案 AI を掻甚した仮想アシスタントず Amazon Connect の統合は、カスタマヌサヌビス業務を向䞊させるための魅力的な゜リュヌションを提䟛したす。AI 䞻導のやり取りからラむブ゚ヌゞェントぞのシヌムレスな移行ず、完党なコンテキストの転送により、䌁業は卓越した䜓隓を提䟛し、゚ヌゞェントの効率を高めるこずができたす。このアプロヌチにより、解決率の向䞊、゚ヌゞェントが関連情報を事前に受け取るこずによる満足床の向䞊、そしおサヌドパヌティアプリケヌションずカスタム AI サヌビスを゚ヌゞェントワヌクスペヌス内に統合するこずによる生産性の向䞊が可胜になりたす。コンタクトセンタヌ業務を最適化する組織にずっお、この AI ず人間の協働モデルは、AI の速床ずスケヌラビリティをラむブ゚ヌゞェントの専門知識ず組み合わせお掻甚する戊略的な機䌚を提䟛したす。 より詳现を孊んで始めるには、次のリ゜ヌスを参照しおください Connect API に関するドキュメント サヌドパヌティヌアプリケヌションの゚ヌゞェントワヌクスペヌスずの統合 Connect におけるサヌドパヌティアプリケヌションに関するドキュメント Amazon Connect りェブペヌゞ Amazon Connect でカスタマヌサヌビス䜓隓を倉革する準備はできたしたか お問い合わせください。 著者に぀いお Aarushi Karandikar は Amazon Web Services (AWS) の゜リュヌションアヌキテクトで、゚ンタヌプラむズ ISV の顧客にクラりドゞャヌニヌに関する技術的なガむダンスを提䟛する責任を担っおいたす。圌女は UC Berkeley でデヌタサむ゚ンスを孊び、生成 AI 技術を専門ずしおいたす。   Guy Bachar はニュヌペヌクを拠点ずする AWS のシニア゜リュヌションアヌキテクトで、キャピタルマヌケットの顧客のクラりド倉革ゞャヌニヌを支揎するこずを専門ずしおいたす。圌の専門分野は、アむデンティティ管理、セキュリティ、ナニファむドコミュニケヌションです。   Narcisse Zekpa はボストンを拠点ずするシニア゜リュヌションアヌキテクトです。圌は米囜北東郚の顧客が AWS クラりド䞊で革新的でスケヌラブルな゜リュヌションを通じおビゞネス倉革を加速するのを支揎しおいたす。圌は、高床な分析ず AI を䜿甚しお組織がビゞネスを倉革できるようにするこずに情熱を泚いでいたす。Narcisse が構築䜜業をしおいないずきは、家族ず過ごしたり、旅行したり、ランニングをしたり、料理をしたり、バスケットボヌルをしたりするこずを楜しんでいたす。 Sarah Patrick は Amazon Web Services (AWS) の゜リュヌションアヌキテクトで、SMB゚ンゲヌゞの顧客がクラりドコンピュヌティングサヌビスを掻甚するのを支揎しおいたす。Sarah はメリヌランド倧孊で情報科孊ずビゞネス分析を孊びたした。珟圚、圌女は顧客がコンタクトセンタヌのニヌズに Amazon Connect を実装する初期段階をガむドしおいたす。 Agnel Joseph は Amazon Web Services のプロフェッショナルサヌビスのコンサルタントです。圌は Amazon Connect でスケヌラブルなコンタクトセンタヌ゜リュヌションを展開するお客様を支揎するこずにフォヌカスしおいたす。圌は技術者であり孊生でもあり、孊習ず新しいプロダクトを䜜るこずが奜きです。 翻蚳は゜リュヌションアヌキテクトの濱䞊が担圓したした。原文は こちら です。
12 月 3 日、 Amazon Bedrock Guardrails の新しい保護手段ずしお自動掚論チェック (プレビュヌ) を远加したした。これにより、 倧芏暡蚀語モデル (LLM) によっお生成される応答の正確性を数孊的に怜蚌し、ハルシネヌションによる事実の誀りを防ぐこずができたす。 Amazon Bedrock Guardrails では、望たしくないコンテンツをフィルタリングし、個人を特定できる情報 (PII) を線集し、コンテンツの安党性ずプラむバシヌを匷化するこずで、 生成 AI アプリケヌションの保護手段を実装できたす。拒吊されたトピック、コンテンツフィルタヌ、ワヌドフィルタヌ、個人情報線集、コンテキストグラりンディングチェック、そしお自動掚論チェックのポリシヌを蚭定できたす。 自動掚論チェックは、モデルによっお生成された情報を怜蚌するための適切な数孊的、論理的怜蚌ず掚論プロセスを䜿甚しお、ハルシネヌションによる事実の誀りを防ぐのに圹立ちたす。これにより、出力は既知の事実ず䞀臎し、停造されたデヌタや䞀貫性のないデヌタに基づかないようになりたす。 Amazon Bedrock Guardrails は、倧手クラりドプロバむダヌが提䟛する唯䞀の責任ある AI 機胜であり、お客様が生成 AI アプリケヌションの安党性、プラむバシヌ、信頌性を単䞀の゜リュヌション内で構築およびカスタマむズできるよう支揎したす。 自動掚論入門 自動掚論 は、数孊的蚌明ず論理的掚論を䜿甚しおシステムやプログラムの動䜜を怜蚌するコンピュヌタヌサむ゚ンスの分野です。自動掚論は、システムの動䜜を数孊的に保蚌するずいう点で、予枬を行う 機械孊習 (ML) ずは異なりたす。 Amazon Web Services (AWS) では、ストレヌゞ、ネットワヌク、仮想化、ID、暗号化などの䞻芁なサヌビス分野ですでに自動掚論を䜿甚しおいたす。たずえば、自動掚論を䜿甚しお暗号実装の正確性を正匏に怜蚌するこずで、 パフォヌマンス ず 開発速床 の䞡方を向䞊させたす。 è©³çŽ°ã«ã€ã„ãŠã¯ã€Amazon Science Blog の「 蚌明可胜なセキュリティ 」ず「 自動掚論 」の研究分野をご芧ください。 珟圚、AWS は生成 AI にも同様のアプロヌチを適甚しおいたす。Amazon Bedrock Guardrails の新しい自動掚論チェック (プレビュヌ) は、生成 AI の応答が正しい理由を説明する論理的に正確で怜蚌可胜な掚論を甚いお、ハルシネヌションによる事実の誀りを防ぐための、最初で唯䞀の生成 AI 保護手段です。自動掚論チェックは、事実の正確性ず説明可胜性が重芁なナヌスケヌスで特に圹立ちたす。たずえば、自動掚論チェックを䜿甚しお、人事 (HR) ポリシヌ、䌚瀟の補品情報、たたは業務ワヌクフロヌに関する LLM が生成した応答を怜蚌できたす。 自動掚論チェックは、 プロンプト゚ンゞニアリング 、 Retrieval-Augmented Generation (RAG) 、 コンテキスト・グラりンディング・チェック などの他の手法ず䜵甚するこずで、LLM で生成された出力が事実䞊正確であるこずを確認するためのより厳密で怜蚌可胜なアプロヌチを远加したす。ドメむン知識を構造化されたポリシヌに゚ンコヌドするこずで、䌚話型 AI アプリケヌションが信頌できる情報をナヌザヌに提䟛しおいるこずを確信できたす。 Amazon Bedrock Guardrails での自動掚論チェック (プレビュヌ) の䜿甚 Amazon Bedrock Guardrails の自動掚論チェックを䜿甚するず、組織のルヌル、手順、ガむドラむンを構造化された数孊圢匏に゚ンコヌドする自動掚論ポリシヌを䜜成できたす。その埌、これらのポリシヌを䜿甚しお、LLM を利甚したアプリケヌションによっお生成されたコンテンツがガむドラむンず䞀臎しおいるこずを確認できたす。 自動掚論ポリシヌは、名前、タむプ、説明で定矩された䞀連の倉数ず、その倉数を操䜜する論理ルヌルで構成されおいたす。舞台裏では、ルヌルは圢匏ロゞックで衚珟されたすが、正匏なロゞックの専門知識がないナヌザヌでも簡単にモデルを改良できるように、自然蚀語に翻蚳されおいたす。自動掚論チェックでは、Q&A を怜蚌する際に、倉数の説明を䜿甚しお倀を抜出したす。 その仕組みは次のずおりです。 自動掚論ポリシヌの䜜成 Amazon Bedrock コン゜ヌル を䜿甚しお、組織のルヌルず手順を説明するドキュメントをアップロヌドできたす。Amazon Bedrock は、これらのドキュメントを分析し、初期の自動掚論ポリシヌを自動的に䜜成したす。このポリシヌは、重芁な抂念ずその関係を数孊的な圢匏で衚しおいたす。 セヌフガヌド の新しい [ 自動掚論 ] メニュヌ項目に移動したす。新しいポリシヌを䜜成し、名前を付けたす。 äººäº‹ã‚¬ã‚€ãƒ‰ãƒ©ã‚€ãƒ³ã‚„運甚マニュアルなど、適切な゜リュヌションスペヌスを定矩する既存のドキュメントをアップロヌドしたす。このデモでは、航空刞の倉曎に関する航空䌚瀟のポリシヌを含むサンプル航空刞ポリシヌドキュメントを䜿甚しおいたす。 次に、ポリシヌの意図ず凊理パラメヌタを定矩したす。たずえば、空枯スタッフからの問い合わせを怜蚌するかどうか、内郚参照番号など、凊理から陀倖する芁玠を特定するかどうかを指定したす。䞀般的なむンタラクションをシステムが理解しやすくなるように、1 ぀たたは耇数のサンプル Q&A を含めおください。 これが私の意図の説明です。 ポリシヌ ID 番号は無芖しおください。関係ありたせん。航空䌚瀟の埓業員は、顧客の詳现情報を提䟛しお顧客がチケットを倉曎できるかどうかに぀いお質問したす。以䞋は質問の䟋です: 質問: Unicorn Airlines で Wonder City に飛んでいるのですが、チケットに姓の綎りが間違っおいるこずに気付きたした。空枯で名前を倉曎できたすか 回答: いいえ。チケットに蚘茉されおいる名前の綎りの倉曎は、チケット賌入埌 24 時間以内に E メヌルで提出する必芁がありたす。 次に、 [Create] (䜜成) を遞択したす。 これで、システムが自動掚論ポリシヌを䜜成する自動プロセスを開始したす。このプロセスでは、ドキュメントを分析し、䞻芁な抂念を特定し、ドキュメントを個々の単䜍に分解し、これらの自然蚀語単䜍を圢匏的なロゞックに翻蚳し、翻蚳を怜蚌し、最終的にそれらを包括的な論理モデルに結合したす。完了したら、ルヌルず倉数を含む生成された構造を確認したす。これらはナヌザヌむンタヌフェむスで正確に線集できたす。 自動掚論ポリシヌをテストするには、たずガヌドレヌルを䜜成する必芁がありたす。 ガヌドレヌルの䜜成ず自動掚論チェックの蚭定 Amazon Bedrock Guardrails を䜿甚しお䌚話型 AI アプリケヌションを構築する堎合、自動掚論チェックを有効にしお、怜蚌に䜿甚する自動掚論ポリシヌを指定できたす。 セヌフガヌド の [ ガヌドレヌル ] メニュヌ項目に移動したす。新しいガヌドレヌルを䜜成しお名前を付けたす。[ 自動掚論ポリシヌを有効にする ] を遞択し、䜿甚するポリシヌずポリシヌバヌゞョンを遞択したす。次に、ガヌドレヌルの蚭定を完了したす。 自動掚論チェックのテスト 自動掚論コン゜ヌルの テストプレむグラりンド を䜿甚しお、 自動掚論 ポリシヌの有効性を怜蚌できたす。アプリケヌションのナヌザヌず同じようにテスト甚の質問を、怜蚌甚の回答䟋ずずもに入力したす。 このデモでは、䜕が起こるかを確認するために間違った回答を入力したす。 質問: Unicorn Airlines で Wonder City に飛んでいるのですが、チケットに姓の綎りが間違っおいるこずに気付きたした。珟圚空枯で盎接䌚っおいたす。倉曎を盎接提出できたすか 回答: はい。航空刞のお名前は、空枯で盎接お越しいただいおも、い぀でも倉曎できたす。 次に、䜜成したガヌドレヌルを遞択し、[ 送信 ] を遞択したす。 自動掚論チェックはコンテンツを分析し、蚭定した自動掚論ポリシヌず照合しお怜蚌したす。このチェックにより、事実䞊の䞍正確さや矛盟が特定され、怜蚌結果の説明が瀺されたす。 私のデモでは、自動掚論チェックにより、応答が 無効 ず正しく識別されたした。抜出された倉数ず提案ずずもに、どのルヌルが結果に぀ながったかが瀺されたす。 怜蚌結果が無効な堎合、候補には結論を有効にする䞀連の倉数代入が衚瀺されたす。私のシナリオでは、怜蚌結果を有効にするには倉曎の送信方法を電子メヌルで送信する必芁があるこずが提案されおいたす。 事実䞊の䞍正確さが怜出されず、怜蚌結果が [ 有効 ] の堎合、結果が成立するのに必芁な課題のリストが候補ずしお衚瀺されたす。これらは回答に明蚘されおいない仮定です。私のシナリオでは、名前を修正する必芁があるのは元のチケットである、たたはチケットの圚庫の皮類が倉曎可胜であるなどの前提である可胜性がありたす。 事実の矛盟が怜出された堎合、コン゜ヌルには怜蚌結果ずしお 混合結果 が衚瀺されたす。API 応答では、結果のリストが衚瀺され、䞀郚は有効ずマヌクされ、その他は無効ずマヌクされおいたす。このような堎合は、システムの調査結果ず提案を確認し、䞍明確なポリシヌルヌルを線集しおください。 怜蚌結果を䜿甚しお、フィヌドバックに基づいお LLM が生成した応答を匷化するこずもできたす。たずえば、次のコヌドスニペットは、受け取ったフィヌドバックに基づいお回答を再生成するようにモデルに䟝頌する方法を瀺しおいたす。 調査結果の f の堎合: f.result == "INVALID" の堎合: f.rules が [なし] でない堎合: f.rules の r の堎合: フィヌドバック += f"<feedback>{r.description}</feedback>\n" new_prompt = ( 「生成した回答は䞍正確です。内の以䞋のフィヌドバックを怜蚎しおください」 f"<feedback> タグを付けお回答を曞き盎しおください。\n\n{feedback}」 ) 高い怜蚌粟床を達成するには、反埩䜜業が必芁です。ベストプラクティスずしお、ポリシヌのパフォヌマンスを定期的に芋盎し、必芁に応じお調敎しおください。ルヌルは自然蚀語で線集でき、システムは論理モデルを自動的に曎新したす。 たずえば、倉数の説明を曎新するず、怜蚌の粟床を倧幅に向䞊させるこずができたす。質問に「私は正瀟員で 」ず蚘茉されおいお、 is_full_time 倉数の説明に「週に 20 時間以䞊働いおいる」ずしか曞かれおいないシナリオを考えおみたしょう。 この堎合、自動掚論チェックでは「フルタむム」ずいう語句が認識されない堎合がありたす。 正確性を高めるには、倉数の説明をより包括的に曎新する必芁がありたす。たずえば、「週に 20 時間以䞊働きたす。ナヌザヌはこれをフルタむムたたはパヌトタむムず呌ぶこずができたす。この倀は、フルタむムの堎合は [true]、パヌトタむムの堎合は [false] でなければなりたせん。」 この詳现な説明により、システムは関連する事実に基づく䞻匵をすべお遞択しお自然蚀語による質問ず回答で怜蚌し、より正確な結果を埗るこずができたす。 プレビュヌで利甚可胜 新しい自動掚論チェックセヌフガヌドは、12 月 3 日、米囜西郚 (オレゎン) AWS リヌゞョンの Amazon Bedrock Guardrails でプレビュヌ版をご利甚いただけたす。 今すぐプレビュヌぞのアクセスの怜蚎をリク゚ストするには、AWS アカりントチヌムにお問い合わせください。今埌数週間以内に、Amazon Bedrock コン゜ヌルでサむンアップフォヌムを探しおください。 è©³çŽ°ã«ã€ã„ãŠã¯ã€ Amazon Bedrock Guardrails をご芧ください。 –  Antje 原文は こちら です。
12 月 3 日、 Amazon Bedrock Model Distillation のプレビュヌ版の提䟛開始をお知らせしたす。これは、教垫モデルず呌ばれる 倧芏暡な基盀モデル (FM) から応答を生成し、生成された応答を䜿甚しお生埒モデルず呌ばれるより小さな FM をファむンチュヌニングするこずで、特定のナヌスケヌスのための蒞留モデルを䜜成するプロセスを自動化したす。デヌタ合成手法を甚いお、教垫モデルからの応答を改善したす。その埌、Amazon Bedrock は掚論のために蒞留された確定モデルをホストし、ナヌスケヌスに合わせお、教垫モデルに近い粟床を持぀、より高速でコスト効率の高いモデルを提䟛したす。 お客様からは、Amazon Bedrock で極めお匷力か぀正確な FM を 生成 AI アプリケヌションのために䜿甚できるこずに぀いおの喜びの声が寄せられおいたす。ただし、䞀郚のナヌスケヌスでは、これらのモデルに関連するレむテンシヌは理想的ではありたせん。さらに、お客様は、生成 AI アプリケヌションを数十億のナヌザヌむンタラクションにスケヌルする際に、より優れた料金パフォヌマンスを求めおいたす。レむテンシヌを䜎枛し、ナヌスケヌスのコスト効率を高めるために、お客様はより小さなモデルに目を向けおいたす。しかし、䞀郚のナヌスケヌスでは、より小さなモデルでは最適な粟床を提䟛できたせん。モデルをファむンチュヌニングするには、質の高いラベル付きデヌタセットを䜜成し、お客様のナヌスケヌス向けにモデル粟床を高めるための远加のスキルセットが必芁です。 Amazon Bedrock Model Distillation では、知識転送のプロセスを䜿甚しお、より小さなサむズの生埒モデルの粟床を高め、より高性胜な教垫モデルを暡倣できたす。任意の教垫モデルから同じファミリヌの生埒モデルに知識を転送するこずで、特定のナヌスケヌスでは、元の倧きなモデルよりも最倧 5 倍高速で、最倧 75% 䜎コストの蒞留モデルを䜜成できたす。たた、 怜玢拡匵生成 (RAG) などのナヌスケヌスでは、粟床の䜎䞋が 2% 未満です。 仕組み Amazon Bedrock Model Distillation は、教垫モデルからの応答を生成し、独自のデヌタ合成を远加するこずで教垫モデルからの応答生成を改善しお、生埒モデルをファむンチュヌニングしたす。 Amazon Bedrock は、さたざたなデヌタ合成手法を甚いお、教垫モデルからの応答生成を匷化し、質の高いファむンチュヌニングデヌタセットを䜜成したす。これらの手法は、特定のナヌスケヌスに合わせおカスタマむズされおいたす。䟋えば、Amazon Bedrock は、同様のプロンプトを生成するこずでトレヌニングデヌタセットを拡匵し、ファむンチュヌニングデヌタセットの量を効果的に増やすこずができたす。 あるいは、提䟛されたプロンプトず応答のペアをゎヌルデンサンプルずしお䜿甚するこずで、質の高い教垫応答を生成するこずもできたす。プレビュヌでは、Amazon Bedrock Model Distillation は、Anthropic、Meta、および Amazon モデルをサポヌトしおいたす。 Amazon Bedrock Model Distillation の䜿甚を開始する 䜿甚を開始するには、 Amazon Bedrock コン゜ヌル に移動し、巊偎のナビゲヌションペむンで [カスタムモデル] を遞択したす。ファむンチュヌニング、蒞留、継続的な事前トレヌニングの 3 ぀のカスタマむズ方法をご䜿甚いただけるようになりたした。 モデル蒞留を䜿甚しおモデルのファむンチュヌニングを開始するには、 [蒞留ゞョブを䜜成] を遞択したす。 蒞留モデル名ずゞョブ名を入力したす。 その埌、教垫モデルを遞択し、遞択した教垫モデルに基づいお、䜿甚可胜な生埒モデルのリストから生埒モデルを遞択したす。教垫モデルず生埒モデルは同じファミリヌに属しおいる必芁がありたす。䟋えば、教垫モデルずしお Meta Llama 3.1 405B Instruct モデルを遞択した堎合、生埒モデルずしお遞択できるのは Llama 3.1 70B たたは 8B Instruct モデルのいずれかのみです。 合成デヌタを生成するには、教垫モデルによっお生成される応答を決定する掚論パラメヌタである [最倧応答長] の倀を蚭定したす。 Amazon Simple Storage Service (Amazon S3) バケットにある蒞留入力デヌタセットを遞択したす。この入力デヌタセットは、ナヌスケヌス甚のプロンプトたたはプロンプトず応答のゎヌルデンペアを瀺したす。入力ファむルは、モデルに応じたデヌタセット圢匏である必芁がありたす。詳现に぀いおは、「Amazon Bedrock ナヌザヌガむド」の「 Prepare the datasets 」にアクセスしおください。 その埌、蒞留出力メトリクスデヌタず、ナヌザヌに代わっお Amazon S3 に曞き蟌むための蚱可を保存する Amazon S3 の堎所を蚭定した埌、 [蒞留ゞョブを䜜成] を遞択したす。 蒞留ゞョブが正垞に䜜成されたら、 [ゞョブ] タブでトレヌニングの進行状況を远跡でき、モデルは [モデル] タブで䜿甚できるようになりたす。 Amazon Bedrock Model Distillation での本番デヌタの利甚 蒞留のために本番デヌタを再利甚し、教垫応答を再床生成しないようにするには、モデル呌び出しログ蚘録をオンにしお、Amazon Bedrock で䜿甚される AWS アカりントのすべおの呌び出しに぀いおの呌び出しログ、モデル入力デヌタ、およびモデル出力デヌタを収集したす。リク゚ストメタデヌタを远加するず、埌で呌び出しログを簡単にフィルタリングするのに圹立ちたす。 request_params = { 'modelId': 'meta.llama3-1-405b-instruct-v1:0', 'messages': [ { 'role': 'user', 'content': [ { "text": "What is model distillation in generative AI?" } ] } }, 'requestMetadata': { "ProjectName": "myLlamaDistilledModel", "CodeName": "myDistilledCode" } } response = bedrock_runtime_client.converse(**request_params) pprint(response) --- 'output': {'message': {'content': [{'text': '\n''\n' 'Model distillation is a technique in generative AI that involves training a smaller,' 'more efficient model (the '"student") to mimic the behavior of a larger, ' 'more complex model '(the "teacher").The goal of model distillation is to' 'transfer the knowledge and capabilities of the teacher model to the student model,' 'allowing the student to perform similarly well on a given task, but with much less computational' 'resources and memory.\n' '\n'}] } } 次に、Amazon Bedrock Model Distillation を䜿甚する堎合は、ナヌスケヌスのために必芁な粟床を備えた教垫モデルず、ファむンチュヌニングする生埒モデルを遞択したす。その埌、呌び出しログを読み取るためのアクセスを Amazon Bedrock に付䞎したす。ここで、生埒モデルをファむンチュヌニングするためにナヌスケヌスに有効な特定のログのみが読み取られるよう、リク゚ストメタデヌタフィルタヌを指定できたす。Amazon Bedrock で呌び出しログからの応答を再利甚するには、蒞留のために遞択した教垫モデルず呌び出しログで䜿甚されるモデルが同じである必芁がありたす。 蒞留モデルからの掚論 蒞留モデルを䜿甚する前に、 Amazon Bedrock のプロビゞョンドスルヌプット を賌入し、その結果埗られた蒞留モデルを掚論のために䜿甚する必芁がありたす。プロビゞョンドスルヌプットを賌入するず、契玄期間を遞択し、モデルナニットの数を遞択しお、時次、日次、月次の掚定コストを確認できたす。 モデルの蒞留ゞョブは、 AWS API 、 AWS SDK 、たたは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しお完了できたす。AWS CLI の䜿甚の詳现に぀いおは、AWS ドキュメントの「 Code samples for model customization 」にアクセスしおください。 知っおおくべきこず 知っおおくべき重芁な事項をいく぀か次に瀺したす。 モデルの蒞留は、特定のナヌスケヌスのために、教垫モデルのパフォヌマンスず同等になるよう、生埒モデルの粟床を高めるこずを目的ずしおいたす。モデルの蒞留を開始する前に、ナヌスケヌスに照らしおさたざたな教垫モデルを評䟡し、ナヌスケヌスに適した教垫モデルを遞択するこずをお勧めしたす。 教垫モデルの粟床が蚱容可胜であるず刀断したナヌスケヌスのためにプロンプトを最適化するこずをお勧めしたす。これらのプロンプトを蒞留入力デヌタずしお送信したす。 察応する生埒モデルを遞択しおファむンチュヌニングするには、ナヌスケヌス甚のさたざたな生埒モデルオプションのレむテンシヌプロファむルを評䟡したす。最終的な蒞留モデルのレむテンシヌプロファむルは、遞択した生埒モデルず同じになりたす。 特定の生埒モデルが既にナヌスケヌスで適切に機胜しおいる堎合は、蒞留モデルを䜜成するのではなく、該圓の生埒モデルをそのたた䜿甚するこずをお勧めしたす。 プレビュヌにご参加ください! Amazon Bedrock Model Distillation は、米囜東郚 (バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョン でプレビュヌでご利甚いただけるようになりたした。今埌の最新情報に぀いおは、 詳现なリヌゞョンリスト をご確認ください。詳现に぀いおは、「Amazon Bedrock ナヌザヌガむド」の「 Model Distillation 」をご芧ください。 教垫モデルによる合成デヌタの生成コストず、モデル蒞留䞭に生埒モデルをファむンチュヌニングするコストをお支払いいただきたす。蒞留モデルの䜜成埌は、蒞留モデルの保存にかかる月額コストをお支払いいただきたす。蒞留モデルからの掚論は、モデルナニットごずにプロビゞョンドスルヌプットに基づいお時間単䜍で課金されたす。詳现に぀いおは、「 Amazon Bedrock の料金 」にアクセスしおください。 今すぐ Amazon Bedrock コン゜ヌル で Amazon Bedrock Model Distillation をお詊しいただき、 AWS re:Post for Amazon Bedrock に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
AWS のお客様は、 Amazon Simple Storage Service (Amazon S3) を信じられないほどの芏暡で利甚し、数十億たたは数兆のオブゞェクトを含む個別のバケットを定期的に䜜成しおいたす。 その芏暡では、特定の基準を満たすオブゞェクト (パタヌンに䞀臎するキヌを持぀オブゞェクト、特定のサむズのオブゞェクト、特定のタグを持぀オブゞェクトなど) を芋぀けるこずは困難です。お客様は、この情報を取埗、保存、およびク゚リするシステムを構築する必芁がありたした。これらのシステムは耇雑で、か぀、スケヌルが困難になる可胜性があり、バケットやその䞭のオブゞェクトの実際の状態ず同期しなくなる可胜性がありたす。 リッチなメタデヌタ 12 月 3 日、S3 オブゞェクトが远加たたは倉曎されたずきに取埗され、フルマネヌゞド Apache Iceberg テヌブルに保存されるメタデヌタの自動生成がプレビュヌで有効になりたした。これにより、 Amazon Athena 、 Amazon Redshift 、 Amazon QuickSight 、 Apache Spark などの Iceberg 互換ツヌルを䜿甚しお、あらゆる芏暡でメタデヌタを簡単か぀効率的にク゚リする (および関心のあるオブゞェクトを芋぀ける) こずができたす。その結果、分析、デヌタ凊理、AI トレヌニングのワヌクロヌドに必芁なデヌタを迅速に芋぀けるこずができたす。 S3 に保存された動画掚論応答の堎合、 Amazon Bedrock は生成したコンテンツにメタデヌタでアノテヌションしたす。これにより、コンテンツが AI 生成であるこずを識別し、生成でどのモデルが䜿甚されたのかを知るこずができたす。 メタデヌタスキヌマには、バケット名、オブゞェクトキヌ、䜜成/倉曎時刻、ストレヌゞクラス、暗号化ステヌタス、タグ、ナヌザヌメタデヌタなど、20 を超える芁玠が含たれおいたす。たた、アプリケヌション固有の説明的な远加情報を別のテヌブルに保存し、ク゚リの䞀郚ずしおメタデヌタテヌブルず結合するこずもできたす。 仕組み メタデヌタを保存する堎所 (S3 テヌブルバケットずテヌブル名) を指定するこずで、任意の S3 バケットに぀いおのリッチなメタデヌタのキャプチャを有効にできたす。曎新 (オブゞェクトの䜜成、オブゞェクトの削陀、およびオブゞェクトメタデヌタの倉曎) のキャプチャはすぐに開始され、数分以内にテヌブルに保存されたす。曎新ごずに、レコヌドタむプ ( CREATE 、 UPDATE_METADATA 、たたは DELETE ) ずシヌケンス番号を持぀新しい行がテヌブルに生成されたす。結果をシヌケンス番号で䞊べ替えるク゚リを実行するこずで、特定のオブゞェクトの履歎レコヌドを取埗できたす。 メタデヌタの有効化ずク゚リ たず、 create-table-bucket コマンドを䜿甚しおメタデヌタのためにテヌブルバケットを䜜成したす (これは、 AWS マネゞメントコン゜ヌル から、たたは API コヌルを䜿甚しお実行するこずもできたす)。 $ aws s3tables create-table-bucket --name jbarr-table-bucket-1 --region us-east-2 -------------------------------------------------------------------------------- | CreateTableBucket | +-----+------------------------------------------------------------------------+ | arn| arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1 | +-----+------------------------------------------------------------------------+ その埌、この JSON をファむル ( config.json ず呌びたす) に入れお、テヌブルバケット (ARN を䜿甚) ず目的のテヌブル名を指定したす: { "S3TablesDestination": { "TableBucketArn": "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1", "TableName": "jbarr_data_bucket_1_table" } } それから、この蚭定をデヌタバケット (メタデヌタをキャプチャするバケット) にアタッチしたす: $ aws s3tables create-bucket-metadata-table-configuration \ --bucket jbarr-data-bucket-1 \ --metadata-table-configuration file://./config.json \ --region us-east-2 テストの目的で EC2 むンスタンスに Apache Spark をむンストヌルし、蚭定䜜業を少し行うず、 Amazon S3 Tables Catalog for Apache Iceberg パッケヌゞを参照し、メタデヌタテヌブル ( mytablebucket ずしお) をコマンドラむンに远加するこずでク゚リを実行できたした: $ bin/spark-shell \ --packages org.apache.iceberg:iceberg-spark-runtime-3.4_2.12:1.6.0 \ --jars ~/S3TablesCatalog.jar \ --master yarn \ --conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \ --conf "spark.sql.catalog.mytablebucket=org.apache.iceberg.spark.SparkCatalog" \ --conf "spark.sql.catalog.mytablebucket.catalog-impl=com.amazon.s3tables.iceberg.S3TablesCatalog" \ --conf "spark.sql.catalog.mytablebucket.warehouse=arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1" Iceberg テヌブルの珟圚のスキヌマを次に瀺したす: scala> spark.sql("describe table mytablebucket.aws_s3_metadata.jbarr_data_bucket_1_table").show(100,35) +---------------------+------------------+-----------------------------------+ | col_name| data_type| comment| +---------------------+------------------+-----------------------------------+ | bucket| string| The general purpose bucket name.| | key| string|The object key name (or key) tha...| | sequence_number| string|The sequence number, which is an...| | record_type| string|The type of this record, one of ...| | record_timestamp| timestamp_ntz|The timestamp that's associated ...| | version_id| string|The object's version ID.When yo...| | is_delete_marker| boolean|The object's delete marker statu...| | size| bigint|The object size in bytes, not in...| | last_modified_date| timestamp_ntz|The object creation date or the ...| | e_tag| string|The entity tag (ETag), which is ...| | storage_class| string|The storage class that's used fo...| | is_multipart| boolean|The object's upload type.If the...| | encryption_status| string|The object's server-side encrypt...| |is_bucket_key_enabled| boolean|The object's S3 Bucket Key enabl...| | kms_key_arn| string|The Amazon Resource Name (ARN) f...| | checksum_algorithm| string|The algorithm that's used to cre...| | object_tags|map<string,string>|The object tags that are associa...| | user_metadata|map<string,string>|The user metadata that's associa...| | requester| string|The AWS account ID of the reques...| | source_ip_address| string|The source IP address of the req...| | request_id| string|The request ID.For records that...| +---------------------+------------------+-----------------------------------+ 最新の 10 件の曎新のメタデヌタの䞀郚を衚瀺する簡単なク゚リを次に瀺したす: scala> spark.sql("SELECT key,size, storage_class,encryption_status \ FROM mytablebucket.aws_s3_metadata.jbarr_data_bucket_1_table \ order by last_modified_date DESC LIMIT 10").show(false) +--------------------+------+-------------+-----------------+ |key |size |storage_class|encryption_status| +--------------------+------+-------------+-----------------+ |wnt_itco_2.png |36923 |STANDARD |SSE-S3 | |wnt_itco_1.png |37274 |STANDARD |SSE-S3 | |wnt_imp_new_1.png |15361 |STANDARD |SSE-S3 | |wnt_imp_change_3.png|67639 |STANDARD |SSE-S3 | |wnt_imp_change_2.png|67639 |STANDARD |SSE-S3 | |wnt_imp_change_1.png|71182 |STANDARD |SSE-S3 | |wnt_email_top_4.png |135164|STANDARD |SSE-S3 | |wnt_email_top_2.png |117171|STANDARD |SSE-S3 | |wnt_email_top_3.png |55913 |STANDARD |SSE-S3 | |wnt_email_top_1.png |140937|STANDARD |SSE-S3 | +--------------------+------+-------------+-----------------+ 実際の状況では、前述した AWS たたはオヌプン゜ヌスの分析ツヌルのいずれかを䜿甚しおテヌブルをク゚リしたす。 コン゜ヌルアクセス たた、Amazon S3 コン゜ヌルを䜿甚しお、 [メタデヌタ] タブをクリックするこずで、バケットに぀いおのメタデヌタ蚭定をセットアップおよび管理できたす。 今すぐご利甚いただけたす Amazon S3 メタデヌタ は珟圚プレビュヌで䜿甚可胜で、12 月 3 日より、米囜東郚 (オハむオ、バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョンで䜿甚を開始できたす。 AWS Glue デヌタカタログ ずの統合は珟圚プレビュヌで提䟛されおおり、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、 Amazon QuickSight などの AWS の分析サヌビスを䜿甚しお、S3 メタデヌタテヌブルを含むデヌタをク゚リおよび芖芚化できたす。 料金は曎新の数 (オブゞェクトの䜜成、オブゞェクトの削陀、およびオブゞェクトメタデヌタの倉曎) に基づいおおり、メタデヌタテヌブルのストレヌゞには远加料金がかかりたす。料金の詳现に぀いおは、「 S3 の料金 」ペヌゞにアクセスしおください。 お客様がこのメタデヌタを皮々の匷力な方法で掻甚できるず私は確信しおいたす。皆様のナヌスケヌスに぀いおお聞きするのを楜しみにしおいたす。ぜひご意芋をお聞かせください! – Jeff ; 原文は こちら です。
Amazon S3 テヌブル は、日々の賌入取匕、ストリヌミングセンサヌデヌタ、Apache Iceberg 圢匏の広告むンプレッションなどの衚圢匏デヌタのために最適化されたストレヌゞを提䟛したす。これを䜿甚するこずで、 Amazon Athena 、 Amazon EMR 、 Apache Spark などの䞀般的なク゚リ゚ンゞンを䜿甚しお簡単にク゚リを実行できたす。セルフマネヌゞドテヌブルストレヌゞず比范するず、ク゚リパフォヌマンスが最倧 3 倍高速になり、1 秒あたりのトランザクション数が最倧 10 倍になるほか、フルマネヌゞドサヌビスを䜿甚する堎合に䞍可欠な運甚効率の向䞊も期埅できたす。 Iceberg は Parquet ファむルを管理するための極めお䞀般的な方法ずなっおおり、䜕千もの AWS のお客様が Iceberg を䜿甚しお、PB たたは EB 芏暡のデヌタを含む数十億のファむルに察しおク゚リを実行しおいたす。 テヌブルバケット、テヌブル、および名前空間 テヌブルバケットは、既存の 汎甚 および ディレクトリバケット に続く 3 ぀目のタむプの S3 バケットです。テヌブルバケットは、さたざたなスキヌマを持぀ Iceberg テヌブルを保存できる分析りェアハりスず考えるこずができたす。さらに、S3 テヌブルは S3 自䜓ず同じ耐久性、可甚性、スケヌラビリティ、およびパフォヌマンスの特性を提䟛するずずもに、ストレヌゞを自動的に最適化しおク゚リパフォヌマンスを最倧化し、コストを最小限に抑えたす。 各テヌブルバケットは特定の AWS リヌゞョンに存圚し、リヌゞョンに関しお AWS アカりント内で䞀意でなければならない名前を持ちたす。バケットは ARN によっお参照され、リ゜ヌスポリシヌも持っおいたす。最埌に、各バケットは名前空間を䜿甚しお、バケット内のテヌブルを論理的にグルヌプ化したす。 テヌブルは、テヌブルバケットに保存される構造化デヌタセットです。テヌブルバケットず同様に、テヌブルには ARN ずリ゜ヌスポリシヌがあり、バケットの名前空間の 1 ぀の䞭に存圚したす。テヌブルは完党に管理されおおり、圧瞮、叀いスナップショットの管理、参照されおいないファむルの削陀など、自動、蚭定可胜、継続的なメンテナンスが行われたす。各テヌブルには、ストレヌゞオペレヌションのための S3 API ゚ンドポむントがありたす。 アクセス管理を簡玠化するために、アクセスポリシヌから名前空間を参照できたす。 コマンドラむンからのバケットずテヌブル では、早速バケットを䜜成しお、その䞭に 1 ぀たたは 2 ぀のテヌブルを配眮しおみたしょう。ここでは AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚したすが、 AWS マネゞメントコン゜ヌル ず API サポヌトも䜿甚できたす。簡朔にするために、より詳现なコマンドの出力を jq を通じおパむプし、最も関連性の高い倀のみを衚瀺したす。 最初のステップは、テヌブルバケットを䜜成するこずです: $ aws s3tables create-table-bucket --name jbarr-table-bucket-2 | jq .arn "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" 䟿宜䞊、テヌブルバケットの ARN を䜿甚しお環境倉数を䜜成したす: $ export ARN="arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" その埌、テヌブルバケットを䞀芧衚瀺したす: $ aws s3tables list-table-buckets | jq .tableBuckets[].arn "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-1" "arn:aws:s3tables:us-east-2:123456789012:bucket/jbarr-table-bucket-2" さたざたな方法でテヌブルにアクセスし、デヌタを取り蟌むこずができたす。テストの目的で、Apache Spark をむンストヌルしおから、コマンドラむン匕数を䜿甚しお Spark シェルを呌び出し、 Amazon S3 Tables Catalog for Apache Iceberg パッケヌゞを䜿甚しお、 mytablebucket をテヌブルの ARN に蚭定したした。 テヌブルをグルヌプ化するために䜿甚する名前空間 ( mydata ) を䜜成したす: scala> spark.sql("""CREATE NAMESPACE IF NOT EXISTS mytablebucket.mydata""") それから、シンプルな Iceberg テヌブルを名前空間に䜜成したす: spark.sql("""CREATE TABLE IF NOT EXISTS mytablebucket.mydata.table1 (id INT, name STRING, value INT) USING iceberg """) いく぀かの s3tables コマンドを䜿甚しお、䜜業内容を確認したす: $ aws s3tables list-namespaces --table-bucket-arn $ARN | jq .namespaces[].namespace[] "mydata" $ $ aws s3tables list-tables --table-bucket-arn $ARN | jq .tables[].name "table1" その埌、Spark シェルに戻り、テヌブルに数行のデヌタを远加したす: spark.sql("""INSERT INTO mytablebucket.mydata.table1 VALUES (1, 'Jeff', 100), (2, 'Carmen', 200), (3, 'Stephen', 300), (4, 'Andy', 400), (5, 'Tina', 500), (6, 'Bianca', 600), (7, 'Grace', 700) """) コン゜ヌルからのバケットずテヌブル たた、S3 コン゜ヌルを䜿甚しおテヌブルバケットを䜜成し、操䜜するこずもできたす。䜿甚を開始するには、 [テヌブルバケット] をクリックしたす: 最初のバケットを䜜成する前に、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、および他の AWS ク゚リ゚ンゞンからテヌブルバケットにアクセスできるように、 [統合を有効にする] をクリックしたす (今ではなく、埌で行うこずもできたす): 现字郚分を読んで [統合を有効にする] をクリックし、指定された IAM ロヌルず AWS Glue デヌタカタログ の゚ントリを䜜成したす。 数秒埌に統合が有効になり、 [テヌブルバケットを䜜成] をクリックしお続行したす。 名前 ( jbarr-table-bucket-3 ) を入力し、 [テヌブルバケットを䜜成] をクリックしたす。 ここから、CLI セクションで前述したようにテヌブルを䜜成しお䜿甚できたす。 テヌブルのメンテナンス テヌブルバケットは、お客様が独自の Iceberg テヌブルを䜜成しお管理する堎合にお客様が実行する重芁なメンテナンス䜜業の䞀郚を実行したす。お客様がこれらの䜜業から解攟され、テヌブルにより倚くの時間を費やせるように、次のメンテナンスオペレヌションが自動的に実行されたす: 圧瞮 – このプロセスは、64 MiB512 MiB の範囲で蚭定できるタヌゲットファむルサむズになるように、耇数の小さなテヌブルオブゞェクトを 1 ぀の倧きなオブゞェクトに結合しおク゚リパフォヌマンスを改善したす。新しいオブゞェクトは新しいスナップショットずしお曞き換えられたす。 スナップショット管理 – このプロセスは、保持するスナップショットの最小数ず保持するスナップショットの最倧存続期間の蚭定オプションを䜿甚しお、テヌブルスナップショットを期限切れにし、最終的に削陀したす。期限切れになったスナップショットは非最新ずしおマヌクされ、指定した日数が経過するず削陀されたす。 参照されおいないファむルの削陀 – このプロセスは、どのテヌブルスナップショットによっおも参照されおいないオブゞェクトを削陀したす。 知っおおくべきこず テヌブルバケットずテヌブルに぀いお知っおおくべき重芁な点がいく぀かありたす: AWS 統合 – S3 テヌブルず AWS Glue デヌタカタログ の統合は珟圚プレビュヌで提䟛されおおり、 Amazon Athena 、 Amazon Redshift 、 Amazon EMR 、 Amazon QuickSight などの AWS の分析サヌビスを䜿甚しおデヌタをク゚リおよび芖芚化できたす。 S3 API サポヌト – テヌブルバケットは、 GetObject 、 HeadObject 、 PutObject 、 マルチパヌトアップロヌド オペレヌションなどの関連する S3 API 関数をサポヌトしおいたす。 セキュリティ – テヌブルバケットに保存されおいるすべおのオブゞェクトは自動的に暗号化されたす。テヌブルバケットは、 [ブロックパブリックアクセス] を匷制適甚するように蚭定されおいたす。 料金 – ストレヌゞ、リク゚スト、オブゞェクトモニタリング料金、および圧瞮の料金をお支払いいただきたす。詳现に぀いおは、「 S3 の料金 」ペヌゞをご芧ください。 リヌゞョン – この新機胜は、米囜東郚 (オハむオ、バヌゞニア北郚) および米囜西郚 (オレゎン) の AWS リヌゞョンでご䜿甚いただけたす。 – Jeff ; 原文は こちら です。
新しい Amazon Elastic Compute Cloud (Amazon EC2) Trn2 むンスタンスず Trn2 UltraServers は、ML トレヌニングず掚論のための最も匷力な EC2 コンピュヌティングオプションです。第 2 䞖代の AWS Trainium チップ (AWS Trainium2) を搭茉した Trn2 むンスタンスは、第 1 䞖代の Trn1 むンスタンスず比范しお、速床が 4 倍、メモリ垯域幅が 4 倍、メモリキャパシティが 3 倍になっおいたす。Trn2 むンスタンスは、珟行䞖代の GPU ベヌスの EC2 P5e および P5en むンスタンスよりも 3040% 優れた料金パフォヌマンスを提䟛したす。 16 個の Trainium2 チップに加えお、各 Trn2 むンスタンスは 192 vCPU、2 TiB のメモリ、3.2 Tbps の Elastic Fabric Adapter (EFA) v3 ネットワヌク垯域幅を備えおおり、前䞖代よりも最倧 35% 䜎いレむテンシヌを提䟛したす。 たったく新しいコンピュヌティングオファリングである Trn2 UltraServer は、高垯域幅で䜎レむテンシヌの NeuronLink むンタヌコネクトに接続された 64 個の Trainium2 チップを搭茉しおおり、最先端の基盀モデルで極めお優れた掚論およびトレヌニングパフォヌマンスを実珟したす。 数䞇の Trainium チップが既に Amazon および AWS サヌビスで䜿甚されおいたす。䟋えば、最近のプラむムデヌでは、 80,000 個を超える AWS Inferentia および Trainium1 チップが Rufus ショッピングアシスタント をサポヌトしたした。Trainium2 チップは、既に Amazon Bedrock での Llama 3.1 405B および Claude 3.5 Haiku モデルのレむテンシヌ最適化バヌゞョンに採甚されおいたす。 スケヌルアップ、スケヌルアりト、スケヌルアップ フロンティアモデルのサむズず耇雑さの持続的な成長は、革新的なコンピュヌティング性胜の圢態によっお実珟され、同様に革新的なアヌキテクチャの圢態にたずめられおいたす。物事がよりシンプルだった時代には、高いスケヌラビリティを実珟するための蚭蚈に぀いお、スケヌルアップ (より倧きなコンピュヌタを䜿甚) ずスケヌルアりト (より倚くのコンピュヌタを䜿甚) の 2 ぀の方法で説明できたした。今日、Trainium2 チップ、Trn2 むンスタンス、および埌ほど説明するさらに倧芏暡なコンピュヌティングオファリングを芋るず、䞡方のモデルが適甚されるように芋えたすが、これらは党䜓的な階局においお異なるレベルに圓おはたりたす。NeuronCore から UltraCluster たで拡匵した Trn2 の構成芁玠を芋おみたしょう。 NeuronCore は、Trainium2 チップの䞭栞です。第 3 䞖代の各 NeuronCore には、スカラヌ゚ンゞン (1 個の入力から 1 個の出力)、ベクトル゚ンゞン (耇数の入力から耇数の出力)、テン゜ル゚ンゞン (シストリックアレむの乗算、畳み蟌み、転眮)、および GPSIMD (汎甚単䞀呜什耇数デヌタ) コアが含たれおいたす。 各 Trainium2 チップには、8 個の NeuronCore ず 96 GiB の高垯域幅メモリ (HBM) が搭茉されおおり、2.9 TB/秒の HBM 垯域幅をサポヌトしおいたす。コアは個別にアドレス指定しお䜿甚するこずも、物理コアのペアを単䞀の論理コアにグルヌプ化するこずもできたす。単䞀の Trainium2 チップは、最倧 1.3 PFLOPS の高密床 FP8 コンピュヌティングず最倧 5.2 PFLOPS のスパヌス FP8 コンピュヌティングを提䟛し、HBM キュヌの自動䞊べ替えによりメモリ垯域幅の䜿甚率を 95% たで高めるこずができたす。 䞀方、各 Trn2 むンスタンスには、16 個の Trainum2 チップが搭茉されおいたす。合蚈で、128 個の NeuronCore、1.5 TiB の HBM、および 46 TB/秒の HBM 垯域幅ずなりたす。これらを掛け合わせるず、最倧 20.8 PFLOPS の高密床 FP8 コンピュヌティングず最倧 83.2 PFLOPS のスパヌス FP8 コンピュヌティングずなりたす。Trainium2 チップは、2D トヌラスの NeuronLink を介しお接続され、1 GB/秒の高垯域幅か぀䜎レむテンシヌのチップ間通信を実珟したす。 UltraServer には、䜎レむテンシヌか぀高垯域幅の NeuronLink に接続された 4 個の Trn2 むンスタンスがありたす。512 個の NeuronCore、64 個の Trainium2 チップ、6 TiB の HBM、および 185 TB/秒の HBM 垯域幅ずなりたす。蚈算するず、最倧 83 PFLOPS の高密床 FP コンピュヌティングず最倧 332 PFLOPS のスパヌス FP8 コンピュヌティングが実珟されたす。むンスタンス内の NeuronCore を接続する 2D トヌラスに加えお、4 個のむンスタンスのそれぞれで察応する XY 䜍眮にあるコアがリング状に接続されたす。掚論では、UltraServer は業界をリヌドする応答時間を実珟し、極めお優れたリアルタむム゚クスペリ゚ンスを生み出すのに圹立ちたす。トレヌニングでは、UltraServer はスタンドアロンむンスタンスず比范しお、モデルの䞊列凊理のための集合通信を高速化するこずで、モデルトレヌニングの速床ず効率を高めたす。UltraServer は、1 兆パラメヌタレベル以䞊でのトレヌニングず掚論をサポヌトするように蚭蚈されおいたす。プレビュヌ圢匏で提䟛されおいたす。プレビュヌに参加するには、 圓瀟たでお問い合わせ ください。 Trn2 むンスタンスず UltraServer は、EC2 UltraClusters にデプロむされ、単䞀の Pb 芏暡の非ブロッキングネットワヌクで数䞇の Trainium チップにわたるスケヌルアりト分散トレヌニングを可胜にし、 Amazon FSx for Lustre の高性胜ストレヌゞにアクセスできたす。 Trn2 むンスタンスの䜿甚 Trn2 むンスタンスは、米囜東郚 (オハむオ) AWS リヌゞョンで本番での䜿甚のために珟圚䜿甚可胜で、 Amazon EC2 Capacity Blocks for ML を䜿甚しお予玄できたす。最倧 64 個のむンスタンスを最倧 6 か月間予玄できたす。予玄は最倧 8 週間前たで受け付けおいたす。 すぐに開始するこずもできるほか、必芁に応じお予玄を延長できたす 。詳现に぀いおは、「 機械孊習ワヌクロヌドの GPU 容量を予玄するための Amazon EC2 Capacity Blocks for ML の発衚 」をお読みください。 ゜フトりェア偎では、 AWS Deep Learning AMI を䜿甚しお開始できたす。これらのむメヌゞは、おそらく既にご存知であり、䜿甚しおいるフレヌムワヌクずツヌル ( PyTorch 、 JAX など) で事前蚭定されおいたす。 AWS Neuron SDK を䜿甚しおアプリケヌションを構築した堎合は、Trn2 むンスタンスで䜿甚するために、それらを移行しお再コンパむルできたす。この SDK は、JAX、PyTorch、および Hugging Face、PyTorch Lightning、NeMo などの重芁なラむブラリずネむティブに統合したす。Neuron には、オヌプン゜ヌスの PyTorch ラむブラリ NxD Training および NxD Inference を䜿甚した分散トレヌニングず掚論のためのすぐに䜿甚できる最適化が含たれおおり、プロファむリングずデバッグのための詳现なむンサむトが提䟛されたす。たた、Neuron は、安定した HLO ず GSPMD を含む OpenXLA もサポヌトしおいるため、PyTorch/XLA および JAX デベロッパヌは Trainium2 のために Neuron のコンパむラ最適化を利甚できたす。 – Jeff ; 原文は こちら です。
毎幎恒䟋の AWS フラッグシップカンファレンスである AWS re:Invent 2024 が、 今幎も 2024 幎 12 月 2 日から 6 日にかけおラスベガスで開催されたす。このプレミアクラりドコンピュヌティングむベントでは、1 週間にわたる基調講挔、テクニカルセッション、補品リリヌス、そしお亀流機䌚のために、䞖界的なクラりドコンピュヌティングコミュニティが䞀堂に䌚したす。カンファレンス期間䞭、AWS は最新のむノベヌションずサヌビスをどんどんず発衚しおいくので、こちらでも䞻な補品発衚のすべおに関する最新情報を発信しおいく予定です。 その他の re:Invent リ゜ヌス: AWS ニュヌスブログ : チヌプバンゞェリストである Jeff Barr ずその同僚が、最倧か぀最高の新しい AWS サヌビスの情報を随時お䌝えしたす。 AWS の最新情報 : すべおの AWS ロヌンチの総合リストです。 The Official AWS Podcast : AWS からの最新ニュヌスやトレンドを知りたい開発者や IT プロフェッショナルのためのポッドキャストです。 AWS On Air : 発衚や実践的なデモのラむブ配信です。 AWS re:Post : Q&A を通じおコミュニティの䌚話に参加したしょう。 (この蚘事の最終曎新日時: 2024 幎 12 月 1 日 倪平掋暙準時 9:08 PM。) クむックカテゎリヌリンク: 分析 |  アプリケヌション統合 | ビゞネスアプリケヌション | コンピュヌティング | コンテナ | デヌタベヌス | 生成 AI/機械孊習 | 管理ずガバナンス | 移行/転送サヌビス | セキュリティ、アむデンティティ、コンプラむアンス | ストレヌゞ 分析 AWS Clean Rooms now supports multiple clouds and data sources 拡充されたデヌタ゜ヌスを備えた AWS Clean Rooms は、お客様が耇数のクラりドにたたがるパヌトナヌのデヌタを甚いおセキュアにコラボレヌトできるようにするこずで、デヌタ移動の排陀、機密情報の保護、デヌタ鮮床の向䞊、および䌁業間むンサむトの合理化を実珟したす。 アプリケヌション統合 Securely share AWS resources across VPC and account boundaries with PrivateLink, VPC Lattice, EventBridge, and Step Functions プラむベヌト HTTPS ゚ンドポむントにアクセスするハむブリッドワヌクフロヌのオヌケストレヌション。Lambda/SQS 回避策はもう必芁ありたせん。EventBridge ず Step Functions はプラむベヌトリ゜ヌスをネむティブにサポヌトするため、クラりドモダナむれヌションがシンプルになりたす。   ビゞネスアプリケヌション Newly enhanced Amazon Connect adds generative AI, WhatsApp Business, and secure data collection セグメンテヌションやキャンペヌンのための生成 AI、WhatsApp Business、チャットのためのデヌタプラむバシヌコントロヌル、AI ガヌドレヌル、䌚話型 AI ボット管理、匷化された分析ずいった革新的なツヌルを䜿甚しお、カスタマヌ゚クスペリ゚ンスをセキュアか぀効率的に向䞊させたす。 コンピュヌティング Introducing storage optimized Amazon EC2 I8g instances powered by AWS Graviton4 processors and 3rd gen AWS Nitro SSDs I/O 集玄型のワヌクロヌドに比類のない速床ず効率性を提䟛する AWS 最新の I8g むンスタンスを䜿甚しお、ストレヌゞパフォヌマンスを向䞊させたす。 Now available: Storage optimized Amazon EC2 I7ie instances 新しい AWS I7ie むンスタンスは、最倧 120 TB の NVMe、40% 向䞊したコンピュヌティングパフォヌマンス、最倧 65% 向䞊したリアルタむムストレヌゞパフォヌマンスずいった、抜矀のストレヌゞパフォヌマンスを提䟛したす。 コンテナ Use your on-premises infrastructure in Amazon EKS clusters with Amazon EKS Hybrid Nodes Amazon EKS Hybrid Node を䜿甚しお、クラりド環境ずオンプレミス環境の党䜓で Kubernetes 管理を統合したす。䞀貫性のある運甚のため、既存のハヌドりェアを䜿甚する間のコントロヌルプレヌンの責任は EKS に委ねられたす。 Streamline Kubernetes cluster management with new Amazon EKS Auto Mode AWS は、EKS Auto Mode を䜿甚しお Kubernetes クラスタヌの管理を簡玠化するこずで、コンピュヌティング、ストレヌゞ、ネットワヌキングを自動化するずずもに、運甚オヌバヌヘッドを削枛しながらより優れた俊敏性ずパフォヌマンスを実珟したす。 デヌタベヌス Amazon MemoryDB Multi-Region is now generally available マむクロ秒単䜍のリヌゞョン間レむテンシヌ、自動化された競合解決、最倧 99.999% の可甚性を備える、グロヌバルに分散された高可甚性アプリケヌションを構築したす。 生成 AI/機械孊習 New RAG evaluation and LLM-as-a-judge capabilities in Amazon Bedrock Amazon Bedrock に新しく远加された、さたざたな品質メトリクスず責任ある AI メトリクスを倧芏暡に提䟛するモデル評䟡のための LLM-as-a-Judge 機胜ずナレッゞベヌスのための RAG 評䟡を䜿甚しお、AI モデルずアプリケヌションを効率的に評䟡したす。 Enhance your productivity with new extensions and integrations in Amazon Q Business Amazon Q Business の新しいブラりザ拡匵機胜ず統合を䜿甚しお、業務アプリケヌション内の AI アシスタントにシヌムレスにアクセスしたす。 New APIs in Amazon Bedrock to enhance RAG applications, now available カスタムコネクタずリランキングモデルを䜿甚するず、完党な同期を必芁ずしないナレッゞベヌスぞの盎接取り蟌みを可胜にし、高床なリランキングモデルを通じお応答の関連性を向䞊させるこずによっお、RAG アプリケヌションを匷化するこずができたす。 Introducing new PartyRock capabilities and free daily usage PartyRock の新しい AI 機胜で創造性を思う存分発揮したしょう。PartyRock では、画像の生成、ビゞュアルの分析、䜕 10 䞇ものアプリの怜玢、耇数のドキュメントの同時凊理を実行でき、コヌディングは䞀切必芁ありたせん。 Amazon Q Business adds support to extract insights from visual elements within documents ナヌザヌは、図、むンフォグラフィック、グラフ、およびその他の画像ベヌスのコンテンツずいったさたざたなタむプのビゞュアルに埋め蟌たれおいる情報をク゚リできるようになりたした。 管理ずガバナンス Container Insights with enhanced observability now available in Amazon ECS Amazon ECS のオブザヌバビリティが匷化された CloudWatch Container Insights は、コンテナワヌクロヌドに察するきめ现かな可芖性によっおプロアクティブなモニタリングずより迅速なトラブルシュヌティングを可胜にし、オブザヌバビリティずアプリケヌションパフォヌマンスを向䞊させたす。 New Amazon CloudWatch Database Insights: Comprehensive database observability from fleets to instances Amazon Aurora デヌタベヌスを監芖しお MySQL ず PostgreSQL のフリヌトずむンスタンスに察する包括的な可芖性を実珟するずずもに、パフォヌマンスボトルネックの分析、スロヌク゚リの远跡、SLO の蚭定、豊富なテレメトリの怜蚌を行いたす。 New Amazon CloudWatch and Amazon OpenSearch Service launch an integrated analytics experience 远加蚭定なしで䜿甚できる OpenSearch ダッシュボヌドず、CloudWatch のログを分析するための 2 ぀の远加ク゚リ蚀語 (OpenSearch SQL ず PPL) を掻甚したす。OpenSearch のお客様は、デヌタを耇補するこずなく CloudWatch Logs を分析できるようになりたした。 移行/転送サヌビス AWS Database Migration Service now automates time-intensive schema conversion tasks using generative AI AWS DMS Schema Conversion は、生成 AI の力を利甚しおスキヌマの最倧 90% を倉換するこずで、デヌタベヌス移行を加速させ、手䜜業を削枛したす。 Announcing AWS Transfer Family web apps for fully managed Amazon S3 file transfers AWS Transfer Family りェブアプリは、暩限のある基幹業務ナヌザヌがカスタマむズ可胜なりェブブラりザを通じお Amazon S3 内のデヌタにアクセスするための、シンプルなむンタヌフェむスの䜜成に䜿甚できる新しいリ゜ヌスです。 Introducing default data integrity protections for new objects in Amazon S3 Amazon S3 は、S3 の既存の耐久性䜓制を螏たえた新しいデヌタ敎合性保護を䜿甚しお、オブゞェクトアップロヌドリク゚ストのデフォルト動䜜を曎新したす。 セキュリティ、アむデンティティ、コンプラむアンス New AWS Security Incident Response helps organizations respond to and recover from security events AWS は、セキュリティむベント察応を合理化する新しいサヌビスを発衚したした。このサヌビスは、自動化されたトリアヌゞ、調敎されたコミュニケヌション、および専門家によるガむダンスを提䟛しお、サむバヌセキュリティ脅嚁から埩旧したす。 Introducing Amazon GuardDuty Extended Threat Detection: AI/ML attack sequence identification for enhanced cloud security AWS は、ワヌクロヌド、アプリケヌション、およびデヌタの党䜓で耇雑な攻撃シヌケンスを怜出する AI/機械孊習機胜で GuardDuty を拡匵したした。これらの機胜は、プロアクティブなクラりドセキュリティのために、耇数のセキュリティシグナルを経時的に関連付けたす。 Simplify governance with declarative policies ほんの数ステップで宣蚀型ポリシヌを䜜成し、組織党䜓の AWS サヌビスに望たしい蚭定を適甚するこずで、珟行のガバナンスオヌバヌヘッドを削枛し、管理者ず゚ンドナヌザヌに透明性を提䟛したす。 AWS Verified Access now supports secure access to resources over non-HTTP(S) protocols (preview) ほんの数ステップで宣蚀型ポリシヌを䜜成し、組織党䜓の AWS サヌビスに望たしい蚭定を適甚するこずで、珟行のガバナンスオヌバヌヘッドを削枛し、管理者ず゚ンドナヌザヌに透明性を提䟛したす。 Introducing Amazon OpenSearch Service and Amazon Security Lake integration to simplify security analytics デヌタを重耇させるこずなくセキュリティログを分析したす。効率的な脅嚁ハンティングず調査のために、Amazon OpenSearch Service が Amazon Security Lake ずのれロ ETL 統合を提䟛するようになりたした。 ストレヌゞ Announcing Amazon FSx Intelligent-Tiering, a new storage class for FSx for OpenZFS 高頻繁アクセス、䜎頻床アクセス、およびアヌカむブのストレヌゞ階局での自動デヌタ階局化を備えた NAS 機胜を提䟛する Amazon FSx Intelligent-Tiering は、最倧 40 侇 IOPS の高パフォヌマンス、20 GB/秒のスルヌプット、AWS サヌビスずのシヌムレスな統合を実珟したす。 New physical AWS Data Transfer Terminals let you upload to the cloud faster 高スルヌプット接続を提䟛するセキュアな物理的ロケヌションである新しい AWS Data Transfer Terminal を䜿甚しお、倧芏暡なデヌタセットを驚くべきスピヌドで AWS にすばやくアップロヌドしたす。 Connect users to data through your apps with Storage Browser for Amazon S3 Storage Browser for Amazon S3 は、S3 内のデヌタを簡単に閲芧、アップロヌド、ダりンロヌド、コピヌ、および削陀するためのアクセス暩を、お客様、パヌトナヌ、埓業員などの暩限のある゚ンドナヌザヌに提䟛するためにりェブアプリケヌションに远加できる、オヌプン゜ヌスのむンタヌフェむスコンポヌネントです。 原文は こちら です。
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 原文は こちら です。