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

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

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

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

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

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

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

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

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

12 月 2 日、NVIDIA H200 Tensor コア GPU と、AWS でのみ利用可能な 3.2 GHz のオールコアターボ周波数 (最大コアターボ周波数 3.8 GHz) のカスタム第 4 世代 Intel Xeon スケーラブルプロセッサーを搭載した Amazon Elastic Compute Cloud (Amazon EC2) P5en インスタンス の一般提供についてお知らせします。これらのプロセッサでは、メモリ帯域幅が 50% 向上し、PCIe Gen5 で CPU と GPU 間のスループットが最大 4 倍になるので、機械学習 (ML) トレーニングと推論ワークロードのパフォーマンスが大きく向上します。 P5en は、Nitro v5 を使用する最大 3200 Gbps の第 3 世代 Elastic Fabric Adapter (EFAv3) を搭載しており、前世代の EFA と Nitro を使用する P5 に比べてレイテンシーが最大 35% 向上しています。これにより、 深層学習 、 生成 AI 、 リアルタイムデータ処理 、 ハイパフォーマンスコンピューティング (HPC) などの用途における分散型トレーニングワークロードの集団通信パフォーマンスが向上します。 P5en インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) GPU (H200) ネットワーク帯域幅 (Gbps) GPU ピアツーピア (GB/秒) インスタンスストレージ (GB) EBS 帯域幅 (Gbps) p5en.48xlarge 192 2048 8 3200 900 8 x 3.84 100 9 月 9 日、 Amazon EC2 P5e インスタンスが発表 されました。このインスタンスは、1128 GB の高帯域幅 GPU メモリを搭載した 8 基の NVIDIA H200 GPU、第 3 世代 AMD EPYC プロセッサ、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージを備えています。これらのインスタンスは GPUDirect RDMA をサポートし、EFAv2 による最大 3200 Gbps の集約ネットワーク帯域幅を提供します。これにより、ノード間通信で CPU をバイパスすることでレイテンシーを低減し、パフォーマンスを効率的にスケールアウトすることが可能になります。 P5en インスタンスでは、推論とネットワークレイテンシーがさらに削減され、さまざまな GPU アクセラレーションアプリケーションの全体的な効率性を高めることができます。P5 インスタンスと比較して、P5en インスタンスでは、ローカルストレージのパフォーマンスが最大 2 倍向上し、 Amazon Elastic Block Store (Amazon EBS) の帯域幅が最大 25% 向上するので、ローカルストレージを使用してモデルの重みをキャッシュしているユーザーの推論レイテンシーパフォーマンスがさらに向上します。 頻繁なデータ交換を必要とする大規模なデータセットやワークロードでは、特に CPU と GPU 間のデータ転送に時間がかかる場合があります。P5 や P5e インスタンスと比較して、PCIe Gen 5 での CPU と GPU 間の帯域幅が最大 4 倍になるため、複雑な 大規模言語モデル (LLM) とマルチモーダル 基盤モデル (FM) に加えて、シミュレーション、医薬品発見、天気予報、財務モデリングなど、メモリを大量に消費する HPC 用途のモデルトレーニング、微調整、推論の実行におけるレイテンシをさらに改善できます。 Amazon EC2 P5en インスタンスの使用を開始する 米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京) の AWS リージョンで利用可能な EC2 P5en インスタンスは、 EC2 Capacity Blocks for ML 、オンデマンド、Savings Plan の購入オプションを通して使用できます。 オプションとしてキャパシティ予約を含む P5en インスタンスの使用方法を紹介したいと思います。EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で米国東部 (オハイオ) の AWS リージョンの [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 p5en.48xlarge インスタンス用の EC2 キャパシティブロックが必要な期間を指定します。EC2 キャパシティブロックを予約できる合計日数は 1～14 日、21 日、または 28 日です。EC2 キャパシティブロックは最大 8 週間前に購入できます。 [キャパシティブロックを検索] を選択すると、ユーザー指定の日付範囲内で仕様を満たす利用可能な最低料金のオプションが返されます。EC2 キャパシティブロックの詳細、タグ、および合計料金情報を確認し、 [購入] を選択します。 これで、EC2 キャパシティブロックが正常にスケジュールされます。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 Capacity Blocks for ML 」を参照してください。 購入したキャパシティブロック内でインスタンスは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して実行することができます。 ここでは、16 個の P5en インスタンスを実行して EFAv3 のメリットを最大化 する AWS CLI コマンドの例を示します。この構成では、8 つのプライベート IP アドレスで最大 3200 Gbps の EFA ネットワーク帯域幅と最大 800 Gbps の IP ネットワーク帯域幅が提供されます。 $ aws ec2 run-instances --image-id ami-abc12345 \ --instance-type p5en.48xlarge \ --count 16 \ --key-name MyKeyPair \ --instance-market-options MarketType='capacity-block' \ --capacity-reservation-specification CapacityReservationTarget={CapacityReservationId=cr-a1234567} --network-interfaces "NetworkCardIndex=0,DeviceIndex=0,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=1,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=2,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=3,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=4,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=5,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=6,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=7,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=8,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=9,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=10,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=11,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=12,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=13,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=14,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=15,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=16,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=17,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=18,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=19,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=20,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=21,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=22,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=23,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=24,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=25,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=26,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=27,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=28,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa" \ "NetworkCardIndex=29,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=30,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" \ "NetworkCardIndex=31,DeviceIndex=1,Groups=security_group_id,SubnetId=subnet_id,InterfaceType=efa-only" ... P5en インスタンスを起動するとき、 AWS Deep Learning AMI (DLAMI) を使用して EC2 P5en インスタンスをサポートできます。DLAMI は、事前設定された環境でスケーラブルで安全な分散型 ML アプリケーションをすばやく構築するためのインフラストラクチャとツールを ML の専門家や研究者に提供します。 Amazon Elastic Container Service (Amazon ECS) または Amazon Elastic Kubernetes Service (Amazon EKS) のライブラリを使用して、P5en インスタンス上で AWS Deep Learning Containers でコンテナ化された ML アプリケーションを実行できます。 大規模なデータセットにすばやくアクセスするには、最大 30 TB のローカル NVMe SSD ストレージを使用するか、 Amazon Simple Storage Service (Amazon S3) で費用対効果の高い事実上無制限のストレージを使用することができます。P5en インスタンスで Amazon FSx for Lustre ファイルシステムを使用して、大規模な深層学習と HPC ワークロードに必要な数百 GB/秒のスループットと 1 秒あたり数百万回の入出力オペレーション (IOPS) でデータにアクセスすることもできます。 今すぐご利用いただけます 現在、Amazon EC2 P5en インスタンスは、EC2 Capacity Blocks for ML、オンデマンド、Savings Plan の購入オプションを通して、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京) の AWS リージョンと米国東部 (アトランタ) ローカルゾーン us-east-1-atl-2a でご利用いただけます。詳細については、 Amazon EC2 料金のページ を参照してください。 Amazon EC2 コンソール で Amazon EC2 P5en インスタンスを試してみてください。詳細については、 Amazon EC2 P5 インスタンスのページ を参照してください。フィードバックは、 EC2 の AWS re:Post 、または通常の AWS サポートの担当者までお寄せください。 – Channy 原文は こちら です。

