macOS 環境向けの AWS CodeBuild で Fastlane がご利用いただけるようになりました。AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、すぐにデプロイできるソフトウェアパッケージを作成する、フルマネージド継続的インテグレーションサービスです。 Fastlane は、モバイルアプリ開発のさまざまな側面を自動化するように設計されたオープンソースツールスイートです。コード署名、スクリーンショット生成、ベータ版の配布、アプリケーションストアへの送信などのタスクを管理するための一元化された一連のツールをモバイルアプリデベロッパーに提供します。一般的な継続的インテグレーションおよび継続的デプロイ (CI/CD) プラットフォームと統合し、iOS と Android の両方の開発ワークフローをサポートします。Fastlane は優れたオートメーション機能を提供しますが、デベロッパーはセットアップとメンテナンス中に課題に直面する可能性があります。特に Ruby の構文とパッケージ管理システムに慣れていないチームは、Fastlane の設定が複雑であると感じる可能性があります。モバイルプラットフォームやサードパーティーサービスの更新によって既存のワークフローの調整が必要になる場合があるため、Fastlane とその依存関係を最新の状態に保つには継続的な作業が必要です。 2024 年 8 月に CodeBuild for macOS を導入 したとき、お客様の課題の 1 つがビルド環境に Fastlane をインストールして維持することであることがわかりました。カスタムビルド環境に Fastlane を手動でインストールすることは可能でしたが、AWS は インフラストラクチャから差別化につながらない手間のかかる作業を取り除き 、お客様がビジネスにとって重要な側面により多くの時間を費やせるようにします。本日より、Fastlane はデフォルトでインストールされ、 buildspec.yaml ファイルで使い慣れたコマンド fastlane build を使用できるようになりました。 Fastlane とコード署名 App Store でアプリケーションを配布するには、デベロッパーは Apple Developer ポータルで生成されたプライベートキーを使用してバイナリに署名する必要があります。このプライベートキーと、それを検証する証明書は、ビルドプロセス中にアクセスできる必要があります。これは、開発チームにとって課題となる可能性があります。なぜなら、開発チームは、開発プライベートキー (特定のテストデバイスへのデプロイを可能にするもの) をチームメンバー間で共有する必要があるからです。さらに、App Store にバイナリをアップロードする前の署名プロセスでは、配布プライベートキー (App Store での公開を可能にするもの) が使用可能である必要があります。 Fastlane は、開発キーと配布キーおよび証明書の管理でもデベロッパーをサポートするという点で、多目的なビルドシステムです。デベロッパーは、 fastlane match を使用して、チーム内で署名マテリアルを共有し、個々のデベロッパーのマシンと CI 環境で安全かつ簡単にこれらにアクセスできるようにすることができます。 match を使用すると、プライベートキー、証明書、モバイルプロビジョニングプロファイルをセキュリティで保護された共有ストレージに保存できます。これにより、デベロッパーのノートパソコンであれ、クラウド内のサーバーマシンであれ、ローカルビルド環境が共有ストレージと同期された状態を維持できます。ビルド時に、アプリケーションに署名するために必要な証明書を安全にダウンロードし、 codesign ユーティリティがそれらの証明書を取得できるようにビルドマシンを設定します。 match を使用すると、GitHub、GitLab、Google Cloud Storage、Azure DevOps、 Amazon Simple Storage Service (Amazon S3) を通じて署名シークレットを共有できます。 これらのいずれかを既に使用していて、プロジェクトを CodeBuild に移行する場合、行うべきことはあまりありません。必要なのは、CodeBuild ビルド環境が共有ストレージにアクセスできることを確認することだけです (デモのステップ 3 をご覧ください)。 仕組みを見てみましょう Fastlane または CodeBuild を初めて使用するお客様のために、その仕組みをご紹介します。 このデモでは、 既存の iOS プロジェクト を使用して始めます。プロジェクトは、CodeBuild でビルドされるように既に設定されています。詳細については、以前のブログ記事「 AWS CodeBuild を利用して、継続的インテグレーションパイプラインに macOS を追加する 」をご覧ください。 3 つのステップで開始する方法を説明します: 既存の署名マテリアルを共有プライベート GitHub リポジトリにインポートする プロジェクトをビルドして署名するように fastlane を設定する CodeBuild で fastlane を使用する ステップ 1: 署名マテリアルをインポートする 私が読んだ fastlane に関する ドキュメント のほとんどでは、開始するために新しいキーペアと新しい証明書を作成する方法が説明されています。これは新しいプロジェクトには確かに当てはまりますが、実際には、プロジェクトと署名キーは既に存在している可能性があります。したがって、最初のステップは、これらの既存の署名マテリアルをインポートすることです。 Apple App Store は、開発と配布に異なるキーと証明書を使用します (アドホック証明書とエンタープライズ証明書もありますが、これらはこの記事の範囲外です)。使用ごとに 3 つのファイルが必要です (合計 6 つのファイル): Apple デベロッパーコンソールから作成してダウンロードできる .mobileprovision ファイル。プロビジョニングプロファイルは、ユーザーの ID、アプリケーション ID、アプリケーションが持つ可能性のある権限をリンクします。 Apple がプライベートキーを検証するために発行した証明書である .cer ファイル。これは、 Apple Developer ポータル からダウンロードできます。証明書を選択し、 [ダウンロード] を選択します。 プライベートキーを含む .p12 ファイル。キーは、 Apple Developer ポータル で作成したときにダウンロードできます。ダウンロードしていないが、マシン上に保存されている場合は、Apple Keychain アプリケーションからエクスポートできます。KeyChain.app は macOS 15.x では非表示になっていることに留意してください。 open /System/Library/CoreServices/Applications/Keychain\ Access.app で開くことができます。エクスポートするキーを選択し、右クリックして [エクスポート] を選択します。 これらのファイルを作成したら、次の内容を含む fastlane/Matchfile ファイルを作成します: git_url("https://github.com/sebsto/secret.git") storage_mode("git") type("development") # または、appstore を使用して配布署名キーと証明書を使用します # type("appstore") GitHub リポジトリの URL を置き換え、 このリポジトリがプライベートであるようにしてください 。これは、署名キーと証明書のストレージとして機能します。 その後、 fastlane match import --type appstore コマンドを使用して、既存のファイルをインポートします。各環境 ( appstore と development ) 用のコマンドを繰り返します。 初回は、 fastlane から Apple ID のユーザー名とパスワードの入力を求められます。証明書の有効性を検証したり、必要に応じて新しい証明書を作成したりするために、App Store Connect に接続します。セッション Cookie は ~/.fastlane/spaceship/<your apple user id>/cookie に保存されます。 fastlane match からもパスワードの入力を求められます。このパスワードを使用して、ストレージ上の署名マテリアルを暗号化するためのキーを生成します。このパスワードは、ビルド時に署名マテリアルをビルドマシンにインポートするために使用されるため、忘れないようにしてください。 コマンドとその出力全体を次に示します: fastlane match import --type appstore [✔] 🚀 [16:43:54]: Successfully loaded '~/amplify-ios-getting-started/code/fastlane/Matchfile' 📄 +-----------------------------------------------------+ | Detected Values from './fastlane/Matchfile' | +--------------+--------------------------------------+ | git_url. | https://github.com/sebsto/secret.git | | storage_mode | git | | type | development | +--------------+--------------------------------------+ [16:43:54]: Certificate (.cer) path: ./secrets/sebsto-apple-dist.cer [16:44:07]: Private key (.p12) path: ./secrets/sebsto-apple-dist.p12 [16:44:12]: Provisioning profile (.mobileprovision or .provisionprofile) path or leave empty to skip this file: ./secrets/amplifyiosgettingstarteddist.mobileprovision [16:44:25]: Cloning remote git repo... [16:44:25]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match. [16:44:27]: Checking out branch master... [16:44:27]: Enter the passphrase that should be used to encrypt/decrypt your certificates [16:44:27]: This passphrase is specific per repository and will be stored in your local keychain [16:44:27]: Make sure to remember the password, as you'll need it when you run match on a different machine [16:44:27]: Passphrase for Match storage: ******** [16:44:30]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [16:44:31]: 🔓 Successfully decrypted certificates repo [16:44:31]: Repo is at: '/var/folders/14/nwpsn4b504gfp02_mrbyd2jr0000gr/T/d20250131-41830-z7b4ic' [16:44:31]: Login to App Store Connect (sebsto@mac.com) [16:44:33]: Enter the passphrase that should be used to encrypt/decrypt your certificates [16:44:33]: This passphrase is specific per repository and will be stored in your local keychain [16:44:33]: Make sure to remember the password, as you'll need it when you run match on a different machine [16:44:33]: Passphrase for Match storage: ******** [16:44:37]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [16:44:39]: 🔒 Successfully encrypted certificates repo [16:44:39]: Pushing changes to remote git repo... [16:44:40]: Finished uploading files to Git Repo [https://github.com/sebsto/secret.git] Fastlane が署名マテリアルを Git リポジトリにインポートしたことを確認します。 次のビルドでこれらの署名マテリアルを使用するようにローカルマシンを設定することもできます: » fastlane match appstore [✔] 🚀 [17:39:08]: Successfully loaded '~/amplify-ios-getting-started/code/fastlane/Matchfile' 📄 +-----------------------------------------------------+ | Detected Values from './fastlane/Matchfile' | +--------------+--------------------------------------+ | git_url | https://github.com/sebsto/secret.git | | storage_mode | git | | type | development | +--------------+--------------------------------------+ +-------------------------------------------------------------------------------------------+ | Summary for match 2.226.0 | +----------------------------------------+--------------------------------------------------+ | type | appstore | | readonly | false | | generate_apple_certs | true | | skip_provisioning_profiles | false | | app_identifier | ["com.amazonaws.amplify.mobile.getting-started"] | | username | xxxx@xxxxxxxxx | | team_id | XXXXXXXXXX | | storage_mode | git | | git_url | https://github.com/sebsto/secret.git | | git_branch | master | | shallow_clone | false | | clone_branch_directly | false | | skip_google_cloud_account_confirmation | false | | s3_skip_encryption | false | | gitlab_host | https://gitlab.com | | keychain_name | login.keychain | | force | false | | force_for_new_devices | false | | include_mac_in_profiles | false | | include_all_certificates | false | | force_for_new_certificates | false | | skip_confirmation | false | | safe_remove_certs | false | | skip_docs | false | | platform | ios | | derive_catalyst_app_identifier | false | | fail_on_name_taken | false | | skip_certificate_matching | false | | skip_set_partition_list | false | | force_legacy_encryption | false | | verbose | false | +----------------------------------------+--------------------------------------------------+ [17:39:08]: Cloning remote git repo... [17:39:08]: If cloning the repo takes too long, you can use the `clone_branch_directly` option in match. [17:39:10]: Checking out branch master... [17:39:10]: Enter the passphrase that should be used to encrypt/decrypt your certificates [17:39:10]: This passphrase is specific per repository and will be stored in your local keychain [17:39:10]: Make sure to remember the password, as you'll need it when you run match on a different machine [17:39:10]: Passphrase for Match storage: ******** [17:39:13]: Type passphrase again: ******** security: SecKeychainAddInternetPassword <NULL>: The specified item already exists in the keychain. [17:39:15]: 🔓 Successfully decrypted certificates repo [17:39:15]: Verifying that the certificate and profile are still valid on the Dev Portal... [17:39:17]: Installing certificate... +-------------------------------------------------------------------------+ | Installed Certificate | +-------------------+-----------------------------------------------------+ | User ID | XXXXXXXXXX | | Common Name | Apple Distribution: Sebastien Stormacq (XXXXXXXXXX) | | Organisation Unit | XXXXXXXXXX | | Organisation | Sebastien Stormacq | | Country | US | | Start Datetime | 2024-10-29 09:55:43 UTC | | End Datetime | 2025-10-29 09:55:42 UTC | +-------------------+-----------------------------------------------------+ [17:39:18]: Installing provisioning profile... +-------------------------------------------------------------------------------------------------------------------+ | Installed Provisioning Profile | +---------------------+----------------------------------------------+----------------------------------------------+ | Parameter | Environment Variable | Value | +---------------------+----------------------------------------------+----------------------------------------------+ | App Identifier | | com.amazonaws.amplify.mobile.getting-starte | | | | d | | Type | | appstore | | Platform | | ios | | Profile UUID | sigh_com.amazonaws.amplify.mobile.getting-s | 4e497882-d80f-4684-945a-8bfec1b310b9 | | | tarted_appstore | | | Profile Name | sigh_com.amazonaws.amplify.mobile.getting-s | amplify-ios-getting-started-dist | | | tarted_appstore_profile-name | | | Profile Path | sigh_com.amazonaws.amplify.mobile.getting-s | /Users/stormacq/Library/MobileDevice/Provis | | | tarted_appstore_profile-path | ioning | | | | Profiles/4e497882-d80f-4684-945a-8bfec1b310 | | | | b9.mobileprovision | | Development Team ID | sigh_com.amazonaws.amplify.mobile.getting-s | XXXXXXXXXX | | | tarted_appstore_team-id | | | Certificate Name | sigh_com.amazonaws.amplify.mobile.getting-s | Apple Distribution: Sebastien Stormacq | | | tarted_appstore_certificate-name | (XXXXXXXXXX) | +---------------------+----------------------------------------------+----------------------------------------------+ [17:39:18]: All required keys, certificates and provisioning profiles are installed 🙌 ステップ 2: プロジェクトに署名するように Fastlane を設定する fastlane/Fastfile に Fastlane ビルド設定ファイルを作成します ( fastlane init コマンドを使用して開始できます)。 default_platform(:ios) platform :ios do before_all do setup_ci end desc "Build and Sign the binary" lane :build do match(type: "appstore", readonly: true) gym( scheme: "getting started", export_method: "app-store" ) end end match アクションが正しく機能するには、 setup_ci アクションが Fastfile の before_all セクションに追加されているようにしてください。このアクションは、適切な許可を持つ一時的な Fastlane キーチェーンを作成します。このステップを実行しないと、ビルドが失敗したり、一貫性のない結果が得られたりする可能性があります。 そして、ローカルビルドをコマンド fastlane build でテストします。キーと証明書をインポートする際に使用したパスワードを入力し、システムにプロジェクトのビルドと署名を実行させます。すべてが正しく設定されていると、同様の出力が生成されます。 ... [17:58:33]: Successfully exported and compressed dSYM file [17:58:33]: Successfully exported and signed the ipa file: [17:58:33]: ~/amplify-ios-getting-started/code/getting started.ipa +---------------------------------------+ | fastlane summary | +------+------------------+-------------+ | Step | Action | Time (in s) | +------+------------------+-------------+ | 1 | default_platform | 0 | | 2 | setup_ci | 0 | | 3 | match | 36 | | 4 | gym | 151 | +------+------------------+-------------+ [17:58:33]: fastlane.tools finished successfully 🎉 ステップ 3: Fastlane を利用するように CodeBuild を設定する 次に、CodeBuild でプロジェクトを作成します。それに役立つステップバイステップのガイドにはここでは立ち入りません。 前回の記事 または CodeBuild ドキュメント をご覧ください。 Fastlane 固有の設定は 1 つだけです。署名マテリアルにアクセスするには、Fastlane は環境変数として渡す 3 つのシークレットの値にアクセスする必要があります: MATCH_PASSWORD : 署名マテリアルをインポートする際に入力するパスワード。Fastlane はこのパスワードを使用して、GitHub リポジトリ内の暗号化されたファイルを解読します FASTLANE_SESSION : ~/.fastlane/spaceship/<your apple user id>/cookie にある Apple ID セッション Cookie の値。セッションの有効期間は数時間から数日間です。セッションの有効期限が切れたら、ノートパソコンからコマンド　 fastlane spaceauth を使用して再認証し、 FASTLANE_SESSION の値を Cookie の新しい値で更新します。 MATCH_GIT_BASIC_AUTHORIZATION : GitHub ユーザー名の Base 64 エンコードで、コロンと個人認証トークン (PAT) が続きます。プライベート GitHub リポジトリにアクセスするためのものです。PAT は、 GitHub コンソール の [プロファイル] > [設定] > [デベロッパーの設定] > [個人アクセストークン] で生成できます。この環境変数の値を生成するには、次のコマンドを使用します: echo -n my_git_username:my_git_pat | base64 。 これらの 3 つの値それぞれについて、 AWS Secrets Manager のシークレットの Amazon リソースネーム (ARN) またはプレーンテキストの値を入力できることに留意してください。 セキュリティ上重要な値を保存するには Secrets Manager を利用することを強くお勧めします 。 私はセキュリティを重視するユーザーなので、次のコマンドを使用して 3 つのシークレットを Secrets Manager に保存します: aws --region $REGION secretsmanager create-secret --name /CodeBuild/MATCH_PASSWORD --secret-string MySuperSecretPassword aws --region $REGION secretsmanager create-secret --name /CodeBuild/FASTLANE_SESSION --secret-string $(cat ~/.fastlane/spaceship/my_appleid_username/cookie) aws --region $REGION secretsmanager create-secret --name /CodeBuild/MATCH_GIT_BASIC_AUTHORIZATION --secret-string $(echo -n my_git_username:my_git_pat | base64) ビルドプロジェクトが Secrets Manager に保存されているシークレットを参照する場合、ビルドプロジェクトのサービスロールで secretsmanager:GetSecretValue アクションを許可する必要があります。プロジェクトの作成時に [新しいサービスロール] を選択した場合、CodeBuild はビルドプロジェクトのデフォルトのサービスロールにこのアクションを含めます。しかし、 [既存のサービスロール] を選択した場合は、このアクションをサービスロールに別途含める必要があります。 このデモでは、次の AWS Identity and Access Management (IAM) ポリシーを使用します: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-2:012345678912:secret:/CodeBuild/*" ] } ] } AWS マネジメントコンソール の CodeBuild セクションでプロジェクトを作成した後、3 つの環境変数を入力します。値は Secrets Manager のシークレットの名前であることに留意してください。 環境変数とその Secrets Manager シークレット名を buildpsec.yaml ファイルで定義することもできます。 次に、プロジェクトのルートにある buildspec.yaml ファイルを変更して、 fastlane を使用してバイナリをビルドおよび署名します。私の buildspec.yaml ファイルは次のようになりました: # buildspec.yml version: 0.2 phases: install: commands: - code/ci_actions/00_install_rosetta.sh pre_build: commands: - code/ci_actions/02_amplify.sh build: commands: - (cd code && fastlane build) artifacts: name: getting-started-$(date +%Y-%m-%d).ipa files: - 'getting started.ipa' base-directory: 'code' バックエンドの Amplify 設定を受け取るには、Rosetta スクリプトと Amplify スクリプトが必要です。プロジェクトで AWS Amplify を利用しない場合、これらは必要ありません。 ビルドファイルには、署名キーをダウンロードしたり、ビルド環境でキーチェーンを準備したりするものがないことに留意してください。 fastlane match がそれを実行してくれます。 新しい buildspec.yaml ファイルと ./fastlane ディレクトリを Git に追加します。これらのファイルをコミットしてプッシュします。 git commit -m "add fastlane support" && git push すべてがうまくいけば、CodeBuild でビルドが実行され、「 成功 」メッセージが表示されます。 料金と利用可能なリージョン CodeBuild for macOS が利用可能なすべての リージョン において、CodeBuild が使用するすべての macOS イメージに、追加料金なしで Fastlane がプリインストールされるようになりました。この記事の執筆時点では、これらのリージョンは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト) です。 私の経験では、 fastlane match を正しく設定するには少し時間がかかります。設定が完了したら、CodeBuild で動作させるのは非常に簡単です。これを CodeBuild で試す前に、ローカルマシンで動作することを確認してください。CodeBuild で問題が発生した場合は、環境変数の値を三重に確認し、CodeBuild が AWS Secrets Manager のシークレットにアクセスできることを確認してください。 さあ、(macOS で) ビルドしましょう! 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 みなさんいかがお過ごしでしょうか。私は週末に軽い気持ちで挑んだアイススケートによる筋肉痛が治っていません。 さて、2025 年 3 月 6 日 に AWS Innovate: Generative AI + Data がオンラインで開催されます。最新の AWS の生成 AI サービスとお客様事例を通じたユースケースを学ぶことができるイベントとなっています。アジェンダも公開されていますのでご覧の上ぜひご登録ください！ それでは、2 月 3 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「DeepSeek-R1 モデルが AWS で使用可能に」を公開 現在話題の DeepSeek ですが、1 月 30 日より Amazon Bedrock と Amazon SageMaker AI で DeepSeek-R1 モデルをデプロイできるようになっています。本記事では、 1) Amazon Bedrock Marketplace 、2) Amazon SageMaker JumpStart 、3) Amazon Bedrock Custom Model Import 、4) Amazon EC2 Trn1 インスタンス の4種類のデプロイ方法を紹介しています。ぜひお試しあれ。 ブログ記事「【開催報告】基盤モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術 ～ AWS Trainium2 & Amazon Bedrock Marketplace ～」を公開 2025 年 1 月 14 日に基盤モデル開発者向けのイベントを開催しました。こちらの記事はイベントの開催報告ブログです。 Amazon EC2 Trn2 インスタンスおよび Trn2 UltraServers と Amazon Bedrock Marketplace の紹介、生成 AI 基盤モデルを開発されたお客様セッションの様子が紹介されています。 ブログ記事「生成 AI を使用して商品画像から新機能を引き出す」を公開 この記事では、小売および消費財業界における生成 AI のユースケースを紹介しています。商品画像を生成 AI でテキスト化することで検索エンジン最適化 (SEO) を改善する、商品画像をベクトル化することでビジュアルデータの検索を可能にする、画像を生成させ商品のアイディエーションに活用する、といった例を挙げています。ユースケースの参考にぜひご覧ください。 ブログ記事「Amazon Q Developerにおけるリアルタイム実行によるコード生成の強化」を公開 Amazon Q Developer エージェント は、複数のファイルにまたがった自律的なコード生成機能を持っています。最近のアップデートで、コード生成に加えて自動でビルド・テストを実行させることもできるようになりました。使い方や例をブログで紹介しています。簡単に試すことができますので、ぜひ記事を読みながら体験いただければと思います。 サービスアップデート Amazon Q Business にて、ユーザークエリのオーケストレーション機能を追加 Amazon Q Business は、企業向けの生成 AI アシスタントサービスです。Salesforce などのビジネスツールや企業固有の情報と連携し、検索・データ活用することが可能になっています。今回のアップデートで、ユーザーの問い合わせ内容を Amazon Q Business が理解し、適切なデータソースに自動的に振り分けて応答生成することができるようになりました。使用するデータソースやビジネスツールを手動で選択する必要がなくなったのが嬉しいポイントです。 Amazon Q Developer の AWS コンソールエラー対応機能が全 AWS リージョンで利用可能に Amazon Q Developer は、権限不足、設定の誤り、サービス制限の超過といったコンソール上に表示されるエラーを診断する機能を提供しています。これまでバージニア北部とオレゴンリージョンのみで提供していましたが、この度全リージョンで利用可能になりました。 Amazon Q Developer にて、Pro Tier サブスクリプションのセットアップが容易に Amazon Q Developer Pro Tier サブスクリプションのセットアップ体験が改善され、設定と管理がより容易になりました。わずか 2 ステップでユーザーやチームのサブスクライブができるようになっています。 次回は、新しく執筆メンバーとして参加することになった ソリューションアーキテクト野間 が最新情報をお届けします！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 まだまだ寒い日が続きますが、みなさんいかがお過ごしですか。私は寒いのが苦手なので、家でゆっくりしたい派です。 少し先のイベントですが、AWS Innovate Generative AI + Data | 2025 年 3 月 6 日開催の 参加登録 が開始しました。AWS だけでなくお客様からの実際のユースケースのセッションも盛りだくさんです。ぜひ、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025 年 2 月 3 日週の主要なアップデート 2/3(月) AWS CodeBuild が Buildkite と統合されました AWS CodeBuild は、セルフホスト Buildkite ランナーのネイティブサポートを提供し、CodeBuild 環境内で Buildkite パイプラインジョブを実行できるようになりました。 AWS CodeBuild は、ソースコードをコンパイルし、テストを実行し、デプロイ準備の整ったソフトウェアパッケージを生成する、フルマネージド継続的インテグレーションサービスです。 Amazon EC2 で Microsoft SQL Server の VSS を使用した自動復旧をサポート Amazon EC2 において、VSS (Volume Shadow Copy Services) を使用した EBS スナップショットからの自動復旧が可能になりました。この機能により、実行中の Microsoft SQL Server データベースを停止することなく、AWS Systems Manager の Automation Runbook を使用して特定の時点への復旧を自動化できるようになりました。VSS は、アプリケーションが実行中でもデータのバックアップを取ることができる機能です。従来は手動で行っていた復旧作業が自動化され、大規模なデータベースでも数分以内に復旧できるようになります。また、新しいデータベースとして復元したり、特定の時点への復旧を行ったりすることも可能です。 2/5(水) AWS Step Functions で AWS アカウントあたり 100,000 個のステートマシンとアクティビティをサポート AWS Step Functions は、AWS のサービス間の連携を視覚的に構築できるワークフローサービスです。今回のアップデートでは、1 つの AWS アカウントで作成できるステートマシンとアクティビティの上限数が、従来の 10,000 から 100,000 へと 10 倍に引き上げられました。ステートマシンとは、システムの処理の流れを定義したものです。この変更により、より多くのワークフローを単一の AWS アカウント内で管理できるようになり、特に動的にワークフローを生成するようなアプリケーションの開発がしやすくなりました。このクォータの引き上げは自動的に全ての AWS アカウントに適用され、お客様側での特別な設定は不要です。 AWS IAM が暗号化された SAML アサーションのサポートを発表 AWS IAM において、SAML 認証情報の暗号化サポートが開始され、セキュリティが大幅に強化されました。SAML は多くのアイデンティティプロバイダー (IdP) が利用するオープンな標準規格で、シングルサインオン (SSO) を実現するために使用されます。この仕組みを通じて、企業のユーザーやアプリケーションは AWS Management Console へのログインや AWS API の呼び出しを行うことができます。今回のアップデートの主な特徴は、アイデンティティプロバイダーが IAM に送信する SAML 認証情報を暗号化できる点です。その結果、SAML 認証情報が中間者（エンドユーザーのウェブブラウザなど）を経由する場合でも、暗号化された状態で安全に転送されることが保証されます。 AWS Wickr でファイルを整理・アクセスできる専用スペースを提供開始 AWS Wickr に、ファイルを整理してアクセスするための専用スペース機能が追加されました。AWS Wickr は、セキュリティを最優先したメッセージングおよびコラボレーションサービスです。この新機能「Wickr Files」により、会話の中でファイルの管理がより便利になりました。Wickr ルームのモデレーターや、自己管理型のグループ会話のユーザーは、フォルダにファイルをアップロードして整理することができるようになりました。また、「Messages」と「Files」のタブを切り替えることで、必要なコンテンツにアクセスし、コラボレーションを効率化することができます。 Amazon Q Business がユーザークエリ管理のオーケストレーションを導入 Amazon Q Business の新機能として、ユーザーの問い合わせ管理のためのオーケストレーション機能が導入されました。Amazon Q Business は、仕事に関する情報検索、洞察の獲得、アクションの実行をサポートする生成 AI アシスタントです。今回のアップデートでは、ユーザーからの問い合わせを理解し、適切なデータソースやプラグインに自動的に振り分けて、関連性の高い回答を生成する機能が追加されました。これまでは、ユーザーが業務上の作業を完了し、データソースから洞察を得るために、異なる業務アプリケーション間を手動で切り替える必要がありました。しかし、このオーケストレーション機能により、ユーザーの問い合わせを企業固有のデータソースやプラグインに自動的に振り分けることで、手動での選択が不要になり、会話体験が大幅に向上しました。 2/6(木) Cost Optimization Hub が EC2 Auto Scaling グループの推奨事項をさらに拡充 Cost Optimization Hub の機能が強化され、EC2 Auto Scaling グループに関する新しいコスト最適化レコメンデーションが追加されました。今回のアップデートにより、アイドル状態の EC2 Auto Scaling グループの検出と、スケーリングポリシーや複数のインスタンスタイプを持つ EC2 Auto Scaling グループのサイジング推奨機能が利用できるようになりました。さらに、スタンドアロンの EC2 インスタンスとは別に、EC2 Auto Scaling グループを簡単にフィルタリングして集計できるため、コスト削減の可能性が高い EC2 Auto Scaling グループを特定しやすくなりました。 Amazon Q Developer で Pro tier サブスクリプションの新しい簡素化されたセットアップ機能を導入 Amazon Q Developer の Pro プランのセットアップ体験が新しく改善されました。Amazon Q は AWS が提供する開発者向けの AI 支援ツールで、今回のアップデートでは特に Pro プランの導入をよりシンプルにする改善が行われました。新しいセットアップ方法では、統合開発環境 (IDE) で Amazon Q Developer を試してみたいユーザーやチーム向けに、わずか 2 ステップの簡単なセットアップフローが用意されました。 Amazon GuardDuty の S3 向けマルウェア保護の料金が値下げ Amazon GuardDuty Malware Protection for S3 の価格が大幅に値下げされました。この機能は、Amazon S3 バケットに新しくアップロードされるオブジェクトに対してマルウェアスキャンを実施する、フルマネージドなセキュリティサービスです。2025 年 2 月 1 日より、データスキャンに関する料金が 85% 引き下げられます。これは、スキャンインフラストラクチャとデータ処理の効率化により実現した改善を、AWS のポリシーに基づいてお客様に還元するものです。GuardDuty Malware Protection for S3 の料金は、評価されるオブジェクトの数とスキャンされるデータ量の 2 つの要素に基づいて計算されます。今回の価格改定では、データスキャンの料金が引き下げられ、例えば US East (バージニア北部) リージョンでは、1 GB あたり $0.60 から $0.09 に下がります。 Amazon RDS for Oracle が 2025 年 1 月のリリースアップデートをサポート Amazon RDS for Oracle において、Oracle Database 19c および 21c に対する 2025 年 1 月のリリースアップデート (RU) のサポートが開始されました。このアップデートにより、Oracle データベースの最新のセキュリティパッチや機能改善が適用できるようになります。Amazon RDS for Oracle の各エンジンバージョンでサポートされている Oracle RU の詳細については、 Amazon RDS for Oracle のリリースノート で確認することができます。自動マイナーバージョンアップグレード (AmVU) オプションを有効にしている場合、AWS リージョンで Amazon RDS for Oracle が提供を開始してから 6 〜 8 週間後に、データベースインスタンスが最新の四半期 RU に自動的にアップグレードされます。これらのアップグレードは、事前に設定されたメンテナンスウィンドウの時間帯に実行されます。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

