AWSのブログ - TECH PLAY

TECH PLAY

AWS

AWS の技術ブログ

å…š3894ä»¶

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 原文は こちら です。
12 月 1 日は、最新の AWS Transfer Family リ゜ヌスである AWS Transfer Family りェブアプリケヌション をご玹介したす。認蚌されたナヌザヌが特定の Amazon Simple Storage Service (Amazon S3) バケット内のファむルを䞀芧衚瀺、アップロヌド、ダりンロヌド、コピヌ、削陀できるようにする、フルマネヌゞドノヌコヌドりェブアプリケヌションを䜜成できたす。組織内倖の非デベロッパヌの Line Of Business ナヌザヌは、デスクトップクラむアント、スクリプト、付箋に曞かれた消えかかっおいる指瀺、たたはロヌカル IT のヘルプを必芁ずせずに、ファむルデヌタを簡単に亀換できたす。 りェブアプリケヌション管理者は、認蚌、アクセス、および蚱可を完党に制埡でき、ペヌゞタむトルず ファビコン を䜿甚しおりェブアプリケヌションをカスタマむズできたす。このブログ蚘事を曞いおいる間に䜜成したりェブアプリケヌションを次に瀺したす: ファむルをクリックしおダりンロヌドしたり、フォルダをクリックしお開いたり、列をクリックしお䞊べ替えたりできたす。瞊の䞉点リヌダヌのメニュヌには、远加のオプションがありたす: 各りェブアプリケヌションは、最倧 160 GiB のファむルのアップロヌドずダりンロヌドをサポヌトし、倧きなファむルには マルチパヌトアップロヌド を䜿甚したす。ファむルは、TLS によっお保護された HTTPS 接続を介しお転送され、自動再詊行ず CRC32 ゚ンドツヌ゚ンド完党性チェックが行われたす。 Transfer Family りェブアプリケヌションのすべお 独自のりェブアプリケヌションを䜜成する方法をわずか 1 分ほどでご説明したす。しかし、たずは重芁な機胜ず利点をいく぀か芋おみたしょう  セキュリティ – Transfer Family りェブアプリケヌションは AWS IAM アむデンティティセンタヌ を䜿甚するため、既存の SAML たたは OIDC ID プロバむダヌ、たたは組み蟌みの Identity Store を䜿甚できたす。いずれの堎合でも、 S3 Access Grants を䜿甚するず、ファむルの衚瀺、ダりンロヌド、削陀、アップロヌド、およびディレクトリの䜜成が蚱可されおいるナヌザヌずグルヌプを完党にきめ现かく制埡できたす。たた、組織は、AWS Transfer Family の SOC、PCI DSS、FedRAMP、HIPAA などのプログラムぞの コンプラむアンス の恩恵も享受できたす。 カスタマむズ – 各 Transfer Family りェブアプリケヌションをペヌゞタむトルず ファビコン でカスタマむズできたす。たた、りェブアプリケヌションの前に Amazon CloudFront ディストリビュヌションを配眮し、HTTPS アクセスず パブリック蚌明曞 を䜿甚しおカスタムドメむン名でホストするこずもできたす。 AWS ゚コシステム – Transfer Family りェブアプリケヌションは AWS でホストされるため、スケヌラブルで可甚性に優れおいたす。すべおのファむルは指定された S3 バケットに保存され、耐久性はむレブンナむン (99.999999999%) です。 S3 バヌゞョニング 、 S3 サヌバヌアクセスログ蚘録 、 S3 むベント通知 などの S3 の機胜 を掻甚できたす。たた、 Amazon EventBridge を䜿甚しお、アップロヌド埌の耇雑なワヌクフロヌをオヌケストレヌトするこずもできたす。 Transfer Family りェブアプリケヌションの䜜成 Transfer Family りェブアプリケヌションを䜜成するステップを芋おいきたしょう。各りェブアプリケヌションは特定の AWS リヌゞョン に存圚するため、 AWS Transfer Family コン゜ヌル を開き、目的のリヌゞョン (この蚘事では us-east-2 ) を遞択し、巊偎で [りェブアプリケヌション] を遞択したす: その埌、 [りェブアプリケヌションを䜜成] をクリックしお続行したす: 必芁に応じお IAM アむデンティティセンタヌ に接続し、Transfer Family りェブアプリケヌションが S3 および S3 Access Grants にアクセスするこずを蚱可する IAM サヌビスロヌル ( 詳现 ) を䜜成たたは遞択したす: [名前] タグを远加し、同時りェブアプリケヌションナヌザヌの最倧数を蚭定しお、 [次ぞ] をクリックしたす。 次に、りェブアプリケヌションを蚭蚈し、ペヌゞタむトルずロゎ (䞡方ずもオプション) を蚭定しおから、 [次ぞ] をクリックしたす: 次のペヌゞで蚭定を確認し、 [䜜成] をクリックしお先に進みたす: これでりェブアプリケヌションが䜜成され、䜿甚する準備はほずんど敎いたした (ただ蚱可ずナヌザヌを蚭定する必芁がありたす): りェブアプリケヌションに関連付けられたバケットのために間もなく䜜成する CORS ポリシヌで [アクセス゚ンドポむント] を䜿甚するので、コピヌしお保存したす。 蚱可ずナヌザヌの蚭定 りェブアプリケヌションを通じおアクセスできる S3 バケットに必芁な読み取りおよび曞き蟌み蚱可を提䟛する IAM カスタム信頌ポリシヌを䜜成したす ( 詳现 )。このポリシヌは、この埌すぐに䜜成する S3 Access Grant で参照されたす: それから、IAM アむデンティティセンタヌでナヌザヌずグルヌプの初期セットを䜜成したす (埌で远加できたす): 次に、りェブアプリケヌションず同じリヌゞョンに S3 バケットを䜜成し、S3 Access Grant を䜜成したす。各 S3 Access Grant は、特定の IAM アむデンティティセンタヌ ID (ナヌザヌたたはグルヌプ) が、読み取りおよび/たたは曞き蟌みのために特定のスコヌプ (バケットたたはバケットのプレフィックス付き郚分) にアクセスするこずを蚱可したす: たた、りェブアプリケヌションがブラりザからバケットにアクセスできるように、CORS ポリシヌ ( 詳现 ) をバケットにアタッチする必芁がありたす: 最埌のステップは、新しいりェブアプリケヌションにナヌザヌを関連付けるこずです。AWS Transfer Family の [りェブアプリケヌション] ペヌゞに戻り、自分のアプリケヌションを芋぀けお、 [ナヌザヌずグルヌプを割り圓おる] をクリックしたす: 自分のディレクトリに新しいナヌザヌを远加するか、たたは既存のナヌザヌを遞択できたす: たずは自分自身を远加したす: 割り圓おが完了するず、 [アクセス゚ンドポむント] (䞊蚘参照) をナヌザヌず共有でき、ナヌザヌ (ここでは自分) はりェブアプリケヌションにログむンできたす: [りェブアプリケヌション゚ンドポむント] ず [アクセス゚ンドポむント] は、デフォルトでは同じです。りェブアプリケヌションのために CloudFront ディストリビュヌションを蚭定 するず、 [アクセス゚ンドポむント] に゚ンドポむントの URL が反映されたす。 蚭定プロセスを通じた高速パスをご玹介したした。お気づきかもしれたせんが、個人レベルおよびグルヌプレベルで読み取りおよび曞き蟌みアクセスを制埡するオプションが倚数ありたす。本番りェブアプリケヌションを蚭定する前に、これらのオプションをすべお調べお完党に理解しおください。 知っおおくべきこず S3 Transfer Family りェブアプリケヌションに぀いお知っおおくべきこずがいく぀かありたす: リヌゞョン – りェブアプリケヌションは 9 ぀の AWS リヌゞョンで䜜成できたす。最新のリストに぀いおは、 りェブアプリケヌションのドキュメント をご芧ください。 料金 – 料金はりェブアプリケヌション/時間単䜍です。 API ず CLI – create-web-app 、 describe-web-app 、他の AWS Transfer Family アクションを䜿甚するこずで、プログラムでりェブアプリケヌションを䜜成および管理できたす。 Storage Browser for S3 – Transfer Family りェブアプリケヌションは、 Storage Browser for Amazon S3 を䜿甚しお構築され、フルマネヌゞドオファリングで同じ゚ンドナヌザヌ機胜を提䟛したす。 開始方法 – Transfer Family りェブアプリケヌションは、 Transfer Family コン゜ヌル で䜿甚を開始できたす。 – Jeff ; 原文は こちら です。
12 月 1 日、 Amazon OpenSearch Service ず Amazon Security Lake のれロ ETL 統合の䞀般提䟛の開始を発衚したした。この統合により、組織はセキュリティデヌタを効率的に怜玢および分析し、実甚的なむンサむトを埗るこずができるため、耇雑なデヌタ゚ンゞニアリング芁件が合理化され、セキュリティデヌタの朜圚胜力が最倧限に匕き出されたす。これは、Security Lake でログをむンプレヌスでク゚リおよび分析する新しい方法であり、デヌタの重耇を最小限に抑え、カスタムデヌタパむプラむンの管理にかかる運甚オヌバヌヘッドを削枛したす。Security Lake デヌタを盎接ク゚リできるため、デヌタの移動コストを節玄できたす。 OpenSearch Service ず Security Lake のれロ ETL 統合により、OpenSearch Dashboards の豊富な分析機胜を䜿甚しお、Security Lake のデヌタをク゚リおよび芖芚化できたす。たた、単䞀のツヌルず単䞀のスキヌマ ( Open Cybersecurity Schema Framework (OCSF) スキヌマ) 内で耇数のデヌタ゜ヌスを分析しお、脅嚁ハンティングず調査のシナリオに圹立おるこずもできたす。 時間が重芁な芁玠ずなる調査ずモニタリングでは、デヌタのサブセットに迅速か぀頻繁にアクセスする必芁がある堎合に、Amazon OpenSearch Service でむンデックス付きビュヌやダッシュボヌドなどの远加のアクセラレヌションを有効にするこずで、オプションでク゚リパフォヌマンスを改善できたす。これらの機胜により、ログの量にかかわらず、Security Lake に保存されおいるすべおのデヌタを完党に可芖化できるため、セキュリティ調査をサポヌトし、セキュリティ䜓制をより良く理解するずずもに、セキュリティ関連のむンサむトを埗るこずができたす。 Amazon Security Lake でのダむレクトク゚リの開始方法 数ステップで䜿甚を開始できたす。たず、Security Lake サブスクラむバヌを䜜成しお Security Lake を有効にする必芁がありたす。その埌、Amazon OpenSearch Service でデヌタ接続を有効にしたす。これにより、ダむレクトク゚リの結果ずむンデックスを保存するための OpenSearch Serverless コレクションが自動的に䜜成されたす。 1.Security Lake を有効にし、デヌタレむクの蚱可を蚭定する AWS マネゞメントコン゜ヌル で Security Lake を有効にするには、収集するデヌタ゜ヌス ( Amazon Route 53 DNS ク゚リ、 AWS CloudTrail ログ、 Amazon VPC フロヌログ、 AWS Security Hub の怜出結果など) ず AWS リヌゞョンを指定したす。私は耇数のリヌゞョンを遞択し、 Amazon Simple Storage Service (Amazon S3) ストレヌゞクラスずロヌルアップリヌゞョンを蚭定しおデヌタを統合したした。 必芁なデヌタ゜ヌスを䜿甚しお組織党䜓にデプロむし、組織に固有のコストを芋積もるこずができるよう、Security Lake は 15 日間の無料トラむアルを提䟛しおいたす。 有効化が完了するず、収集されたすべおのデヌタがアカりントの Amazon Simple Storage Service (Amazon S3) バケットに取り蟌たれたす。 Security Lake の委任された管理者アカりント以倖のアカりントから Security Lake デヌタにアクセスするには、Security Lake に関連付けられた AWS Glue テヌブルのデヌタにアクセスしおク゚リするために AWS Lake Formation サブスクラむバヌを䜜成する必芁がありたす。Security Lake ぞのアクセスが認可されおいる AWS アカりントず倖郚 ID を入力し、アクセスするデヌタ゜ヌスを遞択したす。Lake Formation は、セキュリティアナリストがレむク内のデヌタにアクセスするためのクロスアカりント蚱可を提䟛したす。 ク゚リサブスクラむバヌを䜜成したら、OpenSearch リ゜ヌスをデプロむする予定のアカりントに移動し、Security Lake の委任された管理者アカりントによっお共有されおいる AWS Resource Access Manager (AWS RAM) 共有を受け入れるこずができたす。サブスクラむバヌアカりントは、手動で受け入れられるたで、共有ステヌタスを保留䞭ずしお衚瀺したす。 詳现に぀いおは、「Amazon Security Lake ナヌザヌガむド」の「 Enabling Security Lake using the console 」および「 Create query subscriber procedures 」にアクセスしおください。 2.OpenSearch Service ずのデヌタ接続を䜜成する れロ ETL 統合は、数ステップで䜜成できたす。サブスクラむバヌのアカりントの OpenSearch Service コン゜ヌル で、巊偎のナビゲヌションペむンの [デヌタ接続] セクションで [接続されたデヌタ゜ヌス] を遞択したす。その埌、デヌタ゜ヌスのタむプずしお [Security Lake] を遞択できたす。 次のステップでは、れロ ETL 統合を䜿甚しお Security Lake デヌタ゜ヌスにアクセスするための IAM 蚱可を蚭定できたす。たた、OpenSearch Serverless コレクションず OpenSearch アプリケヌションが自動的に䜜成されたす。 接続が䜜成されたら、Security Lake のデヌタを定期的にク゚リしおビゞュアラむれヌションを䜜成する、事前構築枈みの OpenSearch ダッシュボヌドのいずれかを遞択できたす。Security Lake で VPC フロヌログ、WAF ログ、CloudTrail デヌタ゜ヌス甚のテンプレヌトを䜿甚しおダッシュボヌドを䜜成できたす。 VPC フロヌログ甚の事前構築枈みのダッシュボヌドの䟋を次に瀺したす。 デヌタ接続の詳现に぀いおは、「Amazon OpenSearch Service デベロッパヌガむド」の「 Data connections and permissions 」にアクセスしおください。 3.OpenSearch ダッシュボヌドで Security Lake デヌタをク゚リする OpenSearch ダッシュボヌドで Security Lake デヌタを盎接ク゚リするには、 [怜出] ペヌゞに移動したす。 [怜出] ペヌゞで、デヌタピッカヌワヌクフロヌを䜿甚しお、ク゚リする特定の Security Lake テヌブルを芋぀けるこずができたす。Security Lake ログ゜ヌスごずに 1 ぀のテヌブルがありたす。 遞択埌、䜿甚するク゚リ蚀語 (PPL (Piped Processing Language) たたは SQL (Structured Query Language) のいずれか) を遞択し、ク゚リを蚘述しお実行できたす。PPL のサンプル結果を次に瀺したす: ク゚リを開始するために、事前構築枈みのク゚リテンプレヌトを怜玢しお実行するこずを遞択するこずもできたす。Security Lake で䜿甚可胜なすべおの AWS ログ゜ヌスをカバヌする 200 を超える SQL および PPL ク゚リがありたす。怜玢ボックスを䜿甚しお、興味のあるク゚リを芋぀けるこずができたす。䟋えば、「VPC Flow」ず怜玢するず、VPC フロヌログに関連するすべおのク゚リが衚瀺されたす。各ク゚リず、その䜿甚が掚奚される堎合に぀いおの説明がありたす。 セキュリティ調査をサポヌトするためなど、同じデヌタセットに察しお耇数のク゚リを実行する堎合は、ダむレクトク゚リの結果に぀いおオンデマンドのむンデックス付きビュヌを䜜成できたす。結果が OpenSearch むンデックスに取り蟌たれた埌、OpenSearch の分析機胜を䜿甚しお、䜎レむテンシヌの埌続のク゚リず分析を実行できたす。 むンデックス付きビュヌを䜜成するには、 [むンデックス付きビュヌを䜜成] を遞択し、指定したク゚リ、むンデックス名、および時間範囲を遞択したす。ビュヌが䜜成されるず、ク゚リ結果が取り蟌たれ、䜿甚可胜なむンデックス付きビュヌの䞋に新しく䜜成されたむンデックスの䞀郚ずしおク゚リできるようになりたす。 詳现に぀いおは、「Amazon OpenSearch Service デベロッパヌガむド」の「 Searching data 」にアクセスしおください。 今すぐご利甚いただけたす Amazon OpenSearch Service ず Amazon Security Lake のれロ ETL 統合は、米囜東郚 (オハむオ)、米囜東郚 (バヌゞニア北郚)、米囜西郚 (オレゎン)、アゞアパシフィック (ムンバむ)、アゞアパシフィック (シンガポヌル)、アゞアパシフィック (シドニヌ)、アゞアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アむルランド)、欧州 (ロンドン)、欧州 (パリ)、南米 (サンパりロ)、およびカナダ (䞭郚) の AWS リヌゞョンでご利甚いただけるようになりたした。 OpenSearch Service では、OpenSearch Service でのむンデックスの維持に加えお、倖郚デヌタのク゚リに必芁なコンピュヌティング (OpenSearch Compute Units ずしお) に぀いおのみ別途料金が発生したす。詳现に぀いおは、「 Amazon OpenSearch Service の料金 」をご芧ください。 お詊しいただき、 AWS re:Post for Amazon OpenSearch Service 、たたは通垞の AWS サポヌト窓口たでフィヌドバックをお送りください。 – Channy 原文は こちら です。
12 月 1 日、オンプレミスおよび゚ッゞむンフラストラクチャをクラりド内の EKS クラスタヌに察するノヌドずしおアタッチするために䜿甚できる新機胜である Amazon Elastic Kubernetes Service (Amazon EKS) ハむブリッドノヌド の䞀般提䟛の開始を発衚したした。 Amazon EKS ハむブリッドノヌドを䜿甚するず、クラりド環境ずオンプレミス環境党䜓で Kubernetes 管理を統合し、アプリケヌションを実行する必芁があるすべおの堎所で Amazon EKS のスケヌルず可甚性を掻甚できたす。既存のオンプレミスハヌドりェアを䜿甚しながら、Kubernetes コントロヌルプレヌンの管理責任を EKS にオフロヌドし、ワヌクロヌドのためのオンプレミスキャパシティを節玄できたす。Amazon EKS ハむブリッドノヌドを䜿甚するず、クラりド環境ずオンプレミス環境党䜓で䞀貫した運甚慣行ずツヌルを採甚できたす。 以前に導入した Amazon EKS on AWS Outposts ず Amazon EKS Anywhere に加えお、Amazon EKS ハむブリッドノヌドは、ハむブリッド Kubernetes デプロむのサポヌトを拡匵したす。各 EKS ハむブリッドデプロむオプションで Kubernetes ずハヌドりェアコンポヌネントがどのように管理されるかを比范できたす。 コンポヌネント EKS on Outposts EKS ハむブリッドノヌド EKS Anywhere ハヌドりェア AWS によっお管理 お客様によっお管理 Kubernetes コントロヌルプレヌン AWS によっおホストおよび管理 お客様によっおホストおよび管理 Kubernetes ノヌド Amazon EC2 カスタマヌマネヌゞド型の物理マシンたたは仮想マシン Amazon EKS ハむブリッドノヌドを䜿甚しおオンプレミスおよび゚ッゞむンフラストラクチャを EKS クラスタヌにアタッチするず、 Amazon EKS アドオン 、 ポッド ID 、 クラスタヌアクセス゚ントリ 、 クラスタヌむンサむト 、Kubernetes バヌゞョンの拡匵サポヌトなど、Amazon EKS の他の機胜ず統合を䜿甚できたす。Amazon EKS ハむブリッドノヌドは、䞀元的なモニタリング、ログ蚘録、および ID 管理のために、 AWS Systems Manager 、 AWS IAM Roles Anywhere 、 Amazon Managed Service for Prometheus 、 Amazon CloudWatch 、 Amazon GuardDuty などの AWS サヌビスず本質的に統合したす。 Amazon EKS ハむブリッドノヌドの䜿甚を開始する Amazon EKS ハむブリッドノヌドを䜿甚するステップは次のずおりです。たず、EKS クラスタヌを䜜成し、オンプレミスのノヌドずポッドのサブネットを指定したす。オンプレミス環境のネットワヌク接続ず AWS Identity and Access Management (AWS IAM) 蚱可を蚭定したら、クラスタヌに参加する各ホストで Amazon EKS ハむブリッドノヌド CLI ( nodeadm ) を実行したす。ハむブリッドノヌドがクラスタヌに参加するず、kube-proxy や CoreDNS などの必芁なネットワヌキングコンポヌネントが自動的にむンストヌルされたす。ハむブリッドノヌドがアプリケヌションを提䟛する準備が敎う前に、互換性のある Container Network Interface (CNI) ドラむバヌをむンストヌルする必芁がありたす。Cilium および Calico CNI ドラむバヌは、Amazon EKS ハむブリッドノヌドでの䜿甚がサポヌトされおいたす。 1.前提条件 オンプレミスむンフラストラクチャをハむブリッドノヌドずしお EKS クラスタヌに参加させるには、次を含む特定の前提条件を満たす必芁がありたす: オンプレミス環境ず AWS 間のハむブリッドネットワヌク接続 ( AWS Site-to-Site VPN 、 AWS Direct Connect 、たたは別の仮想プラむベヌトネットワヌク (VPN) ゜リュヌションを䜿甚) オンプレミスノヌドのルヌティングテヌブルにルヌトがあり、オプションでポッドネットワヌクがあり、タヌゲットずしお仮想プラむベヌトゲヌトりェむ (VGW) たたはトランゞットゲヌトりェむ (TGW) が蚭定されおいる仮想プラむベヌトクラりド (VPC) 物理マシンたたは仮想マシンの圢匏のむンフラストラクチャ ハむブリッドノヌドず互換性のあるオペレヌティングシステム コントロヌルプレヌンでハむブリッドノヌドを認蚌するように蚭定された AWS IAM Roles Anywhere たたは AWS Systems Manager のいずれか EKS クラスタヌ IAM ロヌル ず EKS ハむブリッドノヌド IAM ロヌル ハむブリッドノヌドのノヌドオペレヌティングシステムずしお、Amazon Linux 2023、Ubuntu 20.04、Ubuntu 22.04、Ubuntu 24.04、たたは Red Hat Enterprise Linux (RHEL) 8 および 9 を䜿甚できたす。AWS は、これらのオペレヌティングシステムずのハむブリッドノヌド統合をサポヌトしおいたすが、オペレヌティングシステム自䜓のサポヌトは提䟛しおいたせん。オペレヌティングシステムのプロビゞョニングず管理はお客様の責任です。 詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Prerequisites for EKS Hybrid Nodes 」にアクセスしおください。 2.EKS クラスタヌを䜜成し、ハむブリッドノヌドを有効にする Amazon EKS コン゜ヌル に移動し、EKS クラスタヌの䜜成を開始したす。 [ステップ 2 ネットワヌキングを指定] 画面で、 [ハむブリッドノヌドを有効にするようにリモヌトネットワヌクを蚭定] オプションの [ハむブリッドノヌドに䜿甚するオンプレミス環境のために CIDR ブロックを指定] をオンにしたす。 リモヌトノヌドずポッドの Classless Inter-Domain Routing (CIDR) は、RFC-1918 IPv4 IPv4 アドレスである必芁があり、VPC CIDR たたは EKS クラスタヌ Kubernetes サヌビス CIDR ず重耇するこずはできたせん。さらに、リモヌトノヌド CIDR ずリモヌトポッド CIDR は重耇できたせん。ノヌドでりェブフックを実行する堎合、たたはポッドトラフィックがノヌドを離れるずきに CNI がポッドアドレスのために NAT を䜿甚しない堎合は、ポッド CIDR ブロックを指定する必芁がありたす。 たた、 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 eksctl 、および AWS CloudFormation を䜿甚しお EKS クラスタヌを䜜成するこずもできたす。Amazon EKS ハむブリッドノヌドのためにクラスタヌを有効にするには、 remote-network-config フラグを䜿甚しおリモヌトノヌドを指定し、オプションでリモヌトポッド CIDR ブロックを指定したす。 $ aws eks create-cluster --name channy-hybrid-cluster --region=us-east-1 \ --role-arn arn:aws:iam::012345678910:role/eks-cluster-role \ --resources-vpc-config subnetIds=subnet-1234a11a,subnet-5678b11b \ --remote-network-config \ {"remoteNodeNetworks":[{"cidrs":["10.80.0.0/16"]}],"remotePodNetworks":[{"cidrs":["10.85.0.0/16"]}]}} クラスタヌは、 API たたは API_AND_CONFIG_MAP クラスタヌアクセス認蚌モヌドで蚭定されおいる必芁がありたす。EKS ハむブリッドノヌド IAM ロヌルのために Amazon EKS アクセス゚ントリを䜜成しお、ノヌドがクラスタヌに参加できるようにしたす。 $ aws eks create-access-entry \ --cluster-name my-hybrid-cluster \ --principal-arn arn:aws:iam::012345678910:role/eksHybridNodesRole \ --type HYBRID_LINUX Amazon EKS ハむブリッドノヌドは、AWS Systems Manager ハむブリッドアクティベヌションたたは AWS IAM Roles Anywhere によっおプロビゞョニングされた䞀時的な IAM 認蚌情報を䜿甚しお、EKS クラスタヌで認蚌したす。オンプレミスノヌドを接続する前に、AWS Systems Manager ハむブリッドアクティベヌションを䜜成するか、たたは AWS IAM Roles Anywhere で䜿甚するためにノヌドに蚌明曞ずキヌを远加する必芁がありたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Prepare credentials for EKS Hybrid Nodes 」にアクセスしおください。 3.ハむブリッドノヌドを EKS クラスタヌに接続する これで、Amazon EKS ハむブリッドノヌドを EKS クラスタヌに接続する準備が敎いたした。Amazon EKS ハむブリッドノヌド CLI ( nodeadm ) を䜿甚するず、ハむブリッドノヌドずしおのホストのむンストヌル、蚭定、登録を簡玠化できたす。 nodeadm は、 nodeadm install コマンドを実行するず、必芁な AWS Systems Manager たたは IAM Roles Anywhere コンポヌネントを自動的にむンストヌルしたす。 実行䞭の各ホストで nodeadm install プロセスを実行するか、たたはオペレヌティングシステムのビルドパむプラむンの䞀郚ずしお nodeadm install を実行しお、ホストを EKS クラスタヌに参加させるために必芁なコンポヌネントを含むむメヌゞを生成できたす。 $ nodeadm install 1.31 --credential-provider <ssm, iam-ra> {"level":"info","ts":...,"caller":"...","msg":"Loading configuration","configSource":"file://nodeConfig.yaml"} {"level":"info","ts":...,"caller":"...","msg":"Validating configuration"} {"level":"info","ts":...,"caller":"...","msg":"Validating Kubernetes version","kubernetes version":"1.30"} {"level":"info","ts":...,"caller":"...","msg":"Using Kubernetes version","kubernetes version":"1.30.0"} {"level":"info","ts":...,"caller":"...","msg":"Installing SSM agent installer..."} {"level":"info","ts":...,"caller":"...","msg":"Installing kubelet..."} {"level":"info","ts":...,"caller":"...","msg":"Installing kubectl..."} {"level":"info","ts":...,"caller":"...","msg":"Installing cni-plugins..."} {"level":"info","ts":...,"caller":"...","msg":"Installing image credential provider..."} {"level":"info","ts":...,"caller":"...","msg":"Installing IAM authenticator..."} {"level":"info","ts":...,"caller":"...","msg":"Finishing up install..."} EKS クラスタヌに接続するために必芁な情報を含む nodeConfig.yaml ファむルを各ホストで䜜成したす。AWS Systems Manager ハむブリッドアクティベヌションを䜿甚する nodeConfig.yaml の䟋を次に瀺したす。 apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig metadata: name: hybrid-node spec: cluster: name: my-cluster region: us-east-1 hybrid: roleArn: arn:aws:iam:012345678910:role/eksHybridNodesRole ssm: activationCode: <activation-code> activationId: <activation-id> 次に、各ホストで nodeadm を実行したす。 $ nodeadm init -c file:/// nodeConfig.yaml 前述のコマンドが正垞に完了した堎合、ハむブリッドノヌドは EKS クラスタヌに参加しおいたす。これは、Amazon EKS コン゜ヌルたたは kubectl get nodes コマンドで確認できたす。ハむブリッドノヌドのステヌタスが [準備完了] になる前に、互換性のある CNI をむンストヌルする必芁がありたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Install CNI for EKS Hybrid Nodes 」にアクセスしおください。 4.EKS コン゜ヌルで接続されたハむブリッドノヌドを衚瀺および管理する ノヌドの準備が敎ったので、EKS コン゜ヌルでハむブリッドノヌドずそこで実行されおいるリ゜ヌスを衚瀺できたす。 ハむブリッドノヌドの管理ず、それらが実行する゜フトりェアの曎新は、お客様の責任です。Amazon EKS ハむブリッドノヌド CLI の最新バヌゞョンに曎新しお、最新の修正プログラムず曎新を取埗し、Kubernetes バヌゞョンをアップグレヌドできたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Upgrade EKS Hybrid Nodes 」にアクセスしおください。 今すぐご利甚いただけたす Amazon EKS ハむブリッドノヌド は、AWS GovCloud (米囜) リヌゞョンず䞭囜リヌゞョンを陀くすべおの AWS リヌゞョンでご利甚いただけるようになりたした。 前払いの矩務や最䜎料金はなく、EKS クラスタヌず EKS ハむブリッドノヌドは䜿甚した時間に応じお時間単䜍でお支払いいただきたす。ハむブリッドノヌドを含む EKS クラスタヌのクラスタヌあたりの時間単䜍のコストは、暙準サポヌトず拡匵サポヌトの䞡方においお AWS クラりドで実行されおいるノヌドを含む EKS クラスタヌず同じです。さらに、ハむブリッドノヌドを含む EKS クラスタヌでは、ハむブリッドノヌド vCPU ごずに時間単䜍の料金が発生したす。詳现に぀いおは、「 Amazon EKS の料金」ペヌゞ にアクセスしおください。 Amazon EKS コン゜ヌル で EKS ハむブリッドノヌドをぜひお詊しください。詳现に぀いおは、 EKS ハむブリッドノヌドのドキュメント にアクセスしおください。たた、 AWS re:Post for EKS に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
12 月 1 日、 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode の䞀般提䟛の開始を発衚したした。これは、プロビゞョニングから継続的なメンテナンスたで、コンピュヌティング、ストレヌゞ、ネットワヌクに぀いおの Kubernetes クラスタヌ管理を 1 回のクリックで効率化する新しい機胜です。 Amazon Web Services (AWS) で本番グレヌドの Kubernetes アプリケヌションを倧芏暡に実行するために必芁なクラスタヌむンフラストラクチャの管理の運甚オヌバヌヘッドを排陀するこずで、俊敏性ずコスト効率を高め、パフォヌマンスを改善できたす。 お客様が Amazon EKS を遞択するのは、Kubernetes の暙準および移怍性を、AWS クラりドのセキュリティ、スケヌラビリティ、可甚性ず合わせお掻甚できるためです。Kubernetes は高床な知識を備えたお客様にアプリケヌションオペレヌションに察する詳现なコントロヌルを提䟛したすが、他のお客様は、本番グレヌドの Kubernetes アプリケヌションに必芁なコンポヌネントの管理が耇雑で手間がかかるず感じおいたす。 EKS Auto Mode を䜿甚するず、最適なコンピュヌティングむンスタンスの遞択、リ゜ヌスの動的なスケヌル、コストの継続的な最適化、コアアドオンの管理、オペレヌティングシステムぞのパッチ適甚、AWS セキュリティサヌビスずの統合が行われるため、Kubernetes の深い専門知識がなくおもクラスタヌ管理を自動化できたす。AWS は、EKS クラスタヌ内のカスタマヌマネヌゞドむンフラストラクチャず比范しお、EKS Auto Mode でより倧きな運甚䞊の責任を負いたす。EKS コントロヌルプレヌンに加えお、AWS は、アプリケヌションの実行に必芁な EKS クラスタヌ内の AWS むンフラストラクチャを蚭定、管理、保護したす。 すぐに䜿甚を開始しお、パフォヌマンスを改善し、オヌバヌヘッドを削枛できるため、クラスタヌ管理タスクではなく、むノベヌションを掚進するアプリケヌションの構築に泚力できたす。たた、EKS Auto Mode は、コスト効率の高い GPU アクセラレヌテッドむンスタンスを取埗しお実行するために必芁な䜜業を削枛するため、必芁なずきに必芁なキャパシティを 生成 AI ワヌクロヌドのために確保できたす。 Amazon EKS Auto Mode の䜿甚を開始する 䜿甚を開始するには、 Amazon EKS コン゜ヌル に移動しお、EKS クラスタヌの䜜成を開始したす。 [クむック蚭定 (EKS Auto Mode を䜿甚)] ず [カスタム蚭定] の 2 ぀のオプションがありたす。 クむック蚭定を遞択したら、クラスタヌ名ず Kubernetes バヌゞョン、IAM ロヌル、VPC サブネットを入力したす。クラスタヌの䜜成埌に線集できるかどうかにかかわらず、EKS Auto Mode で蚭定のデフォルトの倀を衚瀺できたす。 EKS Auto Mode では、EKS クラスタヌで Kubernetes の次の機胜が有効になりたす: コンピュヌティングの自動スケヌリングず管理 アプリケヌションの負荷分散管理 ポッドずサヌビスのネットワヌキングずネットワヌクポリシヌ クラスタヌ DNS ず GPU のサポヌト ブロックストレヌゞボリュヌムのサポヌト [䜜成] を遞択するず、Auto Mode の EKS クラスタヌが 1 回のクリックで数分でデプロむされたす。 カスタム蚭定オプションを遞択した堎合は、クラスタヌの他の偎面をカスタマむズできたす。このオプションでも EKS Auto Mode を䜿甚できたす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) 、 eksctl 、および AWS CloudFormation を䜿甚しお EKS Auto Mode クラスタヌを䜜成するこずもできたす。新しい EKS Auto Mode クラスタヌを䜜成するには、次の eksctl コマンドを実行したす: $ eksctl create cluster --name=<cluster-name> --enable-auto-mode 詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Create cluster with EKS Auto Mode 」にアクセスしおください。 既存の EKS クラスタヌで EKS Auto Mode を有効にする堎合は、EKS クラスタヌの詳现ペヌゞの [抂芁] タブの [EKS Auto Mode] セクションで [管理] を遞択したす。 EKS Auto Mode を有効にするには、 [EKS Auto Mode を䜿甚] の暪にあるボックスを遞択したす。クラスタヌで蚭定される EKS Auto Mode の遞択を解陀できたす。デフォルトでは、システムずデフォルトのノヌドプヌルの䞡方ずノヌドクラスが䜜成されたす。 たた、 Karpenter 、 EKS マネヌゞドノヌドグルヌプ 、EKS Fargate から、EKS Auto Mode に移行するこずもできたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Enable EKS Auto Mode on existing EKS clusters 」にアクセスしおください。 ワヌクロヌドの芁件を満たすために、EKS Auto Mode クラスタヌの特定の偎面を蚭定できたす。EKS Auto Mode はほずんどのむンフラストラクチャコンポヌネントを自動的に管理したすが、自動化されたむンフラストラクチャ管理の利点を維持しながら、 ノヌドネットワヌキングの蚭定 、 ノヌドコンピュヌティングリ゜ヌス 、 ストレヌゞクラスの蚭定 、および アプリケヌションの負荷分散動䜜 をカスタマむズできたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Change EKS Auto cluster settings 」にアクセスしおください。 これで、EKS Auto Mode で実行されおいる Amazon EKS クラスタヌにさたざたな皮類のワヌクロヌドをデプロむできるようになりたした。䞻芁なワヌクロヌドパタヌンずしお、 サンプルアプリケヌション 、 負荷分散されたりェブアプリケヌション 、 氞続ストレヌゞを䜿甚したステヌトフルワヌクロヌド 、および 特定のノヌド配眮芁件のあるワヌクロヌド が甚意されおいたす。各䟋には、完党なマニフェストずステップバむステップのデプロむ手順が含たれおおり、独自のアプリケヌションのテンプレヌトずしお䜿甚できたす。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Run workloads in EKS Auto Mode clusters 」にアクセスしおください。 今すぐご利甚いただけたす Amazon EKS Auto Mode は、Amazon EKS が利甚可胜なすべおの商甚 AWS リヌゞョン (䞭囜リヌゞョンを陀く) でご利甚いただけるようになりたした。Kubernetes 1.29 以降を実行しおいる任意の EKS クラスタヌで、初期費甚や確玄なしで EKS Auto Mode を有効にできたす。通垞の EC2 コストに加えお、プロビゞョニングされたコンピュヌティングリ゜ヌスの管理に぀いおの料金をお支払いいただきたす。詳现に぀いおは、「 Amazon EKS の料金ペヌゞ 」にアクセスしおください。 2024 幎 12 月 12 日のオンラむンりェビナヌ「 Simplifying Kubernetes operations with Amazon EKS Auto Mode 」に登録しお、EKS Auto Mode によっおワヌクロヌドを本番にデプロむする時間を短瞮し、Kubernetes の運甚䞊のオヌバヌヘッドを削枛する方法に぀いおの詳现をご芧ください。詳现に぀いおは、「Amazon EKS ナヌザヌガむド」の「 Automate cluster infrastructure with EKS Auto Mode 」にアクセスしおください。 Amazon EKS コン゜ヌル で EKS Auto Mode をお詊しいただき、 AWS re:Post for EKS に、たたは通垞の AWS サポヌトの連絡先を通じお、フィヌドバックをぜひお寄せください。 – Channy 原文は こちら です。
来幎の小売業界のトレンドに関しお、様々な論客が予枬を競い合っおいたす。 去幎 は小売業界のトップテクノロゞヌ動向をリストアップしたしたが、今幎は生成 AI に焊点を圓お、泚目すべきトレンドを取り䞊げたいず思いたす。2023 幎が生成 AI が登堎した幎で、2024 幎がその詊隓運甚的な期間だったずすれば、2025 幎はこのテクノロゞヌがさらに成熟する幎になるでしょう。Gartner の蚀う「啓発期」に近づいおいたすが、ただそこには達しおいたせん。 生成 AI の話に飜き飜きしおいる人もいるでしょう。生成 AI ずいうず、Nirvana ずいうグランゞ系ロックバンドを思い出したす。それ以前にも倚くのグランゞ系ロックバンドが登堎しおいたしたが、Nirvana はそうした他の玠晎らしいバンドを匕き離し、圧倒的な泚目を集めたした。Nirvana がそうであったように生成 AI が䞖界に倧きな圱響を䞎えたこずは誰も吊定できたせん。 そこで、2025 幎に泚目すべき、小売業向けの 3 ぀のナヌスケヌスず 3 ぀のテクノロゞヌを玹介したす。 バヌチャルショッピングアシスタントナヌスケヌス ハむパヌパヌ゜ナラむれヌションナヌスケヌス バヌチャル詊着ナヌスケヌス AI ゚ヌゞェントテクノロゞヌ ドメむン固有の基盀モデルテクノロゞヌ Computer Useテクノロゞヌ バヌチャルショッピングアシスタント この゜リュヌション開発のコンセプトはシンプルです。店舗での買い物であれば、䜕を買ったらよいかわからなければ店員に専門的なアドバむスを求めるこずができたす。では、オンラむンショッピングの堎合はどうすればよいのでしょうか? そこで登堎するのが、スプリンクラヌの配管から、デゞタルネットワヌク、寒い日のファッションコヌディネヌトなどさたざたなトピックに粟通した AI を駆䜿したバヌチャルショッピングアシスタントです。地䞭に埋め蟌たれたスプリンクラヌシステムの修理に必芁なツヌルは? 屋倖で最もうたく機胜する Wi-Fi ルヌタヌは? スタむリッシュなスキヌグロヌブを遞ぶ際には䜕を考慮すべき? こうした質問ぞの回答を埗られるようにするこず、それが Amazon が立ち䞊げたバヌチャルショッピングアシスタント Rufus の開発の背景です。 Rufus を特に䟿利にしおいるのは、䌚話圢匏であるこずです。これにより買い物客が回答に満足するたで䌚話を続けるこずができたす。店舗にいる店員のように、バヌチャルショッピングアシスタントは買い物客のニヌズず奜みを理解しようず問いかけを行いたす。これを䌚話型怜玢ず考える人もいるでしょう。 これは確かに埓来の怜玢を眮き換えるものではありたせん。小売業者はたず Search & Product Discovery ゜リュヌションをモダナむズし、次に Chatbots & Virtual Assistants が自瀟にずっお意味があるかどうかを刀断する必芁がありたす。それでもこうした゜リュヌションを䜿甚するこずで、買い手はその商品の賌入をさらに玍埗できるずずもに売䞊向䞊ず返品の枛少に぀ながるでしょう。 ハむパヌパヌ゜ナラむれヌション 機械孊習を甚いたパヌ゜ナラむれヌションは、䌌通った顧客の嗜奜に基づいお個々の顧客の嗜奜を予枬する 協調フィルタリングを Amazon がはじめお䜿甚 しおから25 幎が経過しおいたす。次のトレンドは、機械孊習ず生成 AI を組み合わせるこずで買い物客ひずりひずりに個別の䜓隓をもたらすこずです。これには、マヌケティングコミュニケヌション、怜玢結果、商品詳现ペヌゞ、さらにはチャットボットの䌚話たで、個人の嗜奜に合わせお ハむパヌパヌ゜ナラむズする こずが含たれたす。 最終的には、各りェブストアセッションを個々の買い物客のためにカスタマむズできるようになり、魅力的なテヌマ、カスタマむズされた商品構成、そしお各個人の嗜奜に基づいた遞りすぐったサヌビスを提䟛しお商品を衚瀺できるようになるでしょう。このようなきめ现かなケアを提䟛するホワむトグロヌブサヌビスはか぀お富裕局に限られおいたしたが、䞀般の買い物客にも広がっおいくこずでしょう。小売業者は、過去の販売デヌタ、商品デヌタ、第䞉者の顧客デヌタなどを掻甚し、個々の買い物客ずのすべおのむンタラクションをその人に合わせおベストにハむパヌパヌ゜ナラむズする方法を怜蚎する必芁が出おくるでしょう。 バヌチャル詊着 オンラむン販売は、特にファッションの分野では䌞び悩んでいたした。ずいうのも、買い物客がオンラむン䞊の商品に察しおこれでいいず賌入に螏み切る確信を持ちにくかったからです。商品が自分のむメヌゞどおりかどうかわからないず、賌入をためらう可胜性が高く、色やサむズが違うものをそれぞれ泚文しお合わなかったものを返品するこずがありたす。生成 AI によっお商品をコンテキストに合わせお芖芚的に描写でき、買い物客が商品を バヌチャルに詊着 できるようになりたす。これは、人物ずセヌタヌ、怅子ず居間ずいった 2 ぀の画像を組み合わせるこずで再珟されたす。買い物客はそれを芋お賌入するか吊かを刀断できたす。 Stable Diffusion や Amazon Titan Image Generator などの AI モデルは、むンテリゞェントに画像を組み合わすこずで、買い物客にそれが期埅に合ったものであるかどうかを瀺し、確信をもっお賌入できるようにしたす。アパレル、ファッション、アクセサリヌ、家具やビゞュアル化の恩恵を受けるその他の商品を販売する小売業者は、この機胜の導入を怜蚎する必芁が出おくるでしょう。 AI ゚ヌゞェント チャットボットやバヌチャルアシスタントず䌚話するこずで情報は埗られたすが、ほずんどの堎合、次のアクションぞず導くこずなく終了しおしたいたす。䞀方、゚ヌゞェントは目暙達成に胜力を発揮したす。通垞、自埋的であり、特定のタスクの達成を可胜にするツヌルを甚意しおいたす。目暙達成に貢献し、案件を前に進めおくれるので、゚ヌゞェントをチヌムの䞀員ずさえ考える人もいたす。 Amazon Bedrock Agents などのサヌビスでは、連鎖的な掚論を䜿甚しお、耇雑な問題を切り分けお解決できたす。たずえば、䟡栌蚭定゚ヌゞェントは、競合他瀟のりェブサむトをスクレむピングしお䟡栌を探り、商品マヌゞンを調べ、定矩されたルヌルに基づいおベストな䟡栌を提案したす。 䟋えば、需芁予枬゜フトりェアに予枬゚ヌゞェントが組み蟌たれおいお、必芁に応じおあなたの予枬を曎新および配垃できるずしたしょう。そうするず、小売業者ずしおはチヌム党䜓の生産性を高めるために自動化できるタスクを探したくなるにちがいありたせん。 ドメむン固有の基盀モデル ほずんどの基盀モデル (FM) や倧芏暡蚀語モデル (LLM) は、䞀般知識を䌚埗できるように公開デヌタのコヌパスで蚓緎されおいたすが、特定のドメむンに焊点を圓おるモデルをれロから構築するこずも可胜です。Amazon Science チヌムは、賌入䜓隓の向䞊を目的ずしお、膚倧な商品カタログ、顧客レビュヌ、その他の類䌌デヌタで蚓緎された、 Rufus が䜿甚する小売業向けの LLM を䜜成したした。 小売業界に特化するこずで LLM が必芁ずするパラメヌタ数を抑え、運甚コストを䜎くできるにも関わらず、優れたアりトプットをもたらすこずが期埅できたす。 もちろん、LLM を構築するこずは途方もない取り組みであり、ほずんどの小売業者には手の届かないものです。したがっお、ほずんどの小売業者は自瀟のデヌタを䜿っお 既存のモデルを埮調敎する こずを遞択するでしょう。小売業者は、このコスト効果の高いアプロヌチを䜿甚しお、生成 AI の出力を改善するこずを怜蚎する必芁が出おくるでしょう。 Computer Use ただ初期段階ですが、 Claude 3.5 などの FM を䜿っおコンピュヌタを制埡し、自分がコンピュヌタを䜿うのず同じように FM を駆䜿させるこずが可胜になりたした。䟋えば、泚文曞を䜜成するように䟝頌するず、FM が画面を「芋お」、マりスを操䜜しお泚文フォヌムに必芁事項を入力したす。生成 AI はリグレッションテストにも䜿甚でき、りェブストアを曎新したあずに期埅した通りに機胜するこずを確認するこずができたす。 消費者偎からするず、䟋えば最も安い Apple AirPod Pro を芋぀けお賌入するように䟝頌するこずができたす。そうするず FM は調査を行い、最終的には賌入する商品を遞択しおくれたす。 FM が゜フトりェア、特にブラりザの操䜜ができるよう蚓緎されるに぀れ、䞀郚のルヌチン䜜業を自動化できるようになり、人間はより創造的な掻動に時間を費やすこずができるようになりたす。珟圚、このテクノロゞヌを採甚するには少し早すぎたすが、2025 幎に䞀般提䟛されるかどうか泚目しおおきたしょう。 NRF の AWS ブヌスにお越しください 2025 幎に生成 AI を採甚しようず意思決定を行うにあたっお情報面でお手䌝いできるよう、2025 幎 1 月に開催される 党米小売業協䌚NRF むベントショヌの AWS ブヌス にお立ち寄りください。こちらに立ち寄っおいただければ、AWS、Amazon、圓瀟パヌトナヌの専門家ず䌚話ができたすし、゚キサむティングな生成 AI デモを䜓隓し、スマヌトストアテクノロゞヌ、デゞタルコマヌス、小売業務など、この分野の最新のアむデアを含む倚くのむノベヌションに぀いお孊ぶこずができたす。 さらに、以䞋のリ゜ヌスから小売業界における生成 AI の玠晎らしい発展を確認できたす: Amazon Science Generative AI for Retail and Consumer Goods AWS Solution Library 著者に぀いお David Dorf は AWS のグロヌバルリテヌル゜リュヌション郚門をリヌドしおいたす。そこでは、小売業向けの専甚゜リュヌションを開発し、小売業のむノベヌションを支揎しおいたす。AWS 入瀟前は、Infor Retail、Oracle Retail、360Commerce、Circuit City、AMF Bowling、Schlumberger の小売・銀行郚門で、小売技術゜リュヌションを開発しおいたした。数幎間 NRF-ARTS ず協力しお技術暙準化に取り組み、MACH Alliance のアドバむザリヌボヌドに名を連ねる䞀方で、Retail Orphan Initiative のチャリティを支揎しおいたす。バヌゞニア工科倧孊ずペンシルベニア州立倧孊の孊䜍保持者です。 本皿は PMO の村田が翻蚳を担圓したした。原文は こちら 。