データベース管理システム (DBMS) では、同時実行制御が重要な役割を果たし、複数のトランザクションを同時に実行できるようにします。これにより、データの矛盾や破損を防ぐことができます。同時実行制御とは、特に共有リソースにアクセスする際のトランザクションの相互作用を管理するメカニズムを指します。分散データベース管理システム (D-DBMS) では、データが複数のノードに分散しているため、データ複製、ネットワークの遅延、一貫性の維持などの課題が生じ、同時実行制御の重要性がさらに高まります。 効率的にスケールする分散システムを設計する際、絶え間ない調整を避けることが重要になります。そのため、コンポーネントは他のコンポーネントの状態を継続的に確認できないため、前提を立てる必要があります。これらの前提は、「楽観的」または「悲観的」に分類できます。楽観的な前提は、楽観的同時実行制御 (OCC) の中心的な考え方で、競合は稀であると想定し、ロックを使わずにトランザクションを進行させ、競合が発生した際にのみ解決します。この手法は、分散環境でのスケーラビリティ向上に特に有効ですが、ACID 特性 (アトミック性、一貫性、分離性、耐久性) を維持するために、堅牢な競合検出と解決が必要です。一方、悲観的な前提は、悲観的同時性実行制御 (PCC) の基礎をなすもので、競合は一般的に発生すると想定し、トランザクション中にリソースにロックをかけて干渉を防ぎます。これにより一貫性は確保できますが、スケーラビリティとパフォーマンスが制限される可能性があります。OCC と PCC のどちらを選択するかは、早期の調整を避けて後で競合に対処するか、事前に全てのトランザクション競合を防ぐかによって決まります。 この記事では、効率的なトランザクションパターンを設計するための貴重な洞察を提供し、一般的な同時実行性の課題に対する効果的な解決策の例を示しながら、同時実行制御について深く掘り下げます。また、 サンプルコード を含め、 Amazon Aurora DSQL (DSQL) での同時実行性性制御の例外を滞りなく管理する方法を紹介します。 PCC または OCC を使用する場合 OCC と PCC のどちらを選択するかは、ワークロードとデータベース環境に合わせて慎重に検討する必要があります。 PCC は、ロック管理を最適化できる単一インスタンスのデータベースに適しています。同じ株価指標を継続的に更新するような、小さなキー範囲での頻繁な更新が行われる高競合シナリオで優れた性能を発揮します。この手法は単一インスタンスの RDBMS では効果的ですが、分散システムでは効果が低くなります。 一方、OCC は、リソースのロックを行わずにトランザクションを進行させ、コミット段階でのみ競合をチェックすることで、低競合環境で最も優れたパフォーマンスを発揮します。これにより、実行オーバーヘッドとブロッキングの遅延が削減され、競合が少ない、またはノンブロッキングの実行が重要なワークロードに適しています。OCC は高競合シナリオの管理がより複雑になる可能性がありますが、水平スケーリングの恩恵を受けるスケーラブルなキー範囲や追加のみの操作などの分散システムを効果的にサポートします。 Aurora DSQL のための OCC の利点 Aurora DSQL は楽観的同時実行制御を採用しています。これは、リレーショナルデータベースよりも非リレーショナルデータベースでよく使われる手法です。楽観的同時実行制御では、同じ行を更新しようとする他のトランザクションについてあまり考慮せずにトランザクションロジックを実行します。トランザクション完了時に、データベースへの変更をコミットしようとします。その際、Aurora DSQL は他の同時実行トランザクションからの書き込みが干渉していないかを確認します。干渉がなければトランザクションは正常にコミットされますが、干渉があった場合はデータベースがエラーを返します。このような場合、ユーザーは悲観的同時実行制御を使うデータベースと同様に、どのように処理を進めるかを決める必要があります。ほとんどのユースケースでは、トランザクションをリトライするのが最善のアプローチです。 Aurora DSQL では、クライアントの遅延や長時間実行されるクエリが他のトランザクションに影響を与えたり遅延させたりすることはありません。これは、SQL の実行中ではなく、コミット時にサーバー側で競合が処理されるためです。一方、ロッキングベースの設計では、クライアントがトランザクション開始時に行や全テーブルに排他ロックを取得します。クライアントが予期せず停止した場合、これらのロックが無期限に保持される可能性があり、他の操作がブロックされ、不定長の待ち行列が発生する可能性があります。対して、OCC では、即座に競合を通知し、確定的な結果を提供するため、即座にリトライやアボートができます。ロックベースのシステムでは通常、タイムアウト期間に達した後にのみリトライやキャンセルのロジックが実行されます。このため、Aurora DSQL は、特に AWS リージョン間にまたがる大規模な分散アプリケーションの構築時に発生する現実的な障害や故障に対してより堅牢です。 マルチリージョンクラスターでは、ユーザーがトランザクションを送信すると、SQL 操作がトランザクションが送信されたリージョン (リージョン 1) のローカルストレージで実行されます。トランザクションが完了すると、そのトランザクションに関与したキーとともに事後イメージが、別のリージョン (リージョン 2) に送信されます。リージョン 2 には、そのリージョンの現在の変更をすべて認識しているトランザクション処理リーダーがいます。リーダーはリージョン 1 から事後イメージとトランザクションに関与したキーのリストを受け取ると、それがリージョン内で現在アクティブに変更されているすべてのキーと競合していないかを確認します。競合がなければ、コミットの確認を送り返します。 競合がある場合、最初にコミットしたトランザクションが成功し、残りのトランザクションはリトライする必要があります。その結果、同時実行制御の競合が発生します。 Aurora DSQL は、マルチリージョンのアクティブ・アクティブ可用性を持つ組織のビジネス継続性を実現します。OCC は、同期レプリケーションを使用したマルチリージョンのトランザクションの効率を向上させます。Aurora DSQL は、リージョン間の通信なしにローカルでの読み取りおよび書き込みトランザクションを処理し、トランザクションのコミット要求時にのみリージョン間の整合性を確認します。OCC により、ロックの交渉が不要になるため、Aurora DSQL は完全な事後イメージを事前に処理し、マルチ AZ およびマルチリージョンの定足数に対してチェックできます。このアプローチにより、ロックのオーバーヘッドなしにトランザクションを処理できるため、アベイラビリティゾーンおよびリージョン間の同期トランザクションのレイテンシーが低減されます。 次の図は、マルチリージョンクラスター (アクティブ-アクティブ) を示しています。 楽観的同時実行制御とアイソレーションレベル 他の分散 SQL データベースがSerializable分離レベルをサポートするのに対し、Aurora DSQL は PostgreSQL の repeatable read 分離レベルに相当する強力なスナップショット分離をサポートしています。トランザクションは、開始時のデータベースのスナップショットからデータを読み取ります。これは読み取り専用のトランザクションに特に役立ちます。読み取り専用のトランザクションは待機する必要がなく、OCC の影響も受けにくいためです。 トランザクションパターンのガイダンス 同時に実行されるデータベーストランザクションが同じレコードを更新すると、コンフリクトのリスクがあります。適切なデータモデリングでこのリスクを低減できますが、コンフリクトは避けられません。開発者は、データベースの提供する同時実行管理機能を理解し、アプリケーションに効果的に実装する必要があります。 Aurora DSQL は楽観的同時実行制御を使用しているため、同一キーに対する高頻度の並行更新が発生するユースケースでは、プログラミングアプローチが異なる必要があります。作業が完了したら、トランザクションのコミットを試みます。Aurora DSQL は、他の更新トランザクションがあなたのトランザクションに干渉していないかを確認します。干渉がなければ、トランザクションは成功します。そうでなければ、データベースがエラーを報告します。その場合、すぐにトランザクションをリトライするか、エクスポネンシャルバックオフとジッターを導入して、後続の競合の可能性を減らすかを決める必要があります。 OCC は常にデータベースでのトランザクションの進行を支援しますが、高い競合状態では性能が低下する可能性があります。そのため、以下のようなトランザクションパターンのガイドラインに従うことをお勧めします: トランザクションが失敗する可能性があることを前提に、常にリトライできるようにトランザクションを設計してください 行レベルの競合やデータ更新の競合を最小限に抑えるため、各トランザクションにタイムアウトロジックを実装してください。設定するタイムアウト値は、不要なトランザクションのキャンセルを避けるため、最大クエリ時間を考慮する必要があります 競合が激しく、リトライ率が高い場合は、失敗したトランザクションが異なるランダムな間隔でリトライされるよう、エクスポネンシャルバックオフとジッターを実装してください 既存のキーに対する更新が多い (更新とアップサート) システムでは、競合の可能性を最小限に抑えるため、トランザクションの範囲を小さく保つことが重要です Aurora DSQL で OCC の例外が発生する可能性のあるいくつかのユースケースと、コード例を見ていきましょう。 例 1: リージョン間トランザクションでのデータ競合 Aurora DSQL などの分散 SQL システムでは、OCC 例外が発生する一般的なシナリオは、複数のリージョンが同じデータを同時に更新しようとする場合です。この例では、同じアカウントデータを操作する 2 つのリンクされたリージョン、 us-east-1 と us-east-2 を持つクラスターを想定しましょう。 「us-east-1」のトランザクション A では、アカウントの残高とバージョンを読み取り、更新の準備をしています 同時に、「us-east-2」のトランザクション B も同じアカウントの残高とバージョンを読み取り、自身の更新を行う準備をしています トランザクション B は、アカウントの残高を正常に更新し、バージョンをインクリメントしました その後、トランザクション A が古いバージョンを使って更新をコミットしようとすると、バージョンがトランザクション B によって更新されたため、OCC 例外が発生しました このシナリオは、異なるリージョンの同じデータに対する同時トランザクションが、OCC 例外につながる可能性を示しています。 それでは、コード例を使って詳しく見ていきましょう。 テーブルを作成し、レコードを挿入します: CREATE TABLE orders.accounts ( id int PRIMARY KEY, balance DECIMAL(10, 2), version INT NOT NULL ); INSERT INTO accounts (id, balance, version) VALUES (1, 100.00, 1); トランザクション A がアカウントの残高とバージョンを読み取ります: BEGIN ; SELECT id, balance, version FROM accounts WHERE id = 1 ; トランザクション B が同じデータを読み取り、更新し、バージョンをインクリメントします: BEGIN ; UPDATE accounts SET balance = balance + 50, version = version + 1 WHERE id = 1 AND version = 1 ; COMMIT ; トランザクション A が古いバージョンのアカウントを使って更新しようとすると、OCC 競合が発生します: UPDATE accounts SET balance = balance - 30, version = version + 1 WHERE id = 1 AND version = 1 ; commit ; この場合、トランザクション A は、バージョン番号がトランザクション B によって変更されたことをシミュレートした OCC 例外のため、失敗します。 ERROR: change conflicts with another transaction, please retry: (OC000) 実際に何が起きたのかの詳細を見ていきましょう。 トランザクション A は読み取り/書き込みトランザクションなので、読み取り段階では、クエリプロセッサーが SELECT を解析し、シャードマップを参照してこのデータを保持するストレージノードを特定し、それらのノードからデータを取得します。トランザクション B も読み取り/書き込みトランザクションで、クエリプロセッサーは UPDATE ステートメントの一部として、読み取りセットと書き込みセットを作成します。トランザクション B がコミットを発行すると、クエリプロセッサーは読み取りセットと書き込みセットをパッケージ化し、トランザクションプロセッサーに送信します。各トランザクションプロセッサーは、他のトランザクションによる読み取りセットの変更がないかを確認します。変更がなければ、事前イメージと事後イメージをコミットレイヤーに読み書きし、コミットを永続化し、バージョンは増分されません。トランザクション A が UPDATE ステートメントを発行します。クエリプロセッサーはすでに更新に必要なすべてのデータを持っているので、書き込みセットを作成し、読み取りセットと書き込みセットをトランザクションプロセッサーに渡します。読み取りセットのデータが変更されたため、トランザクションプロセッサーは変更を拒否し、OCC 例外を返します。この時点で、クライアントはトランザクション B による更新を含む同じトランザクションをリトライできます。 例 2: SELECT FOR UPDATE を使用したライトスキューの管理 前述のとおり、Aurora DSQL は通常、読み取ったレコードに対して同時実行性チェックを行いません。 SELECT FOR UPDATE はこの動作を変更し、読み取った行に同時実行性チェックのフラグを立てます。 これが Aurora DSQL でライトスキューを管理する方法です。 ライトスキューでは、2 つの同時トランザクションが共通のデータセットを読み取り、それぞれが共通のデータセットを変更する更新を行いますが、お互いに重複しません。重複がないため (同じデータを変更しないため)、同時実行性の保護は発動しません。 Aurora DSQL では、 FOR UPDATE 句により、フラグ付きの行に対する追加のチェックを行うことで、Optimistic Concurrency Control (OCC) の標準的な動作が変更されます。この調整により、トランザクション が同じデータセットに同時にアクセスする際に発生する可能性のある異常を防ぐことができます。ロック機構を使ってコンフリクトを管理する従来の Pessimistic Concurrency Control (PCC) とは異なり、OCC は潜在的な書き込みコンフリクトを別の方法で処理します。以下の例は、FOR UPDATE 句がこのコンテキストでどのように同時実行性チェックを強制するかを示しています。 この状況が実際に起こりうる例を見てみましょう。 最初に、 Orders テーブルを作成し、いくつかの行を挿入します: CREATE TABLE IF NOT EXISTS orders.orders ( order_id int PRIMARY KEY, customer_id INTEGER NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount NUMERIC(10, 2) ); INSERT INTO orders.orders (order_id, customer_id, order_date, total_amount) VALUES (1, 12, '2024-09-26 14:30:00', 99.99); INSERT INTO orders.orders (order_id, customer_id, order_date, total_amount) VALUES (2, 123, '2024-09-26 14:32:00', 99.99); 2. トランザクション A は、 FOR UPDATE 句を使用して読み取り/書き込みトランザクションを開始しますが、まだ更新を実行したり、コミットしていません: begin ; select order_id, customer_id, total_amount from orders.orders where order_id = 1 FOR UPDATE ; トランザクション B は独自の読み取り/書き込みトランザクションを開始し、コミットします: begin ; select order_id, customer_id, total_amount from orders.orders where order_id = 1 FOR UPDATE ; update orders.orders SET total_amount = 103 WHERE order_id = 1 ; commit ; 3. トランザクション A は、同じトランザクション内で accounts テーブルの更新を試みます: UPDATE orders.accounts SET balance = balance + 60, version = version + 1 WHERE id = 1 AND version = 1 ; commit ; 4. トランザクション A がコミットを発行すると、次の OCC 例外が発生します: ERROR: change conflicts with another transaction, please retry: (OC000) OCC 例外が発生しましたが、変更された読み取りセットを持っていた orders テーブルではなく、別のテーブルが更新されていました。 実際に何が起きたのかを詳しく見ていきましょう このシナリオでは、トランザクション A が order_id=1 の詳細を含む読み取りセットを作成します。一方、読み取り/書き込みトランザクションであるトランザクション B も同じ order_id を読み取りと更新します。その後、トランザクション A が accounts テーブルの残高を更新しようとすると、OCC エラー (OC000) が発生します。トランザクション A が開始されると、クエリプロセッサーは読み取りセットを作成し、コミットする前に書き込みセットを生成するのを待ちます。しかし、トランザクション A が進行中の間に、トランザクション B がトランザクション A の読み取りセットと同じ order_id を更新してコミットします。トランザクション A が accounts テーブルを更新しようとすると、クエリプロセッサーは書き込みセットを作成し、トランザクションプロセッサーによる検証のために読み取りセットと書き込みセットの両方を渡します。この段階で、トランザクションプロセッサーは読み取りセットのデータに新しいバージョンがあることを検知し、トランザクションを拒否し、トランザクション A にリトライを強制します。 この例では、Aurora DSQL でライトスキューを管理したい場合、for update を使うのが効率的な方法であることを示しました。 注意: FOR UPDATE は読み書きトランザクション内でのみ機能します。読み取り専用トランザクションで FOR UPDATE を使用しようとすると、警告が表示され、読み取られた行の更新は報告されません。 postgres=# commit ; WARNING: SELECT FOR UPDATE in a read-only transaction is a no-op COMMIT また、SELECT FOR UPDATE フィルターには、選択するテーブルのプライマリーキーを含める必要があります。今回の場合、orders テーブルのプライマリーキーは order_id なので、この SELECT FOR UPDATE は失敗します。 postgres=> select customer_id from orders where orders.customer_id=123 for update ; ERROR: locking clause such as FOR UPDATE can be applied only on tables with equality predicates on the key しかし、このクエリは主キーを含むフィルターが設定されているため、成功します。 postgres=> begin ; BEGIN postgres=> select customer_id from orders where orders.customer_id=123 and order_id=2 for update ; customer_id 123 (1 row) 例 3: カタログの同期が取れていない例外 データ競合は OCC 例外の主な原因ですが、カタログの同期が取れていない問題も、これらのエラーをトリガーする可能性があります。これらのエラーは、アクティブなセッション中に、テーブルの作成や変更などのデータベーススキーマの変更が行われた際に発生します。例えば、1 つのトランザクションがテーブルを作成している間に、別のトランザクションがそのテーブルの読み取りや書き込みを試みると、セッションのカタログ情報が古くなっているため、OCC エラー (OC001 など) が発生する可能性があります。 操作をリトライすると、初期の失敗後にデータベースカタログが更新されるため、問題が解決されることが多いです。本番環境でこのようなエラーのリスクを最小限に抑えるには、マルチスレッド方式で DDL 操作を行うのは避けることをお勧めします。同時並行のスキーマ変更は、競合状態、トランザクションの失敗、ロールバックの原因となる可能性があります。制御された単一スレッドの環境で DDL 変更を管理することで、競合の問題を軽減し、データベース操作をより滑らかに行うことができます。 これが実際にどのように起こるかの具体例を見てみましょう。 トランザクション A によってテーブルが作成されます: CREATE TABLE orders.accounts ( id INT PRIMARY KEY, balance int, version int ); 既にセッションを開いているトランザクション B が、テーブルにレコードを書き込もうとすると: insert into orders.accounts VALUES (1, 10, 1); postgres=*> insert into orders.accounts VALUES (1, 10, 1); ERROR: schema has been updated by another transaction, please retry: (OC001) LINE 1: insert into orders.accounts VALUES (1, 10, 1); この例では、トランザクション A がテーブルを作成し、トランザクション B が同じテーブルにレコードを書き込もうとしますが、OCC エラーが発生します。しかし、その後のリトライは成功します。 以下は、OCC 例外 (OC001) に遭遇する可能性のある他のいくつかのシナリオで、通常はリトライで解決できます: トランザクション A が既存のテーブルにカラムを追加している間、トランザクション B がそのテーブルから読み取りまたは書き込みを試みると、OCC 例外が発生します。 トランザクション A がテーブルをドロップし、トランザクション B がその後同じテーブルにアクセスしようとします。 トランザクション A がテーブルにカラムを追加し、トランザクション B が同時に別の名前のカラムを追加しようとします。 進行中のトランザクションと競合するカタログの変更。 要約すると、OCC 例外 (OC001) は、データベーススキーマやカタログの変更が同時に行われることが原因で発生することが多いですが、適切なリトライメカニズムを実装することで、一般的に解決できます。 OCC 例外のリトライメカニズムによる処理 OCC では、トランザクションの競合時にリトライを管理するためのベストプラクティスとして、バックオフとジッターの実装が重要です。これにより、同期的なリトライによる更なる競合や、システムの過負荷を回避できます。バックオフにより、競合後のリトライが即座ではなく、徐々に長くなる遅延を設けることで、システムの負荷を軽減できます。ジッターは、これらの遅延にランダム性を導入します。バックオフとジッターを組み合わせることで、OCC を採用する分散システムにおけるコンテンション問題を軽減し、リトライロジックの効率を高めることができます。詳細については、 Exponential Backoff And Jitter を参照してください。以下のコードサンプルは、 このリポジトリ から入手できます。 高トランザクション環境で OCC の例外をシミュレーションし、バックオフとジッター戦略を使ってリトライを管理するシナリオを見ていきましょう。 まず、 create.py スクリプトを使用して、注文スキーマと accounts および orders の 2 つのテーブルを作成します python create.py --host --database postgres --user --region --schema orders load_generator.py スクリプトを実行 して、データベースにロードを生成し、 orders テーブルにデータを挿入します python load_generator.py --host --database postgres --user --region --schema orders --tablename orders --threads 10 OCC 条件を導入するために、別の PostgreSQL セッションで accounts テーブルを変更し、新しい列を追加します ALTER TABLE order.accounts ADD COLUMN balance INT ; スキーマが更新された後、 load_generator.py スクリプトは次のエラーで失敗します Error during insert: schema has been updated by another transaction, please retry: (OC001) 次に、 retry_backoff_jitter.py スクリプトを実行して、組み込みのリトライメカニズムを使用した load_generator.py スクリプトの拡張版を実行し、バックオフとジッターを統合します。 python retry_backoff_jitter.py --host --database postgres --user --region --schema orders --tablename orders --threads 10 accounts テーブルに別のスキーマ変更を加えます ALTER TABLE order.accounts ADD COLUMN totalsale INT ; リトライロジックが発動すると、スクリプトが OCC 例外をリトライで処理しているのが確認できます Error during batch insert: schema has been updated by another transaction, please retry: (OC001), retrying in 2.11 seconds (attempt 1/5) Error during batch insert: schema has been updated by another transaction, please retry: (OC001), retrying in 2.03 seconds (attempt 2/5) リトライ戦略に応じて、この値を微調整することができます。この場合、遅延時間の単位は秒になります。 分散システムでの OCC 例外の効果的な管理には、バックオフとジッターを組み込むことができる包括的なリトライ戦略が必要です。アプリケーションのキースペースの高コンテンション領域 (ホットキー) を避けられない場合でも、予測可能性を確保し、スループットを最大化し、高コンテンション率 (ホットキー) を示す負荷領域の安定性を高めることができます。リトライロジックに加えて、更新インプレースではなく追加のみのパターンを好むことで、最初からコンテンションを最小限に抑えることが重要です。ほとんどの最新のアプリケーション設計と Aurora DSQL などの分散データベースは、既存のキーを更新するのではなく新しいキーを導入することで、最適なシステムのスケーラビリティを実現できます。さらに、冪等性を実装することで、リトライによる重複操作や データ不整合を防ぐことができ、永続的な障害に対するデッドレターキューを設けることで、エスカレーションと手動による介入を可能にし、システムの信頼性をさらに高めることができます。 結論 同時実行制御は、あらゆるデータベース管理システムにとって重要な側面であり、分散データベースを扱う際にはさらに重要になります。Aurora DSQL で OCC を使用することは、分散アーキテクチャのため適切です。トランザクション実行中にリソースロックを必要としないため、スループットとシステム効率が向上します。 Aurora DSQL における OCC の主な利点は次のとおりです: 遅いクライアントや長時間実行クエリに対するレジリエンス – OCC では、コンテンション処理がクエリ実行中ではなくコミット段階で行われるため、1 つの遅いトランザクションが他のトランザクションに影響を与えたり遅延させたりすることはありません。 スケーラブルなクエリ処理 – Aurora DSQL の逆方向検証アプローチは、現在のトランザクションをコミット済みのトランザクションと比較するため、コーディネーションなしにクエリプロセッサーレイヤーをスケールアウトできます。 現実的な障害に対するロバスト性 – OCC により、Aurora DSQL はデッドロックやパフォーマンスボトルネックを引き起こす可能性のあるロック機構に依存しないため、大規模な分散アプリケーションを構築する際の障害やエラーに対してより強靭になります。 OCC には大きな利点がありますが、最適なパフォーマンスを得るには、トランザクションパターンを慎重に検討する必要があります。トランザクションが失敗する可能性があることを前提とし、タイムアウトと ジッター を伴うエクスポネンシャルバックオフを実装し、 SELECT FOR UPDATE を使ってライトスキューを管理するといった原則は、Aurora DSQL を使う開発者にとって重要なガイドラインです。 Aurora DSQL の同時実行制御メカニズムとベストプラクティスを理解することで、複雑で高トランザクションの負荷がかかる環境でも、データの整合性と可用性を維持しながら、システムの分散機能を活用できます。Aurora DSQL の詳細については、 ドキュメントをご覧ください 。 著者について Rajesh Kantamani は、シニア データベース スペシャリスト SA です。彼は、Amazon Web Services 上でデータベース ソリューションの設計、移行、最適化を支援し、スケーラビリティ、セキュリティ、パフォーマンスを確保することに特化しています。余暇には、家族や友人と屋外で過ごすことが好きです。 Prasad Matkar は、EMEA 地域を担当する AWS のデータベース専門ソリューションアーキテクトです。関係データベースエンジンに焦点を当て、AWS へのデータベースワークロードの移行とモダナイゼーションについて、お客様に技術的なサポートを提供しています。