こんにちは！アマゾン ウェブ サービス ジャパンのソリューションアーキテクト金杉です。本ブログでは、3 月 6 日 (木) に開催される AWS Innovate について、その概要と見どころをご紹介します。 AWS Innovate は、年に 2 回開催される、特定のテーマに焦点を当てたテクノロジーオンラインイベントです。2025 年 3 月 6 日に開催する AWS Innovate では、Generative AI + Data をテーマとし、生成 AI やデータ活用における最新の技術動向や事例をみなさまにお届けする予定です (詳細・お申込みは こちら から)。生成 AI というテクノロジーが台頭してから早くも数年経ち、多くのお客様が PoC を経て、本番利用に移り、更にどのように価値を最大化できるかについて模索されています。このような背景から、今回は「生成 AI によるビジネス価値の創出」をテーマとし、「生成 AI ユーザージャーニー」、「データ活用」、「生成 AI アプリケーション開発」の3つの切り口で、全 16 のセッションをお届けします。生成 AI の利用を既に開始している方には、より広く・深く活用を進めるためのベストプラクティスを、生成 AI に興味を持っておりこれから使い始める方には活用のヒントを持ち帰っていただけます。AWS エキスパートのセッションに加え、実際に生成 AI を活用しビジネス価値を生み出しているお客様の事例も紹介してまいります。 生成 AI ジャーニーの進行 生成 AI は事業運営のあり方から働き方まで、我々の仕事に大きな変化をもたらしているのは周知の事実です。業界や組織によって、導入の度合いは異なるものの、生成 AI はこれからの数年間で世の中を大きく変える、ゲームチェンジャーになりうるテクノロジーです。振り返ってみると、2023年、生成 AI は急速に世界の議論の最前線へと台頭しました。多くの個人や組織はこの技術をキャッチアップし、PoC を通じてどのように活用できるか、実験を繰り返していました。2024 年、PoC で得た知見をもとに、生成 AI アプリケーションを本番環境で活用するようになってきました。そして 2025 年はその延長線上で、いかに生成 AI を広く、深く活用していけるかとともに、「どのようにビジネス効果を最大化できるか」に関心がシフトしつつあります。 加えて、AWS は多くのお客様の生成 AI ジャーニーに伴走する中で、「モデルの多様化」、「要件の高度化」、「活用領域の拡大」などのトレンドを観測しています。これには、驚異的なスピードで進化する大規模モデル及び専門領域に特化したカスタムモデルを開発する手法の多様化、「RAG」に加え「エージェント」や「マルチモーダル」などの新しい技術パターンの確立、そして社内利用から to B/to C 向けシステムにおける採用検討の加速、などの背景があります。 「データ」も生成 AI を活用していく上で重要な要素の一つです。世の中で公開されている基盤モデルは企業のプライベートなデータを使って学習されているわけではないので、当然ながら企業の自社コンテキストは把握していません。そのため競合優位性を高めていくためには、自社データを生成AIアプリケーションに組み込ませていくニーズが高まっています。価値を最大化するためには、データを鮮度の高い状態で素早く生成 AI アプリケーションに組み込ませる必要があります。しかし、多くの場合、企業内のデータはサイロ化しているため、統合して活用するにも作業が煩雑となり、工数、コストがかかりがちです。 今回の AWS Innovate では、これらの背景や課題を噛み砕いで説明し、AWS が提供するソリューションやベストプラクティスをオープニングセッションと 3 つのトラックで紹介していきます。 セッションと見どころの紹介 オープニングセッション オープニングセッションでは、生成 AI を活用状況の最新トレンドを踏まえ、ビジネス価値を最大化するためのベストプラクティスについてお話しします。従来専門家のみが扱えると考えられていた AI を、誰もがビジネス価値向上のための選択肢として考えられるようになりました。その背景や技術的な観測を説明した上で、AWS の取り組みやテクノロジーについてご紹介します。生成 AI をこれから導入する方、今後さらに活用を加速していきたい方に対し、AWS がこれまで多くのお客様を支援する過程で培ってきたノウハウをお伝えします。 ブレイクアウトセッション ブレイクアウトセッションでは 3 つのトラックをご用意しました。 １つ目は「生成 AI ユーザージャーニー」をテーマとしています。本トラックは １ つの AWS セッションと ４ つのお客様による事例セッションから構成されます。生成 AI をどのように活用していくかは企業のビジネス関心、利用フェーズ、スキルセットなどから画一的な答えはありませんが、新しい技術を取り入れていく上で成功事例から学べることは多く存在します。本トラックでは、まずAWS が、ビジネスモデルの変革を成し遂げた事例に共通する方程式を紹介し、三菱重工業株式会社様によるカスタマーサポート対応力向上、カラクリ株式会社様から独自 LLM による競合優越性確立、株式会社三菱UFJ銀行様による市場セールス部門での DX 推進、株式会社ゲームエイト様による自動監視による運用コスト削減に関するセッションをお届けします。 ２つ目は「ビジネスに寄与するデータ活用」というテーマで、生成 AI の価値最大化におけるデータの重要性を紹介します。生成 AI の効果を最大化するためには、大規模言語モデル (LLM) の日々向上する性能に加え、自社データを組み合わせ、差別化を図ることが効果的です。そして自社データを継続的に活用していくためには、長期的な観点からのデータ戦略が必要です。本トラックでは、データ戦略に含まれるデータの収集、品質担保、カタログ管理、ガバナンス、そしてデータが最終的にどのように生成 AI に活かせるかを数セッションに分けてお届けします。 最後に、３つ目のトラックでは「生成 AI アプリケーション開発」という観点から、最新のプラクティス・ソリューションを紹介します。生成 AI アプリケーションには SaaS のように手軽に始めるケース、API 経由で独自アプリケーションを構築するパターン、インフラレベルでモデルを独自開発するなど、様々な形態があります。本トラックでは多岐に渡る生成 AI アプリケーションの開発における手法やツール、活用のためのコツを紹介します。また、アプリケーション開発を促進するための、生成 AI による開発者支援のセッションもご用意しています。 当日のアジェンダはこちらです： タイムテーブルを PDF で見る AWS Innovate: Generative AI + Data をより楽しむために 本ブログを通じて、AWS Innovate: Generative AI + Data に少しでも興味を持っていただけた方は、ぜひ イベントページ から登録いただけると幸いです！改めて、今回の Innovate は「生成 AI によるビジネス価値の創出」をテーマとしています。皆さんに対し日進月歩な生成 AI テクノロジーの最新状況を紹介し、更なる活用に向けてヒントをお届けできればと考えています。より有意義な時間となるよう、自身や自社の生成 AI 活用状況を棚卸ししていただくと同時に、実際に AWS のコンソール からサービスを立ち上げて触ってみていただけると、当日の理解がより深まると思います。 それでは、3 月 6 日 (木) のみなさまのご参加をお待ちしています。当日はチャット形式のライブ Q＆A も実施しますので、AI/ML やデータ活用についての疑問点、お悩みなどもお気軽にお寄せください。みなさまと会話できることを楽しみにしております。 詳細・お申込みは こちら から みなさまのご参加をお待ちしています！ ソリューションアーキテクト 金杉

2025 年 1 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Entity Resolution 柔軟で設定可能なワークフローを使用し、複数のアプリケーション、チャネル、データストアにまたがる関連レコードの照合、リンク、拡張を簡単に行うことができるサービス AWS Entity Resolution について、機能の詳細や利用パターンをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データマッチングに課題を抱えている方 AWS を利用したデータコラボレーションを検討されている方 Customer360 など、データ活用に興味がある方 本 BlackBelt で学習できること AWS Entity Resolution を使用したデータマッチング環境の構築について、サービス概要と機能を学習できます。 また、データマッチングを検討、または課題をお持ちの方に向けて、具体的な利用パターンを知ることができます。 スピーカー 髙橋 伸幸 ソリューションアーキテクト AWS IoT Greengrass ネットワーク/セキュリティ編 AWS IoT Greengrass は、インテリジェント IoT デバイスをより速く構築するためのサービスと、IoT デバイス向けのエッジランタイムです。 本セミナーでは、AWS IoT Greengrass のネットワークセキュリティ編として、AWS IoT Greengrass におけるネットワークとセキュリティについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 IoT 製品やサービスの担当者 これから AWS IoT を用いた製品やサービスの開発を検討されている方 AWS IoT Greengrass をインターネット接続に制約があるネットワーク下で使用することを検討されている方 AWS IoT Greengrass のセキュリティの仕組みを把握したい方 本 BlackBelt で学習できること AWS IoT Greengrass をネットワークに制約がある環境で利用する場合の設定や構成例 AWS IoT Greengrass のセキュリティに関する機能や注意すべき点 スピーカー 中谷 友哉, 藤原 弘樹, 小坂 雄大 クラウドサポートエンジニア AWS MGN 大規模移行の計画と実行をお手軽にする便利な機能紹介編 AWS Application Migration Service (AWS MGN) は、お客様のアプリケーションを AWS に単純移行するために推奨される主要なサービスです。本コンテンツでは、大規模な移行、複数アカウントへの移行に活用できる AWS Application Migration Service の4つの機能についてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS MGN を使用した大規模な移行における手順を簡素化したい方 AWS MGN を使用した複数アカウントへの移行を検討されている方 AWS MGN の機能についてより詳しく理解したい方 本 BlackBelt で学習できること AWS MGN の4つの機能（Application/Wave によるグルーピング、Import and Export 機能、Global View 機能、MGN Connector）の概要とメリット スピーカー 鈴木 槙将 ソリューションアーキテクト AWS Transit Gateway deep dive 本セッションでは AWS Transit Gateway の deep dive 編といたしまして、基礎的な概念や仕組みから、アーキテクチャパターン、見落としがちな注意点まで幅広くご紹介いたします。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS を利用される予定のネットワーク担当者 AWS のネットワーク設計を担当している方 AWS Transit Gateway について深く学びたい方 本 BlackBelt で学習できること 基礎的な概念や仕組みから、アーキテクチャパターン、見落としがちな注意点まで幅広くご紹介しています。 初学者から上級者まで AWS Transit Gateway の全てを学習できる内容となっています。 スピーカー 櫻井 俊和 シニアソリューションアーキテクト PrivateLink and Lattice – Amazon VPC Lattice Service 編 Amazon VPC Lattice は、異なる VPC や AWS アカウントにまたがるサービス間のネットワーク接続とアプリケーションレイヤールーティングを管理するサービスです。Blackbelt では、VPC Lattice の基本概念、構成要素、ユースケースについて学べます。 Resource Configuration などの利用については、PrivateLink and Lattice – AWS PrivateLink 編を公開予定です。そちらも合わせてご覧ください。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon VPC Lattice について深く学びたい方 アプリケーションネットワークの構成でお悩みの方 異なる VPC 間のサービス通信の簡素化を目指している方 本 BlackBelt で学習できること Amazon VPC Lattice の概要 Amazon VPC Lattice の機能解説と使用方法 Amazon VPC Lattice のユースケース スピーカー 中本 翔太 ソリューションアーキテクト Amazon GuardDuty 基礎編 Amazon GuardDuty は、悪意のあるアクティビティや異常な動作をモニタリングし、 AWS 環境に対するセキュリティ脅威を検知するサービスです。本セミナーでは、Amazon GuardDuty の機能概要と調査方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon GuardDuty の使用を考えている方 Amazon GuardDuty がどのようなサービスか知りたい方 Amazon GuardDuty が検知した脅威の調査方法について知りたい方 本 BlackBelt で学習できること Amazon GuardDuty の機能の全体像や仕組みの理解 Amazon GuardDuty のデフォルト機能の詳細について Amazon GuardDuty を使用した基本的な調査の流れについて 他サービスを併用した脅威検知時の自動化や対応の流れについて スピーカー 藤田 皓大 クラウドサポートエンジニア Amazon Detective Amazon Detective は、AWS 環境におけるセキュリティ問題の調査と分析を支援するマネージドサービスであり、複雑なセキュリティインシデント調査を強力にサポートするサービスです。本セミナーでは、Amazon Detective の機能や利用方法について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS のセキュリティ運用を担当している方 クラウドセキュリティの可視化や調査機能に興味がある方 Amazon GuardDuty や AWS Security Hub をすでに有効化されている方 Amazon Detective について深く学びたい方 本 BlackBelt で学習できること Amazon Detective の各ユースケースにおける主要機能の理解 Amazon Detective を用いたセキュリティインシデントの調査方法 スピーカー 影山 諒 テクニカルアカウントマネージャー 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-02 AWS Database Migration Service ベストプラクティス – 運用・監視編 クラウドサポートエンジニア 大井 基彰 2025-03 AWS Database Migration Service トラブルシューティング クラウドサポートエンジニア 大石 明久 2025-03 AWS Well-Architected Framework 入門編 シニアパートナーソリューションアーキテクト 前田 賢介