リレーショナルデータベースは、マイクロサービス、ウェブサイト、モバイルバックエンド、SaaS アプリケーションなど、さまざまなアプリケーションやサービスの強力で柔軟な構成要素です。10 年前、私たちは Amazon Aurora を立ち上げ、商用データベースの 1/10 のコストで、MySQL および PostgreSQL との完全な互換性を持つ、並外れた高パフォーマンスと可用性を提供しました。お客様から、管理が容易で、ワークロードに合わせてスケールアップ・ダウンでき、マルチリージョンやマルチ AZ の高可用性アーキテクチャの構築が簡単なリレーショナルデータベースを求める声が寄せられています。 本日、私たちは常時利用可能なアプリケーションに最適な、最速のサーバーレス分散 SQL データベース「Amazon Aurora DSQL」をご紹介します。Aurora DSQL は、事実上無限のスケーラビリティ、最高の可用性、そしてインフラストラクチャ管理ゼロを提供します。ワークロードの需要に合わせて、データベースのシャーディングやインスタンスのアップグレードなしにスケーリングできます。革新的なアクティブ・アクティブの分散アーキテクチャにより、シングルリージョン構成で 99.99%、マルチリージョン構成で 99.999% の可用性を実現し、高可用性アプリケーションの構築に最適です。サーバーレスの設計により、パッチ適用、アップグレード、メンテナンスダウンタイムなどの運用負荷が不要になります。Aurora DSQL は PostgreSQL 互換であり、開発者は既知のリレーショナルデータベースの概念、ドライバー、ツール、フレームワークを使ってアプリケーションを迅速に構築・デプロイできます。 この記事では、Aurora DSQL の利点と始め方について説明します。 Aurora DSQL アーキテクチャと利点 Aurora DSQL は、コンポーネントの障害やアベイラビリティゾーン (AZ) の中断に対応できるシングルリージョン構成と、データの処理と保存の場所を完全に制御できるマルチリージョン構成の 2 つの構成で実行するように設計されています。独自の分離されたアクティブ・アクティブ・アーキテクチャにより、フェイルオーバーやスイッチオーバーによるダウンタイムがなくなるため、高可用性とビジネス継続性を簡単に設計できます。 Aurora DSQL は、3 つの AZ にわたるアクティブ・アクティブ構成のシングルリージョンクラスターを提供します。これにより、レプリケーションラグや従来のデータベースフェイルオーバー操作を最小限に抑えることができます。ハードウェアやインフラストラクチャの障害が発生した場合、手動操作なしで健全なインフラストラクチャにリクエストを自動的にルーティングします。Aurora DSQL のトランザクションは、マルチリージョンでも遅延の影響を最小限に抑えつつ、ACID (Atomicity、Consistency、Isolation、Durability) プロパティ全てを提供します。強力なスナップショット分離を実装し、クラスターエンドポイントへの読み書きに対して強力なデータ整合性を提供します。 次の図は、単一リージョンにおける Aurora DSQL の高可用性クラスタートポロジーを示しています。 シングルリージョン構成では、Aurora DSQL はすべての書き込みトランザクションを分散トランザクションログにコミットし、コミットされたログデータを 3 つの AZ にある ユーザーストレージレプリカに同期的に複製します。クラスターストレージレプリカは、最適なデータベースパフォーマンスのためにストレージフリートに分散されています。Aurora DSQL は、自動でのフェイルオーバーリカバリが設計されています。コンポーネントや AZ に障害が発生した場合、健全なコンポーネントにアクセスを自動的に切り替え、非同期でレプリカを修復します。障害が発生したレプリカが復元されると、Aurora DSQL は自動的にそれらをストレージクォーラムに追加し、クラスターで利用可能にします。 Aurora DSQL は、アプリケーションに最高の耐障害性が必要な場合に、99.999% のマルチリージョン可用性を提供します。 マルチリージョンクラスターは、シングルリージョンクラスターと同じ耐障害性と接続性を提供しつつ、2 つのリージョン エンドポイントを通じて可用性を向上させます。リンクされたクラスターの両方のエンドポイントは、単一の論理データベースを表し、強力なデータ整合性を持つ同時読み書き操作をサポートします。これにより、地理的な場所、パフォーマンス、または耐障害性の目的に応じて、アプリケーションと接続のバランスを取ることができ、読み取り側が常に同じデータを確実に見ることができます。 次の図は、Aurora DSQL マルチリージョンクラスターを使用したアプリケーションのアーキテクチャを示しています。 マルチリージョンクラスターを作成すると、Aurora DSQL は別のリージョンにもう 1 つクラスターを作成し、それらをリンクします。リンクされたリージョンを追加することで、コミットされたトランザクションからの変更がすべて他のリンクされたリージョンに確実に複製されます。各リンクされたクラスターにはリージョンエンドポイントがあり、Aurora DSQL はリージョン間で同期的に書き込みを複製するため、リンクされたクラスターのどこからでも強い整合性のある読み書きが可能です。 第 3 のリージョンがウィットネスリージョンとして機能します。ウィットネスリージョンは、リンクされたクラスターに書き込まれたデータを受け取りますが、クラスターや関連エンドポイントは持ちません。暗号化されたトランザクションログの限定的なウィンドウを保存し、Aurora DSQL がマルチリージョンの耐久性と可用性を提供するために使用されます。 その他の Aurora DSQL 機能 Aurora DSQL は、あらゆる負荷に対応できる事実上無制限のスケールを提供します。クエリ処理層、コミット層、ストレージ層がそれぞれ独立してスケーリングし、読み取り/書き込み比、データサイズ、クエリの複雑さなど、さまざまな特性のワークロードに適応します。つまり、ビジネスの成長に伴いデータベースの性能を維持する必要がなくなるため、開発者は次の重要な機能の開発に集中できます。 開発者は単一の API コールで新しいクラスターを素早く作成し、数分で PostgreSQL と互換性のあるデータベースの使用を開始できます。多くの一般的な PostgreSQL ドライバーやツール、ACID トランザクション、SQL クエリ、セカンダリインデックス、結合、挿入、更新などの基本的なリレーショナル機能をサポートしています。 Aurora DSQL は、シンプルな宣言型のプライバシーとセキュリティ制御、および AWS Identity and Access Management (IAM) と AWS CloudTrail との完全な統合により、セキュリティ体制を強化します。ユーザーのパスワードベースの認証をブロックしつつ、 PostgreSQL ワイヤープロトコル の互換性は維持しています。IAM を使用したトークンベースの認証をサポートし、 AWS Command Line Interface (AWS CLI) と AWS SDK でトークン生成のヘルパー関数を提供しています。 従来のデータベースとは異なり、Aurora DSQL は、従来のロック方式ではなく、楽観的同時性制御 (OCC) を使用しています。スケールアウトするにつれ、OCC により、長時間のトランザクションが他の実行中のトランザクションを遅らせることはありません。Aurora DSQL における OCC の詳細については、 Amazon Aurora DSQL の同時性制御 を参照してください。 結論 Aurora DSQL を使えば、強力な一貫性を持つレジリエントなアプリケーションを簡単に構築できます。これにより、規制上の課題に対応でき、アプリケーションのダウンタイムやデータ損失を気にする必要がありません。革新的な機能を活用すれば、データ管理とアプリケーションのスケーラビリティに新しいアプローチを取ることができます。 プレビューで利用可能になった Aurora DSQL を、ぜひ体験してみてください。 Aurora DSQL コンソール にアクセスするか、 プログラムからアクセスする ための AWS CLI や AWS SDK を使用してください。 詳しくは、 Aurora DSQL の概要 ページをご覧いただくか、詳細情報については包括的な ユーザーガイド をご参照ください。 著者について Raluca Constantin は、AWS 分散 SQL データベースチームのシニアデータベースエンジニアです。 Arun Sankaranarayanan は、ロンドン拠点のデータベース専門ソリューションアーキテクトです。