Amazon Timestream for LiveAnalytics が AWS Database Migration Service (AWS DMS) のターゲットエンドポイントとして新たにサポートされました。この機能追加により、時系列データを AWS DMS でサポートされているソースデータベースから Timestream に移行できるようになります。 多くの業界のお客様が Timestream を採用して、リアルタイムの洞察を導き出し、重要なビジネスアプリケーションを監視し、Web サイトやアプリケーション全体にわたる何百万ものリアルタイムイベントを分析しています。AWS DMS の移行機能を使用する事で、ダウンタイムを削減しながら、既存の時系列データを移行し、進行中の時系列データを Timestream にレプリケートできるようになりました。尚、Timestream は AWS DMS Parallel Load および Parallel Apply 機能もサポートしているため、大量のデータを並行して処理可能であり、大幅に高速なデータ移行が可能になります。 本投稿では、AWS DMS でサンプル PostgreSQL ソースエンドポイントのターゲットとして Timestream を使用する方法を説明します。 ソリューションの概要 DMS で移行を設定するとき、ソースデータベースはデータが現在存在する場所であり、ターゲットデータベースはデータの転送先です。本投稿では、PostgreSQL ソースデータベースから Timestream ターゲットデータベースにデータを移行します。レプリケーションインスタンスは移行タスクを実行するコンポーネントであり、VPC 内のソースとターゲットの両方にアクセスする必要があります。本投稿では、まず Timestream データベースを設定し、データを移行するために AWS DMS に必要な AWS Identity and Access Management (IAM) アクセス許可を割り当てる方法を説明します。セットアップが完了したら、タスクを実行して、データが Timestream データベースに移行されたことを確認できます。 尚、AWS DMS Timestream エンドポイントは RDBMS ソース のみをサポートすることに注意してください。 前提条件 AWS DMS がどのように機能するかについて基本を理解している必要があります。AWS DMS を使い始めたばかりの場合は、 AWS DMS のドキュメント を確認してください。移行を実行するには、サポートされている AWS DMS ソース エンドポイントと Timestream ターゲットも必要です。 Timestream の IAM リソースの設定 Timestream データベースを AWS DMS ターゲットとして設定し、データ移行を開始するのは簡単です。まず、必要な権限を持つ IAM ロールを作成します。 IAM コンソールのナビゲーションペインで ポリシー を選択します。 ポリシーの作成 を選択します。 次のコードを使用して IAM ポリシーを作成します。 AWS リージョン、アカウント ID、データベース名を適宜更新します。本投稿では、ポリシーに dms-timestream-access という名前を付けます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDescribeEndpoints", "Effect": "Allow", "Action": [ "timestream:DescribeEndpoints" ], "Resource": "*" }, { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "timestream:ListTables", "timestream:DescribeDatabase" ], "Resource": "arn:aws:timestream: {region} : {account_id} :database/ {database_name} " }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "timestream:WriteRecords", "timestream:UpdateTable", "timestream:CreateTable" ], "Resource": "arn:aws:timestream: {region} : {account_id} :database/ {database_name} /*" } ] } このポリシーには、Timestream に対する 3 つの主要な権限が含まれています。 エンドポイントの参照権限 – Timestream エンドポイントを参照する機能を付与します。これは、他の Timestream アクセス許可と組み合わせて使用される DescribeDatabase 関数を使用する場合に重要です。 データベースの説明とテーブルリストへのアクセス – 特定のデータベースの説明を使用して、その存在と AWS DMS へアクセス可能かを確認できます。また、そのデータベース内のテーブルをリストすることもできます。これは、既存のテーブルを識別し、必要に応じて新しいテーブルを作成するために重要です。 データ挿入およびテーブル管理機能 – AWS DMS が Timestream にデータ挿入、テーブルの更新、またメモリまたはマグネティックストアの期間に変更が必要な場合に不可欠です。 これで、使用するロールに IAM ポリシーをアタッチできるようになりました。 IAM コンソールのナビゲーションペインで ロール を選択します。 ロールの作成 を選択します。 信頼されたエンティティタイプ で、 AWS サービス を選択します。 サービスまたはユースケース で、 DMS を選択します。 次へ を選択します。 ロールに名前を付けます (本投稿では、 dms-timestream-role という名前を付けます)。 作成したポリシーをアタッチします。 ロールを作成します。 Timestream データベースを作成する Timestream データベースを作成するには、次の手順を実行します。 Timestream コンソールのナビゲーションペインで データベース を選択します。 データベースを作成 を選択します。 設定を選択 で、 標準データベース を選択します。 名前 にデータベースの名前を入力します。 KMS キー は、キー ID を選択します。 データベースを作成 を選択します。 ターゲットの Timestream エンドポイントを作成する AWS DMS を使用して Timestream エンドポイントを設定するには、次の手順を実行します。 AWS DMS コンソールのナビゲーションペインで エンドポイント を選択します。 エンドポイントの作成 を選択します。 エンドポイントタイプ で、 ターゲットエンドポイント を選択します。 エンドポイント識別子 に、エンドポイントの名前を入力します (本投稿では、 timestream-target を使用します)。 ターゲットエンジン に、Amazon Timestream を選択します。 サービスアクセスロールの Amazon リソースネーム (ARN) に、前に作成したロール ( dms-timestream-role ) のロール ARN を入力します。 メモリストアの保持 については、ユースケースに応じて設定します。メモリストアの保持は時間単位で計算され、サポートされる範囲は 1 ～ 8,736 時間です。メモリストアは高速取り込み用に最適化されています。ベストプラクティスとして、移行するデータの大部分に対応できるようにメモリストアの保存期間を設定します。 マグネティックストアの保持 についても、ユースケースに応じて期間を設定します。 マグネティックストアの保持は日単位で測定され、サポートされる範囲は 1 ～ 73,000 日です。マグネティックストアはデフォルトでは読み取り専用ですが、エンドポイント設定を調整し、 EnableMagneticStoreWrites を true に設定することで書き込み機能を有効にできます。この変更を行うと、メモリストアの保存期間外のデータは、長期間保存するためにマグネティックストアに自動的に転送されます。マグネティックストアは履歴データを更新するように設計されており、大量の取り込みはサポートしていません。履歴データをマグネティックストアにロードすることが目的の場合は、AWS DMS を使用して CSV 形式で Amazon Simple Storage Service (Amazon S3) に移行してから、Timestream で バッチロード を使用することをお勧めします。マグネティックストアの保存期間より古い記録は自動的に削除されるため、保存期間の設定を慎重に検討する必要があります。 オプションとして、エンドポイントに CdcInsertsAndUpdates と EnableMagneticStoreWrites を設定できます。 CdcInsertsAndUpdates はブール型フィールドで、デフォルトでは false です。 true の場合、変更データキャプチャ (CDC) 中にソースデータベースへの削除操作の場合、Timestream への反映が行われません。 false の場合、ソースデータベースからデータ削除が行われるタイミングで Timestream へのデータ更新が行われます。これが望ましい動作である可能性がある理由は、本 Blog 執筆時点では、Timestream がレコード削除をサポートしていないためです。代わりに、AWS DMS は、数値タイプの場合は 0 の値、VARCHAR の場合は NULL 文字列、ブール値の場合は False を追加してレコードを null にします。これは、レコードにデータが含まれていないことを示すためです。削除する前の元のレコードを残しておきたい場合は、 CdcInsertsAndUpdates を true に設定します。 EnableMagneticStoreWrites もブール型フィールドです。デフォルトでは false です。 true の場合、メモリストアの保持期間外ではあるが、マグネティックストアの保持期間内であれば、レコードをマグネティックストアに直接書き込むことができます。但し、入力が大きいとスロットリングが発生するため、ほとんどのユースケースでは推奨されません。 EnableMagneticStoreWrites を true とするのは、一部のレコードがメモリストアの保存期間外にあり、それらのレコードをスキップしたくない場合を対象としています。 エンドポイントの作成 を選択して、ターゲットエンドポイントを作成します。 移行タスクを作成する Timestream ターゲットエンドポイントを使用して移行タスクを作成するには、次の手順を実行します。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。[ データベース移行タスクの作成 を選択します。 Timestream ターゲットで使用するレプリケーションインスタンスとソースデータベースエンドポイントを指定します。 ターゲットとして作成した Timestream エンドポイントを選択します。 完了したい移行のタイプに応じて、移行タスクを選択します。 タスク設定 セクションで、 JSON エディタ を選択し、それに応じて設定を調整します。 コードには次の主要なパラメータが含まれています。 ParallelLoadThreads – AWS DMS が各テーブルを Timestream ターゲットに最初にロードするために使用するスレッドの数を決定します。最大は 32 スレッドです。 ParallelLoadBufferSize – Timestream ターゲットの並列ロードスレッドによって使用されるバッファの最大レコード数を、デフォルトの 50 から最大 1,000 までの範囲で設定します。 ParallelLoadQueuesPerThread – ターゲットへのバッチロードのデータレコードを処理するために各スレッドがアクセスするキューの数を定義します。Timestream ターゲットのデフォルト設定は 1 で、範囲は 5 ～ 512 です。 ParallelApplyThreads – CDC ロード中に AWS DMS がデータを Timestream ターゲットにプッシュするために使用する同時スレッドの数を 0 ～ 32 の範囲の値で指定します。 ParallelApplyBufferSize – 各バッファーキューが保持できるレコードの最大数を示します。CDC ロード中に同時スレッドによってデータをタイムストリームターゲットにプッシュするために使用されます。デフォルトは 100、最大値は 1,000 です。 ParallelApplyQueuesPerThread – CDC 中に Timestream エンドポイントにバッチロードするデータレコードを抽出するためのスレッドあたりのキューの数を 1 ～ 512 の範囲で指定します。 これらのパラメータを設定する事で、レコード書き込みをバッチ処理で実施し、より高速な移行を有効にすることができます。 ParallelLoadQueuesPerThread および ParallelApplyQueuesPerThread のサイズは 100 に設定することをお勧めします。これは、Timestream への 1 回の書き込みあたりの最大レコード数であり、この方法で最高のスループットが得られるためです。 スループットに応じてスレッド数を調整する必要があります。 負荷に応じてスレッド毎のキューの数を調整する必要がありますが、インスタンスメモリをあまり消費しないように、50 程度の比較的低い値に設定すべきです。 Timestream ターゲットを使用して AWS DMS 移行タスクを設定する場合の最も重要な部分は、ソーステーブルが Timestream テーブルにどのようにマップされるかです。Timestream をターゲットとして使用する場合、Timestream には独自のマッピングルールがあります。いくつかのサンプルデータを使用して、これがどのように機能するかを見てみましょう。 テーブルが 2 つあるとして、1 つのテーブルは sensor_data 、もう 1 つのテーブルは sensors とします。次のスクリーンショットは、 sensor_data のデータの例を示しています。 このテーブルの作成に使用される SQL コマンドは次のとおりです。 CREATE TABLE sensor_data ( serial SERIAL PRIMARY KEY, sensor_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, temperature NUMERIC, humidity NUMERIC, light NUMERIC, co2 NUMERIC, humidityratio BOOLEAN ); 次のコマンドを使用して、テーブルにサンプルデータを入力します。 INSERT INTO sensor_data (sensor_time, temperature, humidity, light, co2, humidityratio) SELECT NOW() - (random() * (20 * INTERVAL '1 day')), (random() * (30 - 15) + 15)::NUMERIC(5,2), (random() * (90 - 10) + 10)::NUMERIC(5,2), (random() * (1000 - 10) + 10)::NUMERIC, (random() * (2000 - 300) + 300)::NUMERIC, (random() < 0.5)::BOOLEAN FROM generate_series(1, 10000); sensors テーブルの場合、データは重要ではありません。重要なのは、テーブルマッピングが Timestream の移行にどのような影響を与えるかを示すことです。 この例では、以下のようにテーブルマッピングを構成します。 { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "schema-name": "{your_schema}", "table-name": "sensor_data" }, "rule-action": "include" }, { "rule-type": "object-mapping", "rule-id": "2", "rule-name": "timestream-map", "rule-action": "map-record-to-record", "object-locator": { "schema-name": "{your_schema}", "table-name": "sensor_data" }, "target-table-name": "sensor_data_timestream", "mapping-parameters": { "timestream-dimensions": [ "serial" ], "timestream-timestamp-name":"sensor_time" } } ] } 上のコードでは、 sensor_data テーブルのみをマッピングしています。サンプルデータではディメンジョン ( timestream-dimension )として serial を指定し、タイムスタンプ名 ( timestream-timestamp-name ) として sensor_time を設定します。 ディメンジョンとタイムスタンプ名は、Timestream のマッピングルールに必須です。 また、Timestream のマッピングルールを持つテーブルのみが移行されます。 使用可能なマッピングには次の 2 種類があります。 シングルメジャーマッピング – この場合、タイムスタンプまたはディメンション ( sensor_time および serial ) ではないすべての列が独自のレコードにマッピングされます。たとえば、 sensor_data テーブルについて考えてみましょう。ソースデータベース内の 1 レコード毎に、Timestream には 5 つのレコードが存在します。それぞれは同じ sensor_time と serial を持ちますが、温度のレコードが 1 つ、湿度のレコードが 1 つ、光のレコードが 1 つというような形で設定されます。 マルチメジャーマッピング – マルチメジャーマッピングを使用するには、 "timestream-timestamp-name":"sensor_time" と同じセクションに設定を追加します。ここで、マルチメジャーレコードのメジャー名として使用するソースの列を指定します。一例として、 serial: "timestream-multi-measure-name": "serial" のように記述して再利用してみましょう。これは、 serial の値が Timestream のディメンションだけでなくメジャー名としても使用されることを意味します。Timestream の結果は次のようになります。ソースデータベース内のレコード毎に、ディメンション: serial 、タイムスタンプ: sensor_time 、および serial の値のメジャー名を持つ 1 つのレコードが Timestream に存在します (最初の行の例では、このレコードは 1 になります)。このレコードには、ソースデータベースの各列のメジャー値が含まれます。マルチメジャーマッピングを使用する場合は、Timestream の 8,192 個の一意のメジャー名の制限に抵触しないように、通常は "timestream-hash-measure-name": True を使用する必要があります。詳細については、「 マルチメジャーレコードのパーティション化に関する推奨事項 」を参照してください。 本投稿では、単一メジャーマッピングを使用します。したがって、 sensor_data をマッピングするように設定すると、最初の選択ルールに sensors を追加した場合でも、 sensors は無視されます。 タスクの作成 を選択して、Timestream ターゲットエンドポイントを使用して移行タスクを作成します。 移行タスクの実行 タスクを開始するには、次の手順を完了してください。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。 作成したタスクを選択します。 アクション メニューで、 開始 を選択します。 Timestream データベースを監視して、移行アクティビティを表示できます。 移行の検証 データが Timestream にあることを確認するには、次の手順を実行します。 Timestream コンソールのナビゲーション ペインの 管理ツール で、 クエリエディター を選択します。 choose a database to query で、移行先のデータベースを選択します。 移行されたレコードの数を確認するには、次のクエリを入力します。 select count(*) from {your_db_name}."{your_table_name}" サンプルデータを表示するには、次のクエリを入力します。 select * from {your_db_name}."{your_table_name}” 少なくとも 10 行が移行されていると仮定すると、次のスクリーンショットに示すように、結果には選択したテーブル内の 10 行のレコードが表示されるはずです。 エラーハンドリング Timestream への移行時に直面する可能性のある一般的な問題を次に示します。 テーブルマッピングを作成するときは、 timestream-dimension と timestream-timestamp-name を必ず含めてください。また、 timestream-timestamp-name がソースデータベーステーブル内の実際の列であり、タイプが timestamp であり、大文字と小文字が正しいことを確認してください。次のコードを参照してください。 "mapping-parameters": { "timestream-dimensions": [ "serial" ], "timestream-timestamp-name":"sensor_time" } アクセスポリシーの IAM ロールに信頼関係として AWS DMS があることを確認します。これを確認するには、IAM コンソールで自分のロールに移動し、 信頼関係 を確認します。 ParallelLoad または ParallelApply を使用すると、インスタンスはより多くのメモリを使用します。メモリ不足が原因でタスクが失敗した場合は、インスタンスをスケーリングする必要があります。インスタンスのサイジングに関する推奨事項については、「 移行に適した AWS DMS レプリケーションインスタンスの選択 」を参照してください。 クリーンアップ 移行が完了したので、AWS DMS、Timestream、および IAM リソースをクリーンアップします。 AWS DMS コンソールのナビゲーションペインで データベース移行タスク を選択します。 作成したレプリケーションタスクを選択し、 アクション メニューで 削除 を選択します。 AWS DMS コンソールのナビゲーションペインで エンドポイント を選択します。 作成したエンドポイントを選択し、 アクション メニューで 削除 を選択します。 AWS DMS コンソールのナビゲーションペインで レプリケーションインスタンス を選択します。 作成したレプリケーションインスタンスを選択し、 アクション メニューで 削除 を選択します。 Timestream コンソールのナビゲーションペインで データベース を選択します。 削除するデータベースを選択し、 削除 を選択します。 IAM コンソールのナビゲーションペインで ロール を選択します。 作成したロールを選択し、 削除 を選択します。 IAM コンソールのナビゲーションペインで ポリシー を選択します。 作成したポリシーを選択し、 削除 を選択します。 これらの手順を完了したら、この投稿用に作成したすべてのリソースがクリーンアップされるでしょう。 結論 本投稿では、Timestream データベースを作成し、移行に必要なアクセス許可を AWS DMS に付与し、AWS DMS レプリケーションインスタンス、エンドポイント、タスクを作成することで、AWS DMS 移行をセットアップする方法を説明しました。次に、そのタスクを実行し、データが Timestream データベースに正常に移行されることを確認しました。これで、このタスクを独自のワークロードで実行できるようになりました。最後のステップ ( 移行タスクの作成と実行 ) は、AWS DMS タスク間で共通になりました。これにより、希望するリレーショナルデータベースから完全なエンドツーエンドの移行を実行し、データを Timestream データベースに表示できるようになります。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本記事は 2025 年 1 月 30 日に公開された “ Enhancing Code Generation with Real-Time Execution in Amazon Q Developer ” を翻訳したものです。 AI がソフトウェア開発における急速なイノベーションを推進する中で、高品質なコード生成を促進するためには、リアルタイムにテストできる信頼性の高い実行環境が不可欠です。開発者は、 AI が生成したコードがプロジェクトの要件を満たしているかを確認するためのデバッグと反復に多くの時間を費やし、その結果、機能の提供が遅れることもあります。以前の Amazon Q Developer の開発用エージェントはコード生成に重点を置いていました。最新のアップデートにより、エージェントはリアルタイムでコードをビルドしてテストし、開発者がレビューする前に変更を検証できるようになりました。この新機能は、コードレコメンデーションの品質向上、エラーの検出、生成されたコードとプロジェクトの最新状態の同期、そしてコード生成とテストワークフローの両方を効率化することによる開発プロセスの加速が含まれます。これらはコミュニティからのフィードバックに直接対応したものです。 自然言語による入力とプロジェクト固有のコンテキストにより、 Amazon Q Developer エージェント は複数のファイルにまたがる複雑な機能、バグ修正、テストスイートの実装を支援するように設計されています。たとえば、開発者は Amazon Q Developer エージェントに e コマースアプリケーションにチェックアウト機能を追加をリクエストするとしましょう。エージェントは既存のコードベースを分析し、ユニットテストの実行やコードのビルドを含め、数分以内にすべての必要なコード変更とテストを行い、コードがレビューの準備ができていることを確認します。このアプローチにより、開発効率が大幅に向上し、エラーが減少します。 IDE で Amazon Q Developer エージェントを使用するには、 Amazon Q 拡張機能をインストールし、チャットウィンドウで /dev コマンドを使用してリクエストを開始するだけです。 IDE で /dev コマンドが入力されると、エージェントはプロジェクトをパッケージ化して Amazon Q にセキュアな方法でアップロードし、プロジェクト固有のコード生成を開始します。 Amazon Q Developer エージェントは、単なるコード生成だけでなく、開発者とのリアルタイムな接続を維持し、プロセスの進捗を共有しながら、要求された機能のための洗練されたパッチや実装を提供します。 このリアルタイム実行は、開発環境とエージェントが使用できるコマンドを定義する Devfile によって動作します。プロジェクトに Devfile が存在しない場合、 /dev を初めて実行した際に Amazon Q Developer が作成を促します。Devfile がない場合でもエージェントはソリューションを開発できますが、ビルドや単体テストの実行によるフィードバックが得られないため、リアルタイムでの開発支援が制限されます。 Devfile は Devfile 2.2.0 スキーマ に準拠している必要があります。現在、 Amazon Q Developer は install 、 build 、および test コマンドをサポートしています。 Amazon Q Developer の最新アップデートにおける主な機能強化 カスタマイズ可能なコマンド: 開発者は Devfile でコマンドを指定することで、AI エージェントが実行するコマンドを制御できます。これにより、不要なステップを削減し精度を向上させることができます。 柔軟な環境セットアップ: 開発者は依存関係が事前に読み込まれたカスタム Docker イメージを使用して起動時間を短縮できます。これにより、エージェントに必要なツールをすべて備えた状態で動作できます。 サンドボックス化されたセキュリティ: Amazon Q Developer は、隔離された環境内で実行を安全に保護し、包括的なログ記録と堅牢なアクセス許可制御を提供して、行われた変更を保護します。 これらの仕組みにより、 Amazon Q Developer はサンドボックス内で直接テストを実行し、マイグレーションを適用し、インストールコマンドを実行して、反復的な改善のためにエージェントにフィードバックを提供できます。 セキュリティと隔離 AI によって生成されたコードの実行は、セキュリティ上慎重に扱う必要があるため、Amazon Q Developer エージェントはいくつかの保護機能を導入しています: 環境の隔離: コマンドは、非公開のインターネットリソースにアクセスするための認証情報が含まれない隔離された管理下のサンドボックス環境内で実行されます。この環境は、許可されたアクションのみが安全に実行されることを保証します。 Devfile 駆動: この機能には Devfile が必要で、 Devfile の設定により開発者は開発プロセス中にエージェントが使用するコマンドを制御できます。 Amazon Q Developer エージェントの開始方法 Amazon Q Developer を開始するには、 AWS Builder ID を持っているか、 Amazon Q の使用を許可する AWS IAM Identity Center インスタンスを持つ組織に所属している必要があります。 Visual Studio Code でソフトウェア開発に Amazon Q Developer エージェントを使用するには、まず Amazon Q 拡張機能 をインストールします。 Amazon Q Developer のページ で最新バージョンの拡張機能を見つけることができます。この拡張機能は、 JetBrains 、 Eclipse （プレビュー）、および Visual Studio IDE でも利用可能です。サポートされている IDE の詳細なリストと、各 IDE で利用可能な機能については、 Amazon Q Developer のドキュメント を参照してください。 認証後、 Amazon Q のチャットウィンドウで /dev と入力することで、機能開発エージェントを呼び出すことができます。 Amazon Q Developer は、 Amazon Q Developer エージェントによって生成されたコードを安全に実行するために、分離されたサンドボックス環境を活用します。これにより、生成されたコードを安全に実行し、元のコードベースと同期した状態を保ちます。プロセスの仕組みは以下の通りです： 実行環境の初期化: プロンプトを受け取ると、 Amazon Q Developer エージェントはサンドボックスインスタンスまたは開発者が指定した Docker コンテナを開始し、これをコード実行のためのサンドボックス環境として利用します。 安全なコマンド実行: Amazon Q Developer エージェントは、利用者にて定義した Devfile の仕様に基づいて、事前に指定されたシェルコマンドのリストを安全に実行します。 Devfile は開発環境の設定と依存関係をモデル化し、一貫した環境の再現を可能にし、手作業によるセットアップの労力を削減します。開発者は Devfile 内でカスタムコマンドを定義して、依存関係のインストール、テストの実行、データベースマイグレーションの適用、ビルドスクリプトの実行など、サンドボックス内のアクションを制御することで、精度と効率を向上させることができます。 フィードバックと同期: 各コマンドの実行後、コードの変更が追跡され、 AI エージェントにリアルタイムのフィードバックが提供されることで、反復的な改善が可能になります。 ユースケース例 1：既存のプロジェクトへのテストスイートの追加 GitHub の react-solitaire のような React ベースのアプリケーションの機能を強化したいとします。新機能を追加する際、既存の機能を維持し、アップデートのたびに壊れないようにすることが重要です。これを実現するために、継続的なテストとコードの反復のためのテストスイートを作成することを目指します。 これを説明するために、 GitHub から React プロジェクトをクローンし、環境と依存関係を定義する Devfile を追加します。 Devfile により、サンドボックス内でコードの変更を安全に実行・テストできるようになり、既存の機能に影響を与えずにアップデートを適用できます。 以下は React ベースのプロジェクトのシンプルな Devfile です。Devfile を使用すると、依存関係のインストール、プロジェクトのビルド、テストの実行 など、Amazon Q Developer が使用するコマンドを定義できます。 Example Devfile for a React-based Project schemaVersion: 2.0.0 components: - name: dev container: image: public.ecr.aws/aws-mde/universal-image:latest commands: - id: test exec: component: dev commandLine: "npm install && npm run test" リポジトリをクローンしたら、プロジェクトフォルダのルートに Devfile を配置します。次に、Visual Studio Code で Amazon Q のチャットを開き、 /dev コマンドを入力してリポジトリ用のカスタマイズされたテストスイートの作成を促します。 訳者注： Create test suite for my repo : このリポジトリのテストスイートを作って Amazon Q Developer エージェントはコードベースの分析を開始し、実施している変更や作業中のファイルについてリアルタイムで更新情報を共有します。エージェントはまずプロジェクト構造を調査し、必要な更新を計画し、そしてテストスイートを生成します。 数ステップの後、エージェントは必要なテストスイートを作成します。 その後、エージェントはテストを実行し、失敗がないか継続的に監視します。問題が検出された場合、すぐには停止せず、テストからのフィードバックに基づいてコードを積極的に改善し、このプロセスを最大3回繰り返します。3回の反復後も問題が解決しない場合、エージェントはプロセスを中止します。ただし、問題が修正された場合は、次のステップに進みます。たとえば、エージェントが Enzyme が React 18 をサポートしていないことを確認した際、その問題に対処し、テスト環境でテストを再実行しました。 問題が解決されると、エージェントは次のステップに進み、サンドボックスで変更したすべての変更とファイルを表示し、変更を受け入れるかフィードバックを提供するかを尋ねます。 出力に満足している場合は「Accept code」にて変更を受け入れることができ、満足していない場合は「Provide feedback & regenerate」にてエージェントにフィードバックを提供してコードの再生成を要求することができます。 ユースケース例 2：機能が更新された時のテストの再実行 テストの作成と実行に成功した後、エージェントは UI にゲーム名を表示する新機能を追加するよう指示されました。エージェントはリポジトリを分析し、更新が必要なファイルを特定し、変更を実装する正確な場所を決定しました。 更新を適用した後、エージェントはテストを実行して新機能を検証し、既存のコードベースとのシームレスな統合を促進し、開発プロセス全体を通じて信頼性を維持します。 エージェントによる変更を受け入れると、index.html ファイルが更新され、「Solitaire」というテキストが含まれるようになり、新しいコンテンツが既存のプロジェクトにスムーズに統合されます。 まとめ Amazon Q Developer のこの新しいアップデートの導入は、 AI 駆動の開発における重要な進歩を意味しています。これにより、 Amazon Q Developer エージェントはコード生成に重点を置いたツールから堅牢な実行エンジンへと進化しました。開発者がリアルタイムでコードの変更を検証およびテストできるようにすることで、 AI が生成するファイルと修正の正確性と信頼性を向上させることができます。 AWS のマネージドサンドボックスを使用したり、カスタム環境を持ち込んだりする柔軟なオプションにより、開発者は Amazon Q Developer エージェントの可能性を最大限に引き出すためのコントロールを得ることができます。この新しい実行機能により、チームはより迅速に反復し、十分な情報に基づいた調整を行い、ニーズに合わせた安全でインテリジェントなプラットフォームを活用できます。 VS Code または JetBrains の Amazon Q Developer の拡張機能 を更新またはインストールすることで、今すぐ試すことができます。 翻訳はApp Dev Consultantの宇賀神が担当しました。

私は 1 月 27 日週、バンコクで開催された AWS Community Day Thailand に参加し、すばらしい時間を過ごしました。このイベントは、 AWS アジアパシフィック (バンコク) リージョン の最近の立ち上げに続く、興奮が高まっている時期に開催されました。参加者は 300 名を超え、コミュニティからは AWS ヒーロー 1 名と AWS コミュニティビルダー 4 名を含む 15 名の講演者を招き、技術的な専門知識と経験を共有していただきました。 ハイライトは、AWS の Vice President & Chief Evangelist である Jeff Barr 氏による「Next-Generation Software Development」(次世代ソフトウェア開発) と題されるインスピレーションに満ちた基調講演でした。この基調講演により、この日の会場の空気は最高潮に達しました。この日は、AWS の Country Manager for Thailand である Vatsun Thirapatarapong の歓迎の挨拶で幕を開け、AWS ユーザーグループのボランティアと AWS タイチームの多大なサポートのおかげで、さらに特別な日となりました。 イベントの興奮を捉えた写真を次に示します: 1 月 27 日週の AWS のリリース 1 月 27 日週は 30 件以上のリリースがありましたが、私が注目したリリースをいくつかご紹介します: DeepSeek-R1 モデルが AWS で使用可能に – DeepSeek-R1 モデルを Amazon Bedrock と Amazon SageMaker AI にどのようにデプロイできるようになったのかについて、Channy が記事を書きました。これは、インフラストラクチャへの投資を最小限に抑えながら、生成 AI アプリケーションを構築およびスケールするのに役立ちます。 Amazon S3 Tables でテーブル制限がバケットあたり 10,000 に引き上げ – S3 Tables は、各テーブルバケットでの最大 10,000 個のテーブルの作成をサポートするようになりました。これにより、アカウントごとに 1 つの AWS リージョン内で 10 個のバケットにまたがって最大 100,000 個のテーブルにスケールできます。 Amazon S3 メタデータの一般提供を開始 – S3 メタデータは、簡単にクエリでき、自動化され、ほぼリアルタイムで更新されるメタデータを提供し、ビジネス分析とリアルタイム推論アプリケーションを簡素化します。AWS 分析サービスとの統合を含む、システム定義のメタデータとカスタムメタデータの両方をサポートします。 AWS Amplify が Lambda 関数用の TypeScript Data クライアントサポートを追加 – デベロッパーは、 AWS Lambda 関数内で Amplify Data クライアントを使用できるようになりました。これにより、フロントエンドとバックエンドのアプリケーション全体で一貫したタイプセーフなデータオペレーションが可能になります。 AWS Elastic Beanstalk が Amazon Linux 2023 で Python 3.13 、 .NET 9 、および PHP 8.4 のサポートを追加 – AWS Elastic Beanstalk は、Amazon Linux 2023 の強化されたセキュリティとパフォーマンス機能の恩恵を享受しながら、アプリケーションのデプロイに最新の言語機能と改善をもたらします。 community.aws より community.aws から、私が個人的に最も気に入っている 5 つの記事をご紹介します: Deploying DeepSeek-R1 Distill Llama Models on Amazon Bedrock (著者: Manu Mishra) Building Tile Slide (著者: Yash) Farm, Build, Fight! The survival RPG you never knew you needed (著者: AgentOk) PEP and PDP for Secure Authorization with Cognito (著者: Jimmy Dahlqvist) Q-Bits: Simplifying VPC configurations setup with AWS CloudFormation using Amazon Q Developer (著者: Suruchi Saxena) 今後予定されている AWS とコミュニティのイベント カレンダーを確認して、今後の AWS およびコミュニティのイベントにサインアップしましょう: AWS Korea re:Invent reCap Online (2 月 2 日～4 日) – re:Invent 2023 の主要な発表とイノベーションをまとめた、韓国のオーディエンス向けの仮想イベント。 AWS Community Day – 技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とするコミュニティ主導のカンファレンスに参加しましょう。次回の AWS Community Day は アフマダーバード (2 月 8 日) で開催予定です。 AWS Public Sector Day London (2 月 27 日) – 公共部門のリーダーやイノベーターとともに、AWS が政府、教育、医療の分野でデジタルトランスフォーメーションをどのように実現しているのかを詳しく見ていきます。 AWS Innovate GenAI + Data Edition – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンス。複数のリージョンで開催されます: APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日)。 今後開催予定の AWS 主導の対面イベント と、 デベロッパー向けの仮想イベント をさらにご覧ください。 AWS コミュニティ re:Invent re:Caps 最後に、AWS re:Invent の主要な発表やイノベーションについて知りたい場合は、AWS コミュニティがコミュニティの観点でこれらの発表の概要を共有しているので、最新情報を入手できます。 AWS コミュニティ re:Invent re:Caps デッキ をダウンロードしてください。 2 月 3 日週はここまでです。2 月 10 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024 年 12 月 2 日から 6 日の AWS re:Invent で、Amazon の CEO であるアンディー ジャシーは、Amazon が社内で約 1,000 の 生成 AI アプリケーションを開発した経験から得た 有益な教訓を共有しました 。ジャシーは、この大規模な AI デプロイから引き出した 3 つの重要な見解を示しました。これらの見解が Amazon のエンタープライズ AI 実装へのアプローチを形作りました。 1 つ目は、生成 AI アプリケーションをスケールするにつれて、コンピューティングコストが非常に重要になるということです。人々は、より優れた料金パフォーマンスを強く望んでいます。2 つ目は、本当に優れた生成 AI アプリケーションを構築するのは、実際にはかなり難しいということです。3 つ目は、やりたいことを選ぶ自由をビルダーに与えたときに使用されるモデルが多様であるということです。これは驚くことではありません。なぜなら、私たちは同じ教訓を何度も何度も学んでいるからです。それは、世界を支配するツールは 1 つだけではないということです。 アンディーが強調したように、Amazon が提供する幅広く奥深いモデルにより、お客様は独自のニーズにとって最適な機能を正確に選択できます。AWS は、お客様のニーズと技術の進歩の両方を注意深くモニタリングすることで、厳選されたモデルのセレクションを定期的に拡大し、業界で定評のあるモデルに加えて、有望な新しいモデルも含めるようにしています。この高性能で差別化されたモデルオファリングのこの継続的な拡大は、お客様が AI イノベーションの最前線に留まるのに役立ちます。 これが中国の AI スタートアップである DeepSeek につながります。DeepSeek は 2024 年 12 月に DeepSeek-V3 をリリースし、その後、2025 年 1 月 20 日に DeepSeek-R1 、6,710 億のパラメータを備えた DeepSeek-R1-Zero、および 15 億～700 億のパラメータを備えた DeepSeek-R1-Distill モデルをリリースしました。同社は 2025 年 1 月 27 日に、ビジョンベースの Janus-Pro-7B モデルを追加しました。これらのモデルは公開されており、 同等のモデルよりも 90～95% 手頃な料金でコスト効率が高いと言われています 。DeepSeek によると、同社のモデルは、強化学習などの革新的なトレーニング手法を通じて実現された推論機能に強みを持っています。 1 月 30 日より、 Amazon Bedrock と Amazon SageMaker AI で DeepSeek-R1 モデルをデプロイできるようになりました 。Amazon Bedrock は、API を通じて事前トレーニング済みの基盤モデルを迅速に統合したいチームに最適です。Amazon SageMaker AI は、高度なカスタマイズ、トレーニング、デプロイと、基盤となるインフラストラクチャへのアクセスを希望する組織に最適です。さらに、 AWS Trainium と AWS Inferentia を使用して、 Amazon Elastic Compute Cloud (Amazon EC2) または Amazon SageMaker AI を介して DeepSeek-R1-Distill モデルをコスト効率よくデプロイすることもできます。 AWS を利用して、インフラストラクチャ投資を最小限に抑えながら、この強力でコスト効率の高い DeepSeek-R1 モデルを使用することで、生成 AI のアイデアを構築および実験し、責任をもってスケールできます。また、セキュリティのために独自に設計された AWS のサービス上に構築することで、自信をもって生成 AI イノベーションを推進できます。Amazon Bedrock と Amazon SageMaker AI の両方のお客様が使用できる生成 AI アプリケーション用に保護レイヤーを追加するために、DeepSeek-R1 モデルのデプロイを Amazon Bedrock ガードレール と統合することを強くお勧めします。 1 月 30 日、DeepSeek-R1 モデルを AWS にデプロイする方法はいくつかあります: 1) Amazon Bedrock Marketplace (DeepSeek-R1 モデル) 、 2) Amazon SageMaker JumpStart (DeepSeek-R1 モデル) 、 3) Amazon Bedrock Cust om Model Import (DeepSeek-R1-Distill モデル) 、 4) Amazon EC2 Trn1 インスタンス (DeepSeek-R1-Distill モデル) 。 AWS で DeepSeek-R1 モデルの使用を開始するためのさまざまな方法をご紹介します。初めての AI アプリケーションを構築する場合でも、既存のソリューションをスケールする場合でも、これらの方法はチームの専門知識と要件に基づいた柔軟な開始点を提供します。 1.Amazon Bedrock Marketplace の DeepSeek-R1 モデル Amazon Bedrock Marketplace は、Amazon Bedrock の業界をリードするモデルの現在のセレクションに加えて、100 を超える人気、新興、および専門的な FM を提供しています。単一のカタログでモデルを簡単に見つけ、モデルをサブスクライブしてから、マネージドエンドポイントにモデルをデプロイできます。 Amazon Bedrock Marketplace の DeepSeek-R1 モデルにアクセスするには、 Amazon Bedrock コンソール に移動し、 [基盤モデル] セクションの [モデルカタログ] を選択します。モデルプロバイダーで検索またはフィルタリングすることで、DeepSeek を迅速に見つけることができます。 モデルの機能を含むモデルの詳細ページや実装ガイドラインを確認した後、エンドポイント名を指定し、インスタンスの数を選択して、インスタンスタイプを選択することで、モデルを直接デプロイできます。 また、VPC ネットワーキング、サービスロールの許可、暗号化の設定など、DeepSeek-R1 モデルのセキュリティとインフラストラクチャの設定をカスタマイズできるようにする高度なオプションを設定することもできます。本番デプロイの場合、組織のセキュリティとコンプライアンスの要件に合わせてこれらの設定を確認する必要があります。 Amazon Bedrock ガードレールを使用すると、ユーザー入力とモデル出力を個別に評価できます。生成 AI アプリケーションで望ましくない有害なコンテンツをフィルタリングすることで、定義した一連のポリシーを使用してユーザーと DeepSeek-R1 間のインタラクションを制御できます。Amazon Bedrock Marketplace の DeepSeek-R1 モデルは、Bedrock の ApplyGuardrail API でのみ使用でき、Amazon Bedrock の外部で使用可能なカスタム FM とサードパーティー FM のユーザー入力とモデル応答を評価できます。詳細については、「 Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する 」をお読みください。 Amazon Bedrock ガードレールは、 Amazon Bedrock エージェント や Amazon Bedrock ナレッジベース などの他の Bedrock ツールと統合して、責任ある AI ポリシーに整合した、より安全でセキュアな生成 AI アプリケーションを構築することもできます。詳細については、 AWS の責任ある AI ページにアクセスしてください。 Amazon Bedrock Marketplace で DeepSeek-R1 モデルをデプロイする方法については、このステップバイステップガイドをご覧ください。詳細については、「 Deploy models in Amazon Bedrock Marketplace 」にアクセスしてください。 2.Amazon SageMaker JumpStart の DeepSeek-R1 モデル Amazon SageMaker JumpStart は、FM、組み込みアルゴリズム、および数回クリックするだけでデプロイできる事前構築済みの機械学習 (ML) ソリューションを備えた ML ハブです。SageMaker JumpStart で DeepSeek-R1 をデプロイするには、 SageMaker Unified Studio 、 SageMaker Studio 、 SageMaker AI コンソール で DeepSeek-R1 モデルを見つけるか、または SageMaker Python SDK を通じてプログラムを使用して見つけることができます。 Amazon SageMaker AI コンソール で、SageMaker Unified Studio または SageMaker Studio を開きます。SageMaker Studio の場合は、 [JumpStart] を選択し、 [すべてのパブリックモデル] ページで「 DeepSeek-R1 」を検索します。 モデルを選択し、デプロイを選択して、デフォルト設定でエンドポイントを作成できます。エンドポイントが [InService] になると、そのエンドポイントにリクエストを送信して推論を行うことができます。 Amazon SageMaker AI の機能 ( Amazon SageMaker Pipelines 、 Amazon SageMaker Debugger 、コンテナログなど) を使用して、モデルのパフォーマンスと ML オペレーションのコントロールを導き出すことができます。モデルは AWS の安全な環境にデプロイされ、仮想プライベートクラウド (VPC) の制御下にあるため、データセキュリティのサポートに役立ちます。 Bedrock Marketpalce と同様に、SageMaker JumpStart の ApplyGuardrail API を使用して、生成 AI アプリケーション用のセーフガードを DeepSeek-R1 モデルからデカップリングできます。FM を呼び出さずにガードレールを使用できるようになったため、使用するモデルにかかわらず、標準化され、徹底的にテストされたエンタープライズセーフガードをアプリケーションフローにさらに統合できるようになりました。 Amazon SageMaker JumpStart で DeepSeek-R1 をデプロイする方法については、このステップバイステップガイドをご覧ください。詳細については、「 Discover SageMaker JumpStart models in SageMaker Unified Studio 」または「 Deploy SageMaker JumpStart models in SageMaker Studio 」にアクセスしてください。 3.Amazon Bedrock カスタムモデルインポートを使用した DeepSeek-R1-Distill モデル Amazon Bedrock カスタムモデルインポート では、基盤となるインフラストラクチャを管理することなく、単一のサーバーレス統合 API を通じて、カスタマイズされたモデルをインポートして既存の FM とともに使用できます。Amazon Bedrock カスタムモデルインポートを使用すると、15 億～700 億のパラメータを含む DeepSeek-R1-Distill Llama モデルをインポートできます。 Amazon Bedrock モデル蒸留に関する私のブログ記事 でご紹介したとおり、蒸留プロセスでは、6,710 億のパラメータを持つ大規模な DeepSeek-R1 モデルを教師モデルとして使用して、その動作と推論パターンを模倣するように、より小さく効率的なモデルをトレーニングします。 これらの公開モデルを Amazon Simple Storage Service (Amazon S3) バケットまたは Amazon SageMaker Model Registry に保存した後、 Amazon Bedrock コンソール 内で [基盤モデル] の [インポートされたモデル] に移動し、Amazon Bedrock を通じてフルマネージドサーバーレス環境にインポートしてデプロイします。このサーバーレスアプローチは、エンタープライズグレードのセキュリティとスケーラビリティを提供しながら、インフラストラクチャ管理の必要性をなくします。 Amazon Bedrock カスタムモデルインポートを使用して DeepSeek-R1 モデルをデプロイする方法については、この ステップバイステップガイド をご覧ください。詳細については、「 Import a customized model into Amazon Bedrock 」にアクセスしてください。 4.AWS Trainium と AWS Inferentia を使用した DeepSeek-R1-Distill モデル AWS Deep Learning AMI (DLAMI) は、小規模な CPU のみのインスタンスから最新の高性能マルチ GPU インスタンスまで、さまざまな Amazon EC2 インスタンスで深層学習に使用できるカスタマイズされたマシンイメージを提供します。DeepSeek-R1-Distill モデルを AWS Trainuim1 または AWS Inferentia2 インスタンスにデプロイして、極めて高いコストパフォーマンスを実現できます。 使用を開始するには、 Amazon EC2 コンソール に移動し、Deep Learning AMI Neuron (Ubuntu 22.04) と呼ばれる Neuron Multi Framework DLAMI を使用して trn1.32xlarge EC2 インスタンスを起動します。 起動した EC2 インスタンスに接続したら、 大規模言語モデル (LLM) を提供するオープンソースツールである vLLM をインストールし、Hugging Face から DeepSeek-R1-Distill モデルをダウンロードします。vLLM を使用してモデルをデプロイし、モデルサーバーを呼び出すことができます。 詳細については、AWS Inferentia および Trainium に DeepSeek-R1-Distill Llama モデルをデプロイする方法に関するこの ステップバイステップガイド をご覧ください。 Hugging Face で DeepSeek-R1-Distill-Llama-8B または deepseek-ai/DeepSeek-R1-Distill-Llama-70B モデルカードにアクセスすることもできます。 [デプロイ] を選択し、次に [Amazon SageMaker] を選択します。 [AWS Inferentia および Trainium] タブから、DeepSeek-R1-Distill Llama モデルをデプロイするためのサンプルコードをコピーします。 DeepSeek-R1 のリリース以降、Amazon EC2 および Amazon Elastic Kubernetes Service (Amazon EKS) へのデプロイに関するさまざまなガイドが公開されています。確認すべき追加資料をいくつか次に示します: Leveraging DeepSeek-R1 with CPU and GPU options on AWS (著者: Daniel Wirjo ) Benefits of installing DeepSeek on an Amazon EC2 instance (著者: Enrique Aguilar Martinez ) Deploying DeepSeek Llama models on Amazon EC2 inferentia instance (著者: Irshad Chohan ) How to deploy and fine-tune DeepSeek models on AWS (著者: Hugging Face ) Hosting DeepSeek-R1 on Amazon EKS Auto Mode (著者: Tiago Reichert ) 知っておくべきこと 知っておくべき重要な事項をいくつか次に示します。 料金 – DeepSeek-R1 などの公開モデルの場合、Amazon Bedrock Markeplace、Amazon SageMaker JumpStart、および Amazon EC2 のために選択した推論インスタンス時間に基づいて、インフラストラクチャ料金のみが課金されます。Bedrock カスタムモデルのインポートの場合、アクティブなカスタムモデルのコピー数に基づいて、モデル推論についてのみ、5 分単位で課金され。詳細については、 Amazon Bedrock の料金 、 Amazon SageMaker AI の料金 、および Amazon EC2 の料金 のページをご覧ください。 データセキュリティ – Amazon Bedrock と Amazon SageMaker のエンタープライズグレードのセキュリティ機能は、データとアプリケーションを安全かつプライベートにするのに役立ちます。これは、データがモデルプロバイダーと共有されず、モデルの改善にも使用されないことを意味します。これは、Amazon Bedrock と Amazon SageMaker の DeepSeek-R1 モデルなど、すべてのモデル (独自モデルおよび公開モデル) に適用されます。詳細については、「 Amazon Bedrock のセキュリティとプライバシー 」と「 Security in Amazon SageMaker AI 」にアクセスしてください。 今すぐご利用いただけます DeepSeek-R1 は現在、Amazon Bedrock Marketplace および Amazon SageMaker JumpStart で一般提供されています。Amazon Bedrock カスタムモデルインポートと、AWS Trainum および Inferentia チップを搭載した Amazon EC2 インスタンスを使用して、DeepSeek-R1-Distill モデルを使用することもできます。 Amazon Bedrock コンソール 、 Amazon SageMaker AI コンソール 、 Amazon EC2 コンソール で DeepSeek-R1 モデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock および AWS re:Post for SageMaker AI に、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは 2025 年 1 月 22 日に公開された Blog “ Announcing upcoming changes to the AWS Security Token Service global endpoint ” を翻訳したものです。 AWS は、2011 年 8 月に、AWS 米国東部 (バージニア北部) リージョンでホストされている単一のグローバルエンドポイント (https://sts.amazonaws.com) で AWS Security Token Service (AWS STS) をリリースしました。単一のリージョンへの依存を減らすために、AWS は 2015 年 2 月に AWS STS リージョンエンドポイント ( https://sts. {Region_identifier} . {partition_domain} ) をリリースしました。これらのリージョンエンドポイントを使用すると、ワークロードと同じリージョンで STS を使用できるため、パフォーマンスと信頼性が向上します。 しかし、多くのお客様やサードパーティのツールは引き続き STS グローバルエンドポイントを呼び出しており、その結果、これらのお客様は STS リージョンエンドポイントのメリットを受けられていません。今回、アプリケーションの耐障害性とパフォーマンスを向上させるために、お客様側での対応を必要とせずに、STS グローバルエンドポイントに変更を加えることにしました。これらの変更は今後数週間でリリースされる予定です。 本ブログでは、STS グローバルエンドポイントの今後の変更とその利点について説明し、今後使用する STS エンドポイントに関する推奨事項を説明します。 STS グローバルエンドポイントの変更点 STS グローバルエンドポイントに加えられる変更は、信頼性を高め、パフォーマンスを向上させるのに役立ちます。2025 年 1 月現在、STS グローバルエンドポイントへのすべてのリクエストは、米国東部 (バージニア北部) リージョンで処理されています。2025 年初頭から、STS グローバルエンドポイントへのリクエストは、AWS にデプロイされたワークロードと同じリージョンで自動的に処理されるようになります。例えば、アプリケーションが米国西部 (オレゴン) リージョンから sts.amazonaws.com を呼び出す場合、その呼び出しは米国東部 (バージニア北部) リージョンではなく、米国西部 (オレゴン) リージョンでローカルに処理されます。 この変更により、リクエストが デフォルトで利用可能なリージョン から送信された場合、STS グローバルエンドポイントへのリクエストはローカルで処理されます。 1 ただし、リクエストがオプトインが必要なリージョンから送信された場合、または AWS 外部 (オンプレミスネットワークやデータセンターなど) から STS を使用する場合、STS グローバルエンドポイントへのリクエストは引き続き米国東部 (バージニア北部) リージョンで処理されます。 この変更は、デフォルトで利用可能な AWS リージョンに 2025 年半ばまでに順次展開されます。まず欧州 (ストックホルム)から開始予定です。 既存のプロセスの中断を防ぐために、以下の対策を講じています AWS CloudTrail では、STS グローバルエンドポイントに対するリクエストのログは、リクエストがローカルで処理された場合でも、米国東部 (バージニア北部) リージョンに送信されます。STS リージョンエンドポイントに対するリクエストの処理は、引き続き CloudTrail のそれぞれのリージョンに記録され続けます。 STS グローバルおよびリージョンエンドポイントによって実行された操作の CloudTrail ログには、 endpointType と awsServingRegion の追加フィールドが含まれ、リクエストを提供したエンドポイントとリージョンを明確にします。 sts.amazonaws.com エンドポイントに対するリクエストは、どのリージョンがリクエストを処理したかに関係なく、 aws:RequestedRegion 条件キーの値として us-east-1 になります。 sts.amazonaws.com エンドポイントによって処理されたリクエストは、STS リージョンエンドポイントとリクエストクォータを共有しません。 1. さらに、ローカルでリクエストを処理するには、 sts.amazonaws.com への DNS リクエストを、Amazon Virtual Private Cloud (Amazon VPC) の Amazon DNS サーバー (Amazon Route 53 Resolver) で処理する必要があります。 推奨事項 可能な限り、適切な STS リージョンエンドポイント を使用することを引き続き推奨します。オンプレミスのネットワークやデータセンターなど、AWS の外部から STS を使用している場合は、STS 認証情報を使ってアクセスしたい AWS リソースと、同じリージョンの STS リージョンエンドポイントを使用することを推奨します。アジアパシフィック (香港) やアジアパシフィック (ジャカルタ) などのオプトインリージョンで開発している場合、ワークロードをホストしているオプトインリージョンの STS エンドポイントを使用することを推奨します。ブログ記事 リージョナル AWS STS エンドポイントの使用方法 の手順に従うことで、まだグローバル STS エンドポイントを使用しているワークロードを特定し、必要に応じて再構成する方法についての手順や方法を理解することができます。 このブログについて質問がある場合は、 AWS Support に連絡 してください。 Palak Arora Palak は AWS Identity の Senior Product Manager です。彼女は 8 年以上のサイバーセキュリティ経験を持ち、特に Identity and Access Management (IAM) 分野に特化しています。彼女は様々な業界の顧客がエンタープライズおよび顧客の IAM ロードマップと戦略を定義し、全体的な技術リスク環境を改善するのを支援してきました。 Liam Wadman Liam は AWS Identity チームの Principal Solutions Architect です。AWS でエキサイティングなソリューションを構築したり、顧客を支援したりしていないときは、ブリティッシュコロンビアの丘でマウンテンバイクに乗っていることが多いです。Liam は、LIAM を綴るには IAM が欠かせないと指摘します。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は Preventing log loss with non-blocking mode in the AWSLogs container log driver (記事公開日: 2023 年 8 月 3 日) を翻訳したものです。 Introduction 可観測性の向上とトラブルシューティングのために、コンテナログをコンピューティングプラットフォームから、ログ集約サーバーに転送することをお勧めします。実際には、ログサーバーが到達不能になったり、ログを受け入れられなくなる場合があります。ログサーバーの障害に対するアーキテクチャ設計には、トレードオフがあります。サービス所有者は、次の点を検討する必要があります。 アプリケーションは、トラフィックへの応答 (または作業の実行) を停止し、ログ集約サーバーが復旧するのを待つべきでしょうか? (正確な監査ログがサービスの可用性よりも優先されますか?) アプリケーションは、ログサーバーがバッファを使い切る前に復旧することを期待してログをバッファリングしながらトラフィックに対応し続けるべきでしょうか? ログ送信先が利用できないレアケースにおいてログが失われるリスクを受け入れるべきでしょうか? コンテナの ログドライバー では、このトレードオフは上記 1 の考慮事項に対して「ブロッキング」の設定パラメータ、2 の考慮事項に対して「ノンブロッキング」の設定パラメータで実装されています。AWS ブログの「 Choosing container logging options to avoid backpressure 」では、Rob Charlton がこのトレードオフを探求し、 AWSLogs コンテナログドライバーのデフォルトの「ブロッキング」モードでアプリケーションがどのように動作するかをテストする方法を説明しています。 この記事では、「ノンブロッキング」 について詳しく説明し、AWSLogs ログドライバーを使用したログ損失の試験結果を示します。 ソリューションの概要 AWSLogs ドライバーのモード Amazon Elastic Container Service ( Amazon ECS ) では、 AWSLogs ログドライバー がコンテナの stdout と stderr からログをキャプチャし、 Amazon CloudWatch Logs に PutLogEvents API 経由でアップロードします。このログドライバーは、 モード設定 をサポートしており、次のように構成できます。 ブロッキング ( デフォルト) : ログを Amazon CloudWatch に即座に送信できない場合、コンテナコードから stdout または stderr への書き込み呼び出しがブロックされ、コードの実行が停止します。アプリケーションのロギングスレッドがブロックされるため、アプリケーションが機能しなくなり、ヘルスチェックの失敗やタスクの終了につながる可能性があります。必要なロググループまたはログストリームを作成できない場合、コンテナの起動に失敗します。 ノンブロッキング: ログを Amazon CloudWatch に即座に送信できない場合、max-buffer-size 設定で構成されたインメモリバッファに格納されます。バッファを使い切ると、ログが失われます。コンテナコードから stdout または stderr への書き込み呼び出しはブロックされず、即座に実行されます。Amazon ECS on Amazon Elastic Compute Cloud ( Amazon EC2 ) では、必要なロググループまたはログストリームを作成できない場合でも、コンテナの起動は失敗しません。AWS Fargate 上の Amazon ECS では、構成されたモードに関係なく、ロググループまたはログストリームを作成できない場合、コンテナの起動は必ず失敗します。 デフォルトのブロッキングモードから、ノンブロッキングモードへの変更を検討するべきか？ デフォルトのブロッキングモードではアプリケーションの可用性リスクがあるため、サービス所有者はノンブロッキングモードに切り替えることを検討する必要があります。その場合、次のような疑問が生じます。 max-buffer-size はどのように選択すべきでしょうか? デフォルトの 1 MB サイズでログの損失を防げますか? ノンブロッキングモードを使うと、高レートでログを出力するアプリケーションにてログの損失が発生しますか? これらの質問に答えるため、AWS チームはノンブロッキングモードで AWSLogs ドライバー上でスケールしたログの取り込みテストを実行しました。 推奨される max-buffer-size の値はどれですか？ ノンブロッキングモードを選択する場合、このテストから推奨される Amazon ECS タスク定義の設定は以下のとおりです。 "logConfiguration": { "logDriver": "awslogs", "options": { "mode": "non-blocking", "max-buffer-size": "25m", } } バッファのサイズを決定する変数は何ですか？ 最大バッファサイズに影響を与える主な変数は、アプリケーションがデータを出力する頻度とログのスループットです。 CloudWatch Metrics の IncomingBytes メトリクスを使用して、ロググループへの取り込みレートを追跡 します。すべてのコンテナがほぼ同じレートで送信すると想定すると、ロググループの取り込みレートをコンテナの数で割ることで、 個々のコンテナのレート が分かります。 各コンテナからのログのスループットを多めに見積もることをお勧めします。ログ出力は、特にインシデント発生時に一時的に急増する可能性があります。可能であれば、負荷テストや最近のインシデント時のスループットを計算してください。スループットのバーストに対応するため、1 分以下の時間間隔でのピークログ出力レートを使用してください。 テストでわかったことは何ですか？ この記事で説明した結果はパフォーマンスを保証するものではないことにご注意ください。AWS チームが実施したテストの結果を単に共有しているだけです。 ログ集約サーバーが利用可能で正常な場合の主な所見は次のとおりです。 max-buffer-size が 4 MB 以上の場合、コンテナからの出力ログレートが 2 MB/s 以下であれば、ログの損失は発生しません。 max-buffer-size が 25 MB 以上の場合、コンテナからの出力ログレートが 5 MB/s 以下であれば、ログの損失は発生しません。 6 MB/s を超えると、AWSLogs ドライバーのパフォーマンスは予測可能性と一貫性が低くなります。たとえば、100 MB のバッファと 7 MB/s のテストで異常値による失敗が発生しました。6 MB/s 以上 (持続的またはバースト) でログを出力する場合、時折ログ損失を防ぐことができない可能性があります。 Amazon EC2 起動タイプと AWS Fargate 起動タイプの Amazon ECS で、結果は同様です。 このドキュメントでは、テスト結果の簡単な要約を示します。起動タイプとログサイズ別に分けられた完全なベンチマーク結果、分析、データは、 GitHub で確認できます。 テストはどのように実行されましたか？ ベンチマークに使用したコードは GitHub で確認できます。Amazon EC2 のテストは Docker バージョン v20.10.25 で実行しました。AWS Fargate のテストは プラットフォームバージョン 1.4 で実行しました。 各ログ損失テストは、AWSLogs ドライバーを使用して 1 GB のログデータを Amazon CloudWatch Logs に送信する Amazon ECS タスクで実行しました。そのタスクは次に Amazon CloudWatch Logs をクエリして、すべてのログイベントを取得し、受信したログイベントの数をチェックします。各ログメッセージには、予測可能なシーケンス番号である一意の ID が付いています。1 KB と 250 KB のサイズの単一ログメッセージでテストが実行されました。 数千回のテストを実行し、有意な統計分析を行うための十分なデータを取得しました。 バッファを使い切り、ログが失われているかどうかを知ることができますか？ 残念ながら、AWSLogs ログドライバーでは、ノンブロッキングモードのバッファによって失われたログを確認することはできません。Docker デーモンは、ログの損失が発生した際にログステートメントやメトリクスを出力しません。ログ損失メトリクスの提案については、 GitHub にコメントしてください。 バッファサイズはアプリケーションで使用可能なメモリにどのように影響しますか? max-buffer-size 設定は、 Go スライス内のメッセージのバイトサイズ を制御します。ただし、 Go はガベージコレクションされる言語なので、直接メモリ使用量を制約するわけではありません。ある 1 つのテストスイートでは、キューの実際のサイズは平均すると非常に小さく、一般的に 500 KB 未満であることが分かりました。バッファサイズは、レイテンシの期間や、ログのスループットの増加時に一時的に制限値まで上がります。つまり、バッファによって使用されるメモリは瞬間ごとに大きく変動し、Go のガベージコレクションのため、実際のメモリ使用量が設定サイズを超える可能性があります。 コンピューティングプラットフォームはバッファサイズに影響しますか？ テストでは、Amazon EC2 と AWS Fargate の両方で起動した Amazon ECS タスクの結果が同様であることがわかりました。 リージョン間でログを送信する場合、ノンブロッキングモードは安全ですか? AWSLogs ドライバーは、テストタスクと同じリージョンの Amazon CloudWatch API にログを送信する場合、CloudWatch への接続の待ち時間が短いため、はるかに高い速度で一貫してアップロードできます。リージョン間でのログアップロードは信頼性が低くなります。さらに、リージョンの分離というベストプラクティスに反します。リージョン間のログプッシュはネットワークコストも高くなります。 テスト結果 この記事で説明した結果はパフォーマンスを保証するものではありません。私たちは単に実行したテストの結果を共有しているだけです。コンピューティングプラットフォーム (AWS Fargate と Amazon EC2) やログメッセージサイズなどの次元別の完全なデータテーブルについては、 GitHub をご覧ください。 リージョン内テスト実行の概要 以下は、約 17,000 回のリージョン内テスト実行のヒートマップ概要です。シェーディングされたボックス内のパーセント注釈は、最悪のテスト実行でのログ損失のパーセンテージです。赤の濃い色ほど、ログ損失が大きかったことを示しています。ログ出力レートが 2 MB/s 未満のテスト実行では、ログ損失は発生しませんでした。 リージョン間テスト実行の概要 タスクは us-west-2 で実行され、us-east-1 の Amazon CloudWatch にアップロードされました。 結果は、リージョン間のログアップロードは信頼性が低く、ログの損失を防ぐためにはるかに大きなバッファサイズが必要であることを示しています。 まとめ この記事では、以下のことを学びました: コンテナログドライバーのブロッキングとノンブロッキングにおいて、アプリケーションの可用性とログ損失のトレードオフがあります。 max-buffer-size の異なる値でノンブロッキングモードの AWSLogs ドライバーの動作を確認します。 クロスリージョンのログアップロードは推奨されず、ノンブロッキングではログ損失のリスクが高くなります。 コンテナごとのログ出力レートを確認する方法を説明しました。 AWSLogs ドライバーのノンブロッキングモードではログ損失を監視することはできません。 アプリケーションの可用性とログ損失のトレードオフを検討する際、ユースケースがブロッキングモードまたはノンブロッキングモードのどちらを必要とするかを決定する必要があります。トレードオフとしてアプリケーション側の可用性を選択する場合、ノンブロッキングモードの AWSLogs ドライバーまたは他のログ収集ソリューションのどちらを選択しますか？ Fluent Bit と FireLens などの他のほとんどのログ収集ソリューションは、ログのバッファは有限ですがトレードオフとしてアプリケーション側をブロックしません。ただし、ログの損失を防ぐための チューニング や 監視 が容易なソリューションもあります。ノンブロッキングモードの AWSLogs ドライバーを選択する場合、コンテナごとのログ出力レートに応じて、max-buffer-size の値をリスク許容範囲内に設定する必要があります。 GitHub の完全なテスト結果を慎重に確認することをお勧めします。結果に基づき、max-buffer-size には 25m を推奨し、すべてのログアップロードがリージョン内であることを確認してください。リージョン間のログプッシュは非常に信頼性が低いためです。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

新しい Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスを作成すると、そのデータベースインスタンスに対して 特定の権限 がマスターユーザーに付与されます。アプリケーションでマスターユーザーを直接使用しないことを強くお勧めします。代わりに、最小権限の原則とベストプラクティスに従い、アプリケーションに必要な最小限の権限を持つデータベースユーザーを作成してください。 この手法は、次のようなユースケースに適用できます。 アプリケーション固有の SQL Server ログインを使用する代わりにマスターユーザーを使用する セキュリティと説明責任のために、データベース管理者 (DBA) に名前付きアカウントを使用する Amazon RDS for SQL Server に接続するアプリケーションとサービスに対して、最小権限のセキュリティモデルを実装し、特定の名前付きアカウントを使用する この投稿では、マスターユーザーを新しいログインにクローンし、必要最小限の権限を確認する方法について説明します。アプリケーションに必要のない権限を削除することで、最小権限の セキュリティモデルを実装できます。 ソリューション概要 このソリューションでは、マスターユーザーをクローンするために以下の手順を実行します。 ユーザーを複製したい環境で、 usp_rds_clone_login という名前のストアドプロシージャを作成します。これは、 SQL Server Management Studio (SSMS) を使用して Amazon RDS for SQL Server インスタンスに接続することで実現できます。 ストアドプロシージャを実行すると、実行した時点での権限が記述された T-SQL スクリプトが生成されます。 SSMS の結果ペインからスクリプトをコピーし、新しいクエリウィンドウで実行します。 ストアドプロシージャが実行された後、マスターログインと同様のサーバーレベルおよびデータベースレベルの権限を持つ「create login」スクリプトが生成されます。 前提条件 RDS インスタンスでマスターユーザーをクローンする前に、次の準備が整っている必要があります。 Amazon RDS for SQL Server インスタンス データベースへの接続が可能な SSMS 必要な権限を持つユーザー ストアドプロシージャの作成 ユーザーを複製したい環境で、 usp_rds_clone_login ( ダウンロード ) という名前のストアドプロシージャを作成します。次のステップで、特定のログインアカウント、データベースユーザー、サーバーレベルの権限、およびデータベースレベルの権限のクローンを作成するためにこのストアドプロシージャを使用します。Amazon RDS for SQL Server のシステムデータベース以外の任意のユーザーデータベースにストアドプロシージャを作成できます。 プロセスの一部として、スクリプトは次のアクションを実行します。 指定されたパスワードを使用して新しいログインを作成する 新しいログインにサーバーロールのメンバーシップを割り当てる 新しいログインにサーバーレベルの権限を割り当てる LoginToDuplicate に従って、新しいログイン用のデータベースユーザーを作成する LoginToDuplicate に従って、新しいユーザーにデータベースロールメンバーシップを割り当てる LoginToDuplicate に従って、新しいユーザーにデータベースレベルの権限を割り当てる ストアドプロシージャを実行する際、ストアドプロシージャを実行するユーザーにこれらの権限を付与するアクセス権がない場合、スクリプトは結果を生成しません。ユーザーに権限を付与するアクセス権がない場合、出力スクリプトにはその権限が表示されません。これは、スクリプトにアクセスするために使用されるログインに表示権限がないためです。さらに、権限を付与する権限がないのに手動で権限スクリプトを追加しようとするとスクリプトは失敗します。 ストアドプロシージャの実行 ストアドプロシージャを作成した後、新しい T-SQL ウィンドウを開き、次の形式でストアドプロシージャを実行します。スクリプトを実行する前に、キーボードの CTRL + T を押して、結果がテキスト形式になっていることを確認してください。 -- SQL server authentication login EXEC usp_rds_clone_login @NewLogin = [ < duplicate_login_name > ] , @NewLoginPwd = 'Password_for_new_login_here' , @LoginToDuplicate = master_login , @WindowsAuth = 0 ; -- Windows authentication login EXEC usp_rds_clone_login @NewLogin = [ < domain\duplicate_login_name > ] , @NewLoginPwd = NULL , @LoginToDuplicate = master_login , @WindowsAuth = 1 ; SQL 次は、管理者アカウントを新しいドメインユーザーアカウントにクローニングした際の出力例です。 EXEC dbo . usp_rds_clone_login @NewLogin = 'MyDomain\MyDomainUser' , @NewLoginPwd = NULL , @WindowsAuth = 1 , @LoginToDuplicate = 'admin' ; SQL 出力： /*Cloning Process Steps*/ /*==================================================*/ /*1 - Create new login*/ /*2 - Server role membership for new login*/ /*3 - Server level permissions for the new login*/ /*4 - Create database user for new login*/ /*5 - Database role membership for db user*/ /*6 - Database level permissions*/ /*==================================================*/ /*1 - Create new login*/ CREATE LOGIN [ MyDomain\MyDomainUser ] FROM WINDOWS ; /*2 - Server role memberships for new login*/ EXEC sp_addsrvrolemember @loginame = 'MyDomain\MyDomainUser' , @rolename = 'setupadmin' ; EXEC sp_addsrvrolemember @loginame = 'MyDomain\MyDomainUser' , @rolename = 'processadmin' ; /*3 - Server level permissions for the new login*/ USE master ; GRANT ALTER ANY EVENT SESSION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ADMINISTER BULK OPERATIONS TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY SERVER AUDIT TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY CONNECTION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY LOGIN TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY LINKED SERVER TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER ANY SERVER ROLE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER SERVER STATE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT ALTER TRACE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT CREATE ANY DATABASE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW ANY DEFINITION TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW ANY DATABASE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE master ; GRANT VIEW SERVER STATE TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; GRANT ALTER ANY CREDENTIAL TO [ MyDomain\MyDomainUser ] ; /*4 - Create database user for new login*/ USE [ DBATools ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ master ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ msdb ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ rdsadmin ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; USE [ tempdb ] ; IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'admin' ) BEGIN IF EXISTS ( SELECT name FROM sys . database_principals WHERE name = 'MyDomain\MyDomainUser' ) EXEC sys . sp_change_users_login 'Update_One' , 'MyDomain\MyDomainUser' , 'MyDomain\MyDomainUser' ELSE CREATE USER [ MyDomain\MyDomainUser ] FROM LOGIN [ MyDomain\MyDomainUser ] ; END ; /*5 - Database role membership for db user*/ USE [ DBATools ] ; EXEC sp_addrolemember @rolename = 'db_owner' , @membername = 'MyDomain\MyDomainUser' ; USE [ msdb ] ; EXEC sp_addrolemember @rolename = 'SQLAgentUserRole' , @membername = 'MyDomain\MyDomainUser' ; /*6 - Database level permissions*/ USE [ DBATools ] ; DENY BACKUP DATABASE ON DATABASE :: [ DBATools ] TO [ MyDomain\MyDomainUser ] ; USE [ DBATools ] ; DENY BACKUP LOG ON DATABASE :: [ DBATools ] TO [ MyDomain\MyDomainUser ] ; USE [ msdb ] ; GRANT ALTER ANY USER ON DATABASE :: [ msdb ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_task_status ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_tlog_copy_setup ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_tlog_backup_copy_to_S3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_output ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_task_status ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_shrink_tempdbfile ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cdc_disable_db ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cdc_enable_db ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_tuninglog ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_get_audit_file ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_download_from_s3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_delete_from_filesystem ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_gather_file_details ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_file_details ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_partitionfunction ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sqlagent_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_msbi_task ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_upload_to_s3 ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_profile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_partitionscheme ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_msdtc_transaction_tracing ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_ssrs_databases ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_ssis_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_table ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_failover_time ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_changedbowner_to_rdsa ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_account_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_tableview ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_purge_jobhistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_query ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_download ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_list_current_lsn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_profileaccount_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_dms_tlog_read ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querytable ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_configure_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_add_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querydatabase ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_update_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_principalprofile_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_index ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_status_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_help_queue_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_queryindex ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_column ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_indexcolumn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_send_dbmail ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_reports_querycolumn ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_delete_database_backuphistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobhistory ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobs ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysjobactivity ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_add_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_delete_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_update_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_grant_login_to_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_revoke_login_from_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_enum_proxy_for_subsystem ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sysmail_control ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sp_enum_login_for_proxy ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_allitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_event_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_sysmail_mailattachments ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_sysmail_delete_mailitems_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_allitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_server_object_last_sync_time ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_sentitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_get_system_database_sync_objects ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_unsentitems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_set_system_database_sync_objects ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_faileditems ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_input ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_mailitems_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_backup_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_backup_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_mailattachments ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_cancel_task ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_drop_tde_certificate ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ sysmail_event_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_finish_restore ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ sysmail_delete_log_sp ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_tlog_backup_metadata ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ rds_fn_list_user_tde_certificates ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT SELECT ON OBJECT:: [ dbo ] . [ DTA_progress ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_database ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT EXECUTE ON OBJECT:: [ dbo ] . [ rds_restore_log ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT ALTER ON ROLE:: [ SQLAgentUserRole ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ msdb ] ; GRANT ALTER ON ROLE:: [ SQLAgentOperatorRole ] TO [ MyDomain\MyDomainUser ] WITH GRANT OPTION ; USE [ tempdb ] ; GRANT CONTROL ON DATABASE :: [ tempdb ] TO [ MyDomain\MyDomainUser ] ; SQL 出力されたスクリプトをコピーして実行 スクリプトが出力を生成した後、SSMS の結果タブから出力されたスクリプトをコピーし、新しいクエリウィンドウから実行します。スクリプトが実行された後、マスターログインと同様のサーバーレベルとデータベースレベルの権限を持つ新しいログインアカウントが作成されます。 この例では、SSISDB データベースの ssis_admin と ssis_logreader の権限は除外されています。これらの権限が必要な場合は、別途指定してください。 ALTER ROLE [ ssis_admin ] ADD MEMBER [ mydomain\user_name ] ; ALTER ROLE [ ssis_logreader ] ADD MEMBER [ mydomain\user_name ] ; SQL クリーンアップ ログインを複製した後、(例えば、コンプライアンスの理由で) ストアドプロシージャを保持したくない場合は、次のスクリプトを使用してドロップできます。 USE [ DB_NAME ] GO DROP PROCEDURE [ dbo ] . [ usp_rds_clone_login ] ; GO SQL 結論 この投稿では、Amazon RDS for SQL Server でマスターユーザーを新しいログインにクローンする方法について説明しました。また、アプリケーションでマスターユーザーを使用しないための主な考慮事項とベストプラクティスについても説明しました。このソリューションは、ビジネスニーズに必要な最小限の権限を持つ新しいログインを作成するのに役立ちます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Alvaro Costa-Neto は AWS のデータベーススペシャリストソリューションアーキテクトで、クラウド上でのデータベースソリューションの設計と実装を支援しています。彼はデータベース技術に興味があり、主に Microsoft SQL Server を使って 19 年以上にわたり活動してきました。彼はフロリダ州クレルモントに妻と 2 人の子供たちと住んでおり、家族と航空と旅行の愛好家です。仕事を離れると、家族や友人とクックアウトを主催したり、新しい場所を探索したりするのが好きです。 Rakesh Ramanukolanu は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。様々な業界のお客様に対し、SQL Server のワークロードを Amazon RDS や Amazon RDS Custom のようなマネージド データベース プラットフォームに設計、移行、最適化するのを支援しています。 Mesgana Gormley は Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。彼女は Amazon RDS チームで働き、お客様に技術的なガイダンスを提供し、リレーショナルデータベースワークロードの移行、設計、展開、最適化を支援しています。

Amazon Relational Database Service (Amazon RDS) for SQL Server が、SQL Server 認証を使用するログインのパスワードポリシーの設定をサポートするようになりました。この機能により、ビジネス要件に合わせてカスタムパスワードポリシーを作成できます。SQL Server のパスワードポリシーは、パスワードの評価とそれらのパスワードを使用するエンティティの維持に関する様々なルールを定義します。これらのポリシーには以下が含まれる可能性があります。 新しいパスワードに対するパスワードの長さと複雑さの要件の強制 パスワードの有効期限と定期的な変更の強制 不正なパスワードが多数回入力された場合のアカウントのロックアウト この投稿では、Amazon RDS for SQL Server のパスワードポリシーを有効にし、そのポリシーに準拠する SQL Server ログインを作成するプロセスについてご案内します。 SQL Server のさまざまな認証の概要 SQL Server ログインは、データベースに対して認証可能なセキュリティプリンシパルを表すサーバーレベルのオブジェクトです。SQL Server インスタンスに接続するには、ユーザーはログインを使用して認証する必要があります。以下の形式でログインを作成します。 SQL Server 認証（ログイン名とパスワード）を使用 Windows 認証（Windows ユーザーまたはドメインアカウント）を使用 証明書から 非対称キーから この投稿では、SQL Server 認証を使用してログインのパスワード ポリシーを構成する方法にフォーカスします。 前提条件 Amazon RDS for SQL Server インスタンス Amazon RDS for SQL Server インスタンスに接続できる SQL Server Management Studio (SSMS) カスタムパラメータグループ パラメータグループの作成または修正 Amazon RDS for SQL Server ではパラメータグループを通じてパスワードポリシーを有効にすることができます。詳細については、「 Amazon RDS のパラメータグループ 」を参照してください。 以下の表は、SQL Server のパスワードポリシーを設定するために構成可能なパラメータを示しています。以下のパラメータはすべて動的であり、RDS データベースインスタンスの再起動を必要とせずに変更を即座に適用できます。 DB パラメーター 説明 許可された値 デフォルト値 rds.password_complexity_enabled SQL Server ログインのパスワードを作成または変更する際は、パスワードの複雑さの要件を満たす必要がある。 0,1 0 rds.password_min_length SQL Server ログインのパスワードに必要な最小文字数。 0-14 0 rds.password_min_age SQL Server ログインパスワードがユーザーによって変更可能になるまで使用しなければならない最小日数。0 に設定すると、パスワードはすぐに変更できる。 0-998 0 rds.password_max_age SQL Server ログインパスワードが使用できる最大日数で、この日数を超えるとユーザーはパスワードの変更を要求されます。0 に設定すると、パスワードは無期限に有効となる。 0-999 42 rds.password_lockout_threshold SQL Server ログインがロックアウトされる原因となる連続したログイン失敗の回数。 0-999 0 rds.password_lockout_duration ロックアウトされた SQL Server ログインが、ロック解除されるまでに待機しなければならない分数。 1-60 10 rds.password_lockout_reset_counter_after ログイン試行が失敗した後、失敗したログイン試行カウンターが 0 にリセットされるまでに経過しなければならない分数。 1-60 10 RDS インスタンスのバージョンとエディションに基づいて、 新しいパラメータグループを作成 するか、既存のパラメータグループを使用することができます。カスタムパラメータグループが必要です。RDS インスタンスがデフォルトのパラメータグループで実行されている場合は、新しいパラメータグループを作成してください。すでに Amazon RDS for SQL Server インスタンスとそれにアタッチされたカスタムパラメータグループがある場合は、そのパラメータグループの名前をメモしてください。その後、以下の手順を実行します。 Amazon RDS コンソールで、RDS for SQL Server インスタンスを見つけます。 設定タブで、DB インスタンスパラメータグループ rds-sql-parametergroup を選択します。 名前にパスワードというテキストを含むパラメータを検索します。 これにより、RDS インスタンスのパスワード設定に関連するすべてのパラメータが読み込まれます。 編集 をクリックしてパラメータ値を変更します。 rds.password_complexity_enabled の値を 0 から 1 に変更します。 保存をクリックします。 注意: Amazon RDS for SQL Server のマルチ AZ 構成では、パスワードポリシーはプライマリインスタンスとスタンバイインスタンスの両方に適用されます。 SQL Server ログインのパスワードの複雑さを構成 rds.password_complexity_enabled パラメータを有効にしたので、RDS インスタンスに接続し、以下の手順を実行して既存のログインの 1 つにパスワード複雑性ポリシーを適用してください。 SSMSを開きます。 ALTER ANY LOGIN 権限を持つログインを使用して、RDS for SQL Server に接続します。 セキュリティ、ログインのフォルダを展開します。 既存のログインの 1 つを選択し、そのプロパティを表示します。 複雑なパスワードを入力して、ログインのパスワードをリセットします。 パスワードポリシーを適用とパスワードの有効期限を適用を選択します。 OK をクリックします。 パスワードロックアウトポリシーの設定 さらに一歩進んで、Amazon RDS for SQL Server インスタンスにロックアウトポリシーを追加しましょう。ロックアウトの動作を制御する 3 つのパラメータがあります（詳細は上記のパラメータ表を参照してください）。 rds.password_lockout_threshold （デフォルト値 = 0） rds.password_lockout_duration （デフォルト値 = 10） rds.password_lockout_reset_counter_after （デフォルト値 = 10） SQL Server ログインのロックアウトポリシーを有効にするには、RDS パラメータグループに戻り、 rds.password_lockout_threshold パラメータを 0 から 3 に更新します。この設定により、3 回のパスワード入力失敗後に SQL Server ログインがロックアウトされます。 rds.password_lockout_threshold は動的パラメータであり、 CHECK_POLICY が有効になっているすべてのログインに適用されます。 ロックアウトポリシーを有効にしたことで、「CHECK_POLICY」または「パスワードポリシーを適用する」が有効になっている任意の SQL Server ログインに対して、不正なパスワードを使用して 3 回連続でログインに失敗すると、そのログインはロックアウトされます。 以下の図に示すように、SQL Server Management Studio から SQL Server のログイン状態を確認できます。 あるいは、SQL サーバーのログファイルを参照することもできます。 EXEC rdsadmin.dbo.rds_read_error_log Amazon RDS for SQL Server のエラーログによると、3 回のパスワード入力ミスの後、ログインユーザー user1 がロックアウトされ、正しいパスワードを入力しても接続できなくなっています。設定例のパラメータによると、ロックアウト期間は 10 分後に解除されます。データベース管理者は、ロックアウトされたログインを任意のタイミングで手動でロック解除することができます。 注意：プロアクティブな監視のために、失敗したログインを追跡するために SQL Server 監査用の データベースアクティビティストリーム を構成してください。 クリーンアップ この設定が不要になり、今後の料金を避けたい場合は、Amazon RDS for SQL Server インスタンスを 削除 することができます。 結論 この投稿では、Amazon RDS for SQL Server データベースインスタンスで SQL Server 認証を使用したログインに対するパスワードポリシーの適用方法を紹介しました。この機能により、組織の要件に基づいて SQL Server ログインのパスワードポリシーを設定することができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Vikas Babu Gali は、アマゾンウェブサービスにおいてマイクロソフトのワークロードに特化したシニアスペシャリストソリューションズアーキテクトです。彼は、クリケットをプレイすることや、家族や友人と屋外で時間を過ごすことを楽しんでいます。 Wasim Shaikh は AWS のデータベース専門のシニアパートナーソリューションアーキテクトです。お客様と協力して、様々なデータベースや分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を使用する際のソリューションの価値向上を支援しています。

この記事は 「 Upbound Group builds its modernized point-of-sale platform on AWS 」（記事公開日： 2024 年 11 月 18 日）の翻訳記事です。 Upbound Group Inc. (NASDAQ: UPBD) は、テキサス州 Plano に本社を置くオムニチャネルプラットフォーム企業です。 時代とともに進化する消費者のニーズや期待に応える、革新的で包括的、かつテクノロジー主導の金融ソリューションを提供することに力を入れています。 Upbound Group の顧客向け事業部門には、 Rent-A-Center® や Acima® などの業界をリードするブランドが含まれ、店舗をベースとしたさまざまな小売チャネルおよびデジタル小売チャネルでもブランド企業と消費者とが容易に取引できるようにしています。 Upbound Group は、米国、メキシコ、プエルトリコに 2,400 超の自社店舗を構えています。 変化するニーズへの適応 目まぐるしく変化する小売業界では、効率化と顧客満足度の向上にテクノロジーが不可欠です。 Upbound Group は、従来の Swing ベースの SIMS POS システムがイノベーションを妨げていることに気がつきました。 Upbound Group は、以下の主な阻害要因を考慮した結果、オールインクラウドの実装を進めることに決定しました。 時代遅れのテクノロジー 制約のある、時代遅れのテクノロジーを使用した Swing ベースのシステム スケーリングや最新の SaaS ソリューションとの統合が困難 回避策が必要で、開発とテストのサイクルが遅延 技術的な負債が発生し、仕事の進捗において社員のストレスが増加 一貫性のない顧客情報 顧客プロファイルや、実店舗と E コマース事業とのやりとりを統一的に把握する視点が欠如 多くの場合、満足していただける顧客体験を提供できず、また詐欺のリスクが増大 運用上の混乱 レガシーな POS システムのため、運用状況のエンドツーエンドでの可視化が不可能 問題の診断と解決が長期化 以下の図は、Upbound Group が使用したデジタルトランスフォーメーションフレームワークの概要を示しています。 この技術スタックは、API、イベント駆動を中心とする、最新のマイクロサービスアーキテクチャで構成されています。 Upbound Group の顧客需要の高まりに対応できるスケーラビリティと弾力性を備えています。 イベント駆動型のサーバーレスアーキテクチャの採用 モダナイゼーション以前は、Upbound Group はオンプレミスのレガシーインフラストラクチャ上にモノリシックなアーキテクチャを構築していました。 そのため、変化する顧客需要に応じたスケーリングができませんでした。 また、開発者は必要に応じて迅速に機能を構築することもできませんでした。 Upbound Group は、 Amazon API Gateway 、 AWS Lambda 、および AWS Fargate を使用して API ファーストの設計を実装することで、マイクロサービスアーキテクチャに移行しました。 さらに自社レンタルサービスとエンタープライズサービスのアプリケーションスタックを完全にモダナイズし、 開発チームはショッピング体験を向上させる新しい機能を迅速にリリースできるようになりました。 また、ビジネスチームは戦略的および戦術的なビジネス目標を達成するために、ソリューションを自由に組み合わせることが可能になりました。 Upbound Group には、1,080 を超えるトランザクションテーブル、レガシーリース契約、アーカイブデータのほか、2,600 を超えるテーブルを含む 45 TB の履歴データがありました。また商用ソフトウェアの使用やデータベースサーバーの自己管理をやめ、データサイロ化を排除し、データ価値を最大化し、アプリケーションや組織間でデータを共有したいとも考えていました。 そこで Upbound Groupは、 AWS Data Migration Service (DMS) 、 AWS Schema Conversion Tool (AWS SCT) 、カスタムデータベース開発を利用して、従来のトランザクションデータベース (Oracle Exadata 上で実行) から自社専用の Amazon Aurora PostgreSQL に移行したのです。 その後、Upbound Group は正規化と効率的なインデックス作成を優先して、トランザクションデータモデルの最適化、再設計、統合を行いました。 これによりアプリケーションのパフォーマンスが向上し、テーブル数が 400 に、データサイズが 30 TB 未満に減少しました。 また、Upbound Group は Aurora インスタンスを AWS Graviton3 ベースの R7g データベースインスタンスにアップグレードし、システム全体のパフォーマンスを向上させました。 現在では、データは予測可能な程度に安定して着実に、しかもコストを抑えて増加しています。 柔軟でスケーラブルなインテグレーションの選択 Upbound Group は、コアビジネスとエンタープライズマイクロサービスを主要なトランザクションデータベースである RACDB と統合するために、フルマネージド型の高可用性データベースである Amazon RDS Proxy を採用しました。 RDS Proxy のコネクションプールにより、Lambda のマイクロサービスと Aurora データベースが疎結合となることで、Lambda と Aurora はそれぞれの負荷や要件に応じて、個別にスケールできるようになります。これにより、RDS への過剰な接続によるリソースの不足およびメモリの競合が排除できます。というのも、 Amazon Simple Notification Service (SNS) のトピックは、イベント駆動に伴う非同期処理のニーズに対応して複数の Amazon Simple Queue Service (SQS) キューにメッセージを 分散する ことができるからです。 オムニチャネルのカスタマーエクスペリエンスを向上させるため、Upbound Group は Amazon DynamoDB を使用するグローバルカスタマーデータベース (GCDB) と Amazon OpenSearch Service を使用する検索機能を追加しました。これにより、モダナイズされた POS システムである RACPad など、顧客と接点を持つアプリケーションも GCDB と連携します。RACPad で処理される新規顧客の取引データも GCDB に反映されます。こうして Upbound Group は顧客データを一元的に把握できるため、パーソナライズされたマーケティングキャンペーン、統合型カスタマーサポート、クロスセル、アップセルといった顧客にあわせたきめ細かなアプローチが可能になります。 エンドツーエンドのセキュリティ、可用性、回復力の強化 可用性を向上させ、ダウンタイムを短縮するために、Upbound Group は技術スタックを 複数の AWS リージョンに パイロットライト戦略 でデプロイしました。 データレイヤーとして、Upbound Group はリードレプリカを備えた Amazon Aurora マルチ AZ クラスターを採用しました。 ストレージレイヤーでは、Upbound Group は AWS S3 クロスリージョンレプリケーションを使用して、ビジネスデータとアプリケーションデータをプライマリリージョンからセカンダリリージョンに複製します。 DynamoDB グローバルテーブルは複数リージョンのテーブルレプリケーションの管理に使用され、DynamoDB ストリームの変更データキャプチャによりプライマリ GCDB とセカンダリ GCDB の同期が保たれます。 CI/CD パイプラインは、アプリケーションパッケージをセカンダリリージョンにデプロイし、セカンダリデータベースクラスターと統合するように設定されています。 また、プラットフォームエンジニアリングチームは AWS CloudFormation スタックを使って、IaC でデプロイを行っています。 Upbound Group は、以下のような他の AWS サービスも使用しています。 AWS Control Tower は AWS ランディングゾーンを作成、管理、スケーリングします。 AWS Direct Connect は、プライベートインフラストラクチャと AWS 間の専用のハイブリッドネットワーク接続ができるようにします。 アプリケーション開発者は Amazon CloudWatch と AWS X-Ray を使用してカスタムメトリックス、カスタムログ、トレースを有効にし、アプリケーションのパフォーマンスをトラブルシューティングおよびモニタリングします。 データベース管理者は Performance Insights を使用して高度なパフォーマンスモニタリングと Aurora PostgreSQL クラスターの調整を行います。 ビジネス成果 AWS CloudFormation を使用することでインフラの設定やプロビジョニングをテンプレート化できるため、Upbound Group は、この CloudFormation のテンプレートを作成し、それに基づいてインフラのスタックをプロビジョニングしており、また作成したスタックを継続的に管理、更新しています。 AWS Config は、セキュリティとガバナンスを強化するために、AWS リソースのインベントリ、設定履歴、変更通知を管理します。 また、プラットフォームエンジニアリング、アプリケーション開発、エンタープライズサービスエンジニアリングの各チームは、複数の「 Two-Pizza Teams 」を結成することで効果的に連携ができます。 この変革により、Upbound Group は顧客に一貫したオムニチャネル体験を提供できるようになりました。 Amazon OpenSearch を活用したグローバル顧客データベースの統合顧客プロファイルにより、ビジネスチームは顧客獲得と維持を目的とした、ターゲットを絞ったパーソナライズされたキャンペーンを作成できます。 Upbound Group は膨大な履歴データの移行に成功し、2,400 を超える店舗とパートナー拠点で RACPad を活用してスケーラビリティ、信頼性、運用の俊敏性を高めました。 このクラウドファーストのアーキテクチャにより、店舗全体でプロセスが合理化され、1 か月あたり数百時間を節約できたため、スタッフは戦略的なタスクや顧客サービスの向上に集中できるようになりました。 次回のブログでは、RACPad の技術コンポーネントと設計フレームワークについて詳しく説明します。 「サーバーレスファーストのアプローチで AWS のサービススイートに RACPad を構築すると、革新的な体験ができます。 このシフトにより、インフラストラクチャのプロビジョニングという制約を受けずに新機能を迅速にデプロイできるため、開発サイクルを短縮できます。 サーバーレスアーキテクチャの主な利点の 1 つは、オフピーク時にコストをゼロにスケールダウンできることです。 これは従量課金制の価格モデルによって実現されています」 — Pranav Sharma、Director of Platform Delivery 「従来のオンプレミスアーキテクチャからサーバーレスアーキテクチャに移行する際には、移行に関する自社の技術的能力を考慮する必要があります… サーバーレスコミュニティと AWS エンタープライズサポートに頼ることができたおかげで、安心して移行できました」 — Mike Porras、Director of Platform Engineering 「 Transforming Retail in the cloud: A CIO’s Handbook 」をダウンロードして、AWS がビジネスの成長にどのように役立つかをご覧ください。 AWS は MACH Alliance のメンバーでもあります。 イノベーションを促進し、企業、小売業者、CPG 企業が最高の顧客体験を提供できるよう支援します。 AWS Retail Solutions の詳細については、こちら をご覧ください。 著者について Mike Porras Mike Porras は Upbound Group のプラットフォームエンジニアリング担当ディレクターです。 彼は、多様な開発チームと運用チームのニーズをサポートする統合クラウドテクノロジープラットフォームの設計と保守に注力しています。 Brad King Brad King は AWS の Enterprise Account Executive です。 Brad は、複雑な技術概念を説明し、長期的なパートナーシップを通じてクライアントがデジタルトランスフォーメーションの目標を効率的かつ効果的に達成できるようにすることを専門としています。 AK Soni AK Soni は AWS エンタープライズサポートのシニアテクニカルアカウントマネージャーです。 彼は積極的なガイダンスを提供することで、企業顧客がビジネス目標を達成できるよう支援しています。 エンタープライズアプリケーションのアーキテクチャと開発に 19 年以上携わってきた経験から、生成 AI テクノロジーを使用して事業運営を強化し、既存のテクノロジーの限界を克服することに熱心に取り組んでいます。 Pranav Sharma Pranav SharmaはUpbound Group のプラットフォームデリバリー担当ディレクターであり、革新的なテクノロジーソリューションを通じてデジタル変革を推進することに情熱を注いでいます。 彼は最近、AI の使用における倫理と、社会に有益な方法で開発を導く原則の実際についてより深く考え始めました。 プライベートでは料理に腕をふるい、旅行することが大好きです。 Suprakash Dutta Suprakash は AWS のシニアソリューションアーキテクトです。 デジタルトランスフォーメーション戦略、アプリケーションのモダナイゼーションと移行、データ分析、機械学習を専門としています。 AWS の AI/ML コミュニティの一員であり、生成 AI とインテリジェントなドキュメント処理ソリューションを設計しています。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

アマゾン ウェブ サービス ジャパン合同会社は、2025年1月14日に「 基盤モデル開発者向け Deep Dive セッション: 最新の生成 AI 技術 ～ AWS Trainium2 & Amazon Bedrock Marketplace ～ 」を開催しました。 本イベントでは、最新の AWS Trainium2 チップ を搭載した Amazon EC2 Trn2 インスタンスおよび Trn2 UltraServers 、 100以上の基盤モデルへのアクセスが可能な Amazon Bedrock Marketplace について、生成 AI 基盤モデル開発者向けに深掘りするセッションが行われました。本記事では、その模様をお届けします。 オープニング はじめに、アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 サービス & テクノロジー統括本部 統括本部長 安田 俊彦より開会のあいさつをしました。これまで AWS は一貫して、エンジニアがものづくりをしやすい環境を構築してきました。各種のサービスを提供するだけではなく、技術ノウハウをエンジニア同士で共有する場を設けています。 特に近年では日本において、2023年に「 AWS LLM 開発支援プログラム 」、2024年に「 AWS ジャパン 生成 AI 実用化推進プログラム 」を開始するなど、生成 AI や大規模言語モデル (以下、LLM) の開発支援に注力しています。また、経済産業省の「 GENIAC (Generative AI Accelerator Challenge) 」においても 計算リソース提供者として選定 されました。 グローバルでも、「 AWS re:Invent 2024 」では生成 AI 関連で 500 以上のセッションが行われ、最新の AWS Trainium2 チップを搭載する Amazon EC2 Trn2 インスタンスの一般提供開始となり Trn2 UltraServers のプレビューが発表されました。さらに、Amazon Bedrock 上で100以上の基盤モデルを利用できる Amazon Bedrock Marketplace も発表されました。 これらの新サービスについて、今回のイベントにて詳細を解説する旨を述べたうえで「AWS はこれからも、新しいテクノロジーを世界中に届けます」と結びました。 Amazon EC2 Accelerated Compute Update + AWS Trainium2 Deep Dive ここからは、AWS Sr. Product Manager で AWS Trainium, Inferentiaを担当している Joe Senerchia (写真左) と 同じく GPU インスタンスを担当している Dvij Bajpai (写真右) が登壇しました。生成 AI の基盤モデルの学習や推論に適したインフラストラクチャーについて述べ、その上で動作する「Accelerated Compute」アーキテクチャ、その中核をなす新しいサービスについて解説を行いました。 冒頭では、基盤モデルの学習を支えるAWSのインフラ技術要素として、二つの重要なポイントが挙げられました。一つ目はネットワークです。複数のインスタンスへ学習をスケールさせるためには、広帯域の Elastic Fabric Adapter (EFA) が必要不可欠であると説明されました。 二つ目はストレージです。大規模なモデルの学習には膨大なデータが必要となります。さらに、チェックポイントやデータセットの保存も考慮しなければなりません。これらの課題に対応するため、AWS ではマネージドサービスである Amazon FSx for Lustre を提供しています。このサービスを利用することで、ストレージがボトルネックとなることなく GPU 利用率を向上させる仕組みが実現されています。また、FSx for Lustre は昨年、前述の EFA にも対応いたしました。 この２つのサービスを組み合わせることで、これまで以上に大規模学習に伴うデータの読み書きが高速化されます。 EC2 Trn2 インスタンス は Trainium2 (96 GiB HBM) を16チップ搭載し、192 vCPU、2 TiB のホストメモリ、3.2 Tbps の EFA v3 ネットワーク帯域幅を備えています。Trn2 インスタンスでは、Dense 演算性能で 20.8 PFLOPS (FP8)、Sparse 演算性能で 41 PFLOPS (FP8/FP16/BF16/TF32) の性能を持ち、1.5 TiB の HBM を搭載し 46.4 TB/s のメモリ帯域幅を提供します。 さらに、 Trn2 UltraServers についても解説がありました。Trn2 UltraServers は、1 台のサーバー内に 64 個の AWS Trainium2 チップを搭載し、NeuronLink というチップ間の低遅延・高帯域幅通信により、高密度な計算環境を実現します。この設計は、大規模モデルの分散学習や推論において優れたパフォーマンスを発揮します。 AWS Trainium2 の性能を最大限に引き出すためには、 AWS Neuron SDK の利用が重要です。Neuron SDK は、Trainium チップ専用に設計された開発ツールであり、PyTorch や JAX などの主要な機械学習フレームワークをサポートしています。 また、AWS は Anthropic と共同で次世代の AI プロジェクト「Project Rainier」にも取り組んでいます。このプロジェクトでは、数十万個の AWS Trainium2 チップを用いて ExaFLOPS 規模の学習を実現することを目指しており、EC2 UltraServers の進化がその中核を支えています。 Introducing Amazon Bedrock Marketplace 次に、AWS で Amazon Bedrock の Principal Product Manager を務める John Liu が登場しました。Amazon Bedrock は企業がさまざまな生成 AI モデルやツールにアクセスし、それらを簡単に利用できるようにします。 Amazon Bedrock Marketplace では、特定業界や用途に特化した100以上の多様なモデルへのアクセスが可能です。これらのモデルは、Amazon Bedrock の Converse API や InvokeModel API を通じて簡単に利用できます。モデルの利用に必要なインフラは Amazon SageMaker AI 上で提供されています。ユーザーはインスタンスのタイプや数を柔軟に選択でき、必要に応じてオートスケールのポリシーを設定することも可能です。これにより、ワークフローに最適化されたスケーラブルなモデル運用が実現します。 プロバイダー側にも多くの利点があります。Amazon Bedrock Marketplace を活用することで、プロバイダーはモデルの提供プロセスを効率化し、オンボーディングにかかる時間を短縮できます。また、 AWS Marketplace を通じて価格設定を管理することも可能です。セキュリティとプライバシー保護も重要な特徴です。 Amazon SageMaker AI に基づくコンテナ環境で、モデルの重みといった知的財産 (IP) が外部へ流出しない仕組みが整えられています。 Customer Session ここからは、AWS の生成 AI 関連サービスを活用している企業の方々による Customer Session が行われました。 カラクリ株式会社 カラクリ株式会社 取締役 CPO の中山 智文 氏は、同社が開発した生成 AI モデル「 KARAKURI LM シリーズ 」について紹介しました。このシリーズは、日本のカスタマーサポート関連データを大量に学習したオープンモデルです。 HuggingFace で公開されているほか、AWS Marketplace でも利用可能です。 同社はコスト削減やモデルの計算リソース確保のために AWS Trainium を活用しています。AWS Trainium は GPU の約半額で運用でき、AWS からの手厚いサポートが受けられることが大きな利点です。一方で、対応済みのモデルやアルゴリズム以外は自前で対応する必要があることや、AWS Trainium に関連するコミュニティや知見がまだ不足している点を課題に挙げ、「ユーザーコミュニティの成長による、技術の共有と発展が重要」と期待を表現しました。 株式会社 Preferred Networks 株式会社Preferred Networks Vice President of Consumer Products の福田 昌昭 氏は、同社が開発した大規模言語モデル「 PLaMo 」について説明しました。「PLaMo」は GENIAC 第一期で 100B モデルとしてリリースされ、商用版である「PLaMo Prime」は 2024 年 12 月に提供開始されました。また、小規模言語モデル (SLM) の開発にも注力し、コスト削減やリアルタイム処理への対応を目指しています。 「PLaMo」は Amazon Bedrock Marketplace で提供されており、クローズドなクラウド環境で安全に利用できる仕組みを構築しています。また、コスト削減や計算リソースの安定確保などの課題を解消するために、 EC2 G6e インスタンス (NVIDIA L40S Tensor Core GPU) やカスタムシリコン (AWS Trainium、AWS Inferentia) の活用を進めています。福田 氏は生成 AI が「試す」段階から「使う」段階に進んでいると述べ、AWS を活用して生成 AI の社会実装を推進する意向を示しました。 株式会社 リコー 株式会社リコー デジタル戦略部 デジタル技術開発センター 副所長の鈴木 剛 氏は、同社の AI 事業と生成 AI に関連する取り組みについて説明しました。リコー社は、生成 AI やプライベート LLM を活用した AI ソリューションを提供しており、高性能な日本語 LLM の開発を進めています。特に、ベクトル検索やプライベート LLM の実用化に注力し、オープンソースや独自技術を組み合わせることで柔軟なモデル構築を実現しています。 AI モデルの開発においては、オープンなモデルをベースとしつつ、日本語性能を高めるためトークナイザーの工夫やカリキュラム学習、モデルマージを駆使しています。GPT-4 と同等の日本語性能を達成し、多言語対応も進めています。また、AWS Trainium を利用することで、GPU と比較して大幅なコスト削減と効率向上を実現しました。特に、モデルの学習時にスループットを測定し、最適な運用方法を導き出すことで開発効率を高めています。 ストックマーク株式会社 ストックマーク株式会社 取締役 CTO の有馬 幸介 氏は、同社が提供する AI プロダクトと AWS の活用について説明しました。 同社のプロダクト である「A news」「A strategy」には、独自開発の LLM が導入されています。LLM 開発において AWS Trainium を利用したことで、GPU と比較して約 20% のコスト削減を実現しました。また、推論基盤としても AWS Inferentia2 を活用しています。 さらに、Amazon Bedrock Marketplace にモデルを提供しており、これにより広範囲の顧客にリーチできるほか、モデルファイルを直接共有せずに価値を提供できることが利点です。有馬 氏は、AWS Trainium や Amazon Bedrock の活用は敷居が低く、効率的なプロダクト開発を可能にする手段であると強調しました。同社はこれらの技術を活用し、顧客価値を提供するプロダクトの開発を今後も進めていくと締めくくりました。 懇親会 セッション終了後には懇親会が開催され、登壇者や参加者同士が自由に交流する場が設けられました。ここでは、生成 AI 技術や AWS の最新サービスについての情報共有や意見交換が活発に行われ、参加者にとって有益な時間となりました。 おわりに AWS は引き続き、最先端の技術を提供するだけでなく、開発者や企業がそれを最大限に活用できる環境を構築してまいります。学習や交流のための場も積極的に設けますので、ぜひ次回のイベントにご参加いただければ幸いです。 AWSと生成AIでのビジネス課題を解決されたい方は 生成AI実用化推進プログラム をご活用ください (申し込みは2月14日まで)。2月7日に 第2回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ も開催しますのでご参加ください。 著者について 針原 佳貴 Sr. GenAI Startup Solutions Architect, AWS Japan. 日本の生成 AI スタートアップ担当として、基盤モデル開発や Amazon Bedrock Marketplace へのモデル公開を支援。本イベントでは、John のサポートと Customer Session のファシリテーションで参加。

この記事は 「 Unlock new capabilities from product images using generative AI 」（記事公開日： 2024 年 11 月 12 日）の翻訳記事です。 小売および消費財企業は、顧客体験の向上、業務効率の向上、新しい収益源の創出を目的として、生成 AI を採用していっています。 マルチモーダルおよび画像生成の大規模言語モデル (LLM) の最近の進歩により、ビジュアルデータの利用も拡大しています。 たとえば、 Amazon の生成 AI ツール は、出品者が商品説明や動画広告を作成できるよう支援し、業務を効率化し、販売体験を向上させます。 このブログ記事では、革新的な生成 AI のユースケースを 3 つご紹介します。 それぞれのユースケースでは、生成 AI が商品画像やビジュアルアセットからどのように新しい可能性を引き出すことができるかに注目しています。 また、小売企業や消費財企業にもたらされる主なメリットについても説明し、これらのソリューションを AWS 上で実装するためのアーキテクチャガイダンスを提供します。 画像ベースの生成 AI のユースケース 画像からテキストへ コンピュータービジョン機能を備えた生成 AI モデルは、商品コンテンツを変革し、顧客体験を大幅に向上させることができます。 Amazon Bedrock でホストされている Anthropic の Claude 3 などのマルチモーダル LLM を使用することで、企業はビジュアルアセットから詳細な商品説明をシームレスかつ自動的に作成できます。 マルチモーダル LLM は、商品画像内の重要な要素を認識して識別できます。 関連するメタデータを抽出し、この情報を説得力のある、読みやすいテキストに変換します。 生成されたコンテンツは、検索エンジン最適化 (SEO) を改善して商品を見つけやすくし、実際の商品と商品情報の間のギャップを埋め、より包括的で正確な詳細を作成することで、商品ページの内容を充実させます。 こうした改善は、コンバージョン率の向上と顧客満足度の向上につながります。 消費財ブランドは、商品の寸法、素材、スタイルを自動的に推論することで、カタログ管理を効率化することもできます。 この自動化により、より完全で充実した商品データが作成され、業務効率が向上します。 LLM は画像内の特定のオブジェクト、シーン、属性を識別できるため、コンテンツモデレーションのワークフローが効率化され、その一方で規制を遵守するようにします。 また、目の見えないユーザーや弱視のユーザー向けに、詳細な画像キャプションを自動で作成できるため、アクセシビリティも向上します。 アーキテクチャの例 商品イメージと説明プロンプトを 1 つの入力に組み合わせ、Anthropic Claude 3.5 といった Amazon Bedrock 上でホストされているマルチモーダル言語モデルで処理を行います。例ではチェック柄のシャツの画像に対し、「この商品イメージにあった詳細で、検索エンジンで最も見つけやすくなるような商品説明文を作成して」と指示が付加されています。 Amazon Bedrock はこの商品とその特徴について豊富な情報を含む詳細な説明を出力します。例では「このスタイリッシュなチェック柄のフランネルシャツは様々な用途で使えるトレンディな基本アイテムです。高品質な綿フランネル生地を使用し…」といった説明が出力されています。 画像ベースの検索 画像ベースの検索では、コンピュータービジョンを採用して、より直感的で効果的な検索体験を提供します。 Amazon Bedrock の Amazon Titan Multimodal Embeddings などのマルチモーダル埋め込みモデルや、 Amazon OpenSearch Serverless 用の Vector Engine などのベクターデータベースを使用することで、企業はテキストとビジュアルデータの両方を理解する自然言語のセマンティック検索機能を実装できます。 このアプローチにより、より直感的で魅力的なショッピング体験が可能になります。つまり、顧客に厳格な検索条件を強いるのではなく、自然言語と視覚的な手がかりを通じて顧客の意図を理解しようとします。 小売および消費財アプリケーションでは、画像ベースの検索は、顧客が自然言語クエリを使用して商品を見つけるのに役立ちます。 顧客は参考画像をアップロードすることもできます。 顧客は「花柄の赤いドレス」を検索したり、画像をアップロードしてそれに類似するドレスを検索したりすることができます。 システムは視覚的にも意味的にも類似した商品を検索するため、検索の関連性が向上し、コンバージョン率が高まる可能性があります。 組み込み LLM は商品画像を処理し、テキストとビジュアル入力を関連する商品組み込みにマッピングします。 組み込みモデルは、複雑な検索入力の解釈と照合という面倒な作業を行ってくれるため、広範囲にわたるキーワード管理や SEO の取り組みの必要性が軽減されます。 画像ベースの検索は、商品の見つけやすさと検索結果の関連性を大幅に向上させます。 顧客エンゲージメントが向上し、コンバージョン率の向上と売上の増加につながります。 さらに、顧客の意図を深く理解することで、小売業者は状況に応じたパーソナライズされた商品レコメンデーションを提供できるようになり、ショッピング体験がさらに向上し、ビジネスの成長を促進します。 アーキテクチャ例 商品画像は Amazon Bedrock 上でホストされているマルチモーダル組み込みモデル（例えば、Amazon Titan Multimodal Embeddings など）で処理され、商品のビジュアルな特徴をコード化した数値ベクトルに変換されます。 手順 1 で生成されたベクトル情報は Amazon OpenSearch といったベクトルデータベースに格納されます。 ユーザーが検索したい対象商品の画像をアップロードすると、マルチモーダル埋め込みモデルによって処理され、ベクトル表現に変換されます。 ユーザーが入力したクエリのベクトル表現はベクトルデータベースを検索し、最も類似した画像埋め込みを探し出すと、それに関連した商品を出力します。 画像生成 (テキストから画像、画像から画像) Stability AI の Stable Diffusion Ultra や Amazon Titan Image Generator V2 などの画像生成モデルは、どちらも Amazon Bedrock でホストされており、商品のアイディエーションやパーソナライズされた体験に新たな可能性を切り開いています。 このアプローチにより、アイディエーションが迅速になり、複数あることの多いデザイン案を同時に検討して方向性を決定できます。 一般的なユースケースでは、ビジュアルを利用して商品のアイディエーションを行います。 設計者は、基本的なスケッチやコンセプトから始めて、画像生成モデルを使用して、さまざまな商品のアイデアやバリエーションを開発し、具体化できます。 小売業者はまた、画像生成を利用して、ユーザーが指定したシーンや環境で商品をレンダリングすることで、パーソナライズされた商品体験を作り出せます。 たとえばユーザーが居間の画像をアップロードすると、モデルはそれを参照し、その居間に実際に商品が置かれているかのような画像を生成します。 このように指示に基づいて画像を作成することで、購買決定を支援し、顧客エンゲージメントを高めます。 生成 AI を活用した画像生成は、ビジネスに大きなメリットをもたらします。 商品のアイディエーションと設計を加速させると同時に、購入の決定に役立つ高度にパーソナライズされた顧客体験を可能にします。 ただし、これらの機能を実装する場合、企業は信頼性、透明性、責任ある使用を徹底する必要があります。 AWS は、Amazon Titan Image Generator モデルで生成された画像に目に見えない電子透かしを入れることで、こうした取り組みを支援しています。 これにより、商品表現に対する信頼を維持することができます。 また、基本モデルのコンテンツフィルタリング機能は、誤解を招くような商品画像や有害な商品画像が生成されるのを防ぎ、ブランドイメージを守るのに役立ちます。 商品の完全性を保ち、顧客との関係を強化しながら、生成 AI の革新的な可能性を最大限に引き出すには、ブランドはビジュアルコンテンツ制作における AI の使用に関する明確なポリシーを確立する必要があります。 これには、AI をいつ、どのように利用するかについて、顧客に対して明確に説明できるよう透明性を保つことも含まれます。 これらの倫理ガイドラインに従い、AWS の生成 AI 機能を利用することで、企業はクリエイティブな新しいアプリケーションを模索し、収益の可能性を引き出して事業を進めることができます。 アーキテクチャ例 Amazon Bedrock 上のマルチモーダル LLM （例えば Anthropic Claude 3.5 Sonnet）を使って、アイデアの下書きスケッチを解析し、画像生成モデル向けの詳細なプロンプトを生成します。 生成されたプロンプトとオリジナルのアイデア画像を Amazon Bedrock 上でホストされている、Amazon Titan Image Generator G1 といった画像生成 LLM に入力します。 入力プロンプトとオリジナルの下書きスケッチに基づいた高精細にレンダリングされたアイデアイメージが出力されます。 LLM で小売業者の生産性向上 生成 AI は従業員に取って代わるものではありません。 チームがより多くのことを成し遂げられるように支援するのが役目です。 これらのテクノロジーを導入することで、小売業者はさまざまな業務においてアウトプットの質と量の両方を大幅に向上させることができます。 業界を代表するブランドはすでに AWS の生成 AI ソリューションでビジネスを変革しています。 The Very Group が生成 AI でどのように顧客体験を向上させたかをご覧ください。 Zalando と AWS Gen AI Innovation Center が Amazon Bedrock を使用して非構造化データから商品属性を抽出した方法をご覧ください。 生成 AI で小売業務を変革する準備はできていますか? 次の一歩を踏み出しましょう。 Generative AI for Retail and Customer Goods ページ で、AWS がどのように効率を高め、顧客エンゲージメントを高め、ビジネスのイノベーションを加速できるかをご覧ください。 AWS の小売スペシャリストとの個別相談を設定していただき、御社の課題に関してお聞かせください。 AWS re: Invent の「 RCG206: How Nykaa automates product descriptions using generative 」を視聴して、インドの大手小売業者である Nykaa が生成 AI を使用して商品説明を作成している方法をご覧ください。 こうした機能のライブデモンストレーションをNRF 2025: Retailer’s Big Show (2025 年 1 月 12 日～ 14 日) にて実施いたしました。詳細は こちら 。 著者について Matt Barbieri Matt Barbieri は AWS のシニアソリューションアーキテクトで、ニューヨークオフィスに勤務しています。 AWS の元顧客として 10 年近くの経験を持つ Matt は、クラウドの導入とデジタルトランスフォーメーションを通じて小売および消費財企業のビジネスを導いています。 生成 AI やその他のテクノロジーを使用してビジネス上の課題を解決することを専門としています。 Matt は、複雑な技術概念を実用的な戦略に変換しながら、安全かつ規制に準拠した効率的な AWS ソリューションを設計しています。 彼の仕事は、小売企業や消費財企業が急速に変化する市場でイノベーションを加速し、より効果的に競争できるようにすることです。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

このブログは 2023 年 11 月 7 日に Randy Seamans (Principal Storage Specialist and advocate for AWS) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 電子健康記録 (EHR) アプリケーションの市場規模は、高い年間成長率で 400 億 ドル規模に近づきつつあります。EHR の利用者は、革新的な医療の実現に引き続き注力しながら、運用上の負担、管理オーバーヘッド、資本支出、総所有コストを削減するクラウドベースのアプローチを採用することで恩恵を受けることができます。EHR の導入は本質的に複雑で、相互接続された多数のアプリケーションと周辺環境で構成されており、それぞれに独自のストレージとパフォーマンス要件があります。EHR の中核にある本番環境データベースのパフォーマンスは、オンプレミスでもクラウドでも制約要因になる可能性があります。ほとんどの場合、本番環境データベースのストレージ環境は、現在の要件だけでなく、3 ～ 5 年の成長も考慮して構築されています。 Amazon FSx for NetApp ONTAP (FSx for ONTAP) と Amazon Elastic Block Store (EBS) は、医療機関がクラウド導入の過程で直面するあらゆる EHR のストレージ要件に対応できます。 このブログでは、EHR 環境が、使用したパフォーマンスに対してのみ料金を支払いながら、ストレージパフォーマンスを弾力的かつエレガントに、中断なく最適に拡張する方法を学ぶことができます。これにより、医療機関は予測不可能な成長期でもストレージコストを管理できます。まず、ランサムウェアや災害が発生した場合に EHR 環境のクラウドベースの読み取り専用コピーを拡張できる FSx for ONTAP のアーキテクチャについて説明します。次に、可用性が高く災害復旧が可能なクラウドベースの EHR 本番環境について、オンデマンドで拡張可能な FSx for ONTAP のアーキテクチャーを見ていきます。 規模拡大の機会 患者の負荷が増大し 、 医療機関が業務を統合する につれて、これらのワークロードを処理するためのコンピューティング、ネットワーク、ストレージのパフォーマンスに対する需要も高まります。これに応えて、AWS は最近、高度な新しい AWS インスタンスと EBS io2 Block Express を活用して、 Epic のパフォーマンスの拡張性を向上させる ことを発表しました。これは、医療機関が現在導入している EHR 環境の大部分には十分すぎるほどのものです。ただし、医療機関は、合併、買収、または前例のない成長により、計画外の成長を経験することがよくあります。この課題に対処するために、本ブログでは、ストレージコストを制御しながら EHR ストレージ環境を拡張する最適な方法について説明します。 昨年、ストレージブログで、従来のブロックベースのデータベースワークロードを拡張する 並列ストレージとしての FSx for ONTAP アーキテクチャ を紹介しました。本日はこれと同じアプローチを使用して、EHR 関連のストレージパフォーマンスを前例のないレベルにまで高める方法について説明します。実際に、ブログの公開とより高速で新しい Amazon EC2 インスタンス の導入以降、現在では 1 台のサーバーで最大 200 万 IOPS (8K ランダム、サブミリ秒) を実現しています。 ただし、何度も実行できるような基礎的で継続性のあるストレージベンチマークパフォーマンスと、アプリケーション層のストレージパフォーマンスメトリクスを混同しないように注意する必要があります。多くの高度に統合されたアプリケーションがそうであるように、デプロイした EHR アプリケーションが、全体的なアプリケーションパフォーマンスへの影響を左右しない状態で動いていれば、それはストレージパフォーマンスのほんの一部しか利用していないことになります。実際の経験では、この要素は 40 ～ 60% の範囲になる可能性があります。つまり、8K で 200 万 IOPS 実行可能なストレージ環境では、アプリケーションスタック全体からデータベースの本番環境コピーまで含めると、約 100 万 IOPS がそのアプリケーションに対する事実上の実行可能な範囲になる可能性があります。もちろん、その他に関連ワークフローが存在すれば、AWS ストレージ層によって提供される残りのストレージパフォーマンスの余剰分を有効に活用できます。 このことから、ストレージの拡張性が非常に要求されることがわかります。オンプレミスに設置された固定的なストレージ資産とは異なり、クラウドデプロイメントでは、要求するパフォーマンスレベルに対してのみ支払えば良く、前払い資本コストはありません。運用変更や中断もなく、ストレージパフォーマンスを 10 倍以上にすることができます。この拡張性により、組織は現在および将来の EHR 本番環境のストレージ要件を経済的に満たすことができるという確信が得られます。組織は、時間の経過とともにストレージパフォーマンスをゆっくりと拡張することも、災害時に パイロットライト レベルから完全な本番環境ワークロードに数分以内に拡張することもできます。最後に、ストレージのパフォーマンスをほぼリアルタイムで増減できるため、買収・合併やランサムウェアのような不可抗力の事態にも対応できます。 スケーラブルな EHR のストレージ環境に向けて 従来、ほとんどのアプリケーションでは垂直のストレージサイロが好まれていたため、アレイベースのスナップショットを使用して特定の時点での ストレージ IO の一貫性 を確保していました。複数のストレージアレイ間の一貫性はサポートされていませんでした。ワークロードまたは環境全体が単一のアレイに収まらない場合、アプリケーション層またはミドルウェア層は、スナップショットとバックアップのために複数のアレイにわたって一貫性のあるタイミングを調整する必要がありました。この問題は、より現代的な並列ストレージアプローチを採用する上で、長い間障壁となっていました。ONTAP バージョン 9.1.1 以降、 FSx for ONTAP は、 クラスター間 (2 フェーズ) の整合性グループ をサポートしています。この問題を解決することで、ストレージの一貫性を確保しながら、ONTAP の複数のインスタンスにわたってアプリケーションを拡張できるようになりました。これにより、一貫性、瞬時で容量効率の高いクローン、レプリケーション、およびその他の多くの ONTAP 機能を維持しながら、スケーラビリティを大幅に向上させ、次の図に示すように、250 万を超える 8K ランダム IOPS と 64 GB/秒を達成できます。 図 1: IO の一貫性を確保しながら総合パフォーマンスをスケール EHR の本番環境データベースやその他の周辺環境で 250 万 IOPS が必要ない場合は、16 個の FSx for ONTAP サービスのスループットと IOPS をそれぞれ低いレベルに設定できますので、コストを大幅に削減できます。各 FSx for ONTAP の IOPS は、デフォルトで SSD ストレージ 1 GB あたり 3 IOPS ですが、容量に関係なく最大 160,000 IOPS をプロビジョニングすることもできます。各 FSx for ONTAP の DRAM キャッシュに存在するデータでは、読み取り IOPS のレベルがさらに高くなります。また、IOPS は動的に上下に変更できます。同様に、各 FSx for ONTAP のスループットは 128 MB/秒から 4 GB/秒まで動的に設定できます。プロビジョニングするパフォーマンスの量によってコストを制御できます。特定の総合パフォーマンスと容量レベルでは、複数の FSx for ONTAP を利用しても追加料金は発生せず、コストのペナルティなしで極めて高いスケーラビリティを享受できます。このコストモデルは、並列化によってコスト上の利点が得られないオンプレミス環境とは大きく異なります。 パフォーマンス設定の動的な特性について説明したので、2 種類の EHR デプロイメントの例に戻り、パフォーマンスを拡張しながらコストを最適化する方法を説明します。 クラウドベースの EHR 読み取り専用コピー オンプレミスで EHR を運用している組織が災害、悪意のある人物、またはランサムウェアのために追加の保護を必要とする場合、クラウドベースの EHR 資産の読み取り専用コピーを使用すると、オフサイトバックアップよりも迅速に回復できるだけでなく、他の高度なクラウドサービスを活用することもできます。EHR 環境では、クラウドに読み取り専用コピーを作成する方法が複数あります。次の図は、アプリケーション層やデータベース層のレプリケーションの使用方法を示しています。 図 2: EHR のレプリケーションによる読み取り専用コピー 次の図は、オンプレミスの NetApp ファイラーと、SnapMirror レプリケーションのアシスト役として FSx for ONTAP を組み合わせて活用する方法を示しています。AWS でヘルスケアアプリケーションをデプロイする場合は常に、信頼性の高い設計で AWS のベストプラクティスに準拠し、ヘルスケアワークロードの複数のグローバルコンプライアンスフレームワークと複雑なコンプライアンス要件に準拠している Landing Zone for Healthcare の利用を検討してください。オンプレミスのストレージ環境、リカバリの目標、計画に応じて、最適な読み取り専用アーキテクチャを選択してください。 図 3: NetApp SnapMirror による読み取り専用コピー いずれのシナリオでも、通常の運用中は、FSx for ONTAP を並列に複数用意することで、ランサムウェアイベントやその他の急増するユースケースで必要とされるよりもはるかに低い合計 IOPS とスループットに設定できることに注目してください。これにより、コストを抑えながら、オンデマンドでシームレスにパフォーマンスを向上できます。 クラウドベースの EHR 本番環境 FSx for ONTAP は、AWS で実行される完全な EHR 本番環境の基盤要素としても使用できます。オンプレミスの EHR 環境と比較すると、ハードウェアの更新サイクルが不要になり、総所有コスト (TCO) を削減しながら、中断のない従量課金制のスケーラビリティを実現できます。計画外の成長、合併、買収、または急増する要件に直面している医療機関は、AWS 上の FSx for ONTAP のスケーラビリティを活用してコストを管理しながら、同時に無数の高度なクラウドベースのヘルスケアアプリケーションの相互運用性を実現できます。 あらゆる EHR 本番環境の重要なコンポーネントは、災害復旧が可能な高可用性アーキテクチャです。AWS EHR FSx for ONTAP リファレンスアーキテクチャは、次の図に示すように、複数の アベイラビリティゾーン (AZ) (高可用性用) と複数の AWS リージョン (災害復旧用) を活用してこれを実現します。 図 4: 災害復旧機能を備えた高可用性の EHR 本番環境 本番環境リージョンでは、データベース、レポート、テストと開発、およびその他の統合された周辺アプリケーションが 1 つの AZ で実行されています。AZ 全体が使用できなくなる可能性は低いものの、FSx for ONTAP はマルチ AZ サービスとして構成されており、データの同期された独立したコピーが 2 つあるため (図には示されていませんが、各 AZ に 1 つのコピーがあります)、処理は 2 番目の AZ にフェイルオーバーできます。この構成により、オペレーションが大幅に簡素化されるとともに、災害を宣言することなく完全な単一 AZ 障害への対応を可能にします。 AWS リージョン全体が利用できなくなった場合は、災害が宣言され、セカンダリリージョンで処理が再開されます。上の図は、レプリケーションの 2 つの方法を示しています。いずれかまたは両方を使用して、目的の RPO/RTO を達成できます。ストレージ層のレプリケーション (FSx for ONTAP によって実行) は SnapMirror によって実行され、データベースレベルのレプリケーションはアプリケーションスタックによって実行されます。セカンダリリージョンにも FSx for ONTAP によって維持される 2 つの同期コピーがあり、レプリケートされたデータのコピーは合計 4 つあることに注目してください。コストを削減するために、セカンダリリージョンの FSx for ONTAP をはるかに低いパフォーマンスレベルに設定し、災害時またはテストのオンデマンド時にのみパフォーマンスを上げることを検討できます。たとえば、通常の運用中は、並列 FSx for ONTAP の合計パフォーマンスを 300,000 IOPS および 8 GB/秒に設定できます。 単一データベースサーバーのストレージパフォーマンス AWS の 200 Gbit 対応インスタンス が導入されて以来、クライアントネットワークを介して単一のインスタンスに最大 20 GB/秒、8K で 200 万 IOPS を超える FSx for ONTAP のパフォーマンスを集約することが可能になりました。これらのインスタンスは、 EBS 最適化 ネットワークを介して最大 8 GB/秒、350,000 IOPS にも対応しており、場合によっては、 EBS インスタンスストア と呼ばれる NVMe がローカルに接続されていることもあります。その結果、これらのインスタンスの合計ストレージパフォーマンスは 30 GB/秒を超える可能性があります。ただし、極端なスケールを必要とするストレージのデプロイメントでは、データベース用に FSx for ONTAP ブロックデバイスを使用し、一時データベース用に EBS ボリュームを使用することもあります。つまり、テーブルスペース操作の実質的な制限は 20 GB/秒です。一時データベースにインスタンスストアを使用すると、インスタンスに直接接続されたストレージが活用されるためレイテンシーが低くなり、最適化された EBS ボリュームと FSx for ONTAP ブロックデバイスのいずれの場合でもパフォーマンスが高まります。本番データベースを FSx for ONTAP ブロックデバイスに限定すると、FSx for ONTAP スナップショットと FlexClone の使用が可能になり、容量コストが大幅に削減され、Amazon EBS と FSx for ONTAP ベースのスナップショット間の一貫性の問題が回避されます。 集約されたストレージパフォーマンスの分析 ピーク時に 8K で 100 万 IOPS に達する EHR 本番環境のデータベースを考えてみましょう。これは、単一の 200 Gbit 対応クライアントから約 10 GB/秒を消費します。ONTAP 環境全体で 16 個の FSx を利用すると、合計読み取り能力は 64 GB/秒を超え、8K で 250 万 IOPS になります。この総合パフォーマンスの余裕により、他のインスタンスに接続された FlexClone をレポート、クエリ、バックアップ、テスト、開発、またはその他のアクティビティに使用しても、本番環境のパフォーマンスに影響を与えず、全体的なストレージパフォーマンスを低下させる可能性のあるデータ移動 (コピー) も発生しません。これらの AWS アプリケーションインスタンスを組み合わせると、合計で 50 GB/秒、200 万 IOPS を超えるストレージレベルのパフォーマンスが得られます。 まとめ このブログでは、FSx for ONTAP ブロックサービスを EBS と組み合わせて導入する独自の方法について説明しました。この方法では、電子健康記録アプリケーションのパフォーマンスニーズを満たしながら、現在世界最大規模の EHR 導入をはるかに超える拡張が可能です。クラウドの動的で従量課金の特性を活用してストレージレイヤーを最適化し、コストを制御して、EHR アプリケーションを中断したり意識させたりすることなくスケールアップとスケールダウンの両方が可能な環境を作成し、FSx for ONTAP の容量効率の高い FlexClone を活用できます。そのため、組織のストレージ要件が拡大または縮小しても、組織が遊休の資産にコストを支払う必要はありません。 従量課金制の経済性と FSx for ONTAP の高度なストレージ効率性の強力な組み合わせにより、AWS 上で構築された電子健康記録アプリケーション向けに、スケーラブルで信頼性が高く、高可用性、耐災害性を備えながらもコスト効率に優れたストレージソリューションを実現します。 EHR 環境向けに最適化されたストレージへの取り組みを今すぐ開始する方法については、 AWS for Healthcare and Life Sciences にアクセスするか、AWS HCLS の担当者にお問い合わせください。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修はソリューションアーキテクトの宮城が担当しました。 <!-- '"` --> Randy Seamans Randy はストレージ業界のベテランであり、高性能ストレージ、コンピューティング (HPC)、および災害復旧を専門とする AWS のプリンシパルストレージスペシャリスト兼アドボケートです。彼のストレージに関する洞察や楽しみをさらに知るには、https://www.linkedin.com/in/storageperformance で彼をフォローしてください。

はじめに 様々な業界の組織がカスタマーサービス能力の向上を目指す中、 Amazon Connect のようなクラウドベースのコンタクトセンターソリューションの導入は戦略的な優先事項として重要になっています。英国の大手銀行・金融サービスグループである NatWest Group にとって、Amazon Connect を活用したコンタクトセンターを通じて顧客体験を向上させることは、長期的な顧客のロイヤルティと競争優位性を推進する重要な取り組みでした。 しかし、このような大規模な導入に対して包括的な DevSecOps エコシステムの実装と管理することには、独自の課題がよく発生します。 NatWest はこの課題を認識し、Amazon Connect の導入に加え、コンタクトセンター変革の長期的な成功と回復力を確保するため、戦略的に堅牢な DevSecOps エコシステム構築の取り組みを開始しました。 この記事では、このような組織の豊富な経験とそこから得られた教訓、 NatWest の取り組みから得られた貴重な洞察とベストプラクティスを提供します。DevSecOps アプローチを採用することで、組織は効率的で安全性が高く、スケーラブルな顧客体験を提供し、業界における基準を確立することができました。 NatWest が直面した課題 企業全体で共有された Amazon Connect インスタンスの管理 : NatWest は、複数のビジネスユニットとチームにまたがる単一の共有 Amazon Connect インスタンスを導入することを選択しました。このアプローチはリソースの最適化と一貫性の面でメリットを提供しましたが、リソースの分離、リリース管理、チーム間のコラボレーションなどの領域で複雑な課題も発生しました 堅牢なセキュリティとコンプライアンス順守の確保 : 銀行・金融サービスを提供するグループとして、NatWest はコンタクトセンター業務における最高水準のセキュリティとコンプライアンスを維持する必要性を強く認識していました。機密性の高い顧客データの保護と業界規制の遵守のためには、包括的なセキュリティ戦略が最重要事項でした イノベーションのペースの加速 : 競争が激化し、スピードが求められる市場において、NatWest は Amazon Connect を活用したコンタクトセンターの新機能と能力を迅速に開発・展開する必要性を認識しています。組織は、進化する顧客の要求に対応するため、デプロイメントプロセスの最適化を目指しました 運用効率と一貫性の向上 : 複数のチームとビジネスユニットが共有の Amazon Connect インスタンスを活用する中、NatWest はコンタクトセンター環境全体での一貫性を維持することを目指しました。組織は、運用効率と俊敏性を向上させるため、重複した作業、サイロ化されたワークフロー、標準化の欠如に対処しようとしました NatWest のアプローチ NatWest は Amazon Connect の採用とともに、認識した課題に対し、プラットフォームのための包括的な DevSecOps エコシステムを実装する戦略的な取り組みを開始し、実装を完了しました。このアプローチは、顧客体験の向上、業務効率の推進、組織のセキュリティ体制の強化を目的として設計されました。 AWS プロフェッショナルサービスチーム と緊密に連携し、NatWest は主要な課題に対処する多面的なアプローチを実装しました。 環境分離戦略 NatWest の DevSecOps アプローチの中核となったのは、Amazon Connect インスタンスに対する明確に定義された環境分離戦略の実装でした。彼らは、サイロ化された複数インスタンスを用意するのではなく、組織全体のビジネスユニットで共有される単一の Amazon Connect インスタンスを持つことを選択しました。このアプローチにより、管理の一貫性の確保、リソースの利用の効率化が実現でき、チーム間の効果的なコラボレーションが可能になりました。 開発、テスト、本番環境を用意するため、NatWest は以下の環境構造を実装しました。 サンドボックス環境 : 開発者が他の環境に影響を与えることなく、Amazon Connect の機能を試験、探索、習熟するための専用の実験環境です 開発環境 : 新機能や設定の開発と初期テストに使用される個別の AWS アカウントです テスト環境 : 上位環境への変更を適用する前に、機能テストを含む包括的なシステム統合テストを行うための専用の AWS アカウントです 本番前環境 : 本番環境への展開前の最終検証ステップで、個別の AWS アカウントでホストされ、本番環境の設定を密接に反映した環境です 本番前災害復旧環境 : 事業継続性を確保するため、異なる AWS リージョンにデプロイされた本番前環境用の災害復旧環境です 本番環境 : 厳格なセキュリティ対策を備えた専用の AWS アカウントでホストされる、実稼働中の顧客向け環境です 本番災害復旧環境 : リージョンの停止時のバックアップとして機能する、異なる AWS リージョンにデプロイされたフェイルオーバー環境です 各環境を別々の AWS アカウントとリージョンに分離することで、NatWest は明確な責務の分離、セキュリティ強化、効率的なテストと災害復旧戦略を実現しました。この構成により、組織は Amazon Connect インスタンスを効果的に管理し、スムーズな開発ライフサイクル、堅牢なテスト、そしてコンタクトセンター運用の高可用性を確保することができました。 Infrastructure as Code (IaC) 戦略 NatWest は様々な事業部門が利用する共有の Amazon Connect 環境を持っています。このインフラストラクチャを管理するため、組織では IaC ツールとして Terraform を採用しています。画一的なアプローチではなく、NatWest はモジュール型の戦略を採用し、インフラストラクチャをより小さく管理しやすい単位で定義しています。 独立した管理のための分散型アプローチ このモジュール型アプローチにより、異なるチームが専用の Terraform コードリポジトリを使用して、それぞれのインフラストラクチャコンポーネントを独立して管理およびリリースすることができます。この分散型構造を採用することで、NatWest は単一のリポジトリの変更が広範な問題に発展するリスクを軽減することができました。さらに、この戦略によってリリースプロセスを高速化し、インフラストラクチャに導入される問題の潜在的な影響範囲が縮小できます。 意味を持ったリソース命名とタグ付け リソースの競合を防ぎ、チーム間での一貫性を確保するため、NatWest は独自のリソース命名とタグ付けの戦略を実装しています。組織のポリシーと標準に準拠しながら柔軟性を提供することが重要であるため、チームは Amazon Connect の共通のリソースタイプに対するカスタム Terraform モジュールを作成しています。 これらの独自のモジュールにより、一貫した命名規則、タグ付け基準、および事前定義されたポリシー（セキュリティ、コンプライアンスなど）への準拠を強制できます。これらのモジュールを活用することで、NatWest は異なるチームによって作成されたリソースであっても NatWest の Amazon Connect プラットフォーム全体が一貫したアプローチに従うことを確保しています。以下が Amazon Connect 用に定義された Terraform モジュールのリストです。 Amazon Connect AWS Lambda Amazon Lex Amazon DynamoDB その他の一般的なリソース：Amazon Simple Storage Service (S3)、AWS Identity and Access Management (IAM)、AWS Key Management Service (AWS KMS)、Amazon Kinesis このモジュール化された独自のアプローチは、チームによる独立したインフラストラクチャ管理を可能にするだけでなく、一貫性、ベストプラクティスへの準拠、組織のポリシーとの整合性を実現します。 デプロイ戦略 NatWest は、堅牢な IaC アプローチに加えて、Amazon Connect 内の重要なコンポーネントのデプロイプロセスも最適化しています。Amazon Lex ボットや Amazon QuickSight のアセットなどの主要リソースのデプロイ戦略を効率化することで、組織は新機能や性能の開発と提供を加速し、顧客に対してシームレスで一貫性のある体験を確保することができています。 Amazon Lex のデプロイ戦略 NatWest の Amazon Connect コンタクトセンターにおける顧客セルフサービスの重要な部分は、特に Amazon Lex V2 に焦点を当てた複数の Amazon Lex ボットの活用です。チームが迅速にこれらの Lex ボットを開発・デプロイできるようにするため、NatWest はエクスポートとインポートの CI/CD パイプラインを使用した自動デプロイ戦略を実装しています。 複雑な Amazon Lex ボットスキーマのデプロイ管理は、AWS CloudFormation のような従来の IaC ツールを使用すると、課題になる可能性があります。これらのツールに必要な YAML や JSON の定義は、すぐに扱いづらく保守が困難になる可能性があります。この課題に対処するため、NatWest は次のようなより効率的なアプローチを採用しました。 開発者は使いやすい Lex コンソールを使用して Amazon Lex ボットを作成・構築します ボットが十分にテストされた後、開発者はエクスポートパイプラインを活用してボットのスキーマをコードとして取得し、Git リポジトリに保存します 上位環境（開発、テスト、本番など）へのデプロイには、インポート CI/CD パイプラインを使用します。このパイプラインは Git リポジトリからボットスキーマを取得し、対象環境にボットをデプロイします このエクスポートとインポートのアプローチにより、手動での IaC コード作成の必要性を排除し、NatWest は Lex ボットのデプロイプロセスを効率化し、全体的な開発・デリバリーサイクルを加速することができました。 Amazon QuickSight のデプロイ戦略 NatWest はコンタクトセンター業務と並行して、データ駆動型の意思決定をサポートするため、ダッシュボードとレポートの作成に Amazon QuickSight を活用しています。複数の環境でこれらのアセットへの需要が高まるにつれ、QuickSight のアセットを手動でデプロイし管理することは、時間がかかり、エラーが発生しやすいプロセスであることが分かりました。 この課題に対処するため、NatWest は開発者が QuickSight コンソールを使用して QuickSight のダッシュボード、分析、データセット、データソースを迅速に構築およびカスタマイズできる戦略を定義しました。これにより、組織はエクスポートとインポートのパイプラインを活用して、これらのアセットを異なる環境間で迅速にデプロイしています。 NatWest における QuickSight アセットのデプロイメントプロセスは以下の通りです。 ユーザーは QuickSight コンソールを使用して、必要な QuickSight アセット（ダッシュボード、分析、データセット、データソース）を作成・カスタマイズします アセットの準備が整ったら、開発者は NatWest の QuickSight のパイプラインで統合された QuickSight エクスポート API を使用して、それらを JSON バンドルとしてエクスポートします エクスポートされた JSON バンドルは、ソースコードとしてバージョン管理システム（Git）に保存されます 異なる環境（開発、テスト、本番など）へのデプロイ時には、NatWest の QuickSight へインポートするパイプラインを通じ QuickSight インポート API を活用して、JSON バンドルをターゲットの QuickSight アカウントにデプロイします このアプローチにより、大規模な、あるいは複雑な QuickSight 構成で扱いづらくなる可能性がある、AWS CloudFormation や Terraform のようなツールによる複雑な IaC リソースを定義する必要性を回避できます。代わりに、エクスポートとインポートのパイプラインにより、NatWest は QuickSight アセットをコードとして扱い、バージョン管理に保存し、環境全体で一貫してデプロイすることができます。 QuickSight コンソールの使いやすさと自動化されたエクスポート・インポートパイプラインを組み合わせることで、NatWest は開発者の俊敏性を促進しながら、組織全体でデータの可視化と分析アセットの一貫性があり、信頼できるデプロイメントを確保できました。 セキュリティコントロール コンタクトセンター業務における機密性と顧客データの保護の必要性を考慮すると、セキュリティは NatWest にとって最も重要な関心事でした。これに対処するため、Amazon Connect を保護するための予防的および検知的な制御に重点を置いた包括的な DevSecOps セキュリティ戦略を策定しました。 予防的統制 NatWest は DevSecOps 全体で予防的なセキュリティ統制を実装する積極的なアプローチを取りました。 リソースの命名とタグ付けポリシー : 組織はインフラストラクチャの可視性と制御を向上させるため、一貫性があり、意味のあるリソース命名規則とタグ付け基準を実施しました セキュアな構成 : NatWest は独自の Terraform モジュールを活用して、Amazon Connect、AWS Lambda、Amazon Lex、その他のサービスを慎重に構成しました。これらのモジュールにはセキュリティのベストプラクティスと組織のポリシーが組み込まれており、インフラストラクチャが安全かつコンプライアンスに準拠した方法でデプロイされるように構成しました 静的コードスキャン : CI/CD パイプラインの一部として、NatWest は Terraform コード用の Checkov や Python コード用の Bandit などのセキュリティスキャンツールを用い、脆弱性と設定ミスの継続的なスキャンを実装しました AWS サービスコントロールポリシー : サービスコントロールポリシーを活用して、Amazon Connect インスタンスや Amazon Connect の問い合わせ記録、通話録音などの機密データの削除を拒否するなど、厳格なガードレールを実装し、特定のアクションを制限しました 発見的統制 予防的統制を補完するため、NatWest は以下を含む堅牢な発見的統制も実装しました。 AWS Config : NatWest は、標準・カスタム設定ルールの両方を使用して AWS Config を活用、リソースの設定を継続的に監視し、ドリフトや変更を検知しています Amazon Inspector : Amazon Inspector を有効にし、AWS Lambda 関数の脆弱性と設定ミスを定期的にスキャン、潜在的なセキュリティ問題に対処するための貴重な洞察を確認しています セキュリティ監視とアラート : Amazon CloudWatch や AWS Security Hub などのサービスを統合することで、包括的なセキュリティ監視とアラートのフレームワークを確立し、セキュリティインシデントの迅速な特定と対応を可能にしました 予防的統制と発見的統制を組み合わせたこの多層的な DevSecOps アプローチにより、NatWest のコンタクトセンター運営における強力なセキュリティ体制が確保されました。リスクを事前に軽減し、セキュリティインシデントをタイムリーに検知して対処することで、顧客のデータ保護を最高レベルで維持することができました。 開発とデプロイを高速化するツール群 NatWest は、Amazon Connect の開発とデプロイをさらに効率化するために、カスタマイズしたユーティリティとアクセラレーターを作成しました。これらには以下が含まれます。 コンタクトフローを Terraform テンプレートとして出力するツール NatWest が開発した主要なユーティリティの 1 つは、コンタクトフローのエクスポートツールでした。これにより、 Amazon Connect コンソールを使用して開発したコンタクトフローを Terraform テンプレートとしてエクスポート、ハードコードされた ARN を Terraform 変数に置き換えることができます。このユーティリティを活用することで、NatWest は以下を実現できました。 コンタクトフローを IaC として扱い、バージョン管理、環境間での一貫したデプロイを可能にしました Terraform テンプレートを直接適用し、ターゲット環境へのコンタクトフローのデプロイ時に手動設定を回避しました AWS Lambda 関数や Lex ボットなどの共通のコンタクトフローコンポーネントを Terraform 変数で参照することで、一貫性と再利用性を確保しました Contact Lens ルールのエクスポートとパイプライン内でのインポートツール コンタクトフロー管理ツールに加えて、NatWest は Amazon Connect Contact Lens ルールのエクスポートとインポートのパイプラインも作成しました。これにより、組織は Contact Lens ルールの設定をバージョン管理し、環境間で一貫してデプロイすることができ、会話分析に対する標準化されたアプローチを実現しました。 パフォーマンスメトリクスのレポート NatWest は、Amazon Connect コンタクトセンターの全体的なパフォーマンスの可視化を提供するために、カスタムレポートユーティリティを開発しました。これらのツールは、Amazon Connect、Amazon Lex、DynamoDB、AWS Lambda などの様々なソースからログとメトリクスを収集・分析し、包括的なパフォーマンスレポートを生成しました。これにより、組織はデータに基づく意思決定を行い、コンタクトセンター運営の効率性と信頼性を継続的に最適化することができました。 このカスタマイズされたツール群を活用することで、NatWest は Amazon Connect ベースのコンタクトセンターサービスの構築、テスト、デプロイに必要な時間と労力を大幅に削減し、最終的に組織全体の効率性と俊敏性を高めることができました。 実現した効果 Amazon Connect プラットフォームに包括的な DevSecOps エコシステムを実装することで、NatWest は主に以下のような効果が得られました。 標準化され一貫性のあるアプローチ : 複数の環境とビジネスユニットにわたる Amazon Connect リソースを管理するための標準化された一貫したアプローチを確立し、複雑さを軽減し、組織のポリシーとの整合性を確保しました セキュリティ体制の改善 : 予防的および発見的なセキュリティ統制の実装により、NatWest のコンタクトセンター環境の全体的なセキュリティを強化し、機密性の高い顧客データを保護しました 効率性と信頼性の向上 : 自動化されたデプロイメントと IaC の採用により、NatWest のコンタクトセンター運営の効率性と信頼性が向上し、組織は進化する顧客ニーズに迅速に対応できるようになりました リリースプロセスの効率化： NatWest は堅牢なテスト、検証、ロールバックメカニズムを実装し、コンタクトセンターへの新機能と機能の円滑で信頼性の高いデリバリーを確保しました 開発とデプロイの加速 : NatWest が開発した様々なデプロイメント戦略、ユーティリティ、アクセラレーターにより、Amazon Connect プラットフォームのコンポーネントの構築、テスト、デプロイに必要な時間と労力が大幅に削減されました まとめ Amazon Connect コンタクトセンターに包括的な DevSecOps エコシステムを実装することで、NatWest は効率的で安全でスケーラブルな顧客体験を責任もって提供することができました。 NatWest が採用した包括的な DevSecOps フレームワークにより、組織はコンタクトセンター運営のモダナイゼーションで直面する複雑な課題に対処することができました。Amazon Connect リソースを管理するための標準化された一貫したアプローチを確立することで、NatWest は複雑さを軽減し、セキュリティを改善し、コンタクトセンター運営の効率性と信頼性を向上させました。 さらに、Lex ボットと QuickSight アセットのエクスポート・インポートパイプラインの活用を含む、組織の革新的なデプロイメント戦略により、新機能の開発と提供が加速されました。カスタムビルドのユーティリティとアクセラレーターと組み合わせることで、NatWest のチームは進化する顧客ニーズにより俊敏に対応できるようになりました。 この包括的なガイドで説明した戦略とベストプラクティスは、自社のコンタクトセンター運営をモダナイズし、Amazon Connect の可能性を最大限に引き出そうとする組織にとって、貴重な参考事例となります。DevSecOps の考え方を取り入れ、AWS の幅広い機能を活用することで、企業は顧客満足度を向上させ、運用効率を改善し、堅牢なセキュリティ体制を維持することができます。 金融サービス業界が進化し続ける中、Amazon Connect における NatWest の DevSecOps の取り組みは、技術的なモダナイゼーションに対する包括的で顧客中心のアプローチによる変革を示しています。この記事では、コンタクトセンターの変革で同様の成功を目指す他の組織に役立つロードマップを提供しました。 筆者について Abhay Kumar は Natwest のエンジニアリング ディレクターです。コンタクトセンター プラットフォームのアーキテクチャ、開発、保守、品質、セキュリティを担当しています。 Prateek Guleria は Natwest の DevOps リードです。自動化の実行、CI/CD の開発と実装の監督、AWS プラットフォーム上のクラウドインフラストラクチャの維持を担当しています。 Krishanu Bhar は Natwest のシニアソリューションアーキテクトで、金融業界特有のニーズに合わせた安全で拡張性のある、コンプライアンスに準拠したクラウドソリューションの設計に注力しています。デジタルトランスフォーメーションを推進し、銀行業務を最適化するために AWS テクノロジーを活用することに情熱を注いでいます。 Anand Jumnani は英国を拠点とする AWS の DevOps コンサルタントです。 Alex Buckhurst は AWS の シニア Amazon Connect コンサルタントで、イノベーションと顧客中心の設計の構築に焦点を当てています。余暇には、スカッシュをプレイし、バーベキューの腕を磨き、家族との時間を大切にしています。 Wajahat Khan は英国を拠点とする AWS のシニア Amazon Connect コンサルタントです。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 先週はDeepSeekの話題がホットな一週間でしたね。私自身もいろいろなお客さんから、DeepSeekに関してお問い合わせやご相談をいただきました。AWSとしては用途に応じて最適な精度・コスト・レイテンシを備えたモデルを選択して利用できたり、時には自分で開発・調達したモデルをデプロイして利用できることが大事だと考えており、さっそく DeepSeekモデルについても選択肢のひとつに加わりました 。 それでは、1 月 27 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「DeepSeek-R1 models now available on AWS」を公開 英語版の記事そのままですが、速報ということで取り上げます。世の中で注目されているDeepSeekモデルですが、AWSのAmazon BedrockやAmazon SageMaker AIで動作させることが可能になっています。昨年のre:inventで発表されたBedrock Marketplaceの仕組みを使ってDeepSeek-R1を組み込んだアプリケーションをホストしたり、SageMaker JumpStartで学習済みのDeepSeek-R1モデルを動かしてハンズオンの検証を行うなどができるようになっていますので、興味のある方はぜひトライしてみてください。 ブログ記事「Amazon Bedrock で DeepSeek-R1 Distilled Llama モデルをデプロイする」を公開 こちらはDeepSeekに関する和訳済みのブログ記事です。DeepSeek-R1をベースとして、Meta LlamaやQwenのアーキテクチャに基づく15-700億パラメータの蒸留モデルが公開されています。DeepSeek-R1-Distill-Llama-8BとDeepSeek-R1-Distill-Llama-70BについてはAmazon Bedrock Custom Model Import機能でインポートして利用できますので、その方法をご紹介するブログ記事です。 AWS生成AI国内事例ブログ: 東京海上日動システムズ株式会社様、LLMによるアプリケーションモダナイゼーションへの挑戦 東京海上日動システムズ様では、多くの基幹系システムをAWSに移行済みですが、一部はオンプレミスでの運用を継続しており、移行済みのシステムの多くはリフト&amp;シフトによるレガシーなアプリケーション構造のままとなっています。オンプレミスのサーバやEC2で稼働しているJavaアプリケーションをサーバレスアーキテクチャにモダナイズするために、生成AIを活用し効率化することにチャレンジされています。AWS Prototyping Programを活用することで素早く小規模なアプリケーションでの検証を実施、95%は生成AIによるコードで動作し、エラーの多くが単純な修正で解消できることが確認されました。次のチャレンジはひとつのパッケージで完結しないアプリケーションでのバリデーションチェックやエラーハンドリングとのことです。生成AIによるアプリケーションモダナイゼーションは興味深い分野ですので、同様の課題感をお持ちの方はぜひご一読ください。 ブログ記事「GraphRAG Toolkit の紹介」を公開 検索拡張生成(RAG)の精度や、質問への適合性を高めるため、グラフDBによる情報間の関係性を利用するGraphRAGというテクニックが知られています。この記事はグラフDBを活用したRAGワークフローの構築を容易にするPythonライブラリであるGraphRAG Toolkitの意義と使い方をご紹介するものです。 ブログ記事「AWSで実現する安全な生成 AI アプリケーション – OWASP Top 10 for LLM Applications 2025 の活用例」を公開 生成AIによるアプリケーションの安全性は、様々な企業や組織にとって重要な課題です。このブログ記事ではOWASP(Open Worldwide Application Security Project)が提唱する、LLMを組み込んだアプリケーションにおける主要な10のセキュリティ脅威をまとめたOWASP Top10 for LLM ApplicationについてAWSでアプリケーションを設計・開発する方が考慮すべきポイントやリスクシナリオを概説しています。 ブログ記事「金融業界における生成AI活用動向」 様々な業界で生成AIの可能性への期待が高まる中で、2024年は業務での実用を検討・開始する年となりました。この記事では、AWSで金融領域の事業開発担当者からみたAIの活用動向について、インタビュー形式でご紹介するものです。読み物として気軽に読めるようになっていますので、金融業界と関わりの深い方も、そうでない方も、ぜひご覧ください。 ブログ記事「デジタル庁主催の AI ハッカソンに参加しました」を公開 2024年11月にデジタル庁主催で「AIハッカソン、アイデアソン」が開催されました。AWSのエンジニアチームとしてもこの取り組みに参加させていただきましたので、考案したソリューションについてご紹介するブログ記事です。 ブログ記事「生成AIとデータによる小売体験の刷新」 他業界でもそうですが、小売業や消費財業界ではデジタルトランスフォーメーションの重要性が一段と高く叫ばれています。この記事では、生成AIによってどういった変革が可能になるのかを紹介しています。 サービスアップデート Amazon SageMaker Unified Studioのプレビュー可能リージョンを7箇所追加 Amazon SageMaker Unified Studioはデータ・アナリティクス・AIに関するコラボレーションやデータを扱う処理の素早い構築を可能にする統合環境です。今回、新たに7つのリージョン(ソウル、シンガポール、シドニー、フランクフルト、ロンドン、サンパウロ、カナダ(中央))でプレビューが可能になりました。 Amazon Q in QuickSightのDashboard Q&amp;A機能を発表 Amazon Q in QuickSightでDashboard Q&amp;A機能がご利用いただけるようになりました。ダッシュボードにおいて、データに関するQ&amp;Aに応答する機能をワンクリックで追加でき、ダッシュボードのユーザがデータに関する疑問を持った際にセルフサービスで解決するために役立ちます。 Amazon Q Developer Agentが生成したコードに対するビルドとテストのリアルタイム実行に対応 Amazon Q Developer Agentがアップデートされ、生成したコードを開発者がレビューする前にビルドやテストを行うスクリプトを実行できるようになりました。Amazon Qが生成したコードを開発者がチェックする前に、指定されたビルドやテストを自動実行しそれにパスしたものだけを開発者に提示することで、開発者に対してより精度の高いコードが提示される可能性が高まる機能です。 Amazon Q Developer Pro Tierで新規登録ユーザに対する通知メールの自動送信に対応 Amazon Q Developer Pro Tierで新規登録されたユーザに対して自動的にメール通知が行われるようになりました。このメールは24時間以内に送信され、開発者がAmazon Q Developerを利用する上で重要な情報が含まれており、管理者の手間を省くことにつながります。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 注目のアップデートがあり冒頭で紹介します。中国 AI スタートアップ企業の DeepSeek が公開した DeepSeek-R1 モデルや、DeepSeek-R1 をベースとした蒸留モデルを AWS 上にデプロイが出来るようになりました。現時点で 4 つの方法があります。 1. Amazon Bedrock Marketplace で DeepSeek-R1 モデルを利用 2. Amazon SageMaker Jumpstart で DeepSeek-R1 モデルを利用 3. Amazon Bedrock の Custom Model Import で DeepSeek-R1-蒸留モデルを利用 4. EC2 の Trn1 インスタンスで DeepSeek-R1-蒸留モデルを利用 詳細は こちらのブログ で紹介されております。ぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月27日週の主要なアップデート 1/27(月) AWS User Notifications で新機能の AWS Managed Notifications を提供開始 AWS User Notifications の新機能である AWS Managed Notifications の一般提供を開始しました。AWS Health から通知されるメッセージについて、通知先の管理や変更が簡単になります。例えば、セキュリティに関する通知はセキュリティチームのメーリングリストに送付し、料金に関しては管理者のメーリングリストに送付する、といった設定が可能です。メール以外にも、スマートフォンへのプッシュ通知や、Slack や Teams といったチャットを送信先として設定できます。 Amazon EKS マネージドノードグループで新しい minimal アップデート戦略を導入 Amazon EKS のマネージドノードグループで、従来の default に加えて、新しい minimal アップデート戦略を導入しました。アップデート戦略は、更新作業でノードを入れ替える際の動作を指定できます。新しい minimal は、需要の高い GPU 付きの EC2 インスタンスや、Reserved Instance でキャパシティ予約を行っている環境などでメリットがあります。新しいノードを作成する前に古いノードを終了するため、総キャパシティが設定した量を超えることがなく、リソースやコストに制限のある環境で利用しやすいです。詳細は こちらの AWS Document をご覧ください。 Amazon S3 メタデータの一般提供を開始 Amazon S3 メタデータの一般提供を開始しました。S3 Bucket に保存しているデータの種別をメタデータとして付与することで、必要なデータを発見しやすくなるメリットがあります。サイズやオブジェクトソースなどのシステム的なメタデータや、業務内で利用する、製品 SKU、トランザクション ID、コンテンツ評価などのカスタムメタデータの付与ができます。Amazon Athena、Amazon Data Firehose、Amazon EMR、Amazon QuickSight、Amazon Redshift などの AWS 分析サービスを使用して、S3 メタデータテーブルの可視化やクエリーが可能です。 詳細はこちらのブログ をご覧ください。 1/28(火) AWS Amplify がサーバーサイドの AWS Lambda 関数で TypeScript データクライアントの使用をサポート AWS Lambda 関数内で Amplify データクライアントを使用できるようになりました。この新機能により、フロントエンドアプリケーションで使用する時と同様に、型安全なデータ操作を Lambda 関数内で直接利用でき、生の GraphQL クエリを記述する必要がなくなります。これにより、開発時間が短縮でき、エラーが最小限に抑えられ、コードベースの保守性が向上します。 1/29(水) Amazon Redshift がクエリ監視と診断を改善するための強化されたクエリモニタリングを提供開始 Amazon Redshift で、パフォーマンスのボトルネックを効率的に特定し改善に活かせる、強化されたクエリモニタリング機能を提供開始しました。トレンド分析のためのパフォーマンス履歴の表示、ワークロードの変更の検出、時間の経過に伴うクエリパフォーマンスの変化の理解、クエリプロファイラーによるパフォーマンスの問題の診断などがやりやすくなります。 1/30(木) Amazon SES Mail Manager が大阪リージョンを含めた新しいリージョンで提供開始 SES Mail Manager が、大阪リージョンを含む、11 個の新しいリージョンで利用が可能になりました。Mail Manager は組織内でメールを送受信する際に、コンプライアンスを一元的に管理できる機能セットです。例えば、DKIM が Pass になったメールのみ受信する、Trend Micro Virus Scanning と連携しウイルススキャン後にメールを受信する、といったルール管理が可能です。 SES Mail Manager がアドレスとドメインリストのサポートを追加 SES Mail Manager が既知のアドレスと未知のアドレスを区別するために、定義済みのメールアドレスとドメインリストをサポートしました。この機能により、Mail Manager を利用してメールを送受信する際に、誤入力されたメールアドレスや、ディレクトリハーベスティング攻撃、すでに信頼しているドメインなどをルールエンジン上で識別でき、必要に応じたセキュリティのアクションを指定できます。 Amazon Lex のアシスト付きスロット解決機能を東京リージョンを含めた新しいリージョンで提供開始 Amazon Lex のアシスト付きスロット解決機能の提供リージョンを拡大しました。東京リージョンを含む 10 リージョンで利用可能です。アシスト付きスロット解決機能は、Amazon Bedrock と連携することで、お客様との会話で精度向上のメリットがあります。例えば、「レンタル契約の期限はいつですか?」という質問に対して、お客様が「リースは来月 1 日に期限切れになります。」と回答したときに、生成 AI 機能を活かして 2025-02-01 といった内容の理解を試みるものです。 詳細はこちらのドキュメント をご覧ください。 Amazon Timestream for InfluxDB でストレージスケーリングをサポート Amazon Timestream for InfluxDB で、ストレージスケーリング機能を提供開始しました。割り当てられたストレージをスケーリングし、ストレージ階層を変更することが可能になります。より高速で性能の高いストレージ階層に移行したり、割り当てられたストレージ容量を拡張したりすることで、データ取り込み、クエリ量、その他のワークロードの変動に素早く対応できます。 CloudWatch Database Insights が OS プロセスの履歴スナップショットをサポート CloudWatch Database Insights が、データベースで実行されているオペレーティングシステム (OS) プロセスの履歴スナップショットの分析をサポートするようになり、データベースの負荷状況と OS プロセスを紐づけた分析がやりやすくなります。この新機能では、実行プロセスがデータベース上のシステムリソースをどのように使用しているかを DBA が理解するのに役立ち、OS プロセスメトリクスとデータベース負荷を簡単に関連付けることができます。OS プロセススナップショットは、Database Insights が利用可能なすべてのリージョンで、Aurora PostgreSQL と Aurora MySQL の両方で利用できるようになりました。 1/31(金) Amazon EBS でスナップショットから EBS を作成する際のリソースレベルのアクセス許可をサポート Amazon EBS で、スナップショットから EBS ボリューム作成時にリソースレベルのアクセス許可をサポートするようになりました。例えば、EBS スナップショットに機密性の高いデータが存在しているときに、特定の Organizations や AWS アカウントに存在する EBS スナップショットのみの利用を制限することが可能です。 詳細はこちらのブログ をご確認ください。 AWS Glue で新たに 14 個のコネクタを提供開始 AWS Glue で新たに、アプリケーション用途の 14 個のコネクタを提供開始しました。Blackbaud Raiser’s Edge NXT、CircleCI、Docusign Monitor、Domo、Dynatrace、Kustomer、Mailchimp、Microsoft Teams、Monday、Okta、Pendo、Pipedrive、Productboard、Salesforce Commerce Cloud からデータを取り込むことが可能です。コネクタごとに行う設定や制限事項などが AWS Document にまとめられております。 AWS Transfer Family web apps で、大阪を含めたリージョンの拡張 AWS Transfer Family web apps で、大阪リージョンを含む、20 個の新しいリージョンで利用が可能になりました。AWS Transfer Family web apps は、ウェブブラウザを通じて Amazon S3 のデータにアクセスができるインターフェースを提供します。S3 のデータの閲覧、アップロード、ダウンロードなどが可能な画面を利用可能です。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です