12 月 1 日、 Amazon Connect は、 生成 AI 、高度なセキュリティ機能、および効率的なボット管理を通じて、企業がコンタクトセンターの運用を強化するのに役立つ一連の新機能を導入しました。これらのイノベーションは、セキュリティとコンプライアンスを維持しながら、有意義な人間とのやり取りのための時間とスペースを増やすことで、企業がより良い顧客体験を提供するのに役立ちます。 コンタクトセンターのマネージャーは、セルフサービスの解決率の最適化、エージェントのパフォーマンスの効率的な評価、およびデータプライバシーコンプライアンスの維持において、常に課題に直面しています。さらに、会話型 AI エクスペリエンスの作成と管理には、多くの場合、専門的な専門知識と複数のサービスにわたる複雑な統合が必要です。 これらの課題に対処するために、Amazon Connect は、ターゲットを絞ったキャンペーンのための生成 AI を活用した顧客セグメンテーション、オムニチャネル サポートのためのネイティブ WhatsApp ビジネス メッセージング、チャット インタラクションにおけるセキュアな顧客データの収集、Amazon Connect インターフェースにおける簡素化された会話型 AI ボット管理、 Amazon Q in Connect の新たな機能強化などの主要機能を導入しました。Amazon Connect では、 Amazon Connect Contact Lens による新しい分析機能も追加され、ボットのパフォーマンスとコンタクトセンターの運用を最適化できるようになりました。 ここでは、最高水準のデータセキュリティとオペレーショナルエクセレンスを維持しながら、よりパーソナライズされた効率的なカスタマーエクスペリエンスを実現するのに役立つ新機能を紹介します。 生成 AI 搭載機能 Amazon Connect は、新しい生成 AI 機能を統合して顧客との対話を自動化および強化し、よりスマートなターゲティングとより効率的なコンタクトセンター管理を可能にします。 生成 AI セグメンテーションとトリガーベースのキャンペーン – 生成 AI を利用した支援を使用して、会話プロンプトを使用して お客様セグメント を作成します。これにより、企業は自然言語による説明を使用して正確な顧客セグメントを作成できるため、特定の顧客グループを簡単に特定してリーチできます。トリガーキャンペーンにより、組織はカート放棄などの特定の顧客イベントに基づいて顧客とコミュニケーションをとることができます。 すぐに使える提案から始めることもできます。 会話型 AI ボットの作成を簡素化し、Amazon Q in Connect で強化しましょう– Amazon Lex を搭載した会話型 AI ボットを Amazon Connect ウェブインターフェイス内で直接作成、編集、管理できます。これらのボットは、カスタマーサービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect で強化できるようになりました。Amazon Q in Connect は、コンタクトセンターのエージェントが推奨応答やアクションを行うのを支援することに加えて、自動音声応答 (IVR) とデジタルチャネルにわたるエンドカスタマーのセルフサービスインタラクションをサポートするようになりました。 この統合は、大規模言語モデル (LLM) による高度な会話機能を提供することで、従来の音声およびチャットボットの Amazon Lex 機能を超えています。システムは、設定済みのナレッジベース、顧客情報、ウェブコンテンツ、およびサードパーティのアプリケーションデータをインテリジェントに検索して、事前定義された意図と一致しない顧客の質問に回答します。管理者はインスタンスにカスタムガードレールを設定して、応答生成の制限を定義し、 Amazon Q in Connect のパフォーマンスを監視できます。 生成 AI による自動評価: スーパーバイザーは、生成 AI を使用して連絡先の最大 100% を自動的に評価できます。 生成 AI による連絡先分類: 自然言語インテントを使用して既存のセマンティックマッチ機能を改善します。 インターフェースとツールの改良 ボットの管理と監視の機能が強化され、自動エクスペリエンスの作成と最適化が簡単になりました。 WhatsApp ビジネス メッセージング用の Amazon Connect – WhatsApp ビジネス メッセージングとネイティブに統合されているため、顧客は音声、SMS、チャット、ビジネス向け Apple メッセージなどの既存 の Amazon Connect チャネル に加えて、 WhatsApp 経由でサポートを受けることができます。Amazon Connect のオムニチャネル機能に加えて、企業は Amazon Connect アプリケーション内で一貫したサービスの提供と管理を維持しながら、希望するコミュニケーションチャネルで顧客と会うことができます。 コンタクトレンズの会話型 AI ボットダッシュボード — Amazon Connect に組み込まれた会話 AI ボットのパフォーマンスをモニタリングするための分析を提供します。 連絡先の詳細に関するセルフサービス音声 (IVR) 録音と対話ログ — 音声録音を含むセルフサービス対話の包括的な記録を提供します。 日中予測の改善 — 日中の予測を以前に公開された予測と比較できます。 Amazon Connect 付きセールスフォースコンタクトセンター (プレビュー) — Amazon Connect のデジタルチャネルとユニファイドルーティングを Salesforce カスタマーリレーションシップマネジメント (CRM) システムにネイティブに統合します。 この新しいサービスにより 、企業は Amazon Connect と Salesforce チャネルの両方に単一のルーティングおよびワークフローシステムを使用できるようになり、通話、チャット、ケースを適切なセルフサービスまたはエージェントインタラクションにインテリジェントに転送できます。興味があれば、 サインアップしてプレビューに参加してください 。 チャットのセキュリティ強化 チャットインタラクションのセキュリティとコンプライアンスを強化し、機密情報の安全な処理を可能にする新機能。 チャット内の機密顧客データの収集 — Amazon Connect のチャットとメッセージングには 、チャットでのやり取り中に機密性の高い顧客情報を安全に処理できるデータプライバシーオプションが含まれるようになりました。この機能は、個人を特定できる情報 (PII) とペイメントカード業界 (PCI) のデータを保護し、データ保護規制の遵守を促進します。 主なメリット Amazon Connect の最新機能は、生成 AI、強化されたセキュリティ、および合理化されたボット管理を組み合わせて、企業を支援します: カスタマーエクスペリエンスの変革 — Amazon Connect は AI を活用したセグメンテーションを通じて顧客とのやりとりを向上させ、パーソナライズされたエンゲージメント戦略を可能にします。WhatsApp Business の新しいメッセージングは、オムニチャネルサポート機能を拡張し、顧客が希望するチャネルで対応できるようにします。さらに、Amazon Q in Connect などの高度なボット機能により、セルフサービスの解決率が向上し、より効率的なカスタマーエクスペリエンスが実現します。 セキュリティと運用の強化 — コンタクトセンターは、業務効率を維持しながら、PCI 準拠のチャットインタラクションでセキュリティ体制を強化できるようになりました。カスタム AI ガードレールは適切な回答の生成を促進し、シンプルなボット管理インターフェースにより専門知識が不要になります。分析および予測機能により、包括的なパフォーマンスモニタリングが可能になり、データ主導の意思決定が可能になり、コンタクトセンターの最適な運営が可能になります。 価格と提供状況 — これらの機能は現在、 Amazon Connect がサポートされているすべての AWS リージョンでご利用いただけます 。価格については、 Amazon Connect 料金表をご覧ください。 実装ガイダンスについては、 Amazon Connect のドキュメントを参照してください 。 – Eli 原文は こちら です。

本記事は 2024 年 11 月 13 日に AWS for Industries で公開された “ Create frictionless retail experiences with Just Walk Out RFID lanes ” を翻訳したものです。 本日、 Amazon Just Walk Out は、小売業者が 1 日程度で店舗に RFID チェックアウト機能を追加できる新しい RFID レーンを発表しました。急速に変化する小売環境において、従来の POS システムはボトルネックの原因となり、チェックアウトに時間がかかり、スタジアムやコンサート会場のような人通りの多い場所ではスタッフの非効率的な使用につながります。Just Walk Out RFID レーンは、迅速でスムーズなチェックアウトソリューションを提供することで、こうした課題に対応します。これらのレーンは、既存のシステムにシームレスに統合され、あらゆる規模のスペースに適応し、店舗レイアウトの再構成の柔軟性を高めるように設計されています。さまざまな決済プロバイダーと統合し、運営の人件費を削減することで、最終的に全体的な買い物体験を向上させます。Just Walk Out RFID レーンは、より迅速なチェックアウト時間とより効率的な運営を可能にすることで、小売業者や会場運営者のビジネスを変革するのに役立ちます。 RFID レーンのセットアップと購入を説明する 30 秒のビデオ 顧客からのフィードバック 「この技術は、レジ待ちを無くし、ファン体験を劇的に向上させました。また、次のシーズンの前に、在庫管理機能のために会場全体で RFID タグを導入することも楽しみにしています。これは、スムーズなチェックアウトを実現することと同じくらい、あるいはそれ以上に大きな機会です。」 — Miami Dolphins, Hard Rock Stadium & Formula 1 Crypto.com Miami Grand Prix リテール・オペレーションズ・シニア・マネージャー ローレン・ガーリー Just Walk Out RFID レーン：ユースケースと利点 混雑エリアの管理と繁忙時間帯の混雑軽減は、多くの小売業者にとって課題です。パイロット実験では、Just Walk Out RFID レーンが従来の POS システムと比較して最大 4 倍速いチェックアウトスピードを実現し、ペースの速い環境やスポーツイベント、コンサートに理想的であることが示されました。また、パイロット顧客は店舗運営に必要な労働力を 40% 削減し、棚卸しにかかる時間を 96% 短縮しました。Just Walk Out RFID レーンは、小売業者や会場運営者が、大規模イベント時に大勢の群衆を効率的に処理できるダイナミックな買い物環境を作り出す力を与えます。例えば、会場運営者はコンサートやハーフタイム中にアリーナやスタジアムでの待ち時間を迅速に短縮し、商品購入をスムーズにすることで、ファンにとってよりスムーズで効率的な買い物体験を確保します。同様に、商品やアパレルの小売業者はブラックフライデーや年末セールなどのピーク時の買い物期間に、レジでのボトルネックや長い行列を最小限に抑えて、より効果的に対処できます。Just Walk Out RFID レーンにより、小売業者や会場運営者はあらゆる規模の店舗をサポートし、未使用のスペースを素早く恒久的または一時的な小売拠点 (ポップアップショップや季節限定イベントなど) に変えることができる柔軟性を得られます。これらの RFID レーンは迅速な設置と容易な再配置が可能なように設計されており、以下のような主要なメリットをもたらします： 機動性 ：RFID レーンを簡単に再構成し、一時的または恒久的な配置で柔軟なレイアウトを実現。 柔軟性 ：様々な支払い方法、POS システム、ロイヤルティプログラムと統合可能。 正確性 ：棚卸しに必要な労力を削減。 汎用性 ：従来のチェックアウトシステムと組み合わせたり、単独の POS として独立して運用可能。 RFID 技術とは何か、そしてどのように機能するのか？ RFID は、電波を介してアイテムの識別、分類、追跡を可能にすることで、非接触型の小売体験を実現する技術です。このプロセスは、RFID タグとレーンからなる二部構成のシステムを通じて動作し、各タグにはデータを保存し送信するマイクロチップが含まれています。RFID タグが RFID レーンの範囲内にある場合、マイクロチップはタグ上のデータをレーンに送信します。各タグは固有の番号で応答し、レーンがそれを受信して解読します。タグからのデータは処理された後、ホストシステムに送られます。リーダーとタグの間のこのデータ交換は高速かつ効率的で、ミリ秒単位で行われます。 Just Walk Out は RFID タグを提供するためにエイブリィ・デニソン社と提携しています。エイブリィ・デニソン社は業界で最も包括的な高性能・高品質の RFID 製品ポートフォリオを提供しており、迅速な導入のための標準サイズとフォーマットのオプション、UPC 統合ソリューション、補助的なハングタグと粘着ラベル、ブランド付きや装飾されたハングタグ、幅広いサイズオプション、そして ARC 認証やその他のユースケース仕様を満たす様々なインレイオプションなどが含まれます。 Just Walk Out は、レーンハードウェア、タグプリンター、タグ印刷 UI、また店舗での作業で必要な工具類を提供します。電源と接続性を用意すれば、商品にタグを付けるだけです。Just Walk Out RFID レーンにより、小売業者は自社のエコシステムに統合することができ、Just Walk Out のデータを主要な POS や ERP システム、ロイヤルティプログラム、柔軟な決済プロバイダーと同期させることができます。Just Walk Out は、データが自動的にあなたのシステムに流れ込むことを確保し、これにより分析や在庫管理において既存のプロセスを継続して使用することができます。 Just Walk Out RFID レーンがあなたのビジネスに与える影響を学ぶ Just Walk Out は、お客様のために革新を続け、柔軟で適応性の高いソリューションによってあなたのビジネスを変革することをより容易にしています。あらゆるスペースにシームレスに統合し、変化するニーズに迅速に対応する能力を持つ Just Walk Out RFID レーンは、多様な小売環境を管理するための汎用的なアプローチを提供します。Just Walk Out RFID レーンについてさらに詳しく知り、このソリューションについて理解を深めるには、 Just Walk Out ビジネス開発チームにお問い合わせください 。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。 Mouni R. Mouni R. は AWS の製品管理 (技術) シニアマネージャーです。彼は、店内での買い物客と店舗管理者の体験を作り出す Just Walk Out 製品・設計チームを率いています。彼のチームは、コンピュータビジョンと RFID 技術を活用して、スムーズな買い物体験と店舗運営体験を可能にしています。

みなさま、AWS re:Invent 2024 はお楽しみいただけましたでしょうか。 2024 年 12 月 6 日に実施した [AWS Black Belt Online Seminar] AWS re:Invent 2024 速報 の資料及び動画についてご案内させて頂きます。動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画へのリンクは「  AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「  AWS Black Belt Online Seminar の Playlist  」をご覧ください。 AWS re:Invent 2024 速報 AWS re:Invent 2024 で発表されたばかりの新サービス、新機能を 1 時間に凝縮して一挙紹介！ 資料（  PDF  ） | 動画（  YouTube  ） 対象者 AWS に興味をお持ちのすべての方 AWS re:Invent 2024 を見逃してしまった方、振り返りたい方 日本語でわかりやすく新サービス、新機能の概要を知りたい方 本 BlackBelt で学習できること AWS re:Invent 2024 で発表されたばかりの新サービス、新機能 スピーカー 小林 正人 ( Kobayashi Masato ) Solutions Architect また、併せて以下のイベントへ是非ご参加ください。 AWS re:Invent 2024 re:Cap – Keynote 編 〜AWS re:Invent キーノートの主要メッセージ、新サービス、アップデートをご紹介〜 2024 年 12 月 17 日（火）、19 日（木）、20 日（金） 登録はこちら AWS re:Invent Recap – インダストリー編 〜AWS の最新アップデートをインダストリー別にご紹介〜 2025 年 1 月 28 日（火）〜 登録はこちら AWS re:Invent Recap – ソリューション編 〜AWS の最新アップデートをソリューション別にご紹介〜 2025 年 2 月 4 日（火）〜 登録はこちら 本 BlackBelt を通じて、みなさまが深堀りしたいと思えるサービスが見つかり、より詳細にその機能やメリットを調べていただくきっかけとなれば幸いです。 また、毎週のアップデートをまとめている 週刊 AWS も公開される予定ですので楽しみにお待ち下さい！

12 月 1 日、 AWS Security Incident Response を発表しました。これは、企業がセキュリティイベントを迅速かつ効果的に管理できるように設計された新しいサービスです。このサービスは、お客様がアカウントの乗っ取り、データ侵害、ランサムウェア攻撃など、さまざまなセキュリティイベントに備え、対応し、復旧できるようにすることを目的としています。 セキュリティ インシデント対応は、 Amazon GuardDuty と、 AWS Security Hub を介した統合されたサードパーティの脅威検出ツールからのセキュリティ検出結果のトリアージと調査を自動化します。コミュニケーションと調整が容易になり、セキュリティイベント中に支援できる AWS カスタマーインシデント対応チーム (CIRT) のセキュリティ専門家に 24 時間 365 日連絡できます。このサービスは、準備から検出、分析、復旧まで、インシデント対応ライフサイクルの各段階にわたって、より包括的なサポートをお客様に提供することを目的としています。 セキュリティイベントは、お客様にとってますます広範囲に及び、複雑になっています。セキュリティチームは毎日、膨大な数のアラートに直面することが多く、リソースの優先順位が間違っていたり、効果が低下したりする可能性があります。検出結果を手動で調査すると、リソースに負担がかかり、顧客が重要なセキュリティアラートを見落とす可能性があります。さらに、複数の利害関係者による対応の調整、さまざまな環境での権限の管理、およびアクションの文書化は、プロセスを複雑にします。お客様へのサポートを強化し、セキュリティイベント中にお客様が直面する、差別化されていないさまざまな面倒な点を取り除く機会があります。 主な機能 AWS Security Incident Response は、お客様がセキュリティイベントに効果的に備え、対応し、復旧できるよう支援する 3 つの主要機能を通じてこれらの課題に対処します: セキュリティ インシデント対応では、セキュリティ ハブを介して GuardDuty のセキュリティ検出結果とサポートされているサードパーティ ツールを自動的に優先順位付けし、即時対応が必要な優先度の高いインシデントを特定します。このサービスは、自動化とお客様固有の情報を使用して、予想される行動に基づいてセキュリティ検出結果をフィルタリングおよび抑制し、チームが重要なセキュリティアラートに集中できるようにします。 このサービスは、事前設定された通知ルールと権限設定を提供することで、インシデント対応を簡素化します。これらの設定は、サードパーティのセキュリティプロバイダーを含む社内外の利害関係者に適用できます。お客様は、メッセージング、安全なデータ転送、ビデオ会議のスケジュール設定などの統合機能を備えた集中コンソールにアクセスでき、すべてサービス API または AWS マネジメントコンソール からアクセスできます。その他の機能には、ケース履歴の自動追跡とレポート機能があり、セキュリティチームは修復と復旧作業に集中できます。 お客様は、セルフサービスの調査ツールと AWS CIRT による年中無休のサポートを利用できます。また、お客様はインシデントを個別に処理することも、サードパーティのセキュリティベンダーと相互運用することもできます。これらのオプションにより、お客様は特定のニーズと要件に基づいてインシデント対応を選択、管理、実施できます。 コア機能に加えて、お客様は、セキュリティインシデント対応のパフォーマンスを長期的に測定、監視、および改善するのに役立つメトリックを備えたサービスダッシュボードの恩恵を受けます。これらの指標には、平均解決時間 (MTTR)、特定期間内のアクティブなケースとクローズされたケースの数、トリアージされた検出結果の数、およびその他の主要業績評価指標が含まれます。お客様は、情報を照合したり、1 回限りのレポートを作成したりしなくても、これらの指標にすぐにアクセスできます。 開始方法 オンボーディングプロセスはいくつかのステップで完了できます。セキュリティインシデントレスポンスは AWS Organizations と統合され、セキュリティレイヤーを追加して、現在および将来のアカウントに包括的なセキュリティを提供します。お客様はまず、組織内の中央アカウントを選択します。このアカウントでは、すべてのアクティブおよび過去のセキュリティイベントを作成および管理できます。 次に、お客様はプロアクティブなインシデント対応機能を有効にできます。これにより、セキュリティ インシデント対応がセキュリティ ハブを通じて GuardDuty やサードパーティの検出ツールからの検出結果を監視および調査できるようにするサービス レベルの権限が作成されます。これらの検出結果は、サービス自動化と、一般的な IP アドレス、 AWS ID およびアクセス管理 (IAM) プリンシパル、その他の関連属性を含む顧客固有のデータを使用して自動的に並べ替えられ、修復されます。自動的に修復できない検出結果については、セキュリティ インシデント対応部門がセキュリティ ケースを作成し、お客様の組織内の適切な関係者に通知します。 お客様は、特定の IAM ロールをデプロイすることで、コンテインメントアクションを実行するサービスの権限を設定することもできます。これらのセキュリティインシデント対応抑制機能を使用することで、お客様はインシデント対応時間を短縮し、セキュリティイベントがアカウントやリソースに与える影響を最小限に抑えることができます。 空き状況と使用開始 AWS セキュリティインシデントレスポンスは現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、ストックホルム) の 12 の AWS リージョンでご利用いただけます。 AWS セキュリティインシデントレスポンスの詳細については、 製品ページ をご覧ください。 – Betty 原文は こちら です。

ある時点で、AWS のすべてのお客様が、できるだけ早く将来に移行したいと言っています。モダナイゼーションの取り組みを簡素化し、成長を促進し、クラウドに適応すると同時に、コストも削減したいと考えています。これらの顧客は通常、組織のさまざまな部門が管理する多様なテクノロジースタック上で実行されている、オンプレミスで実行されている大規模なレガシーアプリケーションスイートを所有しています。さらに困難なことに、これらの組織は多くの場合、厳しいセキュリティとコンプライアンスの要件を満たさなければなりません。 共有の準備をする Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Service (Amazon ECS) コンテナサービス、 Amazon Elastic Kubernetes Service (Amazon EKS) コンテナサービス、独自の HTTPS サービスなどの AWS リソースを、 Amazon Virtual Private Cloud (Amazon VPC) と AWS アカウントの境界を越えて共有し、 Amazon EventBridge を介してイベントドリブンアプリを構築したり、 AWS Step Functions でワークフローをオーケストレーションしたりするために使用できるようになりました。既存のワークロードを更新し、最新のクラウドネイティブアプリをオンプレミスのレガシーシステムに接続し、すべての通信をプライベートエンドポイントとネットワーク経由でルーティングできます。 これらの新機能は Amazon VPC Lattice と AWS PrivateLink を基盤として構築されており、ネットワークの設計と制御のための新しいオプションが多数用意されています。また、すべてのテクノロジースタックを統合してオーケストレーションするための優れた新しい方法もいくつか用意されています。たとえば、既存のオンプレミスアプリケーションを利用するハイブリッドイベント駆動型アーキテクチャを構築できます。 現在、一部のお客様は AWS Lambda 関数または Amazon Simple Queue Service (Amazon SQS) キューを使用してデータを VPC に転送しています。このような差別化されていない重労働を、よりシンプルで効率的なソリューションに置き換えることができるようになりました。 これらすべてをまとめることで、場所に関係なく、モダナイゼーションの取り組みを加速し、アプリケーション間の統合を簡素化するのに役立つ一連のサービスを利用できます。EventBridge と Step Functions は PrivateLink および VPC ラティス と連携して動作し、HTTPS ベースのパブリックアプリケーションとプライベートアプリケーションをイベント駆動型アーキテクチャとワークフローに統合することができます。 重要な用語と概念は次のとおりです: リソースオーナー VPC — 共有するリソースがある VPC。この VPC の所有者は、1 つ以上の関連するリソース設定を使用してリソースゲートウェイを作成し、 AWS Resource Access Manager (RAM) を使用してリソースコンシューマー (別の AWS アカウントなど) や、EventBridge と Step Functions を使用してイベント駆動型のアーキテクチャとワークフローを構築する開発者などのリソースコンシューマーとリソース設定を共有します。リソースオーナーとは、この VPC の管理と給餌を担当する組織内の人物 (おそらくあなた) と定義しましょう。 リソースゲートウェイ — ゲートウェイに関連付けられているリソース設定で示されるように、クライアントがリソースオーナー VPC 内のリソースにアクセスできるように、VPC への入口を提供します。1 つのリソースゲートウェイで複数のリソースを利用することができます。 リソース — リソースオーナー VPC 内の HTTPS エンドポイント。これは、データベース、データベースクラスター、EC2 インスタンス、複数の EC2 インスタンスの前にある Application Load Balancer 、AWS Cloud Map を介して検出可能な ECS サービス、 Network Load Balancer の背後にある Amazon Elastic Kubernetes Service (Amazon EKS) サービス、または AWS Site-to-Site VPN または AWS Direct Connect を介してオンプレミスで実行されているレガシーサービスになります。 リソース構成 — 特定のリソースゲートウェイを介してアクセスできるリソースのセットを定義します。リソースは IP アドレス、DNS 名、または (AWS リソースの場合) ARN で参照できます。 リソースコンシューマー — リソースオーナー VPC 内のリソースに接続して提供されるサービスを使用するアプリケーションの構築を担当する組織内の担当者。 リソースの共有 このパワーのすべては、さまざまな方法で活用できます。この記事ではその1つに焦点を当てます。 まず、私はリソースオーナーの役割を果たします。VPC コンソールで リソースゲートウェイ をクリックし、ゲートウェイがないことを確認し、 リソースゲートウェイの作成 をクリックして開始します: 名前 ( main-rg ) と IP アドレスタイプを割り当ててから、ゲートウェイを配置する VPC とプライベートサブネットを選択します (これは 1 回限りの選択であり、新しいリソースゲートウェイを作成しない限り変更できません)。また、インバウンドトラフィックを制御するために最大 5 つのセキュリティグループを選択します: 下にスクロールして、必要なタグを割り当て、 リソースゲートウェイの作成 をクリックして次に進みます: 新しいゲートウェイは数秒でアクティブになります。感謝の気持ちを込めてうなずき、 リソース設定を作成 をクリックして先に進みます: 次に、最初のリソース構成を作成する必要があります。リソースオーナー VPC のプライベートサブネット上の EC2 インスタンスで HTTPS サービスを実行しているとしましょう。サービスに DNS 名を割り当て、インスタンスの IP アドレスを返す Amazon Route 53 エイリアスレコードを使用します: この例では、パブリックホストゾーンを使用しています。すでにプライベートホストゾーンのサポートに取り組んでいます。 DNS のセットアップがすべて完了したら、 リソース設定の作成 をクリックして次に進みます。名前 ( rc-service1 ) を入力し、タイプとして リソース を選択し、先に作成したリソースゲートウェイを選択します: 下にスクロールして EC2 インスタンスをリソースとして定義し、DNS 名を入力し、ポート 80 と 443 の共有を設定します: ここで、少し寄り道をして、RAM コンソールに移動してリソース共有を作成し、他の AWS アカウントがリソースにアクセスできるようにします (これはオプションであり、クロスアカウントシナリオにのみ該当します)。サービスごとに 1 つのリソース共有を作成することもできますが、ほとんどの場合、共有を 1 つ作成し、それを使用して関連サービスのコレクションをパッケージ化します。これを実行して、 共有サービスと呼びます : 回り道から戻って、リソース共有のリストを更新し、作成したリソース共有を選択して、 リソース構成の作成 をクリックします: リソース設定は数秒で準備完了です。 まとめと計画時間 先に進む前に、簡単にまとめて計画を立てましょう。私が (リソースプロバイダーの役割で) これまでに持っていることは次のとおりです: MainVPC — 私のリソースオーナー VPC。 main-rg — MainVPC のリソースゲートウェイ。 rc-service1 — main-rg のリソース設定です。 service1 — MainVPC のプライベートサブネットの EC2 インスタンスで固定 IP アドレスでホストされている HTTPS サービス。 さて、次は何でしょう? 共有 — これが最初の、そして最もわかりやすい使用法です。 AWS リソースアクセスマネージャー (RAM) を使用してリソース設定を別の AWS アカウントと共有し、別の VPC からサービスにアクセスできます。一方 (リソースコンシューマーとして)、共有されているサービスに接続するための簡単な手順をいくつか実行します: サービスネットワーク — サービスネットワークを作成し、リソース設定をサービスネットワークに追加し、VPC に VPC エンドポイントを作成してサービスネットワークに接続できます。 エンドポイント — VPC に VPC エンドポイントを作成し、そのエンドポイントを介して共有リソースにアクセスできます。 モダナイズ — 従来の Lambda または SQS 統合を削除して、差別化されていない面倒な作業を取り除くことができます。 ビルド — EventBridge と Step Functions を使用して、イベント駆動型アーキテクチャを構築し、アプリケーションをオーケストレーションすることができます。このオプションを選びます! EventBridge とステップ関数によるプライベートリソースへのアクセス EventBridge と Step Functions により、Slack、Salesforce、アドビなどの SaaS プロバイダーのものなど、パブリック HTTPS エンドポイントに簡単にアクセスできるようになりました。12 月 1 日のリリースにより、プライベート HTTPS サービスの利用も同様に簡単になりました。 リソースコンシューマーとしては、EventBridge 接続を作成し、共有されたリソース設定を参照して、イベントドリブンアプリケーションからサービスを呼び出すだけです。私がすでに知っていることはすべてまだ当てはまり、民間サービスにアクセスする新たな力を得ました。 EventBridge 接続を作成するには、EventBridge コンソールを開き、 統合 メニューの 接続 をクリックします: 既存の接続 (今のところなし) を確認してから、 接続を作成 をクリックして次に進みます: 接続の名前 ( MyService1 ) と説明を入力し、 API タイプとして プライベート を選択し、前に作成したリソース設定を選択します: 下にスクロールすると、接続しているサービスの認証を設定する必要があります。 カスタム設定 と 基本認証 を選択し、サービスの ユーザー名 と パスワード を入力します。また、クエリ文字列に Action=Forecast を追加して (認証にはたくさんのオプションがあることがわかります)、 作成 をクリックします: 接続は数分で作成され、準備が整います。次に、 HTTP タスク を使用して接続を選択し、API エンドポイントの URL を入力し、HTTP メソッドを選択して Step Functions ワークフローで使用します: これで、Step Functions ワークフローでプライベートリソースを利用できるようになりました! この接続をイベントバスとパイプの EventBridge API デスティネーションターゲットとして使用することもできます。 知っておくべきこと これらの素晴らしい新機能について知っておくべきことがいくつかあります: 料金 — VPC へのデータ転送にかかる GB 単位の料金を含め、 ステップファンクション 、 EventBridge 、 PrivateLink 、 VPC ラティス の既存の料金が適用されます。 リージョン – 21の AWS リージョンで Resource Gateway と Resource Configurations を作成、使用できます: 米国東部 (オハイオ州、バージニア州北部)、米国西部 (カリフォルニア州北部、オレゴン州)、アフリカ (ケープタウン)、アジア太平洋 (香港、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、中東 (バーレーン)、南米 (サンパウロ)。 開発中 — 前述したように、プライベートホストゾーンのサポートに取り組んでいます。また、EventBridge と Step Functions を通じて、他のタイプの AWS リソースへのアクセスをサポートすることも計画しています。 – Jeff ; 原文は こちら です。

本稿は、2024 年 9 月 4 日に AWS Cloud Enterprise Strategy Blog で公開された “ Centralizing or Decentralizing Generative AI? The Answer: Both ” を翻訳したものです。 はじめに ビジネスおよび IT の意思決定者にとって、もはや、生成 AI を採用するかどうかでは問題ではなく、どのようにして最大限の効果と最小限のリスクで実装するかという点です。生成 AI の管理と展開を、集中化するか、分散化するかは、長期的な影響を伴う重要な戦略的決定です。 ブログの記事「 集中化か分散化か？ 」で強調されているように、企業は生成 AI のような変革技術を導入する際に、集中化と分散化のトレードオフを考慮する必要があります。集中化は全社的なガバナンス、規模の経済、統一されたデータ管理を実現できる一方で、分散化はより迅速なイノベーションとビジネスニーズへのより緊密な対応を可能にするかもしれません。 私たちは、両方の戦略の強みを活用するハイブリッドモデルという、より洗練されたアプローチを推奨します。すなわち、インフラを集中化しながらイノベーションを分散化するというアプローチです。この戦略は、強固なガバナンスと俊敏なデリバリーを組み合わせ、生成 AI のインパクトを最大限に引き出すための体制を整えます。 ビジネスニーズの特定 生成 AI の技術に焦点を当てるのではなく、価値と競争優位性を生み出すことができる、影響力の大きい分野を特定します。 カスタマーサービス： AI 搭載のチャットボットでサポートを強化しながらコストを削減。 マーケティング： AI を活用して、大規模なパーソナライズされたコンテンツ作成を実現。 製品開発： AI で設計コンセプトとシミュレーションを生成。 製薬： AI で分子構造を探索することで、新薬開発を加速。 金融サービス： リスク評価、不正検出、個別アドバイスに AI を活用。 ソフトウェア開発： AI によるコーディングとバグ検出により生産性を向上。 サプライチェーン： AI 主導の予測分析と物流計画による最適化。 人事： 候補者のスクリーニングとマッチングに AI を活用し、採用プロセスを合理化。 特定するための重要な質問 生成 AI が対応できる重要なビジネス上の問題や機会とはどのようなものですか？ 生成 AI から最も恩恵を受ける組織の領域や機能は何ですか？ 差別化された AI ソリューションを構築するために、組織が活用できる独自のデータ資産や専門知識は何ですか？ ビジネスニーズとユースケースを明確に定義することで、組織は生成 AI の展開とガバナンスをサポートするのに最も適した組織構造と運用モデルを決定することができます。 ハイブリッドアプローチ：両方の長所を活かす 生成 AI にとって最適な組織構造とはどのようなものでしょうか。私たちは AWS エンタープライズストラテジストとして、財務および人事チームが、まずリソースのインパクトを最大限に高め、次にビジネスニーズに迅速に対応し、最後にガードレールの構築と、一般化された作業の方法を確立できることに感銘を受けています。 これらの領域にベストプラクティスとナレッジをもたらす集中化されたチームを擁しており全社的な業務を行っていますが、誰もが人材と財務の管理もあわせて期待されています。 AI は同様にビジネスのあらゆる側面に浸透していくでしょう。現場レベルではモデルの出力結果の妥当性を評価する能力など、スキルや知識が必要とされるいくでしょう。 インフラレイヤーの集中化 AI インフラストラクチャを集中化することで、企業は規模の経済性を実現しながら、トレーニング、ファインチューニング、独自 AI モデルの開発といった複雑でリソース集約的なプロセスを効率的に管理できるようになります。この統合により、データ管理、分析、モデルのメンテナンスが合理化され、企業全体のコストと複雑性が削減されます。 集中化により、一貫したデータ品質、セキュリティ、コンプライアンス基準が確保され、信頼性の高い生成 AI モデルの開発と展開を成功させる上で重要な要素となります。これらのリソースを統合することで、組織は AI 技術を導入する際に直面する課題をより効果的に乗り越え、その潜在的なメリットを最大限に活用することができます。 通常、専門のデータチームが、この集中管理されたインフラを管理し、組織内の他の部門に対してガイダンス、トレーニング、ツール、ガバナンスを提供します。このチームは高度な AI/ML スキルを持ち、組織の生成 AI を利用する能力が確固たるインフラの上に構築されるようにします。 ビジネス領域全体に AI イノベーションを分散 生成 AI のインフラは集中化の恩恵を受ける一方で、イノベーションは分散化された環境でこそ活気づきます。分散化アプローチは、ビジネス領域全体にわたる AI のユースケースの多様性に対応します。法律文書の要約から、金融データの分析、研究開発における設計、マーケティングコンテンツの作成まで、さまざまなユースケースに対応します。これらのアプリケーションには、異なる基盤モデルだけでなく、カスタマイズ、ファインチューニング、品質管理対策、ユーザーインターフェース設計、既存のアプリケーションやビジネスプロセスとの統合が必要です。 このようなユースケースの多様性と個別性が進むにつれて集中化された環境は効率が悪くなっていきます。各部門の独自のニーズや迅速なイノベーションサイクルに対応することが困難になるためです。しかし、データメッシュ (データを分散化し、AI を分散化するモデル) は、ビジネス部門のニーズにうまく適合できるでしょう。 財務や人事のように、ベストプラクティスを提供する中央集権型のチームは存在しますが、組織の各部門は独自の能力を開発し発揮しています。生成 AI の場合、組織全体にわたるチームに権限を与えることで、モデルの結果を評価し、AI をワークフローに統合し、イノベーションを一から推進することを意味します。 データメッシュにより、各分野や部門の専門チームが AI アプリケーションのオーナーの役割を担います。これらのチームはビジネス上の課題やオポチュニティに最も近い位置にあり、影響力の大きい AI ユースケースを特定し、実装する上で最適な立場にあります。AI ソリューションのプロトタイプを迅速に作成し、テストと改善を行うことで、特定の業務上の文脈や戦略目標との緊密な整合性を確保することができます。これにより、生成 AI ソリューションの開発と展開が加速されるだけでなく、各部門の特定の業務上の文脈や戦略目標との緊密な整合性が確保されます。 分散モデルにおける効果的なガバナンスの維持 分散モデルでは、より迅速なイノベーションと特定のビジネスニーズへのより緊密な適合が実現しますが、組織全体で一貫性、品質、コンプライアンスを確保するための効果的なガバナンスと統制を維持することが重要です。 これを実現するには、いくつかの主要な戦略が必要です。 集中化されたプラットフォームとツール： 生成 AI ソリューションを構築し展開する際に、各部門のチームが活用できる標準化されたツール、モデル、API のセットを提供する集中化されたプラットフォームを提供します。これにより、品質、セキュリティ、コンプライアンスのベースラインが確保されます。 共有責任モデル： 生成 AI の推進の中心となるデータサイエンスおよびエンジニアリングチームが標準、ガイドライン、ベストプラクティスを設定し、各部門のチームがそれぞれのコンテキストに合わせてカスタマイズして適用する共有責任モデルを確立します。 ガバナンス委員会： 中心となるチームと各部門チームの代表者が集まる部門横断的なガバナンス委員会を結成し、生成 AI ソリューションの展開を検討し承認します。これにより、戦略的な整合性と一貫したリスク管理を維持することができます。 集中化されたモニタリングと監査： 組織全体における生成 AI アプリケーションのパフォーマンス、利用状況、コンプライアンスを追跡するための集中化されたモニタリングと監査を実施します。 知識の共有とコラボレーション： 生成 AI の推進の中心となる各部門のチーム間で知識の共有とコラボレーションの文化を醸成し、洞察、方法論、教訓の交換を促進します。これにより、一貫した品質とベストプラクティスの採用を確保できます。 中央化されたプラットフォームのサポートにより、ビジネス部門のチームは成長する 分散化は孤立を意味するものではありません。各部門のチームは、ガイダンス、トレーニング、ツール、ガバナンスを提供する集中化されデータサイエンスサポートの恩恵を受けます。これにより、統制と統一性を維持しながら、最新の方法論とテクノロジーへのアクセスを確保できます。中央集権型の専門知識は、通常、プラットフォームチームとして独自のモデルのトレーニングを担当するチームから提供されます。 ブログ記事「責任ある AI のベストプラクティス: 責任ある信頼できる AI システムの促進」 では、生成 AI のライフサイクル全体にわたって公平性、透明性、説明責任を維持する方法について説明しています。これは、生成 AI ソリューションを分散型かつ部門特化型で展開する際に極めて重要です。これにより、ソリューションが組織の倫理原則に沿ったものとなり、偏見を助長したり、意図しない被害を引き起こしたりすることがなくなります。 おわりに 生成 AI の実装の未来は、集中化と分散化を戦略的にバランスさせることにあります。 集中化されたインフラは、今日の規制環境において不可欠なセキュリティ、スケーラビリティ、コンプライアンスのインフラを提供します。分散化された実行レイヤーは、特定のビジネスニーズに合わせた AI ソリューションを迅速に開発し、展開することを可能にします。このハイブリッドモデルは、組織が俊敏性を高めながらコントロールを維持することを可能にする強力な戦略的優位性を提供します。コアとなるインフラを集中化し、アプリケーション開発を分散化することで、企業は AI 導入の複雑性を乗り越えながら、その変革の可能性を最大限に引き出すことができます。 AI 主導の未来で成功を収めるには、企業はイノベーションの最前線に身を置き、同時に、集中化と分散化の両方の要素を活用する緻密な戦略を今から策定することで、強固なガバナンスと拡張性を確保する必要があるのです。 —Matthias Patzak and Tom Godden 参考になるサイト: 集中化か分散化か？ – by Mark Schwartz Welcome to a New Era of Building in the Cloud with Generative AI on AWS – by Swami Sivasubramanian Data Lakes vs. Data Mesh: Navigating the Future of Organizational Data Strategies – by Matthias Patzak How Technology Leaders Can Prepare for Generative AI – by Phil Le-Brun Your AI is Only as Good as Your Data – by Tom Godden Navigating the Generative AI Landscape: A Strategic Blueprint for CEOs and CIOs – by Tom Godden AWS でのデータレイク データメッシュとは何ですか? Matthias Patzak マティアスは、AWS ソリューションアーキテクチャ部門のプリンシパルアドバイザーを経て、2023 年初めにエンタープライズストラテジストチームに加わりました。この役職において、マティアスは、クラウドがイノベーションのスピード、IT の効率性、およびテクノロジーが人、プロセス、テクノロジーの観点から生み出すビジネス価値の向上にどのように役立つかについて、経営陣と共同で取り組んでいます。 AWS 入社前は、マティアスは AutoScout24 の IT 担当副社長、Home Shopping Europe の最高経営責任者を務めていました。両社において、マティアスはリーン・アジャイルの運用モデルを大規模に導入し、クラウドへの移行を成功に導きました。その結果、納期の短縮、ビジネス価値の向上、企業評価の向上を実現しました。 Tom Godden トム・ゴッデンは、Amazon Web Services (AWS) のエンタープライズストラテジスト兼エバンジェリストです。AWS 入社前は、Foundation Medicine の最高情報責任者 (CIO) として、FDA の規制下にある世界トップクラスの癌ゲノム診断、研究、患者治療結果のプラットフォームの構築に携わり、治療結果の改善と次世代の精密医療の実現に貢献しました。それ以前は、Alphen aan den Rijn Netherlands にある Wolters Kluwer で複数の上級技術リーダー職を歴任し、ヘルスケアおよび生命科学業界での経験は 17 年以上に及びます。トムはアリゾナ州立大学で学士号を取得しています。

本日、強化された AWS Pricing Calculator が、請求とコスト管理コンソールからパブリックプレビュー機能として利用できるようになったことを発表致します。新機能では、新しいワークロードや既存の AWS 使用量の変更についてディスカウントを含めた正確なコスト見積もりを行うことができます。これにより、あるリージョンから別のリージョンへのワークロード移行、既存のワークロードの変更もしくは新しいワークロードの計画やコミットメント購入計画などについて時間を節約しコスト見積もりの正確性を向上させることができます。 既存の Web サイトとしての Pricing Calculator と異なり、強化された Pricing Calculator を開始するには開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。 AWS Pricing Calculator のこれまでの歩み 最もよくある一般的な質問の 1 つは、” AWS 上でワークロードを実行するとどのくらいコストがかかりますか？” というものです。これに応えるために、2007 年に AWS Simple Monthly Calculator をローンチしました。これは、最新の料金変更に対応し、簡単にコスト見積もりを行えるツールです。2018 年には、 AWS Pricing Calculator をローンチしました。シンプルな UI で幅広いサービスに対応しており Pricing Calculator はすぐに AWS ワークロードのコストを見積もるための頼りになるリソースとなりました。2023 年には、 1 つのツールですべてのアーキテクチャのニーズに対応した料金を調査できるよう Simple Monthly Calculator の廃止 を決定しました。これ以来、Pricing Calculator の機能を向上させ拡張し続けてきました。 本日のローンチ以前は、AWS Pricing Calculator を利用して AWS 上のワークロードのコスト影響を評価できました。しかし、ディスカウントについては自分自身で計算する必要がありました。さらに、変更を加える場合にはまず既存の使用量を収集する必要がありました。また、コストの見積もりを保存したりチームで共有するための出力や管理プロセスを構築する必要がありました。 強化された Pricing Calculator （パブリックプレビュー） お客様からのフィードバックを取り入れて、請求とコスト管理コンソールで利用できる新しく強化された AWS Pricing Calculator を開発しました。まず、AWS アカウントで Pricing Calculator にログインし、見積もりに過去の AWS 使用量をインポートできるようになりました。また、これらの見積もりをアカウントに直接保存し、今後のリファレンスとできます。次に、AWS が請求書を作成するために利用しているものと同じ計算ロジックを利用して AWS 請求全体のコストを見積もることができるようになりました。この機能により、Savings Plans や Reserved Instances などの様々なディスカウントが全体のコストにどのように影響するのかより詳しく理解するために役立ちます。最後に、ディスカウントを適用させながら、特定のワークロード（すべての AWS 使用量のサブセット）のコストをインタラクティブに見積もることができます。開始するには、 請求とコスト管理コンソール にログインし、左側ナビゲーション内の “予算と計画” セクションにある Pricing Calculator (Preview) / 料金見積りツール (プレビュー) をクリックしてください。それでは、詳細について見ていきましょう。 2 種類の見積もり 新しい Pricing Calculator の機能は、パブリックプレビューとして 2 種類のコスト見積もりをサポートしています。ワークロード見積もりと請求見積もりです。 ワークロード見積もり を利用すると、様々なワークロードやアプリケーションの変更によるコスト影響をインタラクティブにモデル化し、ディスカウントを適用した効果を自動的に含ませることができます。アプリケーションを所有している場合や、アプリケーションに関する財務もしくは組織内の使用量に関して責任を持っている場合は、こちらの見積もりが役に立ちます。ワークロード見積もりは、管理アカウント、メンバーアカウントとスタンドアロンアカウントすべての AWS アカウントで利用できます。 請求見積もり を利用すると、管理アカウントのユーザーは AWS サービスの使用量の変化に加えて、Savings Plans と Reserved Instances を含んだりコミットメント金額を調整した見積もりを作成できます。これはすべてのコストと使用量が一括請求で計算されることにより実行されます。一括請求での見積もりは、アカウント間で割引の共有を行いながら活用できるため、より長期間のコミットメントを含めたシナリオを評価したいお客様によって特に有益です。 おそらく皆さんは、この新しい Pricing Calculator の機能を活用する色々な方法について考えているのではないでしょうか？まさに、新しいビジネスをサポートするための既存ワークロードの拡張や新規ワークロードの追加、レジリエンシー、パフォーマンスもしくはコスト最適化などの理由による新しいリージョンへの移行や推奨されるライトサイジングの実装といったシナリオに活用できます。既存の Amazon EC2 の使用量を変更しながら新しく Amazon RDS を追加する必要があるユースケースについて、お客様が手短な回答を探している例について見てみましょう。 ワークロード見積もり あなたが所属するチームが m5d.16xlarge インスタンスの使用量を月あたり 355 時間から 1460 時間に増やすことを決めました。見積もりコストは増加しますが、他のワークロードを変化させた場合のコスト影響も一緒に確認したいとします。 自分のアカウントで Pricing Calculator にログインし、使用可能なパラメーターとしての日付範囲やフィルター（リージョン、アカウント、タグやコストカテゴリなど）を用いて過去のワークロードをインポートし、ワークロード見積もりを作成してください。EC2 サービスの使用量のみをインポートすることができます。これを実行するために、Amazon Elastic Compute Cloud サービスでフィルタリングし、新しい使用グループを作成して名前を付け、詳細を設定してサービスの使用量を編集してください。 図 1. ワークロード見積もりへ過去の EC2 使用量を追加した例 図 2. 既存 EC2 の使用量詳細の編集例 状態の列が “Modified” となり、フィルタリングされたベースライン使用量と変更された推定コストの比較をすぐに確認することができます。 図 3. ワークロード見積もりのランディングページ例 既存の EC2 使用量を変更することに加えて、チームはさらに新しく追加する Amazon Aurora MySQL データベースの使用量に関するコスト影響を把握したいと考えています。このような場合は、新しい Amazon Aurora の使用量を同じワークロード見積もりに加えることができます。これを行うために、“Amazon Relational Database Service” でフィルタし、新しいサービス使用量を加え、詳細を設定することでコストへの影響をすぐに確認することができます。 図 4. 新しく Amazon RDS ( Aurora 使用量）を追加した例 図 5. 新しい Amazon Aurora の詳細設定例 新しく Amazon Aurora の使用量を設定すると、Amazon Aurora の使用量をすぐに反映した見積もりをテーブルで再度確認できます。 図 6. 更新されたワークロード見積もりページ例 請求見積もり チームがワークロードの成長によるコストへの影響について理解した後に、増加した使用量をカバーする新しい Savings Plans を購入する必要があるとします。請求見積もりの機能により、Savings Plans と Reserved Instances の両方を含む AWS 請求全体のコストをモデル化することができます。例えば、m5d.16xlarge EC2 インスタンスの月あたりの使用量を 355 時間から 1460 時間へ増やし、この増加分をカバーするために $1.00/hour の EC2 Instance Savings Plans を追加購入するとします。この場合、請求見積もりを使用することで、全体への影響を把握できます。これを行うためには、新しい請求シナリオを作成し、先月の EC2 使用量をインポートします。次に、増加した使用量を反映させるために関連する使用量の行を変更し、さらに新しい Savings Plans を請求シナリオに追加します。これらの手順を完了させたら、‘Create report’ をクリックして請求シミュレーションを開始してください。 図 7. 請求見積もりページ例 シミュレーション結果が作成されると、請求見積もりのリストで確認することができます。見積もりのタイトルをクリックして、詳細を確認できます。請求見積もりの結果ページでは、一括請求ファミリーのコストと使用量に関する課税前の重要な情報が表示されます。上位 7 サービスと明細項目レベルで変更されたコストと使用量を確認できます。明細項目では、シナリオで使用量が変更された行とコミットメントでカバーされ変更された行やディスカウント適用に伴い変更された行が含まれます。 図 8. 請求結果ページ例 注意点 レイテンシー ：ワークロード見積もりでは、すぐにコスト見積もりを取得できます。請求見積もりでは、処理するデータのサイズに依存しますが、新しい設定の詳細を利用して完全な請求を計算する必要があるため、最大 12 時間の待ち時間が発生する可能性があります。これは非同期処理となり、完了するとメール通知を受け取ります。 Savings Plans コストモデリング ：時間あたりのコミットメント金額が異なる個別の Savings Plans を購入した場合のコストへの影響について分析するために、新しくローンチされた Savings Plans Purchase Analyer を利用し、様々な購入シナリオにまたがった推定削減額、カバレッジと使用率をインタラクティブにモデル化できます。もし、組織の使用量にまたがった既存のすべての Savings Plans、Reserved Instances とディスカウントに加えて、新しく追加したり変更した使用量、Savings Plans や Reserved Instances によるコスト影響を総合的に把握したいのであれば、Pricing Calculator の請求見積もり機能を利用してください。 結論 新しい Pricing Calculator の機能は、コスト計画に対する確信を高め、組織が必要とする重要なビジネスの意思決定に必要なクリティカルな回答を得るための処理を迅速にします。詳細については、 AWS Pricing Calculator の ユーザーガイド 、 API ドキュメント や 料金 を参照してください。（訳者注：ワークロード見積もりは、無料で作成できます。請求見積もりは、月 5 件まで無料で作成できますが、以降は 1 件あたり $2 の費用が発生します。） 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Jeremiah Myers Jeremiah は、AWS Billing and Cost Management services のシニアテクニカルプロダクトマネージャーです。クラウドコストの責任者がAWS 上の将来のワークロードをよりよく計画できる支援に注力しています。以前のキャリアでは、複数のグローバルソフトウェア製品をローンチし、ベンチャー企業をバックアップするスタートアップを共同成立しました。 Bowen Wang Bowen は、AWS Billing and Cost Management services のプリンシパルプロダクトマーケティングマネージャーです。財務やビジネスのリーダーがクラウドの価値と Cloud Financial Management を最適化する方法をより理解できるようにすることに重点を置いています。以前のキャリアでは、テックスタートアップの中国市場参入を支援していました。

Amazon Connect に、 生成 AI 、高度なセキュリティ機能、そして合理化されたボット管理を通じて、コンタクトセンター運用を強化する新機能を導入しました。これらのイノベーションは、セキュリティとコンプライアンスを維持しながら、有意義なやり取りの時間を増やすことで、組織がより良い顧客体験を提供するのに役立ちます。 コンタクトセンターの管理者は、セルフサービス解決率の最適化、エージェントのパフォーマンスの効率的な評価、データプライバシーコンプライアンスの維持といった課題に常に直面しています。さらに、会話型 AI インタフェースの構築と管理には、多くの場合、専門知識と複数のサービスにまたがる複雑な統合が必要とされます。 これらの課題に対応するため、Amazon Connect は以下のような機能を導入しました： ターゲットを絞ったキャンペーン向けの生成 AI を活用した顧客セグメンテーション オムニチャネルサポートのためのネイティブ WhatsApp Business メッセージング チャットでの顧客機微情報の安全な収集 Amazon Connect インターフェースでの会話型 AI ボット管理の簡素化 Amazon Q in Connect の新機能 また、Amazon Connect は Amazon Connect Contact Lens による新しい分析機能を追加し、ボットのパフォーマンスとコンタクトセンター運用の最適化が可能になりました。 これらの新機能により、最高水準のデータセキュリティと運用の卓越性を維持しながら、よりパーソナライズされた効率的な顧客体験を創出することができます。 生成 AI を活用した機能 Amazon Connectは、顧客との会話を自動化し強化するための新しい生成 AI 機能を統合しました。これにより、よりスマートなターゲティングとより効率的なコンタクトセンター管理が可能になります。 生成 AI セグメンテーションとトリガーベースのキャンペーン – 会話型プロンプトを使用して 顧客セグメント を作成する生成 AI 支援機能を活用します。これにより、組織は自然言語による説明を用いて正確な顧客セグメントを作成できるようになり、特定の顧客グループの識別とリーチがより容易になります。トリガーキャンペーンでは、カート放棄などの特定の顧客イベントに基づいて顧客とコミュニケーションを取ることができます。 提案機能からすぐに使い始めることもできます。 会話型AIボットの作成を簡素化し、Amazon Q in Connect で強化 – Amazon Connect のインターフェースで、 Amazon Lex の会話型 AI ボットの作成、編集、管理が直接行えるようになりました。さらにこれらのボットを顧客サービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect によって強化できます。Amazon Q in Connect は、コンタクトセンターのエージェントに推奨応答やアクションを提案するだけでなく、音声自動応答 (IVR) やデジタルチャネルを通じたエンドユーザーのセルフサービス対応もサポートしました。 この統合により、大規模言語モデル (LLM) を活用した高度な会話能力が提供され、従来の Amazon Lex の音声やチャットボット機能を大幅に拡張します。システムは、あらかじめ設定された応答パターンに合致しない顧客の質問に対して、設定済みのナレッジベースや顧客情報、Web コンテンツ、サードパーティアプリケーションのデータをインテリジェントに検索して回答します。管理者は、インスタンスごとにカスタムガードレールを設定し、回答生成の制限を定義したり、 Amazon Q in Connect のパフォーマンスを監視したりすることができます。 生成 AI を活用したエージェントの自動評価 : スーパーバイザーは生成 AI を使用して、最大で 100% のコンタクトを自動的に評価できるようになりました。 生成 AI を活用したコンタクトの分類 : 自然言語インテントを使用して、既存のセマンティックマッチ機能を改善しました。 インターフェースとツールの改善 ボットの管理とモニタリングの機能を強化し、自動化されたエクスペリエンスの作成と最適化が簡素化されました。 WhatsApp Business メッセージングとの連携 – WhatsApp Business メッセージングとネイティブに統合し、既存の Amazon Connect チャネル (音声、SMS、チャット、 Apple Messages for Business ) に加えて、 WhatsApp 経由でのサポートを顧客に提供可能になりました。Amazon Connect のオムニチャネル機能にこの機能が追加されたことによって、組織は Amazon Connect アプリケーション内で一貫したサービス提供と管理を維持しながら、顧客に応じたコミュニケーションチャネルで対応できるようになります。 Contact Lens 会話型 AI ボットダッシュボード – Amazon Connect で構築された会話型 AI ボットのパフォーマンスを監視するための分析機能を提供します。 コンタクトの詳細におけるセルフサービス音声 (IVR) の録音 – 音声録音を含む、セルフサービス対話の包括的な記録を提供します。 当日予測の改善 – 予測、キャパシティプランニング、スケジューリング機能の一部として、以前に公開された予測と当日予測の比較が可能になりました。 Salesforce Contact Center with Amazon Connect (プレビュー) – Amazon Connect のデジタルチャネルとユニファイドルーティングを Salesforce の顧客関係管理 (CRM) システムにネイティブ統合します。この 新しい統合 により、組織は Amazon Connect と Salesforce のチャネルの両方に単一のルーティングおよびワークフローシステムを使用し、通話、チャット、ケースを最適なセルフサービスまたはエージェントとの対話へインテリジェントに振り分けることができます。ご興味をお持ちの方は、 プレビューへの参加 にサインアップしてください。 チャットのセキュリティ強化 チャットにおけるセキュリティとコンプライアンスを強化する新機能により、機密情報の安全に取り扱うことが可能になります。 チャットでの機密顧客データの収集 – Amazon Connect のチャットおよびメッセージング に、チャット対話中の顧客機密情報を安全に扱うためのデータプライバシーオプションが追加されました。この機能は、個人を特定可能な情報 (PII) とペイメントカード業界 (PCI) データを保護し、データ保護規制へのコンプライアンスを促進します。 主なメリット Amazon Connect の最新機能は、生成 AI、強化されたセキュリティ、合理化されたボット管理を組み合わせることで、組織に以下のメリットをもたらします : 顧客体験の変革 – Amazon Connect は AI を活用したセグメンテーションを通じて顧客とのインタラクションを向上させ、パーソナライズされたエンゲージメント戦略を可能にします。新しい WhatsApp Business メッセージングはオムニチャネルサポート機能を拡張し、顧客の好むチャネルで対応します。さらに Amazon Q in Connect を含む高度なボット機能によりセルフサービスの解決率が向上し、より効率的な顧客体験を提供します。 セキュリティと運用の強化 – コンタクトセンターは、運用効率を維持しながら PCI 準拠のチャット機能によりセキュリティを強化できるようになりました。カスタム AI ガードレールは適切な応答生成を促進し、シンプルなボット管理インターフェースにより専門知識の必要性が排除されます。分析と予測機能は包括的なパフォーマンス監視を提供し、最適なコンタクトセンター運用のためのデータ駆動型の意思決定を可能にします。 価格と利用可能リージョン – これらの機能は、 Amazon Connect がサポートされている すべての AWS リージョン で本日から利用可能です。価格設定については、 Amazon Connect の料金ページ をご覧ください。実装ガイダンスについては、 Amazon Connect のドキュメント をご参照ください。 Elizabeth Fuentes 私の使命は、複雑な概念をわかりやすい説明に分解し、開発者が継続的にスキルと知識を広げられるようにすることです。カンファレンス、チュートリアル、オンラインリソースを通じて、私は自分の専門知識を世界中の開発者コミュニティと共有し、彼らが潜在能力を最大限に発揮するためのツールと自信を提供しています。実践的なアプローチと、複雑なものを簡素化するというコミットメントをもって、私は AWS テクノロジーの世界における成長と学習のきっかけとなるよう努めています。 翻訳はシニア Amazon Connect ソリューションアーキテクト清水が担当しました。原文は こちら です。