この記事は Run GenAI inference across environments with Amazon EKS Hybrid Nodes (記事公開日: 2024 年 3 月 19 日) を翻訳したものです。 この記事は、Principal Container Specialist SA である Robert Northard、EKS の Senior Product Manager である Eric Chapman、Senior Specialist Partner SA である Elamaran Shanmugam が執筆しました。 イントロダクション Amazon Elastic Kubernetes Service ( Amazon EKS ) Hybrid Nodes は、クラウドとオンプレミスにわたって生成 AI 推論ワークロードを実行する方法を変革します。EKS クラスターをオンプレミスのインフラストラクチャに拡張することで、管理の一貫性と運用の複雑さの軽減を実現しながら AI アプリケーションをデプロイできます。Amazon EKS はマネージドな Kubernetes コントロールプレーンを提供し、EKS Hybrid Nodes を使用すると、オンプレミスのインフラストラクチャをワーカーノードとして Amazon EKS コントロールプレーンに参加させることができます。これにより、オンプレミスで Kubernetes コントロールプレーンを管理する必要がなくなります。EKS Hybrid Nodes を使用すると、単一の EKS クラスター内でクラウドとオンプレミスの両方のキャパシティを活用できます。 EKS Hybrid Nodes は、次に挙げるような多くの AI/ML のユースケースとアーキテクチャを実現できます。 レイテンシーの影響を受けやすいワークロードをサポートするための、エッジでのリアルタイム推論を含むユーザに近い場所でのサービス実行 データレジデンシーに関する要件のためにオンプレミスに留まらなければならないデータを使用したモデルのトレーニング ナレッジベースを使用した RAG アプリケーションのような、ソースとなるデータに近い場所での推論ワークロードの実行 ピーク需要時に多くのコンピュートリソースを利用するために AWS クラウドの弾力性を利用 既存のオンプレミスハードウェアの利用 本記事では、単一の EKS クラスターを使用し、EKS Hybrid Nodes を活用してオンプレミスで AI 推論を実行し、さらには Amazon EKS Auto Mode を活用して AWS クラウドでも実行する概念実証 (PoC) について説明します。EKS Auto Mode は、コンピューティング、ストレージ、ネットワーキングなどの Kubernetes クラスターの管理を自動化します。EKS Auto Mode の詳細については、 Amazon EKS ユーザーガイド をご覧ください。 ソリューション概要 本記事の例における推論ワークロードのため、 NVIDIA NIM を通じてモデルをデプロイします。NVIDIA NIM は、GPU を使って AI モデルを実行するために NVIDIA によって最適化されたマイクロサービスです。EKS Hybrid Nodes と EKS Auto Mode の両方を有効化した EKS クラスターを作成し、オンプレミスのマシンをハイブリッドノードとしてクラスターに参加させます。オンプレミスへのデプロイでは、モデルを EKS Hybrid Nodes にデプロイする前に、NVIDIA ドライバーと Kubernetes 用の NVIDIA デバイスプラグインをインストールします。最後に、NVIDIA GPU と AWS Neuron インスタンスに必要なドライバーが事前構成されている EKS Auto Mode のノードにモデルをデプロイします。このウォークスルーには、EKS Hybrid Nodes を実行するためのハイブリッドネットワークと認証の前提条件を確立する手順は含まれていません。これらは Amazon EKS ユーザーガイド に記載されています。 図 1: EKS Hybrid Nodes と AWS リージョンにおける EKS ノードの両方を含む EKS クラスターの概要 上記は、このウォークスルーで使用するアーキテクチャのハイレベルな図を示しています。 Amazon Virtual Private Cloud (VPC) には、EKS Auto Mode のワーカーノードをホストする 2 つのパブリックサブネットと 2 つのプライベートサブネットがあります。コントロールプレーンとハイブリッドノード間の通信は、VPC を経由してトランジットゲートウェイまたは仮想プライベートゲートウェイの出入り口を通過し、プライベートなネットワーク接続経由でルーティングされます。EKS Hybrid Nodes は、オンプレミス環境と AWS リージョン 間の 信頼できるネットワーク接続 を必要とします。これは、 AWS Site-to-Site VPN 、 AWS Direct Connect 、またはユーザー管理の VPN ソリューションを使用して確立できます。 ルーティングテーブル、セキュリティグループ、ファイアウォールルールを設定して、各環境間の双方向通信を可能にする必要があります。 前提条件 このソリューションを完了するために必要な前提条件は以下のとおりです。 インターネットへのルートを持つ 2 つのプライベートサブネットと 2 つのパブリックサブネットを備えた Amazon VPC オンプレミスネットワークと Amazon VPC 間の AWS Site-to-Site VPN オンプレミスノードの場合、VPC CIDR レンジや Kubernetes Service の IPv4 CIDR と重複しない IPv4 RFC-1918 に準拠した CIDR ブロック Amazon EKS ユーザーガイド に詳細が記載されている、ファイアウォールルール、ルーティングテーブル、セキュリティグループといった Hybrid Nodes のネットワーキング要件 マシンイメージに含まれる NVIDIA ドライバー と NVIDIA Container Toolkit と EKS Hybrid Nodes に対応するオペレーティングシステム を実行するオンプレミスのマシン NIM へのアクセスに必要な NVIDIA NGC アカウントとAPI キー (NVIDIA の ドキュメント を参照してください) 以下のツール Helm 3.9+ kubectl eksctl v0.205.0+ AWS Command Line Interface (AWS CLI ) ウォークスルー 次のステップでは、このソリューションの概要を説明します。 EKS Hybrid Nodes と EKS Auto Mode を有効化したEKS クラスターの作成 Amazon EKS クラスターの作成および管理のための CLI ツールである eksctl を使用して、EKS Hybrid Nodes と EKS Auto Mode が有効化された EKS クラスターを作成します。 ClusterConfig ファイルとして cluster-configuration.yaml を作成します。このファイルには EKS Auto Mode を有効にする autoModeConfig と EKS Hybrid Nodes を有効にする remoteNetworkConfig が含まれています。有効な remoteNetworkConfig の値については、 EKS Hybrid Nodes のドキュメント を参照してください。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: hybrid-eks-cluster region: us-west-2 version: "KUBERNETES_VERSION" # Disable default networking add-ons as EKS Auto Mode # comes integrated VPC CNI, kube-proxy, and CoreDNS addonsConfig: disableDefaultAddons: true vpc: subnets: public: public-one: { id: "PUBLIC_SUBNET_ID_1" } public-two: { id: "PUBLIC_SUBNET_ID_2" } private: private-one: { id: "PRIVATE_SUBNET_ID_1" } private-two: { id: "PRIVATE_SUBNET_ID_2" } controlPlaneSubnetIDs: [ "PRIVATE_SUBNET_ID_1" , "PRIVATE_SUBNET_ID_2" ] controlPlaneSecurityGroupIDs: [ "ADDITIONAL_CONTROL_PLANE_SECURITY_GROUP_ID" ] autoModeConfig: enabled: true nodePools: [ "system" ] remoteNetworkConfig: # Either ssm or ira iam: provider: ssm # Required remoteNodeNetworks: - cidrs: [ "172.18.0.0/16" ] # Optional remotePodNetworks: - cidrs: [ "172.17.0.0/16" ] Bash ClusterConfig ファイルを作成した後、以下のコマンドを実行して EKS クラスターを作成します。 eksctl create cluster -f cluster-configuration.yaml Bash クラスターの状態が Active になるのを待ちます。 aws eks describe-cluster \ --name hybrid-eks-cluster \ --output json \ --query 'cluster.status' Bash ハイブリッドノードの準備 EKS Hybrid Nodes は kube-proxy と CoreDNS を必要とします。以下の eksctl コマンドを実行してアドオンをインストールしてください。ハイブリッドノードには自動的に 「eks.amazonaws.com/compute-type: hybrid」というラベルが付与されます。このラベルを使用してハイブリッドノード向け、あるいは別のノードをワークロードのデプロイ対象にすることができます。EKS Hybrid Nodes で Amazon EKS アドオンをデプロイする方法の詳細は「 ハイブリッドノードのアドオンを構成する 」をご覧ください。 aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name kube-proxy aws eks create-addon --cluster-name hybrid-eks-cluster --addon-name coredns Bash AWS クラウドで少なくとも 1 つの CoreDNS レプリカを実行する場合は、CoreDNS が実行されている VPC およびノードへの DNS トラフィックを許可する必要があります。さらには、オンプレミスのリモート Pod CIDR へは、Amazon VPC のノードからルーティング可能でなければなりません。mixed モードの EKS クラスターの実行に関するガイダンスについては、 EKS Hybrid Nodes ユーザーガイド を参照してください。 オンプレミスのノードを Amazon EKS コントロールプレーンに EKS ハイブリッドノードとして登録できます。そのためには、 nodeadm という EKS Hybrid Nodes CLI をインストールします。nodeadm によって、マシンを EKS ワーカーノードに変換するために必要なコンポーネントをインストールできます。これらのコンポーネントには kubelet、containerd、 aws-iam-authenticator が含まれます。マシンに nodeadm をインストールしてノードをクラスタに接続するには、EKS Hybrid Nodes のドキュメント「 ハイブリッドノードを接続する 」にある手順に従ってください。 ハイブリッドノードでワークロードを実行する前に、互換性のある Container Network Interface (CNI)ドライバーをインストールしてください。EKS ハイブリッドノードで CNI を設定する手順は「 ハイブリッドノードの CNI を設定する 」を参照してください。 ノード登録時に、ハイブリッドノードが属するゾーンを指定するために、たとえば topology.kubernetes.io/zone のようなノードのラベルや Taints を追加するように kubelet の設定を変更できます。ワークロードのスケジューリングのために、接続されている GPU のさまざまな機能を表すラベルを追加することもできます。 GPU と非 GPU のキャパシティが混在する場合、GPU ノードに --register-with-taints=nvidia.com/gpu=Exists:NoSchedule という Taints を追加することをお勧めします。これにより、GPU ノード上に非 GPU ワークロード (CoreDNS など) がスケジュールされなくなります。 nodeadm を使用する場合の kubelet 構成の変更方法については、EKS Hybrid Nodes の ドキュメント をご確認ください。 以下の kubectl コマンドを実行して、ノードが接続され Ready 状態にあることを検証してください。 ハイブリッドノードが Ready になるには、CNI をインストールする必要があります。 ❯ kubectl get nodes -o wide -l eks.amazonaws.com/compute-type = hybrid NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME mi-1111111111111111 Ready < none > 5d v1.xx.x. 10.80 .146.76 < none > Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 mi-2222222222222222 Ready < none > 5d v1.xx.x. 10.80 .146.28 < none > Ubuntu 22.04 .4 LTS 5.15 .0-131-generic containerd://1.7.12 Bash Kubernetes 用 NVIDIA デバイスプラグインのインストール 本セクションでは、オンプレミスの EKS ハイブリッドノードに必要な NVIDIA ドライバーと NVIDIA Container Toolkit が設定されていることを前提としています。 Kubernetes デバイスプラグイン を使用すると、GPU などのシステムハードウェアを kubelet に通信できます。このウォークスルーでは NVIDIA GPU を使用するため、Kubernetes スケジューラーが GPU デバイスを公開できるように、NVIDIA デバイスプラグインをインストールする必要があります。NVIDIA ドライバと NVIDIA Container Toolkit がマシンイメージに含まれておらず、containerd が NVIDIA Container ランタイムを使用できるように設定されていない場合は、代わりに NVIDIA GPU Operator をデプロイできます。この Operator は、NVIDIA デバイスプラグインとともに、これらのコンポーネントを実行時にインストールします。 kubectl を使用して NVIDIAデバイスプラグインをインストールするには、まずデプロイメントマニフェストをダウンロードします。 https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.17.1/deployments/static/nvidia-device-plugin.yml Bash 最新バージョンについては、NVIDIA デバイスプラグインの GitHub リポジトリ を確認してください。 EKS Auto Mode では、NVIDIA デバイスプラグインをインストールする必要はありません。デバイスプラグインの DaemonSet は、GPU を搭載したハイブリッドノードでのみ実行する必要があります。ラベル eks.amazonaws.com/compute-type: hybrid を使用して、 .spec.template.spec.nodeSelector の一部として NVIDIA デバイスプラグインをハイブリッドノードを対象に更新するとともに、GPU ワーカーノードと非 GPU ワーカーノードの混在している場合は、必要に応じて追加のラベルを追加してください。 nodeSelector: eks.amazonaws.com/compute-type: hybrid Bash マニフェストを適用して NVIDIA デバイスプラグインをインストールします。 kubectl apply -f nvidia-device-plugin.yml Bash 以下のコマンドを使用して、NVIDIA デバイスプラグインの Pod が実行されていることを確認します。 kubectl get pods -n kube-system Bash NVIDIA デバイスプラグインの確認のため kube-system 内の Pod を一覧表示したとき、以下の出力が期待されます。DaemonSet は GPU を搭載したノード上でのみスケジュールされる必要があります。 NAMESPACE NAME READY STATUS kube-system nvidia-device-plugin-daemonset-mb8hw 1 /1 Running kube-system nvidia-device-plugin-daemonset-vtz8h 1 /1 Running Bash GPU ステータスが 割り当て可能なノード に表示されているかどうか検証することで、GPU が kubelet に公開されているかどうかを確認できます。 kubectl get nodes "-o=custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu" -l eks.amazonaws.com/compute-type = hybrid Bash GPU が接続されたノードをリスト表示した場合に予想される割り当て可能なノードの出力以下に示します。 NAME GPU mi-11111111111111111 1 mi-22222222222222222 1 Bash EKS Hybrid Nodes 上での推論のために NVIDIA NIM をデプロイ NVIDIA NIM をデプロイする前に、 前提条件 としてコンテナレジストリと NVIDIA API キーを設定する必要があります。 NGC_API_KEY をご自身の API キーに置き換えてください。 kubectl create secret docker-registry nvcrio-cred --docker-server = nvcr.io --docker-username = '$oauthtoken' --docker-password = $NGC_API_KEY kubectl create secret generic ngc-api --from-literal = NGC_API_KEY = $NGC_API_KEY Bash 以下のコマンドを実行して NIM Helm チャートをクローンします。 git clone https://github.com/NVIDIA/nim-deploy.git cd nim-deploy/helm Bash Helm チャートのオーバーライドを作成します。nodeSelector でハイブリッドノードにデプロイするように設定します。 cat > nim.values.yaml << EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: hybrid resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: "nvidia.com/gpu" operator: "Exists" effect: "NoSchedule" EOF Bash values.yaml ファイルのイメージリポジトリを変更することで、異なるモデルをデプロイできます。 helm install nim nim-llm/ -f ./nim.values.yaml Bash このデプロイではモデルキャッシュは使用されていません。スケーリングイベント中のアプリケーションの初期化を高速化するために、モデルキャッシュの使用を検討することをおすすめします。モデルキャッシュを実装するには、適切な CSI ドライバーの構成とストレージインフラストラクチャが必要になります。 サンプルプロンプトを使用したNIM のテスト NIM マイクロサービスをテストするには、NIM の Sercice への Kubernetes ポートフォワーディングを構成します。 kubectl port-forward service/nim-nim-llm 8000 :8000 Bash 以下の curl コマンドを実行し、出力を確認してください。 curl -X 'POST' \ "http://localhost:8000/v1/completions" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "model": "mistralai/mistral-7b-instruct-v0.3", "prompt": "What is a Kubernetes Pod", "max_tokens": 30 }' Bash 期待される応答は以下です。 { "id" : "cmpl-b50fb31c13e4420bac5243047ef5e404" , "object" : "text_completion" , "created" : 1741976435 , "model" : "mistralai/mistral-7b-instruct-v0.3" , "choices" : [ { "index" : 0 , "text" : "? \n \n A Kubernetes Pod is the smallest unit of computation in the Kubernetes API object model that represents a portion of a running application. Each" , "logprobs" : null, "finish_reason" : "length" , "stop_reason" : null, "prompt_logprobs" : null } ] , "usage" : { "prompt_tokens" : 7 , "total_tokens" : 37 , "completion_tokens" : 30 } } Bash EKS Hybrid Nodes へのモデルのデプロイが成功しました。 次に、同じ EKS クラスターで実行されている EKS Auto Mode のノードでモデルをデプロイします。 EKS Auto Mode へのデプロイ EKS ハイブリッドノードで実行する必要のないワークロードをデプロイできます。EKS Auto Mode の 組み込み NodePool には GPU ベースのインスタンスが設定されていないため、GPU を持つ NodePool を定義する必要があります。EKS Auto Mode は、NVIDIA GPU と Neuron デバイスとの 統合 を提供するので、ドライバやデバイスプラグインをインストールする必要がありません。 次のコマンドを実行して、 g6 インスタンスファミリーを使用した NodePool を作成します。 cat > nodepool-gpu.yaml << EOF apiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: disruption: budgets: - nodes: 10% consolidateAfter: 1h consolidationPolicy: WhenEmpty template: metadata: {} spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: "karpenter.sh/capacity-type" operator: In values: ["on-demand"] - key: "kubernetes.io/arch" operator: In values: ["amd64"] - key: "eks.amazonaws.com/instance-family" operator: In values: - g6 taints: - key: nvidia.com/gpu effect: NoSchedule terminationGracePeriod: 24h0m0s EOF kubectl apply -f nodepool-gpu.yaml Bash ワークロードに特定のネットワーク帯域幅やインスタンス GPU 要件がある場合は、 EKS Auto Mode でサポートされている他の Well-Known ラベル を設定することを検討してください。 以下のファイルを作成することで、EKS Auto Mode へのデプロイ用に NVIDIA NIM の値を更新します。 cat > nim.values.yaml << EOF image: repository: "nvcr.io/nim/mistralai/mistral-7b-instruct-v0.3" tag: latest model: ngcAPISecret: ngc-api nodeSelector: eks.amazonaws.com/compute-type: auto resources: limits: nvidia.com/gpu: 1 persistence: enabled: false imagePullSecrets: - name: nvcrio-cred tolerations: - key: nvidia.com/gpu effect: NoSchedule operator: Exists EOF Bash 以下のコマンドを実行して、NIM Helm リリースを新しいバージョンにアップグレードします。 helm upgrade nim nim-llm/ -f ./nim.values.yaml Bash NodeClaims をリスト表示して、EKS Auto Mode が NVIDIA NIM を提供するために g6.xlarge をそのリージョンに起動したことを確認します。 > kubectl get nodeclaims NAME TYPE CAPACITY ZONE NODE READY gpu-wq9qr g6.xlarge on-demand us-west-2b i-33333333333333333 True Bash テストするには、前のステップを繰り返し、サンプルのプロンプトで NIM をテストします。 クリーンアップ 本記事で作成したすべての AWS リソースをクリーンアップして長期的なコストを発生させないようにするには、以下のコマンドを実行してください。 helm delete nim kubectl delete -f nodepool-gpu.yaml kubectl delete -f nvidia-device-plugin.yml eksctl delete cluster -f cluster-configuration.yaml Bash 前提条件の一部として作成したその他のリソースが不要になった場合は、それらについてもクリーンアップしてください。 結論 本記事では、Amazon EKS Hybrid Nodes が AI ワークロードを実行する方法の例を紹介しました。Amazon EKS Hybrid Nodes は Kubernetes フットプリントを Amazon EKS に統合し、Kubernetes コントロールプレーンの管理の必要性をなくし、運用オーバーヘッドを削減します。 EKS Hybrid Nodes の詳細と使用方法については、 EKS Hybrid Nodes ユーザーガイド を参照してください。また、ハイブリッドノードの仕組み、機能、ベストプラクティスについて説明している re:Invent 2024 のセッション (KUB205) もご覧ください。Amazon EKS での AI/ML ワークロードの実行に関するその他のガイダンスは、 Data on EKS プロジェクト も参考にできます。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

3 月 31 日、すべての商用リージョンと AWS GovCloud (米国) リージョンのすべてのエンドポイントタイプ、カスタムドメイン、管理 API で、 Amazon API Gateway の IPv6 サポートを開始しました。REST、HTTP、WebSocket API、カスタムドメインを設定して、既存の IPv4 サポートに加えて IPv6 クライアントからの呼び出しを受け入れることができるようになりました。デュアルスタック (IPv6 と IPv4) クライアントから API Gateway 管理 API を呼び出すこともできます。世界中の組織が IPv4 アドレスの不足とコスト増加に直面する中、IPv6 の実装は、将来を見据えたネットワークインフラストラクチャの構築において必要不可欠になっています。このデュアルスタックのアプローチは、組織が将来的なネットワーク互換性を維持し、グローバルなリーチを拡大するのに役立ちます。 Amazon Web Services (AWS) 環境のデュアルスタックの詳細については、 IPv6 on AWS のドキュメントをご覧ください。 新しいデュアルスタックリソースの作成 この投稿では、デュアルスタック IP アドレスタイプを使用して API またはドメイン名を作成する方法として、 AWS マネジメントコンソール と AWS Cloud Development Kit (CDK) という 2 つの方法に焦点を当てています。 AWS コンソール コンソールで新しい API またはドメイン名を作成する場合、IP アドレスタイプとして [IPv4 のみ] または [デュアルスタック (IPv4 と IPv6)] を選択します。 次の図に示すように、新しい REST API を作成するときにデュアルスタックオプションを選択できます。 カスタムドメイン名についても、次の図に示すように、同様にデュアルスタックを設定できます。 何らかの理由で IPv4 のみに戻す必要がある場合は、IP アドレスタイプ設定を変更できます。更新を有効にするために API を再デプロイする必要はありません。 すべてのエンドポイントタイプ (EDGE、REGIONAL、PRIVATE) の REST API がデュアルスタックをサポートします。プライベート REST API はデュアルスタック設定のみをサポートします。 AWS CDK AWS CDK では、まずデュアルスタック REST API とドメイン名を設定します。 const api = new apigateway.RestApi(this, "Api", { restApiName: "MyDualStackAPI", endpointConfiguration: {ipAddressType: "dualstack"} }); const domain_name = new apigateway.DomainName(this, "DomainName", { regionalCertificateArn: 'arn:aws:acm:us-east-1:111122223333:certificate/a1b2c3d4-5678-90ab', domainName: 'dualstack.example.com', endpointConfiguration: { types: ['Regional'], ipAddressType: 'dualstack' }, securityPolicy: 'TLS_1_2' }); const basepathmapping = new apigateway.BasePathMapping(this, "BasePathMapping", { domainName: domain_name, restApi: api }); IPv6 ソース IP と認可 API が IPv6 トラフィックの受信を開始すると、クライアントソース IP は IPv6 形式になります。ソース IP アドレスを参照するリソースポリシー、Lambda オーソライザー、または AWS Identity and Access Management (IAM) ポリシーを使用する場合は、それらが IPv6 アドレス形式に対応するように更新されていることを確認してください。 例えば、リソースポリシーの特定の IPv6 範囲からのトラフィックを許可する場合などです。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "execute-api:stage-name/*", "Condition": { "IpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "2001:db8:1234::/48" ] } } } ] } まとめ API Gateway のデュアルスタックサポートは、IPv4 アドレスの不足とコストの管理、政府や業界の指示への準拠、ネットワークの将来への準備に役立ちます。デュアルスタックの実装は、IPv4 クライアントと IPv6 クライアントの両方を同時にサポートすることにより、スムーズな移行パスを提供します。 API Gateway のデュアルスタックのサポートを開始するには、 Amazon API Gateway のドキュメントをご覧ください。新しい API 用にデュアルスタックを設定したり、最小限の設定変更で既存の API を更新したりできます。 – Betty 執筆プロセス中にリソースを提供し、質問に答え、貴重なフィードバックを提供してくれた Ellie Frank (elliesf)、Anjali Gola (anjaligl)、Pranika Kakkar (pranika) に特に感謝します。このブログ記事は、Service チームと Product Management チームの共同サポートによって実現しました。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

AWS Summit のシーズンがやってきました! 現在、無料のイベントが世界中で開催されており、AWS のクラウドコンピューティングコミュニティが一堂に会してつながり、コラボレートし、学んでいます。オンライン参加か現地参加かにかかわらず、これらの会合は AWS の知識を深める貴重な機会を提供します。私は AWS Amsterdam Summit に参加するので、ぜひ皆さんにお会いしたいと思っています。参加される予定の場合は、声をかけに来てください! 今すぐ AWS Summit ウェブサイト にアクセスしてお住まいの地域のイベントを検索し、登録アラートにサインアップして、お近くの AWS Summit への参加を予約しましょう。 AWS のニュースと言えば、先週も新しい発表がありました。ではそれらを見ていきましょう。 3 月 24 日週のリリース 私が注目したリリースはこちらです。 AWS Amplify ホスティングとの AWS WAF 統合の一般提供開始 – Amplify コンソールでのワンクリック統合、または Infrastructure as Code (IaC) を使用して、 AWS Amplify アプリケーションに AWS WAF を直接アタッチできるようになりました。この統合は、SQL インジェクションやクロスサイトスクリプティング (XSS) といった一般的なウェブエクスプロイトを防ぐマネージドルールなど、AWS WAF のすべての機能へのアクセスを提供します。アプリケーションのニーズに基づいたカスタムルールを作成する、IP アドレスからのリクエストレートを制限することで分散型サービス拒否 (DDoS) 攻撃を防ぐレートベースのルールを実装する、そして特定の国からのアクセスを制限するためのジオブロッキングを設定することも可能です。ファイアウォールサポートは、Amplify ホスティングが稼働しているすべての AWS リージョン でご利用いただけます。 Amazon Bedrock のカスタムモデルインポートがリアルタイムのコスト透明性を導入 – Amazon Bedrock のカスタムモデルインポート を使用してカスタマイズされた 基盤モデル (FM) を実行している場合は、コンピューティングリソースに対する完全な透明性を実現し、推論コストをリアルタイムで計算できるようになります。モデルを呼び出す前に、 Amazon Bedrock コンソールと Amazon Bedrock API の両方を使用して、必要最小限のコンピューティングリソース (カスタムモデルユニット、つまり CMU) を確認できます。トラフィックの増加に対処するためにモデルがスケールするときは、使用された CMU の合計数を Amazon CloudWatch メトリクスでリアルタイムに把握できるため、ほぼ瞬時の可視化によるコストコントロールの改善が可能になります。これは、モデル構成をその場で変更してコストを最適化するために役立ちます。この機能は、Amazon Bedrock のカスタムモデルインポートがサポートされているすべてのリージョンでご利用いただけます。詳細については、Amazon Bedrock ユーザーガイドの「 Calculate the cost of running a custom model 」を参照してください。 Amazon Bedrock ナレッジベースがベクトルストレージ用の Amazon OpenSearch マネージドクラスターのサポートを開始 – Amazon Bedrock ナレッジベース は、 検索拡張生成 (RAG) 用の企業データソースに FM をセキュアに接続することで、関連性と正確性の高い応答を提供します。今回のリリースにより、Amazon Bedrock ナレッジベースの全機能を使用しながら、 Amazon OpenSearch マネージドクラスター をベクトルデータベースとして使用できるようになります。この統合により、既に Amazon OpenSearch Serverless 、 Amazon Aurora 、 Amazon Neptune Analytics 、Pinecone、MongoDB Atlas、および Redis が含まれるサポート対象ベクトルデータベースのリストがさらに拡大されます。ベクトルデータベースとのネイティブな統合は、カスタムデータソース統合を構築する必要性の軽減に役立ちます。この機能は、Amazon Bedrock ナレッジベースと OpenSearch サービスのすべての既存リージョンで一般提供されます。 Amazon Bedrock ガードレールが業界トップクラスの画像コンテンツフィルターの一般提供を発表 – この新機能は、業界トップクラスのテキストおよび画像コンテンツセーフガードを提供する機能で、カスタムセーフガードを構築したり、エラーが発生しやすい手動によるコンテンツ管理に頼ったりすることなく、有害なマルチモーダルコンテンツを最大 88% ブロックするために役立ちます。画像コンテンツフィルターは、コンテンツフィルターポリシー内のすべてのカテゴリー (憎悪、侮辱、性的、暴力、不正行為、プロンプト攻撃など) 全体に適用できます。 Amazon Bedrock ガードレール は、有害なコンテンツやプロンプト攻撃の検出とブロック、特定のトピックを拒否して禁止するためのトピックの定義、個人データなどの個人を特定できる情報 (PII) の削除、特定の単語のブロックを実行するための設定可能なセーフガードを提供します。また、自動推論チェックを使用することで、モデルハルシネーションを検出してブロックし、モデルの応答や主張の関連性を特定して、モデルの応答に含まれる事実に基づく主張を識別、修正、説明するためのコンテキストグラウンディングチェックも提供します。この機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、およびアジアパシフィック (東京) の各リージョンで一般提供されます。詳細については、AWS 機械学習ブログの「 Amazon Bedrock Guardrails image content filters provide industry-leading safeguards 」、および Amazon Bedrock ユーザーガイドの「 Stop harmful content in models using Amazon Bedrock Guardrails 」を参照してください。 Amazon Q in QuickSight のシナリオ機能の一般提供開始 – 隠れた傾向を明らかにすることでデータ分析をガイドするこの機能は、自然言語でのやり取りを通じてビジネスに関する推奨事項を提供し、より詳しく調査するための次のステップをインテリジェントに提案します。この機能を使用することで、専門的なスキルやアナリストのサポート、またはスプレッドシート内のデータの手動での操作を必要とすることなく、過去の傾向の調査、将来のシナリオの予測、ソリューションのモデル化を実行できるようになります。直感的なインターフェイスとステップバイステップのガイダンスを提供する Amazon Q in QuickSight のシナリオ機能は、複雑なデータ分析をスプレッドシートよりも最大 10 倍速く実行できるようにします。行っているのがマーケティング予算の最適化、サプライチェーンの合理化、または投資の分析であるかにかかわらず、Amazon Q は高度なデータ分析を実行しやすくすることで、組織全体でのデータ主導の意思決定を可能にします。この機能はどの Amazon QuickSight ダッシュボードからでもアクセスできるため、データの視覚化から what-if 質問や代替案の比較へとシームレスに移行できます。以前に行った分析の変更、拡張、再利用も簡単に実行できるため、変化するビジネスニーズへの迅速な適応に役立ちます。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 アジアパシフィック (ムンバイ) および欧州 (パリ) AWS リージョンで Amazon DataZone の提供を開始 – Amazon DataZone は、組織内のデータプロデューサーとコンシューマー間でデータをカタログ化、検出、分析、共有、制御するための、完全マネージド型のデータ管理サービスです。 アジアパシフィック (ムンバイ) および欧州 (パリ) AWS リージョンで次世代 Amazon SageMaker の提供を開始 – Amazon SageMaker は、あらゆるデータ、分析、AI のための拠点です。SageMaker Unified Studio は、AWS の分析ツールと AI/ML ツールを統合する単一の開発環境を提供します。 メキシコ (中部) およびアジアパシフィック (タイ) AWS リージョンで Amazon Redshift Query Editor V2 の提供を開始 – Amazon Redshift Query Editor V2 は、データアナリスト、データサイエンティスト、データベース開発者などの SQL ユーザー向けのウェブベースのツールを使用して、 Amazon Redshift データウェアハウスとデータレイク内のデータへのアクセス性を向上させます。 Amazon Keyspaces がすべての AWS リージョンをサポートするためにマルチリージョンレプリケーションを拡張 – Amazon Keyspaces (Apache Cassandra 向け) は拡張性と可用性に優れたマネージド型の Cassandra 互換データベースで、既存のアプリケーションコードと開発者ツールを使用した AWS での Cassandra ワークロードの実行に役立ちます。 アジアパシフィック (タイ) およびメキシコ (中部) AWS リージョンで AWS Network Firewall の提供を開始 – AWS Network Firewall は、トラフィックに合わせて自動的にスケールするマネージド型ファイアウォールサービスで、インフラストラクチャのメンテナンスを一切必要とせず、複数の AWS アカウント全体での一元化されたポリシーコントロールのために AWS Firewall Manager と統合します。 イスラエル (テルアビブ) およびアジアパシフィック (香港) AWS リージョンで Amazon CloudWatch RUM の一般提供を開始 – CloudWatch RUM は、クライアント側のパフォーマンスデータをリアルタイムで収集し、エンドユーザーエクスペリエンスメトリクス (異なるジオロケーション、ブラウザ、デバイス全体でのページ読み込み異常、コアウェブバイタル、エラーなど) を表示するダッシュボードを提供することで、ウェブアプリケーションを監視します。 アジアパシフィック (タイ) およびメキシコ (中部) AWS リージョンで Amazon VPC IP Address Manager の提供を開始 – AWS ワークロードの IP アドレスを簡単に計画、追跡、監視できるようにする Amazon Virtual Private Cloud (Amazon VPC) IP Address Manager (Amazon VPC IPAM) は、ルーティングとセキュリティのニーズに基づいたアドレスの分類や、IP アドレスの割り当てを規定するシンプルなビジネスルールの設定に役立ちます。 アジアパシフィック (シドニー) AWS リージョンで Amazon Q Business の提供を開始 – Amazon Q Business は、情報を探し出し、インサイトを獲得して、職場でアクションの実行するための、最も高度な能力を備えた生成 AI 駆動のアシスタントで、エンタープライズシステム内のデータと情報に基づいて質問に答え、要約を提供し、コンテンツを生成して、タスクをセキュアに完了することができます。 米国東部 (バージニア北部) とアジアパシフィック (ジャカルタ) AWS リージョンで Amazon EC2 P5en インスタンスの提供を開始 – P5en インスタンスには、メモリサイズが 1.7 倍の H200 GPU が 8 個搭載されており、第 4 世代 Intel Xeon プロセッサと Gen5 PCIe との組み合わせで 4 倍の CPU-GPU 帯域幅を実現します。これは、深層学習、生成 AI、リアルタイムのデータ処理、ハイパフォーマンスコンピューティング (HPC) などの用途における分散型トレーニングワークロードの集団通信パフォーマンスの向上に役立ちます。 米国西部 (北カリフォルニア) AWS リージョンで Amazon EC2 R8g インスタンスの提供を開始 – より大きなインスタンスサイズを提供するこれらのインスタンスは、AWS Graviton3 ベースの R7g インスタンスよりも最大 3 倍多い vCPU (最大 48xlarge) とメモリ (最大 1.5 TB) を備えています。Graviton3 ベースの R7g インスタンスと比較した場合、これらのインスタンスはウェブアプリケーションで最大 30%、データベースで最大 40%、大規模な Java アプリケーションで最大 45% 高速になります。 アジアパシフィック (東京) AWS リージョンで Amazon EC2 C8g インスタンスの提供を開始 – これらのインスタンスは、Graviton3 ベースの Amazon C7g インスタンスよりも最大 3 倍多い vCPU とメモリを使用する、より大きなインスタンスサイズを提供します。AWS Graviton3 プロセッサと比較した場合、AWS Graviton4 プロセッサは、データベースで最大 40%、ウェブアプリケーションで最大 30%、大規模な Java アプリケーションで最大 45% 高速になります。 メキシコ (中部) および アジアパシフィック (タイ) AWS リージョンで Amazon SageMaker AI の提供を開始 – Amazon SageMaker AI は、より迅速に機械学習 (ML) モデルを構築、トレーニング、デプロイする能力をすべての開発者とデータサイエンティストに提供する、完全マネージド型のプラットフォームです。 Amazon ElastiCache がアジアパシフィック (ジャカルタ) およびアジアパシフィック (ハイデラバード) AWS リージョンで AWS PrivateLink のサポートを開始 – AWS PrivateLink は、トラフィックをパブリックインターネットに公開したり、ネットワークトラフィックをセキュア化したりすることなく、VPC、AWS サービス、およびオンプレミスネットワーク間のプライベート接続を提供します。 Amazon ElastiCache で AWS PrivateLink を使用するには、 Amazon VPC コンソール 、 AWS SDK 、または AWS コマンドラインインターフェイス (AWS CLI) を使用して、VPC 内にある Amazon ElastiCache 用の インターフェイス VPC エンドポイント を作成します。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日中に開催されるすべての AWS 主催の対面およびバーチャルイベント は、こちらで閲覧できます。 3 月 31 日週のニュースは以上です。4 月 7 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

(本記事は 2024/11/03に投稿された Pre-warming Amazon DynamoDB tables with warm throughput を翻訳した記事です。翻訳は SA の嶋田朱里が担当しました。) Amazon DynamoDB は需要に応じて自動的にスケーリングできることで有名な NoSQL データベースです。しかし、ユースケースによっては、テーブルを作成した瞬間から大量のトラフィックを処理する必要がある、または今後のイベントに備えて突発的なトラフィックの増加に対応する必要がある場合があります。このような場合に対応するために、新機能として ウォームスループット が導入されました。この機能により、DynamoDB テーブルとインデックスが即座にサポート可能なスループットを把握し、パフォーマンスを最適化するための事前ウォーミングを行うことが可能になります。 この記事では、ウォームスループットについて、その仕組みを説明し、高トラフィックシナリオを処理する際のメリットを紹介します。また、この機能を DynamoDB テーブルとインデックスで最大限活用するためのベストプラクティスと実践的なユースケースについても説明します。 DynamoDB のキャパシティモード ウォームスループットについて説明する前に、 DynamoDB のキャパシティモードとスループットについて復習しましょう。 プロビジョンドキャパシティモードでは、予測可能なワークロードに対して、特定のスループットを設定できます。一方、オンデマンドモードは需要に合わせて自動的にスケーリングするため、予測不可能なワークロードに適しています。スループットは、Read Capacity Unit (RCU) と Write Capacity Unit (WCU) で測定されます。RCU は 1 秒あたり 4 KB の読み取りを、WCU は 1 秒あたり 1 KB の書き込みを可能にします。 詳細については、開発者ガイドの DynamoDB スループットキャパシティ を参照してください。 ウォームスループットとは ウォームスループットは、テーブルまたはインデックスがすぐにサポートできる読み取りおよび書き込み操作について、インサイトを提供します。これらの値は使用量が増加するにつれて大きくなります。また、より高いウォームスループット値を積極的に設定することで、テーブルまたはインデックスをあらかじめ事前ウォーミングすることもできます。この方法は、商品の発売、フラッシュセール、大規模なオンラインイベントなど、瞬間的なトラフィックの急増が予想されるシナリオで特に有益です。次のビデオでは、ウォームスループットを使用して、テーブルとインデックスをあらかじめ事前ウォーミングしておくことで、商品の発売やフラッシュセールなどの重要なイベント中に生じる、大量のトラフィックの急増を効果的に処理し、レイテンシーの削減とアプリケーションの応答性向上を実現する方法を紹介しています。 ウォームスループットの理解 ウォームスループット値は、DynamoDB テーブルのスループットキャパシティの最大値を示すものではありません。むしろ、テーブルが即座に処理できる最小スループットを表しています。テーブルをあらかじめ事前ウォーミングすることで、テーブルが即座にサポートできる読み取りと書き込みの数を設定し、特定レベルのトラフィックに処理開始時から対応できるようにします。 テーブルの事前ウォーミングは非同期で行われ、他の操作を妨げることはありません。そのため、事前ウォーミング処理と同時に、他のテーブルへの更新を実行することができます。この柔軟性により、アクティブな事前ウォーミング操作中でも、更新された値を含む新しいリクエストを送信することで、いつでも簡単にウォームスループット値を調整できます。事前ウォーミング処理の完了に要する時間は、要求されたウォームスループット値とテーブルまたはインデックスのストレージサイズによって異なります。 DynamoDB のスケーリング機能は最初の事前ウォーミングだけでなく、アプリケーションの成長に合わせて動的に調整されます。時間の経過とともにワークロードが増加すると、DynamoDB は自動的にウォームスループット値を高めて、より多くのトラフィックに対応できるようになり、手動の介入なしに一貫したパフォーマンスを確保できるようになります。 例えば 1 秒あたり 10 万件の書き込みリクエストに対応するようにテーブルを事前ウォーミングした場合、そのテーブルはすぐにそのトラフィックを処理できるようになります。例えばアプリケーションのトラフィックが増加し、1 秒あたり 15 万件の書き込みリクエストに達した場合、DynamoDB はこの追加の負荷に対応するために自動的にスケーリングを行います。アプリケーションの成長ニーズに応じて、シームレスにテーブルを対応できるようにします。ウォームスループット値はテーブルの現在のキャパシティとパフォーマンス能力を正確に反映するように調整されます。 ウォームスループット値を追跡し、時間の経過とともにどのように変化するかを確認するには、 DescribeTable API を使用します。この API は、テーブルとグローバルセカンダリインデックスの両方について、現在のウォームスループット値に関する詳細情報を提供します。そのため、トラフィックパターンと将来の要件に基づいた積極的な調整に役立てることができます。 事前ウォーミングの一般的なユースケース DynamoDB テーブルの事前ウォーミングが必要かどうかを判断する前に、アプリケーションが必要とするピークスループットを理解することが重要です。ピークスループットを見積もることで、予想される負荷を DynamoDB テーブルで処理できるように準備することができ、スロットリングやパフォーマンスの問題を回避できます。以下はアプリケーションのピークスループットを計算し、事前ウォーミングが必要かどうかを判断するためのガイドです。これらのステップはオンデマンドキャパシティモードとプロビジョンドキャパシティモードのどちらのテーブルにも適用されます。 Step1：ワークロードパターンの理解 ピークスループットを計算する最初のステップは、ワークロードのトラフィックパターンを明確に理解することです。以下を考慮してください: 操作の種類 : 主に読み取りリクエストと書き込みリクエストのどちらを処理しますか、それとも両方のリクエストを処理しますか？ トラフィックの性質 : 予測可能なピーク時間帯 (例えば、日次や週次のパターン) はありますか、それとも不定期な急増 (例えば、フラッシュセール、商品の発売、主要なイベントなど) がありますか？ Step2：秒間のピークリクエスト数の見積もり ワークロードを理解したら次のステップは、アプリケーションがピーク時に処理する必要がある 1 秒あたりの読み取りリクエストと書き込みリクエストの数を見積もることです。これには 2 つの方法があります。 過去のデータ : アプリケーションがすでに本番環境で稼働している場合は、トラフィックログやモニタリングデータを確認して、ピーク時の 1 秒あたりの最大読み取りリクエスト数と書き込みリクエスト数を特定します。これらの値をピークスループットの計算の基準として使用します。 予測 : 将来のイベントやリリースに備える場合は、想定されるトラフィックの増加を予想し、ピークスループットを見積もります。ユーザー数、ユーザーあたりの予想アクション数 (商品の閲覧回数や取引回数など)、ピーク時間の長さを考慮します。 Step3：読み取りと書き込みのキャパシティユニットの計算 リクエスト数の推定値を取得したら、DynamoDB テーブルに必要な読み取りリクエストユニット (RRU) と書き込みリクエストユニット (WRU) を計算できます。この例では、オンデマンドキャパシティモードの値を使用していますが、プロビジョンドキャパシティモードのテーブルでも同様のプロセスになります。 RRU : 強い整合性の読み取りの場合、 1つのアイテム (最大 4 KB) を読むために 1 RRU が消費されます。結果整合性の読み取りの場合、 1 つの RRU で 2 つの読み取りリクエスト (最大 4 KB) が可能です。RRU を計算するには: アイテムの平均サイズを KB で計算する アイテムの平均サイズを 4 で割る 1 秒あたりの読み取りリクエスト数を掛ける 結果整合性の読み取りか強い整合性の読み取りかに基づいて調整する 注: 小さいアイテムを扱う場合、強い整合性の読み取りリクエストでは 1 RRU、結果整合性の読み取りリクエストでは 0.5 RRU を消費する WRU : 1 つのアイテム (最大 1 KB) を書き込むために 1 つの WRU が消費されます。WRU を計算するには: アイテムの平均サイズを KB で計算する 1 秒あたりの書き込みリクエスト数を掛ける キャパシティユニットの詳細については、 開発者ガイド を参照してください。 Step4：変動性を考慮する 大抵の場合、トラフィックは一定ではないため、最初の見積もりを超えるトラフィックの急増に備えることも重要です。予期しないスパイクに対応できるよう、ピークスループットの計算にはバッファを追加することを検討してください。 例えばピーク時に 80,000 WRU/秒と見積もった場合、需要の急増に対応するために 100,000 WRU/秒で事前ウォーミングを行うことを検討してください。ただし、余裕を持って事前ウォーミングを行うと、追加コストが発生する可能性があります。 Step5：事前ウォーミングの必要性の判断 ピーク時の RRU と WRU を計算したら、これらの値をテーブルの現在のウォームスループット値と比較します。計算されたピークスループットが現在のウォームスループット値を大幅に上回る場合、または即時のトラフィックの急増 (商品の発売時やフラッシュセールなど) が予想される場合は、事前ウォーミングをお勧めします。これにより、テーブルがピークトラフィックに対応でき、パーティションの容量制限を超えた場合に発生する可能性のあるスロットリングを回避できます。システムが需要を満たすために対応する過程で、スロットリングやパーティション分割が発生すると、クライアントのレイテンシーが上昇することがあります。 ユースケース例 ウォームスループットの概念を紹介したので、次にこの機能が特に有益となる実際のユースケースを見ていきましょう。 高トラフィックに備えた新しいオンデマンドテーブルの準備 新しい DynamoDB オンデマンドテーブルは、初期のウォームスループットとして、毎秒 4,000 件の書き込みリクエストと 12,000 件の読み取りリクエストで開始します。新しいアプリケーションの起動時など、トラフィックが突然増加した場合、増加する需要を満たすために、DynamoDB は容量を徐々に拡張します。ただし、テーブルの書き込み要求が瞬時に 1 秒あたり 4,000 件を超えた場合、スケーリング処理中に一部のリクエストが スロットリング する可能性があります。このスロットリングにより、レイテンシーが増加したり、障害が発生したりして、ユーザー体験に影響が生じ、結果として収益が失われる可能性があります。 これらの問題を防ぐため、リリース時に高トラフィックが予想される場合は、テーブルを事前ウォーミングしておくことが推奨されます。事前ウォーミングにより、想定される負荷をテーブルが即座に処理できるようになり、スロットリングのリスクが低減します。DynamoDB のリアクティブなスケーリングするのを待つことなく、シームレスなユーザー体験を提供できます。 次のグラフは、新しいオンデマンドテーブルに対して実施された負荷テストを示しています。テーブルが予想以上のスループット(青線)に対応するためにスケールされるまで 、過剰なスロットリング(オレンジ線)が発生しました。 あらかじめ事前ウォーミングをすると、1 秒あたり 100,000 件の書き込みリクエストのベースラインを設定できます。DynamoDB はこのレベルのトラフィックを即座に処理できるようにテーブルをスケーリングするため、スケーリングの遅延がなくなり、スロットリングのリスクを軽減できます。 この事前準備により、ピーク時の需要でも顧客が迅速に取引を完了できるスムーズなユーザー体験を実現できます。リクエストの失敗、パフォーマンスの低下、スケーリングの遅延を心配する必要はなく、システムがイベントに備えられているという確信を得ることができます。 次のグラフは、前回と同じ負荷テストを実施したものですが、今回はテーブルを 100,000 WRU で事前ウォーミングしています。テーブルはすでにスケールアウトされ、スループットを処理する準備ができていたため、スロットリングは発生しませんでした。 大規模イベントへの準備 あなたは E コマース企業で、1 年の中で最もトラフィックが多いイベントの 1 つであるスーパーボウルの期間中に、フラッシュセールを準備しているとします。 すでに DynamoDB テーブルを用意しており、リクエストを処理できる状態にしていますが、予想されるトラフィックの急増を考えると、テーブルがその負荷に耐えられるかを確認することが重要です。推定に基づき、このイベントの最大トラフィックは 10% のバッファを含めて、100,000 件/秒の書き込みリクエストに達する可能性があると計算しました。 準備として、まず上記のように予想される負荷を計算し、現在のテーブルのウォームスループット値と比較します。推定されるピーク値が既存のウォームスループット値を上回る場合は、テーブルの事前ウォーミングが推奨されます。これにより、テーブルがトラフィックを即座に処理できるよう準備され、このような需要の高いイベント中にスロットリングや遅延が発生するリスクを軽減できます。 DynamoDB への移行の準備 既存のアプリケーションを DynamoDB に移行する際、移行開始時からテーブルが予想されるトラフィックに対応できるよう準備しておくことが、スムーズな移行のために重要です。従来のリレーショナルデータベースや他の NoSQL ソリューションから移行する場合、抽出、変換、ロード (ETL) ジョブが DynamoDB に書き込む際に、大量のデータとトラフィックの急増に対処する必要があります。 必要なキャパシティを DynamoDB テーブルにあらかじめ事前ウォーミングしておくことで、すぐに予想されるトラフィックを処理できるようになり、移行時に発生するかもしれない読み取りおよび書き込みリクエストの急増にもすぐに対応できるようになります。特にダウンタイムやパフォーマンス低下への余裕がほとんどない場合には、事前ウォーミングによって移行に伴う不確実性を排除できます。データを移行する際、DynamoDB は予想されるスループットのレベルまでスケーリングできるため、アプリケーションは高トラフィックを即座に処理することができます。 高トラフィックの E コマースプラットフォームや重要なエンタープライズワークロードを移行する場合でも、テーブルのウォームスループットの値を増やしておくことで、アプリケーションに必要なパフォーマンスのベースラインが保証され、ユーザがシステムとやり取りを開始する際の潜在的なスロットリングや遅延の問題を回避することができます。ウォームスループットのメリットとユースケースについて説明したので、続いて設定方法を説明します。 ウォームスループットの設定方法 AWS マネジメントコンソール、 AWS Command Line Interface (AWS CLI)、または Software Development Kit を利用することで、事前に大量のトラフィックに備えるための設定を行うことができます。 AWS マネジメントコンソールを使用した、ウォームスループット値の設定 DynamoDB コンソールに移動し、 Create table を選択します。 テーブルの主キー属性を指定します。 Table settings の下で、 Customize settings を選択します。 Read/write capacity settings で、 On-demand を選択します。 Warm Throughput に予想される最大の読み取りリクエスト数と書き込みリクエスト数を入力します。 テーブル作成を完了させます。 既存のテーブルまたはインデックスにウォームスループット値を適用する方法については、 開発者ガイド を参照してください。 AWS Command Line Interface (AWS CLI) を使用した、ウォームスループット値の設定 aws dynamodb create-table \     --table-name FlashSaleTable \     --attribute-definitions AttributeName=ProductID,AttributeType=S \     --key-schema AttributeName=ProductID,KeyType=HASH \     --billing-mode PAY_PER_REQUEST \     --warm-throughput ReadUnitsPerSecond=50000,WriteUnitsPerSecond=100000         ...         "WarmThroughput": {             "ReadUnitsPerSecond": 50000,             "WriteUnitsPerSecond": 100000,             "Status": "UPDATING"         },         ... ベストプラクティス 事前ウォーミングのベストプラクティスは次のとおりです。 正確に見積もる : 過去のトラフィックパターンを分析したり、予測ツールを使用したりして、ピークスループットを正確に見積もります。 重要なテーブルに適用する : 注目度が高く、即時のトラフィックスパイクが予想されるイベントやアプリケーションをサポートするテーブルに焦点を当てます。 必要に応じて調整する : ワークロードの要件に対する理解を深めながら、テーブルの事前ウォーミングを調整します。 ウォームスループット値の監視 DynamoDB テーブルの現在の機能を理解し管理することは、大規模なイベントの前に特に重要です。DescribeTable API を使用すると、オンデマンドモードとプロビジョンドモードのすべてのテーブルで、ウォームスループットの値を監視できます。この呼び出しにより、現在のテーブルのウォームスループット値が提供されるため、大きなトラフィックイベントの前にすべてが適切に設定されているかを確認できます。 aws dynamodb describe-table --table-name FlashSaleTable      ...      "WarmThroughput": {             "ReadUnitsPerSecond": 50000,             "WriteUnitsPerSecond": 100000,             "Status": "ACTIVE"         },      ... これらの設定を定期的に確認することで、大規模な処理に対して自信を持って備えることができ、DynamoDB テーブルは常に最高のパフォーマンスを発揮できるようになります。 ウォームスループットの互換性 ウォームスループットは、グローバルセカンダリインデックスやグローバルテーブルなどの DynamoDB の重要な機能と完全に統合されており、システム全体で一貫したパフォーマンスを確保するのに役立ちます。 セカンダリインデックス グローバルセカンダリインデックス (GSI) の場合、ウォームスループットの値を個別に指定できるため、ワークロードの要件に合わせてパフォーマンスを細かく調整できます。ベーステーブルから GSI への書き込みレプリケーションでボトルネックを回避するには、GSI の WriteUnitsPerSecond をベーステーブルと同等以上の値に設定することをお勧めします。ただし、インデックスのパーティションキーまたはソートキーのいずれか、あるいは両方を頻繁に更新する場合は、書き込み競合を防いで最適なパフォーマンスを実現するために、 WriteUnitsPerSecond をベーステーブルの値の 1.5 倍に増やすことをお勧めします。 次のコード例は、GSI に事前ウォーミングを設定する方法を示しています。 aws dynamodb update-table \ --table-name FlashSaleTable \ --attribute-definitions AttributeName=GSI1PK,AttributeType=S \ --global-secondary-index-updates '[     {         "Create": {             "WarmThroughput": {                 "ReadUnitsPerSecond": "12000",                 "WriteUnitsPerSecond": "100000",             },             "IndexName": "GSI1",             "KeySchema": [                 {                     "AttributeName": "GSI1PK",                     "KeyType": "HASH"                 }              ],             "Projection": {                 "ProjectionType": "ALL"             },         }     } ]' グローバルセカンダリインデックスを更新する手順については 開発者ガイド を参照してください。 DynamoDB グローバルテーブル ウォームスループットは DynamoDB Global Tables v2019.11.21 (現行) と完全に互換性があり、一貫したパフォーマンスでグローバルワークロードを効率的に管理できます。レプリカがあるすべての AWS リージョンでテーブルを事前ウォーミングできます。そのため、ユーザーの地理的位置に関係なく、高トラフィックを同時に処理できるようになります。 デフォルトでは、ウォームスループット値を更新するリクエストは、読み取りと書き込みのどちらの操作においても、すべてのレプリカ間で自動的に同期されます。そのため、すべてのリージョンで一貫したパフォーマンスが実現されます。 Infrastructure as Code (IaC) ウォームスループットの主なメリットの 1 つとして AWS CloudFormation などのインフラストラクチャーコード (IaC) ツールとの統合があります。以前はオンデマンドの DynamoDB テーブルを事前ウォーミングするには、複数のステップが必要でした。テーブルをプロビジョンドモードに切り替え、手動でキャパシティを増やし、一定期間後にオンデマンドモードに戻す必要がありました。この方法で目的は達成できますが、複数回のデプロイと調整が必要でした。 ウォームスループットを使えば IaC を利用した DynamoDB テーブルの管理が大幅に簡単になります。テーブル作成時にウォームスループットの値を渡すことで、テーブルをあらかじめ事前ウォーミングできるようになりました。これにより手動の介入や複雑なワークフローが不要になり、IaC テンプレート内で直接、テーブルのパフォーマンスベースラインを定義できるようになります。 次の CloudFormation テンプレートは、オンデマンド ( PAY_PER_REQUEST ) モードで FlashSaleTable という名前の DynamoDB テーブルを定義しています。このテーブルには String 型の ProductID という主キーがあります。 WarmThroughput は、最初の ReadUnitsPerSecond を 50,000 RCU、 WriteUnitsPerSecond を 100,000 WCU に設定しています。 AWSTemplateFormatVersion: 2010-09-09 Resources:   TestTableTemplate:     Type: 'AWS::DynamoDB::Table'     Properties:       TableName: FlashSaleTable       BillingMode: PAY_PER_REQUEST       AttributeDefinitions:         - AttributeName: ProductID           AttributeType: S       KeySchema:         - AttributeName: ProductID           KeyType: HASH       WarmThroughput:         - ReadUnitsPerSecond: 50000           WriteUnitsPerSecond: 100000 次のテンプレートでは、eu-west-1 と eu-west-2 リージョンにレプリケートされた、FlashSaleTable という名前の DynamoDB グローバルテーブルを作成します。単一リージョンの例と同様に、 WarmThroughput を 50,000 RCU、100,000 WCU に設定しています。 AWSTemplateFormatVersion: 2010-09-09 Resources:   TestTableTemplateGlobal:     Type: 'AWS::DynamoDB::GlobalTable'     Properties:       TableName: FlashSaleTable       AttributeDefinitions:         - AttributeName: ProductID           AttributeType: S       BillingMode: PAY_PER_REQUEST       KeySchema:         - AttributeName: ProductID           KeyType: HASH       WarmThroughput:         ReadUnitsPerSecond: 50000         WriteUnitsPerSecond: 100000       Replicas:         - Region: eu-west-1         - Region: eu-west-2       StreamSpecification:         StreamViewType: NEW_AND_OLD_IMAGES ウォームスループットの料金 ウォームスループットの料金は、テーブルが配置されている特定のリージョンでプロビジョニングされた WCU と RCU のコストに基づきます。テーブルを事前ウォーミングする場合、コストは新しい値と現在のテーブルまたはインデックスがサポートしているウォームスループットの差に基づいた 1 回限りの料金として計算されます。 デフォルトでは、オンデマンドテーブルのウォームスループットのベースラインは 4,000 WCU と 12,000 RCU です。新しく作成したオンデマンドテーブルを事前ウォーミングする場合、指定した値とこれらのベースライン値の差分のみが課金されます。 例えば既存のテーブルを 40,000 WCU と 40,000 RCU で事前ウォーミングする場合、テーブルにすでに 10,000 WCU と 12,000 RCU が設定されていれば、追加で必要な 30,000 WCU と 28,000 RCU に対して 1 回限りの課金が発生します。事前ウォーミングでは、テーブルが現在使用しているテーブルクラスやキャパシティモードに関係なく、Standard テーブルクラスのプロビジョンドキャパシティが使用されます。 バージニアリージョン (us-east-1) のコストは次のとおりです。 - $0.00065 per WCU - $0.00013 per RCU 計算式: - 30,000 write units * $0.00065 = $19.50 - 28,000 read units * $0.00013 = $3.64 合計金額: $23.14 これにより、テーブルはスケーリングの遅延なしに即座に大量のトラフィックを処理できるようになります。また、課金は設定したキャパシティに対してにのみ生じます。コストを適切に管理するには、予想されるスループットの需要を正確に見積もり、それに応じてあらかじめ事前ウォーミングを実施することが重要です。詳細については、 DynamoDB 料金ガイド を参照してください。 まとめ ウォームスループットは DynamoDB テーブルを作成した瞬間から、または既存のテーブルに対して、高トラフィックに備えるために使用できる新機能です。新商品の発売やスーパーボウルなどの大規模なオンラインイベントに備える際、ウォームスループットは信頼性の高い、一貫したパフォーマンスを提供するテーブルの用意を確実に支援します。 ウォームスループットの詳細については Amazon DynamoDB 開発者ガイド を参照してください。 著者について Lee Hannigan は、アイルランドのドネゴールに拠点を置く Sr. DynamoDB Specialist Solutions Architect です。分散システムに関する豊富な専門知識を持ち、ビッグデータと分析技術の強固な基盤を備えています。Sr. DynamoDB Specialist Solutions Architect として、 DynamoDB の機能を活用したワークロードの設計、評価、最適化を支援することが得意です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 4 月 3 日 (木) 14:00-16:00 に、 流通小売/消費財/EC 企業向けのオンラインセミナー を開催します。 リテールテック JAPAN は、開催 41 回目を迎える国内最大の流通業向け情報システム総合展示会（日本経済新聞社主催）です。こちらの展示会に AWS が 8 年ぶりに出展しました。オンラインセミナーでは、AWS ブースの展示テーマ、展示デモのバーチャル・ブースツアー、ミニシアターで行われたライトニングトークなど改めてご紹介します。ご登録の上、ぜひご視聴ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年3月24日週の主要なアップデート 3/24(月) Amazon Q in QuickSight のシナリオ機能が一般提供開始 Amazon Q in QuickSight のシナリオ機能が一般提供開始になりました。アシスタント生成 AI が搭載されたシナリオ機能では、自然言語でビジネス上の課題などを与えることで、それに対するデータ活用やインサイトなどを得ることが出来ます。例えば「売上を上げるための施策はどういったことが考えられますか？」といった抽象的なテキストを投げると、QuickSight で作成したダッシュボードを基に、地域別、製品カテゴリ別、ディスカウントの傾向分析などをアシスタント生成 AI が自動的に行ってくれ、インサイトを出してくれます。100 % 正しいものではないですが、気が付かなかったインサイトを発見することができ、その後のアクションのきっかけにしていただけると思います。手元で触った範囲ですが、「日本語で出力してください」とテキストで依頼すると、日本語で出力することを確認できました。リージョンは、バージニア北部、オレゴン、フランクフルト、アイルランドで利用可能です。 AWS Elemental MediaConnect が NDI® 出力のサポートを追加 AWS Elemental MediaConnect で、NDI® (Network Device Interface) の出力をサポートしました。NDI は高品質かつ低遅延のビデオ接続技術であり、ライブプロダクションアプリケーションで広く使用され、500 以上のハードウェア製品と 300 以上のソフトウェアアプリケーションでサポートされています。カメラなどのオンプレミスソースをクラウドでのライブプロダクションに接続するプロセスが、従量課金制の価格モデルを使用することで、より簡単に展開できます。 AWS DMS Schema Conversion が IBM Db2 for z/OS から Amazon RDS for Db2 の変換をサポート AWS DMS Schema Converison は、データベースの移行を行う際に、移行元のデータベースを自動的に評価し、移行先のデータベースサービスと互換性のある形式に変換して、移行に伴う負担を軽減できます。今回のアップデートで、IBM Db2 for z/OS から Amazon Relational Database Service (RDS) for Db2 への変換をサポートしました。ストアドプロシージャ、関数、ビューなどのデータベースオブジェクトを自動的に変換できます。特に、環境間の構文の違いや互換性の違いを解決でき、メインフレーム移行に便利に利用できます。 3/25(火) Amazon OpenSearch Service で OR2 と OM2 のインスタンスタイプをサポート Amazon OpenSearch Service で 2 つの新しいインスタンス、OR2 と OM2 をサポートしました。新世代の OpenSearch 最適化インスタンスは OR1 インスタンスと同じアーキテクチャを使用し、より良い価格性能を提供するものです。OR2 インスタンスは、以前の OR1 インスタンスと比較して最大 26% 高いインデックス作成スループットを提供し、R7g インスタンスと比較して 70% 向上しています。OM2 インスタンスは、内部ベンチマークにおいて OR1 インスタンスと比較して最大 15% 高いインデックス作成スループットを提供し、M7g インスタンスと比較して 66% 向上しています。 Amazon RDS for SQL Server が Teradata データベースへのリンクサーバをサポート Amazon RDS for SQL Server が、Teradata データベースへのリンクサーバをサポートするようになりました。リンクサーバは、外部のリモートデータベースサーバーからデータを読み取り、コマンドを実行できるようにする SQL Server の機能です。この発表により、RDS for SQL Server インスタンスを AWS 上または社内で実行されている Teradata データベースにリンクできるようになります。 3/26(水) AWS Amplify Hosting が AWS WAF の提供開始 AWS Amplify Hosting が AWS WAF の統合を提供開始しました。マネージドルールを使用して SQL インジェクションやクロスサイトスクリプティング (XSS) などの一般的な web 攻撃や脆弱性から保護することができます。さらに、特定のアプリケーションニーズに基づいてカスタムルールを作成したり、DDoS 攻撃から保護するためのレートベースのルールを実装したり、特定の国からのアクセスを制限するためのジオブロッキングを使用したりすることができます。この統合により、お客様は web アプリケーションのセキュリティを向上し、脅威からの保護をしやすくなります。 Amazon SageMaker HyperPod クラスターにおける Slurm のマルチヘッドノードをサポート Amazon SageMaker HyperPod クラスターで、マルチヘッドノードをサポートしました。これにより、大規模の生成 AI モデル開発ワークロードの障害耐性と可用性を向上させます。単一のヘッドノードがジョブスケジューリングとリソース割り当てを管理する場合、ヘッドノードの障害が生成 AI モデル開発の業務に影響を与えてしまいます。これに対応するため、HyperPod Slurm クラスター内に複数のヘッドノードを設定できるようになりました。プライマリヘッドノードに障害が発生した場合、Slurm は自動的にクラスター操作をバックアップノードに移行し、ダウンタイムを最小限に抑え、ワークロードの継続的な可用性を提供します。 AWS サンプルアプリケーションで Amazon S3 用 Storage Browser を素早くデプロイが可能に GitHub Repository で公開しているサンプルアプリケーションを利用 して、利用者が簡単に S3 に接続してファイルのアップロード、ダウンロード、管理を行うためのアプリケーションを簡単にデプロイできるようになりました。このサンプルアプリケーションには、Storage Browser for Amazon S3 が利用されています。Amplify Hosting または任意のホスティングプロバイダーでホストできます。 3/27(木) AWS CloudFormation が IaC ジェネレーターでターゲットリソーススキャンをサポート開始 IaC ジェネレーターはアップデート以前から存在していた機能で、AWS 上のリソースをスキャンし、IaC 対象リソースを選択することで、既存のリソースから CloudFormation テンプレートを生成できるものです。今回のアップデートで、リソーススキャンのステップで IaC ジェネレーターがスキャンする対象のリソースタイプを指定できるようになりました。デフォルトですべてのリソースをスキャンする代わりに、ワークロードに関連するリソースにのみを対象にすることで、スキャン時間の削減と、選択のしやすさが向上するメリットがあります。 Amazon EKS が、クラスターアップグレードの際にアップグレードインサイトチェックを適用 Amazon EKS で Kubernetes クラスターアップグレードの際に、互換性に影響を与える可能性のある問題が既に検出されている場合、誤ったクラスターアップグレードを防止する新しい仕組みを提供開始しました。この機能は EKS アップグレードインサイトを活用しており、非推奨の Kubernetes API 使用などの、Kubernetes バージョンアップグレードに影響を与える可能性のある問題を自動的にスキャンします。このアップデートにより、問題が発見されている場合、クラスターアップグレードを停止するようになります。また、アップグレード時にチェックを無効化するオーバーライドフラグも導入しました。 Amazon Bedrock Knowledge Bases がベクトルストレージに Amazon OpenSearch マネージドクラスターをサポート Amazon Bedrock Knowledge Bases で Amazon OpenSearch マネージドクラスターをベクトルストアとしてサポートしました。これまで、OpenSearch Serverless, Aurora, Neptune, Pinecone などをサポートしていたところに、新たに追加された形です。OpenSearch マネージドクラスターを利用することで、カスタムシノニムや カスタムプラグインを通じた日本語形態素解析器の Sudachi などが利用できるようになり、RAG における精度向上のメリットを得やすくなります。また、OpenSearch マネージドクラスターでは、考慮点は必要ですが、コスト効率の高い 1 台のインスタンス構成をご検討いただけます。 OR1/OR2 のインスタンス を利用した場合、EBS にデータを書き込む際に、Amazon S3 にデータが同期的にコピーされます。インスタンスに障害が発生した場合、Amazon S3 から自動的にデータの復旧を行う仕組みがあります。障害発生時にはアクセスができなくなりますが、一時的な停止を許容できるユースケースの場合はご検討いただけます。 3/28(金) Amazon EC2 C8g インスタンスが AWS アジアパシフィック (東京) で利用可能 EC2 で、C8g インスタンスが、新たに東京リージョンで利用可能になりました。AWS Graviton4 プロセッサを搭載し、AWS Graviton3 ベースのインスタンスと比較して最大 30% 優れたパフォーマンスを提供します。C8g インスタンスは、高性能コンピューティング (HPC)、バッチ処理、ゲーム、ビデオエンコーディング、科学的モデリング、分散分析、CPU ベースの機械学習 (ML) 推論、広告配信などの計算集約型ワークロード向けに構築されています。 Amazon EC2 が特定の宛先へのより多くの帯域幅とジャンボフレームをサポート Amazon EC2 でリージョン間 VPC ピアリングや、Direct Connect を利用する際に、EC2 インスタンス帯域幅を最大限利用できるようになりました。これまで、EC2 インスタンスからリージョン間または AWS Direct Connect に向けて通信する際に、32 以上の vCPU を持つインスタンスでは帯域幅制限の 50%、小規模なインスタンスでは 5 Gbps に制限されていました。このアップデートで、インスタンスのベースライン仕様の全帯域幅または 5Gbps のいずれか大きい方で帯域幅を送信できるようになりました。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

あなたや組織が生成 AI 技術を検討をしている最中であれば、これらの先進的なアプリケーションにどの程度の投資が必要か把握しておくことが重要です。運用効率の向上、生産性の向上、顧客満足度の向上など、生成 AI への投資によって期待される利益を目指す一方で、コスト最適化と効率向上を実現するための手段についても十分理解しておく必要があります。この刺激的な旅を案内するため、AI プラクティショナーや FinOps リーダーが AWS での生成 AI 導入に関連するコスト最適化の方法を理解するのに役立つ実践的なヒントを満載した一連のブログ記事を公開していく予定です。 AWS の生成 AI スタック全体にわたる柔軟な実装と価格オプション 生成 AI 技術を活用してビジネスアプリケーションを強化する際に、 AWS の生成 AI スタック 全体で幅広い実装オプションが見つかるでしょう。通常以下の 3 つの一般的な実装アプローチが採用されています。 高度な機械学習の専門知識を持ち、制御と柔軟性を最大限に必要とする組織では、AWS のインフラストラクチャーを使用してカスタムモデルのトレーニングとデプロイを行うことができます。 Amazon Elastic Compute Cloud (Amazon EC2) は最高レベルの制御を提供しますが、自分で機械学習インフラストラクチャーとフレームワークを管理する必要があります。一方、 Amazon SageMaker AI は、カスタムモデル開発の柔軟性を維持しながら、インフラストラクチャーの重い作業を処理するフルマネージドサービスを提供します。 SageMaker JumpStart は、完全なカスタム開発と事前トレーニング済みモデルの中間点となるような、ファインチューニングが可能な構築済みのソリューションとモデルを提供します。 機械学習への取り組みの初期段階にあり、カスタマイズと利便性のバランスを求めている組織は、 Amazon Bedrock を通じて Anthropic、AI21 Labs、Amazon、Meta、 Deepseek R1 などのプロバイダーが提供する主要な事前トレーニング済み AI モデルにアクセスできます。 最小限の設定で迅速に実装するには、AWS の生成 AI 搭載アシスタントである Amazon Q を使用してすぐに使えるアプリケーションをデプロイできます。これにより、組織データへのアクセスが容易になったり、コードを書いたり、コンテンツを生成したり、質問に答えたりすることができます。 それぞれの実装アプローチには、コスト最適化を目的とした柔軟な価格オプションが用意されています。AWS のインフラストラクチャーを活用してカスタムモデルのトレーニングとデプロイを行う場合、安定したワークロードには Compute Savings Plans と Machine Learning Savings plans を、フォールトトレラントなトレーニングタスクには スポットインスタンス を利用できます。Amazon Bedrock 経由でモデルにアクセスする場合、トークン単位の従量課金である オンデマンド料金設定 、プロビジョンドスループットによるキャパシティーの予約、もしくは一括処理用のバッチ推論のいずれかを選択できます。Amazon Q を使用して組織のソフトウェア開発とビジネスプロセスを変革する場合は、2 つのサブスクリプションモデル (Business Lite と Business Pro) を提供する Amazon Q Business 、もしくは無料利用枠と Pro の階層の両方を提供する Amazon Q Developer のいずれかを選択できます。 （画像内訳：私たちは、コストを最適化し、価値を最大化しながら、お客様が生成 AI の力を活用できるよう支援することに全力を注いでいます。生成 AI サービスの革新と拡大を続ける中で、これらのテクノロジーを効率的かつ費用対効果の高い方法で使用するための知識とツールをお客様に提供することにも同様に注力しています。私達が AI の取り組みを共同で加速するために、すべてのお客様とパートナーにこれらのコスト最適化手法を検討することをお勧めします。 Rahul Pathak、データ・AI事業開発担当副社長） 生成AI を成功させるためのクラウド財務管理戦略 多くの組織にとってパンデミックがクラウドアプリケーションのコストを再評価する重要な転換点であったとすれば、パンデミック後の回復期と生成 AI への関心の高まりが相まって、技術への投資を精査することが必要になるでしょう。組織で明確な クラウド財務管理（CFM） 戦略をまだ設定していない場合、今がクラウド投資を検討し、基本的な CFM を実践する時です。 事前の慎重な検討 ：ビジネスのニーズを技術的な構成に変換して、生成 AI プロジェクトのコストを見積もります。 AWS Pricing Calculator を使用して、スタンドアロンプロジェクトのコストを見積もったり、生成 AI プロジェクトに関連するリソースの変更を既存のクラウドワークロードに追加/変更したり、請求全体をシミュレートしたりできます。Pricing Calculator の請求見積もり機能では、割引条件をより正確に考慮できます。実際の生成 AI アプリケーションに関しては、検索拡張生成（RAG）や Text-to-SQL クエリのような実証済みのパターンから始めることをお勧めします。通常これらのパターンはドキュメント化とコスト構造が確立されているため、コスト計画と管理が簡単になります。 継続的な監視 ：コストや使用量が上限を超えた際に通知する AWS Budgets のアラートを使用し、個別の事業部門の予算上限を設定します。その月の総コストの予算を作成したり、サービス、タグやコストカテゴリなどのディメンションを使用して特定のサービスに関連するコストや使用量を追跡する予算を作成することもできます。 AWS Cost Anomaly Detection で検出された各コスト異常の根本原因分析に注意してください。AWS リージョン、アカウント、サービスや使用タイプを詳細に分析することで、潜在的なコスト超過の原因を迅速に特定して対処することができます。 全体像の把握 ：生成 AI への投資を分析する際には、初期開発（例：データの準備、モデルの選定、カスタマイズ）、継続的な運用（例：コンピューティング、ストレージ、エネルギー）や管理費（例：教育、監視）を含む総所有コスト（TCO）を含める必要があります。AWS Cost Explorer と Data Exports を使用して、生成 AI プロジェクトで利用する AWS サービスで発生したコストと使用量を確認できます。ただし、他のすべての費用を追跡し続けることも同様に重要です。投資の全容が明らかになったら、これらの費用を責任部門に割り当てることをお勧めします。そうすることで、ユーザーは適切な可視性を得て、支出に対する説明責任を負うことができます。クラウドへの投資とビジネス成果（例：テキスト要約あたりのコスト、画像生成あたりのコスト）やパフォーマンスの境界（例：応答時間）と関連付ける KPI ターゲットは、投資効果を評価し適切な行動を促すための優れた方法です。 知識を深めて実践に活かす ：クラウドの俊敏性とスケーラビリティを活用して生成 AI アプリケーションを開発および拡張し、利用可能なすべてのディスカウントにより購入オプションを戦略化します。生成 AI ワークロードは GPU ベースのインスタンスの恩恵を受けることができます。 AWS Compute Optimizer は、GPU 使用率を含む複数のメトリクスをモニタリングし適切なサイズに関する推奨事項を提示します。Compute Optimizer が GPU メトリクスを収集するために、NVIDIA ドライバーと Amazon CloudWatch エージェントをインストールする必要があります。詳細は、 NVIDIA GPU メトリクスを収集する 、を参照してください。Amazon SageMaker AI は、生成 AI モデルを開発、トレーニング、デプロイするための包括的なプラットフォームを提供します。Amazon SageMaker と高速コンピューティングインスタンスに対するニーズが一貫している場合は、 SageMaker Savings Plans の活用を検討してください。 Savings Plans Purchase Analyzer を使用して、SageMaker Savings Plans の時間あたりのコミットメントのコスト影響を推定できます。 基本的な CFM スキルを取得したいのであれば、都合のいいときに 無料のデジタルトレーニングコース を受講できます。 AWS Certified AI Practitioner は AWS の AI/ML 技術にさらに親しむために役立ちます。 トレードオフの対策：生成 AI アプリケーションのコスト最適化とパフォーマンスのバランス 上記の CFM 戦略に加えて、生成 AI ワークロードで検討できるコスト最適化戦略が他にも多くあります。これらの方法は大幅なコスト最適化のメリットをもたらすだけでなく、アプリケーション全体のパフォーマンスも向上させます。 プロンプトキャッシュ ：頻繁に使用されるプロンプトとその応答をキャッシュすることで、応答時間を短縮し、重複する API 呼び出しを削減します。 モデル蒸留 ：推論のレイテンシーを下げ全体的なコンピューティングとメモリ使用率を削減するために、特定のユースケースにフォーカスする小さなモデルをトレーニングします。 バッチ処理 ：複数のリクエストを 1 つのバッチにまとめて処理することで、GPU の使用率を改善しスループットを向上させます。 ただし、これらコスト最適化の方法を実装する際にはトレードオフがあります。リソースの効率性とアプリケーションの信頼性のバランスや応答時間と出力の品質・深さのバランスをどの程度取るかを検討します。アプリケーションとユーザーエクスペリエンスを設計し改良していく中で、異なる手法を試し、精度を最大化しレイテンシーを最小限に抑えることで、最終的にカスタマーエクスペリエンスを向上させる最適なハイブリッドアプローチを見つけることができます。 今後の予定 様々な生成 AI サービスを採用しながら、コスト最適化戦略を見つけ実装する支援をするため、特定の AI サービスを利用する際に考慮すべき重要な分野を掘り下げた以下のブログ記事を公開する予定です。ブログ記事を公開次第リンクを追加します。 Amazon EC2 と SageMaker AI を利用したカスタム AI モデル開発のコスト最適化 Amazon Bedrock で基盤モデルを使用する際のコスト最適化 Amazon Q をデプロイする際のコスト最適化 生成 AI をサポートするインフラストラクチャーのコスト最適化 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスの主任プロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re: Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。

AWS CodeBuild で並列テスト実行のサポートが開始されたことをお知らせします。これにより、テストスイートを同時に実行し、ビルド時間を大幅に短縮できます。 この記事のために作成したデモプロジェクト では、環境をプロビジョニングする時間を含め、テストの合計時間が 35 分から 6 分に短縮されました。 AWS マネジメントコンソール の次の 2 つのスクリーンショットは、その差を示しています。 テストスイートの順次実行 テストスイートの並列実行 継続的インテグレーション (CI) を大規模に実行する際に、テスト時間が非常に長くかかることは大きな課題となります。プロジェクトの複雑さが増し、チームの規模が大きくなるにつれて、包括的なテストスイートの実行に必要な時間が大幅に長くなり、パイプラインの実行時間の長期化につながる可能性があります。これにより、新機能やバグ修正の提供が遅れるだけでなく、タスクを進める前にビルドの結果を待たなければならないため、デベロッパーの生産性が低下します。私は実行に最大 60 分かかったパイプラインを経験したことがありますが、最後のステップで失敗し、全体の再実行が必要となり、さらなる遅延が生じました。このような長いサイクルは、CI プロセスにおけるデベロッパーの信頼を損ない、フラストレーションを生じさせ、最終的にはソフトウェア配信サイクル全体のスピードダウンにつながる可能性があります。さらに、テストが長時間実行されることで、リソースの競合、コンピューティング能力の無駄な使用を理由とするコストの増加、開発プロセスの全体的な効率の低下が生じる可能性があります。 CodeBuild における並列テスト実行により、複数のビルドコンピューティング環境で同時にテストを実行できるようになりました。この機能は、各ビルドノードがテストスイートのサブセットを個別に実行するシャーディングアプローチを実装します。CodeBuild は、現在のノード番号とノードの合計数を識別する環境変数を提供します。この環境変数は、各ノードが実行するテストを決定するために使用されます。ビルド時にコントロールビルドノードやノード間の調整は行われません。各ノードは独立して動作し、テストの割り当てられた部分を実行します。 テスト分割を有効にするには、 buildspec.xml の batch fanout セクションを設定し、必要な並列処理レベルと他の関連パラメータを指定します。さらに、適切なテストコマンドと選択した分割方法とともに、ビルドステップで codebuild-tests-run ユーティリティを使用します。 テストは、指定したシャーディング戦略に基づいて分割されます。 codebuild-tests-run は、次の 2 つのシャーディング戦略を提供します: 均等な分散。 この戦略は、テストファイルをアルファベット順に並べ替え、並列テスト環境全体にわたってチャンクで均等に分散します。テストファイルの名前または数量が変更されると、シャード間でファイルが再割り当てされる可能性があります。 安定した分散。 この戦略は、一貫性のあるハッシュアルゴリズムを使用して、シャード間でのテストの分散を修正します。新しいファイルが追加または削除されても、ファイルのシャードへの既存の割り当ては維持されます。 CodeBuild は、テストを並列実行する際におけるテストレポートの自動マージをサポートします。自動テストレポートマージにより、CodeBuild はテストレポートを単一のテストサマリーに統合し、結果分析を簡素化します。マージされたレポートには、合格/不合格の集約されたステータス、テスト期間、および失敗の詳細が含まれるため、手動でのレポートを処理する必要性が軽減されます。マージされた結果は、 CodeBuild コンソール で表示したり、 AWS コマンドラインインターフェイス (AWS CLI) を使用して取得したり、テスト分析を効率化するために他のレポートツールと統合したりできます。 仕組みを見てみましょう プロジェクトで並列テストを実装する方法を説明します。このデモでは、 数百のテストを含む非常に基本的な Python プロジェクト を作成しました。迅速に進めるために、 コマンドラインで Amazon Q Developer に 1 個のプロジェクトと 1,800 件のテストケースを作成するよう指示しました。各テストケースは個別のファイルに含まれており、1 秒で完了します。すべてのテストを順番に実行するには、環境をプロビジョニングする時間を除いて 30 分かかります。 このデモでは、10 個のコンピューティング環境でテストスイートを並列実行し、スイートの実行にかかる時間を測定します。 これを実行するために、プロジェクトに buildspec.yml ファイルを追加しました。 version: 0.2 batch: fast-fail: false build-fanout: parallelism: 10 # ten runtime environments ignore-failure: false phases: install: commands: - echo 'Installing Python dependencies' - dnf install -y python3 python3-pip - pip3 install --upgrade pip - pip3 install pytest build: commands: - echo 'Running Python Tests' - | codebuild-tests-run \ --test-command 'python -m pytest --junitxml=report/test_report.xml' \ --files-search "codebuild-glob-search 'tests/test_*.py'" \ --sharding-strategy 'equal-distribution' post_build: commands: - echo "Test execution completed" reports: pytest_reports: files: - "*.xml" base-directory: "report" file-format: JUNITXML YAML ファイルには、言及しておくべき部分が 3 つあります。 まず、 batch の下に build-fanout セクションがあります。 parallelism コマンドは、並列実行するテスト環境の数を CodeBuild に伝えます。 ignore-failure コマンドは、ファンアウトビルドタスクの失敗を無視できるかどうかを示します。 次に、プリインストールされた codebuild-tests-run コマンドを使用してテストを実行します。 このコマンドは、テストファイルの完全なリストを受け取り、現在のノードで実行する必要があるテストを決定します。 上記で説明したように、均等な分散と安定した分散のいずれかを選択するには、 sharding-strategy 引数を使用します。 実行の候補であるすべてのファイルを渡すには、 files-search 引数を使用します。パフォーマンス上の理由から、提供されている codebuild-glob-search コマンドを使用することをお勧めしますが、 find(1) などの任意のファイル検索ツールも機能します。 test-command 引数を使用して、シャードで実行する実際のテストコマンドを渡します。 最後に、 reports セクションは、各ノードでテストレポートを収集してマージするよう CodeBuild に指示します。 その後、CodeBuild コンソールを開いて、プロジェクトと、このプロジェクトのバッチビルド構成を作成します。ここでは新しいことは何もないので、詳細は割愛します。 開始するためのすべての詳細はドキュメントに記載されています 。  並列テストはバッチビルドで機能します。 バッチで実行するようにプロジェクトを設定してください 。 これで、テストスイートの実行をトリガーする準備ができました。GitHub リポジトリに新しいコードをコミットするか、またはコンソールでビルドをトリガーできます。 数分後、ビルドのさまざまなステップのステータスレポートが表示されます。これには、各テスト環境またはシャードのステータスが含まれます。 テストが完了したら、 [レポート] タブを選択して、マージされたテストレポートにアクセスします。 [レポート] セクションでは、すべてのシャードのすべてのテストデータを集約し、すべてのビルドの履歴を保持します。 [レポート履歴] セクションで最新のビルドを選択して、詳細レポートにアクセスします。 想定どおり、1,800 件のテストケースについて、集約されたステータスと個別のステータスを確認できます。このデモでは、すべてが合格し、レポートは緑色です。 デモプロジェクトの 1,800 件の各テストは 1 秒で完了します。このテストスイートを順番に実行したところ、完了までに 35 分かかりました。テストスイートを 10 個のコンピューティング環境で並列実行すると、環境をプロビジョニングする時間を含めて 6 分で完了しました。 並列実行にかかった時間は、順次実行にかかった時間の 17.1% でした 。実際の数値はプロジェクトによって異なります。 その他の情報 この新しい機能は、すべてのテストフレームワークと互換性があります。 ドキュメントには、Django、Elixir、Go、Java (Maven)、Javascript (Jest)、Kotlin、PHPUnit、Pytest、Ruby (Cucumber)、Ruby (RSpec) 用の例が含まれています 。 スペース区切りのリストを受け入れないテストフレームワークの場合、 codebuild-tests-run CLI は、 CODEBUILD_CURRENT_SHARD_FILES 環境変数を通じて柔軟な代替手段を提供します 。この変数には、現在のビルドシャードのテストファイルパスの改行区切りリストが含まれます。これを使用して、さまざまなテストフレームワークの要件に適応し、テストファイル名をフォーマットできます。 独自のシャーディングスクリプトを記述し、各ビルドで自動的に設定される CODEBUILD_BATCH_BUILD_IDENTIFIER 環境変数を使用することで、テストを環境間で分割する方法をさらにカスタマイズできます。この手法を用いて、フレームワーク固有の並列化または最適化を実装できます。 料金と利用可能なリージョン 並列テスト実行により、これまで必要だった時間と比べて大幅に短時間でテストスイートを完了できるようになり、開発サイクルが加速し、チームの生産性が高まります。この記事の説明のために作成したデモプロジェクトで費やされた時間は、順次ビルドの 18.7% でした。 並列テスト実行は、 CodeBuild が提供する 3 つのコンピューティングモード 、すなわち、オンデマンド、リザーブドキャパシティ、 AWS Lambda コンピューティングのすべてでご利用いただけます。 この機能は、CodeBuild が提供されているすべての AWS リージョン で今すぐご利用いただけます。使用するコンピューティングリソースについての 標準の CodeBuild 料金 以外の追加コストはかかりません。 今すぐ CodeBuild で並列テスト実行をぜひお試しください。詳細を確認し、テストの並列化を開始するには、 AWS CodeBuild ドキュメント にアクセスしてください。 – seb PS: デモアプリケーションとそのテストスイートを作成するために使用したプロンプトは次のとおりです:「I’m writing a blog post to announce codebuild parallel testing.Write a very simple python app that has hundreds of tests, each test in a separate test file.Each test takes one second to complete.」 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

本ブログは、キヤノンITソリューションズ株式会社様と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 本記事では、 キヤノンITソリューションズ株式会社様 が Amazon Bedrock を活用した新機能によって既存サービスの強化を行なった事例についてご紹介します。 背景 / 課題 キヤノンITソリューションズ株式会社様が提供するローコード開発プラットフォーム「 WebPerformer-NX 」は、デジタルセルフサービスを推進するビジネスユーザー（以下ビジネスユーザー）が迅速にWebアプリケーションを開発できる環境を提供しています。このプラットフォームでは、基本的な機能は GUI で簡単に実装できる一方、複雑なロジックや外部サービスとの連携の実装には JavaScript、SQL や WebPerformer-NX 特有の関数を手動で記述する必要がありました。 この課題は特に、プログラミングに精通していないサービス利用者にとって大きな障壁となっていました。コードの記述に時間がかかり、本来のビジネスロジックの実装に集中できないという状況が発生していました。構文エラーや論理的なミスが発生した際には、デバッグにも多くの時間を費やしていました。 キヤノンITソリューションズ株式会社様では、これらの課題を解決し、より多くのビジネスユーザーがスムーズにアプリケーション開発を行えるような機能強化が求められていました。 ソリューション / 構成内容 この課題に対応するため、キヤノンITソリューションズ株式会社様は Amazon Bedrock を活用しコード生成機能を WebPerformer-NX に実装しました。 自然言語からコードを生成する仕組み 新機能では、サービス利用者が日本語の自然言語で実装したい機能を指示すると、Amazon Bedrock がその指示内容を受け取り、適切な JavaScript コードや WebPerformer-NX 特有の関数を含むコードを自動生成します。例えば、「年月日の入力フィールドの値より、現在の日付から年齢を算出する。未来の日付を入力したらエラー処理する」といった指示を書くと、フォームに入力された値と現在の日付を取得して差を計算し年齢を表示する処理や、エラーハンドリングを行うコードが生成されます。 プロンプトエンジニアリングの工夫 単純に生成AIを導入するだけでは、WebPerformer-NX 特有の関数や構文に対応したコードを生成することはできません。しかも、それら WebPerformer-NX 固有の要素は、固定された情報ではないため、ファインチューニングで対応することもできません。 そこで、開発チームはプロンプトを工夫し、それら WebPerformer-NX 特有の要素をインコンテキスト・ラーニングすることで、WebPerformer-NX 特有の関数や構文を正確に理解し生成できるようにするとともに、一般的な JavaScript コードと WebPerformer-NX 特有のコードを適切に組み合わせられるよう工夫しました。これにより、サービス利用者の自然言語による指示から、実際に動作する高品質なコードを生成することが可能になりました。 最適なモデルの選定 複数の生成 AI モデルを検証した結果、コード生成の精度が最も高かった Anthropic 社の Claude を採用しました。Claude は特に、コンテキストを理解する能力と、正確なコード生成能力に優れており、WebPerformer-NX 特有の関数にも対応できることが確認されました。 短期間での開発実現 Amazon Bedrock が提供する充実した機能群（監視やログ機能など）により、開発チームは生成AI機能の実装に集中することができました。その結果、わずか 3 ヶ月という短期間でコード生成機能を開発し、リリースすることに成功しました。Amazon Bedrock の呼び出しには、Amazon API Gateway、AWS Lambdaといったサーバーレスサービスを活用し、インフラ管理の負担軽減、スケーラビリティの確保、コスト最適化を実現しました。 導入効果 WebPerformer-NX へのコード生成機能の導入により、以下のような効果が得られました： キヤノンITソリューションズ株式会社様側の効果 短期間での機能実装: Amazon Bedrock のマネージドサービスとしての特性を活かし、わずか 3 ヶ月という短期間で高度なコード生成機能を実装できました。これにより、市場の要求に迅速に対応することができました。 開発リソースの効率化: 生成 AI 機能の開発において、インフラ構築やモデル管理などの負担が軽減され、コア機能の開発に集中できました。 サービス利用者側の効果 高精度なコード生成: 生成されたコードの 70〜90% はそのまま利用可能であることが確認できており、残った処理も簡単な修正で使用できるケースが大半であることが確認できています。これにより、利用者はコードの記述ではなく、ビジネスロジックの設計に集中できるようになりました。 開発工数の大幅削減: 複雑なロジックのコード記述にかかる時間が大幅に削減され、開発工数を最大 50% 削減することに成功しました。特に、プログラミングの経験が少ないユーザーにとって、この効果は顕著でした。 学習コストの低減: プログラミング知識がなくても、自然言語で指示するだけでコードが生成されるため、WebPerformer-NX を使いこなすための学習コストが低減しました。これにより、より多くのビジネスユーザーがアプリケーション開発に参加できるようになりました。 まとめ キヤノンITソリューションズ株式会社様の事例は、生成 AI を活用することで既存のサービスを強化できることを示しています。Amazon Bedrock を活用したコード生成機能の導入により、WebPerformer-NX の使いやすさが向上し、サービス利用者の開発工数を最大 50% 削減することに成功しました。 また特筆すべきは、3 ヶ月という短期間で高精度のコード生成機能を実装できたことです。これは、Amazon Bedrock が提供する充実した機能と使いやすさが貢献をしています。 今後も、キヤノンITソリューションズ株式会社様は生成 AI を活用したサービス強化を進め、より多くのビジネスユーザーがプログラミングの壁を越えて、自らの業務課題を解決するアプリケーションを開発できる環境を提供していく予定です。 WebPerformer-NX は、無償で利用いただけるフリーアカウントやサンプルアプリをご提供しています。 WebPerformer-NX 公式サイト にアクセスいただき、ページ中段の「 スタートガイドアカウント作成ガイド 」から 3 ステップでご登録いただけます。 執筆者 キヤノンITソリューションズ株式会社 プラットフォーム開発部 高塚 剛 様 (写真左) キヤノンITソリューションズ株式会社 デジタルサービス開発部 佐野 彰彦 様 (写真右) Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)

みなさん、こんにちは。ソリューションアーキテクトの野間です。 おしごとの都合で移動中にこのブログを書いているのですが、照明が消されていて両隣は寝ているというなんともやりづらい状況です（笑）それでも最新の情報を皆様にお伝えすべく週刊スタッフは頑張っております！さて、最近事例紹介が多くなってきた印象です。生成 AIについて調査・検証の段階を終え、ビジネスへの実装が進んでいるからでしょう。 今週も、生成AIの最新情報をお届けしていきますので、最後までお付き合いください。それでは、今週のトピックを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ：「岩崎電気株式会社様の AWS 生成 AI 事例「カメラ付き照明で冠水検知を実現。照明の専門メーカーとして80年以上の歴史を持つ製造業のモノとコト融合」 このブログでは、80年以上の歴史を持つ照明専門メーカーの岩崎電気株式会社が、AWSの生成AI技術を活用して路面冠水監視システムを開発した事例を紹介しています。同社は Amazon Bedrock を使って、監視カメラの映像から冠水状況を自動検知し、リアルタイムで危険を通知するシステムを構築しました。従来は専用センサーが必要だった冠水検知を、カメラ付き照明と生成 AI の組み合わせで実現。監視員の労力を80%削減し、24時間リアルタイム監視を可能にしています。企画から約2ヶ月という短期間でプロトタイプを完成させ、 GenU を用いた効率的な検証とコスト効率を考慮した AI モデルの使い分けが成功要因となりました。照明設備のインフラを活用した防災システムという新たな価値創出に、生成AIが貢献している興味深い事例です。 AWS生成AI国内事例ブログ：「大規模マルチモーダル AI による鉄道車両の異常画像検知システムの実証実験」 このブログは、JR東日本、ドイツ鉄道、JEISが、AWSのマルチモーダルAI技術を活用して車両外観検査の画像にAIを活用する取り組みについて紹介しています。カメラの映像と音声センサーから得られるデータを組み合わせることで、目では見えない異常な振動や音の変化も捉え、鉄道設備の故障を早期に発見できるようになりました。Amazon Lookout for Vision、Amazon SageMaker、Amazon Bedrockなどの技術を組み合わせたシステムにより、保守作業の効率化と安全性の向上が実現します。AIによる予防保全で、私たちの日常を支える鉄道インフラの安全性がさらに高まることが期待されています。 ブログ記事「製造業の設計開発領域での AI 活用 – 「身体性」の原理から考える」（前編） （後編はこちら） このブログでは、製造業での生成AI活用について「身体性」という考え方に着目して考察しています。これは、頭で考えるだけでなく、実際に手を動かして物を作る時に生まれる知恵や発見を大切にする考え方です。特に機械設計では、この身体性知能が大きな威力を発揮します。部品同士の干渉チェック、振動や熱による変形予測、組立性の検証など、図面上では見えない問題を事前に発見できます。熟練の設計者が持つ「手触り感覚」や「重さのバランス」といった暗黙知をAIが学習し、設計の初期段階から反映できるようになれば、試作回数の削減や開発期間の短縮につながります。AIと人間の新しい協働の形が見えてくる示唆に富んだ内容となっています。 ブログ記事「Amazon Q Developer の新しいコンテキスト機能で、コードのコントロールを強化しよう」 Amazon Q Developer に便利な機能が追加されました。コードを書く時にコンテキストを理解し、例えば、あなたが書いているコードの全体像を把握したり、関連するファイルを自動的に参照したりして、より的確なアドバイスや提案をしてくれるようになりました。これにより、開発者はコードの説明に時間を取られることなく、より創造的な作業に集中できます。プログラミング初心者から熟練者まで、開発作業がぐっと効率的になる新機能です。詳細はブログをチェックしてください。 サービスアップデート Amazon Bedrock Guardrails、業界をリードする画像コンテンツフィルターの一般提供開始を発表 Amazon Bedrock のガードレール機能を強化し、画像コンテンツフィルター機能の一般提供を開始しました。この新機能により、企業は生成AIアプリケーションで使用される画像の内容を自動的に検査し、不適切なコンテンツをブロックできるようになります。 Amazon Bedrock Knowledge Bases がベクトルストレージとしてAmazon OpenSearch Managed Cluster をサポート Amazon Bedrock Knowledge Basesに、ベクトルストアとしてAmazon OpenSearch Managed Clusterが利用できるようになりました。Amazon Bedrock Knowledge BaseとOpenSearchサービスが利用可能なすべてのリージョンで一般提供されています。 Amazon Q Business がアジアパシフィック（シドニー）リージョンで利用可能に Amazon Q Business は、企業向けの生成AIアシスタントです。組織内の情報やデータを活用して、質問に答える、要約を作成する、コンテンツを生成する、タスクを完了するなどの機能があります。 今回、アジアパシフィック（シドニー）リージョンで新たに利用可能になりました。 Amazon Bedrock カスタムモデルインポートで、リアルタイムのコストの可視化を実現 Bedrock コンソールや API を通じて、モデル実行に必要な最小限のコンピュートリソース（Custom Model Units：CMU）を事前に確認できます。また、CloudWatch メトリクスを通じて使用された CMU の総数がリアルタイムで表示され、推論コストの可視化が可能です。これにより、お客様はコストをリアルタイムで把握し、必要に応じてモデル設定を動的に変更することで、コストの最適化が可能になります。 Amazon Q in QuickSight でシナリオ機能が一般提供開始 Amazon Q in QuickSight に、データ分析を革新的に進化させる新機能が追加されました。自然言語での対話を通じて、隠れたトレンドの発見やビジネスへの推奨事項の提示、より深い分析へのステップを提案します。特別なスキルがなくても過去のトレンドの探索や将来のシナリオの予測、ソリューションのモデリングが可能になります。 Amazon Q Business の Slack および Teams 連携機能をアップグレード 1つの Slack ワークスペースまたは Teams 組織内で最大10個の Amazon Q Business 統合 を作成できるようになり、テスト環境や本番環境、異なるユーザーグループごとに個別の統合が可能になりました。また、フリーテキストでのフィードバック機能が追加され、ユーザーの満足度確認やフィードバックの収集が可能になりました。 今週は以上でした。それでは、また来週もお楽しみに！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。

本記事は 2025 年 2 月 18 日に公開された ” Streamline DNS management for AWS PrivateLink deployment with Amazon Route 53 Profiles ” を翻訳したものです。 はじめに AWS PrivateLink インターフェイスエンドポイント を採用するエンタープライズ企業における主な課題は、導入プロセスの効率化、エンドポイント数の最小化、コストの最適化です。これらの課題に対処するための実績あるアプローチは、 AWS Transit Gateway と Amazon Route 53 Resolver を組み合わせて使用し、複数の Amazon Virtual Private Cloud(VPC) およびオンプレミス環境で AWS PrivateLink インターフェイスエンドポイントを効率的に共有することです。これにより、必要なインターフェイスエンドポイントの数を最小限に抑えることができ、コストと運用オーバーヘッドの削減を実現できます。 PrivateLink は、VPC とサポートされている AWS サービス、Software as a Service (SaaS) アプリケーション、AWS またはオンプレミスでホストされているサードパーティサービス間のプライベート接続を実現します。PrivateLink は VPC インターフェイスエンドポイントを使用して、VPC とターゲットサービス間の安全な接続を確立します。しかしながら、組織が VPC とアカウントを大規模に拡張していった場合、マルチアカウント環境で、数千規模の VPC に横断してインターフェイスエンドポイントをデプロイすることになり、複雑性とコストが増加しかねません。 Amazon Route 53 プロファイル は、この アーキテクチャ を再検討し、改善することができます。Route 53 プロファイルを統合することで、複数の AWS アカウントを横断する膨大な数の VPC で DNS 管理を簡素化、および一元化できるため、PrivateLink の展開はスケーラブルになります。 本稿では、PrivateLink が、同じアカウント内、複数のアカウント間、オンプレミス環境と統合された VPC や AWS サービス間で、どのように安全なプライベート接続を実現するかを説明します。また、インフラストラクチャを拡張する場合でも、アーキテクチャを最適化する場合でも、 PrivateLink のデプロイを習得するための実用的なステップバイステップのガイドとなります。 ソリューション概要 ハブアンドスポークモデルで PrivateLink を一元的に展開すると、多数の VPC とアカウントに PrivateLink を展開する際の課題に対応できます。図 1 では、PrivateLink VPC エンドポイントが一元化され、Shared Services VPC 内に展開されています。Dev アカウントと Prod アカウントのスポーク VPC は、Transit Gateway または AWS Cloud WAN を介して Shared Services VPC に接続することで、エンドポイントにアクセスできます。オンプレミスのデータセンターは、 AWS Direct Connect または AWS Site-to-Site VPN を介して AWS 環境とのハイブリッド接続を確立することで、これらの一元化された PrivateLink VPC エンドポイントにアクセスできます。 図 1 : Shared Services VPC の集中型 VPC エンドポイント DNS 管理は、集中型デプロイメントモデルを実装する際に重要な要素です。PrivateLink 対応サービスの VPC インターフェイスエンドポイントを作成する際のセットアッププロセス内で [DNS 名を有効にする] オプションを選択してプライベート DNS を有効にすることができます。この機能を有効にすると、AWS サービスのパブリック DNS 名は VPC エンドポイントのプライベート IP アドレスに解決する AWS マネージドの Private Hosted Zone(PHZ) が作成されます。ただし、このマネージド PHZ は、VPC エンドポイントをホストするハブ VPC 内でのみアクセス可能であり、他のスポーク VPC と共有することはできません。これを克服するために、次のセクションで説明するカスタム PHZ を使用します。 PrivateLink の DNS 解決のためのカスタム PHZ VPC-to-VPC およびオンプレミス接続の場合、VPC エンドポイントのプライベート DNS を無効にすることから始めます。 VPC コンソールで、 [エンドポイント] を選択して対象のエンドポイントを選択します。 [アクション] を選択し、 [プライベートDNS名を変更] を選択します。 [プライベート DNS 名の設定を変更] で、 [このエンドポイントで有効にする] のチェックを外します。 [変更を保存] を選択します。 図 2 :プライベートDNS名を変更する プライベート DNS 名を無効にすると、 Route 53 PHZ を作成 できます。サービスエンドポイント名を使用し、AWS サービスの VPC エンドポイント名をポイントする エイリアスレコード を設定します。 図 3 : Route 53 エイリアスレコードの作成 この例では、us-east-1 AWS リージョン に AWS Lambda のエンドポイントを作成しているため、エンドポイントの末尾は lambda.us-east-1.vpce.amazonaws.com となります。 このカスタム PHZ をハブ VPC に作成し、それを他のスポーク VPC に関連付けしていきます。これにより、すべてのスポーク VPC で AWS サービスのパブリック DNS 名をエンドポイントのプライベート IP アドレスに解決できるようになり、複数の VPC 間でシームレスな接続が可能になります。 通常、複数の VPC 間で VPC エンドポイントの DNS 解決を有効にするには、各 VPC エンドポイントの PHZ を全てのスポーク VPC に手動で関連付ける必要があります。ハブ VPC とスポーク VPC の両方が同じ AWS アカウント内にある場合、この関連付けは AWS マネジメントコンソール で設定できます。異なるアカウントにある場合は、 AWS コマンドラインインターフェイス (AWS CLI) または SDK を使用して関連付けをする必要があります。このプロセスについては、 Route 53 デベロッパーガイド をご参照ください。 図 4 :クロスアカウント PHZ 関連付けを使用した Shared Services VPC 内の集中型 VPC エンドポイント 次のセクションでは、Route 53 Resolver プロファイル を使用して、このプロセスを効率化し、よりスケーラブルにする方法を紹介します。 Route 53 プロファイルを使用した VPC to VPC PrivateLink の DNS 解決 図 5 のアーキテクチャ図は、単一リージョンのワークロードを示しています。Dev アカウントには Dev VPC 、Prod アカウントには Prod VPC という VPC がデプロイされています。前述のように、これらの VPC は Transit Gateway または AWS Cloud WAN で接続されています。このアーキテクチャにより、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスから Shared Services VPC の VPC エンドポイントが使用できるようになっています。Dev VPC または Prod VPC のいずれかに存在するインスタンスは、 Amazon Kinesis および Lambda にプライベートにアクセスできます。 図 5 : DNS 解決に Route 53 プロファイル を使用する Shared Services VPC 内の集中型 VPC エンドポイント 次の手順では、どのように Route 53 プロファイルがこのプロセスを効率化するかを示します。 Shared Services VPC で、PrivateLink を使用して Kinesis と Lambda に安全にアクセスする VPC Interface エンドポイントを作成します。 これらのエンドポイントごとに PHZ を設定 します。 Shared Services アカウントに Route 53 プロファイルを作成 し、Shared Services VPC に 関連付け ます。 この Route 53 プロファイルに Kinesis と Lambda の両方の PHZ を 関連付け ます。 この新しく作成された Route 53 プロファイル を Dev アカウントと Prod アカウントを拡張するために、 AWS Resource Access Manager (AWS RAM) を使用して両方のアカウントとプロファイルを 共有 します。 共有後、Dev アカウントと Prod アカウントから、Route 53 プロファイルを各々の VPC に 関連付け をします。 この VPC エンドポイントの実装は、すべての VPC において、Kinesis および Lambda のパブリック DNS 名をプライベート IP アドレスに解決できることを意味します。スポーク VPC 内のすべてのリソースは、Transit Gateway または AWS Cloud WAN を介して Kinesis, Lambda サービスにパブリックインターネットを経由せずに、Shared Services VPC の VPC エンドポイント経由で安全にアクセスできるということです。 今後、サポートされている他の A​​WS サービスの新しい VPC エンドポイントを作成する場合、必要な手順は、各 VPC エンドポイントの PHZ を一元化された Route 53 プロファイルに関連付けるだけです。関連付けが確立されると、この Route 53 プロファイルにリンクされている VPC は、新しく作成された VPC エンドポイントへの DNS 名の解決ができるようになります。 既存または新規のアカウントで新しい VPC をプロビジョニングする場合でも同様に、その VPC を共有している Route 53 プロファイルに関連付けます。また、Transit Gateway または AWS Cloud WAN を使用して、Shared Services VPC とのレイヤー 3 接続も提供します。その結果、新しい VPC は、Shared Services アカウント内のすべての PHZ に自動的に関連付けられるようになり、それぞれの VPC エンドポイントへのシームレスな DNS 解決が提供されます。 オンプレミスネットワークにおける PrivateLink の DNS 解決 図 6 に示すこのシナリオでは、AWS 環境と外部ネットワークの間にレイヤー 3 接続を確立します。オンプレミスのリソースは Kinesis や Lambda などの AWS サービスに到達する必要があるため、オンプレミスの DNS 解決のためのソリューションを実装しなければなりません。 図 6 :オンプレミスでの DNS 解決に Route 53プロファイルを使用する Shared Services VPC 内の集中型 VPC エンドポイント Direct Connect または Site-to-Site VPN を使用して、既存の Transit Gateway または AWS Cloud WAN にレイヤー 3 の接続を確立します。(2025/3 時点で AWS Cloud WAN の Direct connect gateway 接続は東京リージョン未対応： 参考 ) Route 53 Resolver のインバウンドエンドポイントを、Shared Services VPC にデプロイします オンプレミスの DNS Resolver では、Kinesis と Lambda の DNS クエリを Route 53 Resolver のインバウンドエンドポイントの IP アドレスに送信する転送ルールを設定します。 Route 53 Resolver のインバウンドエンドポイントが作成されている Shared Services VPC に関連づけられている PHZ は、クエリを解決するときに VPC に関連付けられた Route 53 プロファイルよりも優先されます。 考慮点とベストプラクティス VPC エンドポイントは、高可用性を実現するために、複数のアベイラビリティゾーン (AZ) (理想的には 2 つ以上) に配置すべきです。Route 53 Resolver インバウンドエンドポイントも、同様に複数のAZで構成し、AZレベルの障害の影響を軽減しましょう。 PHZ が Route 53 プロファイル に関連付けされ、そのプロファイルが VPC に関連付けられている場合、PHZ を VPC に明示的に関連付ける必要はありません。 Route 53 プロファイルを個々のアカウントと共有するのではなく、特定の組織単位 (OU) または組織全体と共有できます。Route 53 プロファイルが OU または組織全体と共有されている場合、その範囲内の既存と新しく作成されたアカウントは自動的にこの Route 53 プロファイルにアクセスできます。これにより、Route 53 プロファイルを個々の AWS アカウントと手動で共有する必要はありません。 Route 53 の 料金ページ で説明されているように、Route 53 プロファイルは、プロファイルと VPC の アソシエーション 1 時間あたりの料金で請求されます。多数のプロファイルを作成すると、コストが高くなる可能性があります。 VPC が PHZ と Route 53 プロファイルの両方に関連付けられている場合、Route 53 Resolver は PHZ の直接の関連付けを優先します。「 Route 53 プロファイル設定の優先順位付け方法 」のドキュメントで説明されています。 各インターフェイスエンドポイントは、 AWS PrivateLink クォータのドキュメント に記載があるように、AZ ごとの持続トラフィックとバーストトラフィックの特定の帯域幅をサポートしています。より高い帯域幅要件をサポートするには、この ソリューション を検討してください。 まとめ 本稿では、AWS PrivateLink の展開に AWS Transit Gateway または AWS Cloud WAN を使用した集中型モデルを使用する際に、Amazon Route 53 プロファイルを簡単に統合して DNS 管理を支援する方法について紹介しました。開始するには、 AWS PrivateLink と Amazon Route 53 プロファイル のページにアクセスしてください。 翻訳は Solutions Architect の齋藤が担当しました。原文は こちら です。 著者について Kunj Thacker Kunj は AWS のテクニカルアカウントマネージャーであり、カナダのバンクーバーに拠点を置いています。彼はネットワークとインフラストラクチャエンジニアリングの幅広い経歴を持っています。新しい技術に情熱を傾けており、顧客がAWS上のクラウドインフラストラクチャを構築、実装、最適化するのを支援しています。 Salman Ahmed Salman Ahmed は、AWS Enterprise Support のシニアテクニカルアカウントマネージャーです。彼は旅行およびホスピタリティ業界の顧客がクラウドインフラストラクチャを設計、実装、サポートするのを支援しています。ネットワーキングサービスへの情熱と長年の経験により、彼は顧客がさまざまなAWSネットワーキングサービスを採用するのを支援します。仕事以外では、写真、旅行、スポーツ観戦を楽しんでいます。 Ankush Goyal Ankush Goyal は、AWS Enterprise Support のシニアテクニカルアカウントマネージャーであり、旅行およびホスピタリティ業界の顧客がクラウドインフラストラクチャを最適化する支援を専門としています。20年以上のIT経験を持つ彼は、AWSネットワーキングサービスを活用して、運用効率とクラウドの採用を推進することに注力しています。Ankush は、インパクトのあるソリューションを提供し、顧客がクラウド業務を効率化できるための支援に情熱を注いでいます。

本記事は 2025年01月08日に公開された ” Analyzing AWS Transit Gateway Data Processing charges with cost allocation tags ” を翻訳したものです。 はじめに AWS は AWS Transit Gateway においてコスト配分タグをサポートし、一般提供することを 発表 しました。コスト配分タグを使用すると、AWS リソースにタグを付け、タグごとにコスト内訳を確認できます。以前まで、Transit Gateway はアタッチメントの時間料金の分類と割り当てにコスト配分タグをサポートしていました。今回の発表により、マルチアカウントシナリオでタグを使用してデータ処理料金を割り当てることができるようになりました。この記事では、Transit Gateway でコスト配分タグを使用して、データ処理料金をタグごとに分類して割り当てる方法を紹介します。 Transit Gateway の料金とコスト配分 Transit Gateway では、アタッチメントごとの1時間あたりの使用料金に加え、Transit Gateway を通過するトラフィック量に応じた使用料金があります。大規模なマルチアカウント環境では、Transit Gateway をインフラストラクチャーアカウントにデプロイするのが一般的です。その後、 AWS Resource Access Manager (AWS RAM) を使用して組織内のすべて、または一部のアカウントと共有します。共有されたアカウントは、VPC 接続用の VPC アタッチメント を表示したり、作成したりできます。このシナリオでは、以下に示すTransit Gateway の使用料金は共有されたアカウントに課金されます。 VPC アタッチメントの 1 時間あたりの料金 Transit Gateway に送信されたデータ量に応じたデータ処理料金 詳細な料金と例については、Transit Gateway の 料金ページ をご覧ください。 企業内の異なるチームがTransit Gateway の VPC アタッチメントを所有している場合、コスト配分のために各チームのTransit Gateway 使用量と料金を決定したいケースがあります。これらのアカウントが統合請求の一部であり、すべての料金が組織内の支払いアカウントに集約される場合、各チームのTransit Gateway コストの追跡、レポート作成、可視化することが課題になる可能性があります。以前の ポスト では、 Transit Gateway フローログ を使用して個別のアカウント料金を決定する方法を示しています。このアプローチには、 Amazon Athena を使用してフローログをクエリすることが含まれており、追加のセットアップと設定が必要になる場合がありました。 Transit Gateway がコスト配分タグをサポート Transit Gateway のコスト配分タグ のサポート開始により、このタスクはシンプルになりました。各共有アカウントでTransit Gateway リソースにタグを付け、コスト配分タグを有効化することで、時間単位のアタッチメント料金とデータ処理料金の両方についてコストを追跡できるようになります。 タグはAWSリソースに割り当てるキーと値のペアです。 AWS Cost Explorer では、タグをコスト配分タグとして有効化できます。有効化すると、コスト配分タグによってコストを分類し追跡することができます。例えば、「Team」という名前のタグを作成し、値を「A」として、会社内のチームAが所有するリソースに割り当てることができます。「Team」タグをコスト配分タグとして有効化した後、このタグで料金を追跡したり、Cost Explorer でタグによるフィルタリングやグループ化を行ったり、さらなる分析や可視化のために、「AWS コストと使用状況レポート」などに追加したりすることができます。 AWS のコスト配分は以下の3段階のプロセスで行います。 リソースにコスト配分タグを付ける AWS Billing Console のコスト配分タグセクションでタグを有効化する Cost Explorer でタグをフィルタリング、グループ化し、コストカテゴリを作成する リソースにタグを作成してアタッチした後、24時間以内にAWS Billing Console のコスト配分タグセクションの「ユーザー定義コスト配分タグ」に表示されます。AWS がリソースタグの追跡を開始するには、これらのタグを有効化する必要があります。タグを有効化してから、Cost Explorer に表示されるまでに最大24時間かかることがあります。Cost Explorer のフィルターまたはグループ化フィールドの「タグ」の下にタグが表示されたら、タグでフィルタリングまたはグループ化を開始して、タグごとの使用状況と料金を表示できます。 コスト配分タグの設定方法 先に述べたように、Transit Gateway の料金はアタッチメント時間と処理されたデータ量に基づいて課金されます。時間単位のアタッチメント料金を分類し配分するには、Transit Gateway アタッチメントにキーとユニークな値でタグ付けします。同様に、Transit Gateway のデータ処理料金を配分するには、各共有アカウントのTransit Gateway リソースにキーとユニークな値でタグ付けします。図1の例示アーキテクチャがこのアプローチを示しています。 図1: アーキテクチャの例 ここでは、共有サービスアカウントに1つのTransit Gateway があります。このアカウントには、Transit Gateway に接続された1つのShared Service VPC があります。また、異なるアカウントのWorkload VPC 二つが同じTransit Gateway に接続されています。設定を始めるには、以下の手順に従ってください。 ステップ1：各アカウントのTransit Gateway リソースと、Transit Gateway アタッチメントに以下のようにタグを付けます。 Shared Service VPC接続に「Team:Infra」とタグ付け Workload VPC A アタッチメントに「Team:A」とタグ付け Workload VPC B アタッチメントに「Team:B」とタグ付け 共有サービスアカウントのTransit Gateway に「Team:Infra」とタグ付け ワークロードアカウントAのTransit Gateway リソースに「Team:A」とタグ付け ワークロードアカウントBのTransit Gateway リソースに「Team:B」とタグ付け ステップ2 : コスト配分タグで「Team」タグを有効化する ステップ1で適切にリソースにタグ付けした後、支払いアカウントのAWS Billing and Cost Management コンソールでタグが利用可能になるまで最大24時間かかる場合があります。その後、コスト配分タグとして有効化することができます。 図2は、AWS Billing and Cost Management コンソールのコスト配分タグセクションで、「Team」タグが有効化可能な状態で表示されていることを示しています。 図2.コスト配分タグの表示 以下に示す図3は、「Team」タグが有効化されたコスト配分タグとして表示されていることを示しています。 図3.有効化されたコスト配分タグ ステップ3：Cost Explorer で「Team」タグを使用してフィルタリングとグループ化を行う タグフィルターを適用すると、Cost Explorer は選択された値でタグ付けされたリソースの料金のみを表示します。また、特定のタグでグループ化すると、料金は選択されたタグの値ごとにグループ化されます。図4は、各チームのTransit Gateway の1時間あたりのアタッチメント料金とデータ処理料金を示しています。 図4. Team タグによるフィルタリングとグループ化 もし「Team」タグで他のリソースがタグ付けされている場合、それらの料金も図4のビューに反映されます。各チームのTransit Gateway のデータ処理料金のみを確認するには、「Usage Type」フィルターに”<Region>-TransitGateway-Bytes (GigaBytes)”を追加します。この例では、Transit Gateway はus-east-1 AWS リージョン にあるため、図5に示すように、USE1-TransitGateway-Bytes (GigaBytes)でフィルタリングします。 図5： 「USE1-TransitGateway-Bytes (GigaBytes)’」でフィルタリングし、「Team」 タグでグループ化した結果 AWS コストカテゴリーを使用した可視化 AWS コストカテゴリー を使用すると、ニーズに基づいてコストと使用情報を意味のあるカテゴリーにグループ化できます。カスタムカテゴリーを作成し、アカウント、タグ、サービスなどの様々な要素によって定義したルールに基づいて、コストと使用状況をカテゴリーにマッピングできます。コストカテゴリーが設定され有効化されると、AWS Cost Explorer、 AWS Budgets 、 AWS Cost and Usage Report (CUR) でこれらのカテゴリー別にコストと使用状況を表示できます。 この例では、コストカテゴリーで 「Team」 という名前のカテゴリーを定義し、「Team」 タグの値に基づいてコストと使用状況を分類するルールを構築しています。これにより各チームのコストが分類され、図6に示すようにコストカテゴリーで視覚化できます。 図6. コストカテゴリーによる可視化 留意事項と制限事項 VPC、 AWS Direct Connect 、またはVPNからTransit Gateway に送信される通信量(Gigabyte)に対してデータ処理料金が適用されます。 AWS Site-to-Site VPN 接続をTransit Gateway にアタッチする場合、VPN接続はTransit Gateway と同じアカウントにある必要があります。そのため、データ処理料金はそのアカウントで集計されます。Direct Connectアタッチメントの場合、データ処理料金はDirect Connect Gateway を所有するアカウントに適用されます。Transit Gateway ピアリングまたは Transit Gateway Connect アタッチメントから送信されるトラフィックにはデータ処理料金はかかりません。 効果的なコスト配分のために、個々のTransit Gateway アタッチメントはアタッチメントごとのコスト配分のタグ付けを行うことができますが、データ処理料金はアカウントレベルで集計されることに注意することが重要です。つまり、データ処理料金は、同じTransit Gateway にアタッチされた単一アカウントからのすべてのVPC に対して集計されます。 さらに、Transit Gateway ピアリングアタッチメントの場合、各Transit Gateway 所有者は他のTransit Gateway とのピアリングアタッチメントに対して時間単位で請求されます。 最後に このポストでは、マルチアカウント環境でTransit Gateway のデータ処理料金を表示する際に、コスト配分タグをどのよう利用するかを示しました。また、コスト配分タグを使用してコストカテゴリーでコストを可視化する方法も示しました。コスト配分タグについてさらに詳しく学ぶには、 ドキュメンテーションページ をご覧ください。 翻訳はNetwork Specialist Solutions Architect の奥村が担当しました。原文は こちら です。 執筆者について Suresh Samuel Sureshは、AWSのプリンシパル・テクニカル・アカウント・マネージャーです。 金融サービス業界の顧客がAWSで業務を行うのを支援しています。 仕事をしていない時は、テキサス州で鳥を撮影したり、家族と過ごしたり しています。 Anbu Kumar Krishnamurthy Anbuは、AWSのシニア・テクニカル・アカウント・マネージャーで、 顧客のビジネスプロセスをAWSクラウドと統合し、運用の卓越性と 効率的なリソース利用を実現するための支援を専門としています。 顧客のソリューション設計と実装、問題のトラブルシューティング、 AWSの環境最適化を支援しています。 顧客が望むビジネス成果を達成するためのソリューションを設計 する際に、顧客と協力して取り組んでいます。

こんにちは。製造業のお客様を技術支援しているソリューションアーキテクトの中西です。 本ブログは 前編 ・後編にわかれたブログシリーズの後編です。 ハードウェア開発とソフトウェア開発の原理的な違い 前編 では、「身体性」という概念を通して、現代の AI がハードウェア設計のコア業務で活躍しにくい理由を原理的に解き明かしました。「そうは言っても、ソフトウェア開発では生成 AI が強力にエンジニアを後押ししていることは事実じゃないか。なぜものづくり全般に適用できないのか」というツッコミを受けそうです。ということで、ハードウェア開発の中の機械設計と、ソフトウェア開発の中のプログラミングを例として、それらの原理的な違いを体系的かつ詳細に深掘りしていきます。 図 3: ハードウェアの機能は物理学に基づく無数の相互作用の中から生じるが、ソフトウェアの機能は有限の人為的ルールに従って生じる プログラミング (図 3 右側) エンジニアは、特定のコード実行環境を想定し、その世界で動くコードを記述します。この環境はランタイム、OS、ハードウェアの階層構造からなり、すべて人間が設計した明示的なルールに従います（未定義動作や放射線の影響などを除けば、そのように期待されています）。 ソフトウェアの動作原理は、コード実行環境が定める人為的ルールです。コードが解釈され実行されると、メモリやストレージの状態変化が起き、これが機能として発現しますが、この結果も人為的ルールの範囲内でのみ発生することが期待されます。この人為的ルールの数は有限です。そうでなければ、コンパイラやインタプリタのサイズが無限大になってしまいます。 そういう意味では、ソフトウェアの動作原理はある程度限定的であり、把握しやすいと言えます。エンジニアはこの動作原理を学ぶことで頭の中でコードを動かしながら、あるいは、コードを開発環境で実際に動かしてみた結果からフィードバックを得ながら、開発します。 機械設計 (図 3 左側) 機械設計では、エンジニアは部品の形状と材質を決定します。ここでは、幾何公差、表面性状、表面処理、熱処理なども一般化して「形状と材質」と表現することにします。しかし、その決定には物理環境との無数の相互作用（図 3 の赤い矢印）を考慮しなければなりません。それこそが機械の動作原理だからです。作用反作用、温度変化、音、摩擦など、非線形かつ時間変化する相互作用はまさにカオスです。 「法則がわかっている物理現象なので CAE などでシミュレーションできるのでは？」と思われるかもしれませんが、モデル化もせずに多数の物理現象を手当たり次第にシミュレートして設計パラメータを決定することは不可能です。よくある思考実験である「宇宙にある全ての素粒子の位置と運動量がわかれば、それをシミュレーションして完全な未来予知ができる」が現実的でないのと同様です。機械部品は物理環境（系）と常に相互作用しており、完全なシミュレーションができる範囲を超えています。エンジニアが職務を全うするためには、この無数の相互作用と対峙し、「適切に」ハンドリングしなければならないのです。 プログラミングにおける「コードを仮想的あるいは実際に動かしてみて……」のような開発方法は機械設計では原理的に通用せず、プログラミングとは異なるタイプの思考が必要になるということです。 無尽蔵に増える考慮点 物理環境での無数の相互作用を相手にすることがどれだけ大変か、例を使って説明します。 図 4: ステンレスフライパン 筆者は最近、図 4 のようなステンレスフライパンを買いました。フライパンには可動部がないので機械として比較的単純な部類です。なんとなく AI でサクっと作れそうな形に見えるかもしれません。さて、この設計者は何を考えてフライパンの形を決めているでしょうか。材質があらかじめ決まっているとすると、設計者として筆者なら以下を考えます。 柄と本体のスポット溶接の数と位置、および溶接跡が内壁の洗浄性に与える影響 強火で加熱した際の熱伝導を考慮した柄のパイプ寸法と人間工学に基づく取付角度 フライパンを傾けて液体を注ぐ時の注ぎやすさを考慮したフチの加工方法 ステンレス – アルミ – ステンレスの3層貼り底の熱膨張による応力に耐える接合方法 洗浄性や食材の返しやすさを考慮した内壁の曲率半径とプレス成形時の金属流動性を踏まえた肉厚設計 （……書ききれませんが、無数に出てきます） フライパンですらこれほど大変なのに、複数の部品からなる機械ならもっと大変ですね。 設計が決まれば、その設計が要件を満たすかを一つ一つ精査したくなると思います。頭で考えてもいいですし、わからなかったら、ある考慮点にスコープを絞って物理現象をモデル化したうえで、CAE を使って計算することもできます。もしそれも難しければ、実物を作ってテストできます。そうして全ての考慮点についてフィードバックを繰り返す方法なら、AI のような存在にも機械設計ができるでしょうか？ その答えは No と考えています。 機械設計では身体性知能が役に立つ 上に箇条書きした考慮点の数々はかなり網羅的に見えますが、限定的とも言えます。なぜなら「いきなり地球の重力が反転したらフライパンはどうなるか」とか「万が一身長 10m の人間がいても柄のサイズはこのままでいいのか」とか「もし空気の粘度が上がって水のようになったらフライパンを振れるのか」とか、そういう突拍子もない無限個の思考を排除できているからです。 何を馬鹿なことをと言われるかもしれませんが、これは AI の分野で「フレーム問題」と呼ばれる概念と同様だと考えています。 フレーム問題とは、AI が直面する難問の一つです。これは、ある状況で「何が関連し、何が関連しないか」を判断する能力に関わります。人間はある状況下で直感的に「考慮すべきこと」と「無視してよいこと」を区別できますが、AI にこの能力を持たせることは困難です。 実際の製品設計では、設計者は物理環境への理解に基づいて「考慮すべき範囲」を適切に設定します。これは単なる知識の適用ではなく、身体的知能を駆使した高度な知的プロセスです。フライパン一つとっても、設計者は、物理環境における無数の相互作用を考慮するのと同時に、無限にある「考慮しなくてよい可能性」を自然に排除しています。以上から、依然としてハードウェア設計においては、身体性知能ならではの「フレームを適切に設定する能力」が必須と言えるでしょう。 たしかに、CAD ベンダなどを中心に 3D ジオメトリを生成できる「ジェネレーティブデザイン」の AI ツールは既に世に出ています。これらのツールは設計者が与える制約条件のもとで形状を生成しますが、そのプロセスは機械設計全体の流れの中では限定的である上、製造プロセスを考慮できないために量産部品への適用には課題がある現状です。そのためこれらのツールは機械設計のコア業務で広く活躍できるレベルに到達していません。「フライパンとして使えそうな形」を生成してくれるツールをありがたいと感じる場面もあるかもしれませんが、それよりむしろ、機械設計の本質は上記のような細かい無数の考慮点のほうにあります。 機械設計に必要なすべては、その機械が製造の過程あるいは使用される過程で、外界とどのように相互作用し、どのような物理現象を生むのか、に関する身体性にもとづく想像力です。時間変化するカオス的相互作用のある物理空間で発達した知能（＝身体性知能）のみが、これを理解できるのです。 現代の AI を製造業に活用するには AI/ML の技術は次のように分類され、一般的にはそれぞれ次のような強みを持っています。 従来の ML: 数値予測、最適化、異常検知、画像認識などの分析に強みを持ちます。 生成 AI: テキストモデルは文書作成、知識検索、説明生成、レポート作成に最適です。マルチモーダルモデルは図表付き文書や動画からのデータ抽出、画像や音声などの生成に活用可能です。 AWS は製造業を 5 つの主要領域で捉えています。 設計開発領域 生産領域 スマートプロダクト & サービス領域 サプライチェーン領域 サステナビリティ領域 本ブログのスコープである 設計開発領域 について業務レベルにドリルダウンして、AI/ML の技術ごとに活用可能性を概観してみようと思います。 図 5: 設計開発領域の業務ごとの AI/ML の活用可能性 本ブログで深ぼって論じてきた 基本設計・詳細設計 は身体性知能が必要なため△評価です。一方で、企画・構想設計、生産技術との連携、プロジェクト管理といった業務の中で、言語的コミュニケーションが中心の業務あるいは画像からの情報抽出などが役に立つ業務では、生成 AI が強みを発揮します。解析・シミュレーションは数値計算・最適化に関する従来の ML（擬似的なシミュレーション結果を出力するサロゲートモデルを含む）が活用できる可能性があります。設計のコア業務以外に目を向ければ、身体性知能が必須ではなく、AI/ML の技術を効果的に活用できる領域が広がっていることがわかります。 まとめ 本ブログでは製造業の設計領域のコア業務に AI が活用できるかを論じました。ある業務で AI が活躍できるかどうかは、その業務が身体性知能を必要とするかどうか、という原理から考えるアプローチを提案しました。現代の AI の限界を理解し、それ以外の適切な領域で AI/ML を活用することで、大きなビジネス効果を得られます。このために、製造業のお客様は Amazon Bedrock , Amazon SageMaker , AWS IoT など多様な AWS サービスのエコシステムを活用できます。 近い将来、AI のパラダイムシフトが起こる可能性はあります。技術の進化は速く、本ブログで「難しい」と述べた部分も、モデルの改善によって（身体性知能の完全な再現ではないにしても）かなり近いところまで到達するかもしれません。ユースケースや時代によって最適な AI モデルが変わる中で、簡単にモデルを切り替えられる Amazon Bedrock のメリットは大きいです。AWS は幅広い LLM をラインナップしており、お客様は最新のモデルを最小の労力で試し、実際の業務に組み込むことができます。 我々は普段から AI を使うなかで、AI の能力に感嘆することもあれば、本ブログで示したような限界を目にすることもあります。しかし、絶え間ないイノベーションがこの壁を一つずつ取り払っていくはずです。我々が知能を真に理解できる日を心から楽しみにしています。 著者紹介 中西 貴大 (Takahiro Nakanishi) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな AWS サービスは AWS IoT Core です。機械も含めてものづくり全般が好きで、自分と同い年の愛車を整備したり、計器デバイスを自作したりしながら大事に乗っています。

こんにちは。製造業のお客様を技術支援しているソリューションアーキテクトの中西です。 生成 AI が普及するなかで、設計領域のユースケースとして「仕様書に記載された要件から図面や設計パラメータを出力したい」、「図面に表現された部品を理解した AI のインサイトが欲しい」といったご相談をお客様からいただくことがあります。機械設計の経験があり機械が大好きな筆者としても、お客様のご期待に応えたい気持ちが強いですが、残念ながらこれらのユースケースに対して現状の AI が大活躍することは「原理的に」難しいです。 では、なぜできないのか？ 将来的にできるようになるのか？ このあたりが気になるところかと思います。本ブログでは前編・ 後編 に分けて、原理的な観点からそこに迫ります。これにより、普及が進む生成 AI の活用シーンを一緒に見極め、効果的な投資の一助になれたら幸いです。 前編: 「身体性」という概念を通して、現代の AI がハードウェア設計のコア業務で活躍しにくい理由を原理的に解き明かします。 後編 : ハードウェア開発とソフトウェア開発の本質的な違いを明らかにしつつ、製造業のどの領域で AI が効果的に活用できるのかを探ります。 現在主流の AI のパラダイムとその限界 これまで機械学習 (ML) は、教師あり学習ではラベルつきデータを学習して分類問題を解いたり、教師なし学習ではラベルなしデータに内在するパターンや規則性を明らかにしたりする技術でした。このパラダイムは、大規模言語モデル (LLM) が台頭しても大きく変わることはありません。LLM は非常に大規模なラベルなしデータを学習した結果得られた自然言語の潜在的な確率的パターンに基づいて応答します。 人間は柔軟で臨機応変な行動能力を持ち、「知能」を持っていると言われます。では、現在主流のこれらの AI (Artificial Intelligence) は、人間と同様の知能 (Intelligence) と呼べるのでしょうか？ この問いは、AI 研究や認知発達科学において非常に重要です。以前から一部の研究者はこの課題感を持っており、知能の発現には「身体性」が必要と唱えています。本ブログでは身体性という切り口から、設計領域での生成 AI 活用を見ていきたいと思います。 AI と「身体性」 身体性とは？ 身体性 (embodiment) とは、知能や認知プロセスが単に脳や計算機の中だけで起こるのではなく、身体全体と環境との相互作用を通じて形成されるという考え方です。知能を持つシステムを構築するために、環境と相互作用する「身体」が必要であることは、これまでの認知科学や発達心理学で明らかになっています。 従来の AI 研究では、人間の知能を推論、記憶などの機能ごとに分解して、それぞれの入力と出力の関係をモデル化しようとしてきました。このアプローチに基づく以上、人間のような真に柔軟で臨機応変な知能を実現することはできません。なぜでしょうか？ 知能と身体性の関係 人間は発達の過程で、身体と外界との相互作用を通じて学習し、抽象的概念や推論能力が自発的に発達するプロセスを経ます。一方、現代の AI は、開発者が論理規則や統計モデルとして構築した言語的知識の帰結のみを明示的にシステムに埋め込むアプローチとなっています。 「認知ロボティクス」に関する 論文 ではこう表現されています： 発達システムは「流れ」であり、ある瞬間の機能や構造は「渦」といえる。従来の AI や認知ロボティクスの方法は、静水中に渦の型を入れたあと、適当な水流を起こして意図した渦の発生と維持を期待することに近い。 論文の表現を借りるなら、真の知能は「川の流れ」のようなもので、その中に生まれる「渦」が私たちが観察できる知的な振る舞いといえます。これに対して現代の AI は、あらかじめ「渦の形」を決めておいて、それらしい動きが出るように水を流すようなものでした。でも、本物の川の渦はそうやって作られるものではありませんよね。 人間は発達の過程で、身体と外界との相互作用を通じて学習し、抽象的概念や推論能力が自発的に発達します。この過程は教師なし学習であり、学習結果は入力のみに依存するので、意味のある学習が生まれるのか疑問に思うかもしれません。この疑問を解消するのが、まさに身体性です。身体と環境の物理的特性によって、発生する相互作用全体は構造化されています。その構造化を与えるのが身体性であり、身体性こそが「川の流れ」を規定して学習結果に意味を与え、知能を発現させるのです。 AI における身体性の欠如がもたらす影響 図 1: マルチモーダル生成 AI による機械図面の理解力を試す実験 実際に、筆者が過去に書いた機械図面をマルチモーダル生成 AI に読ませてみたところ、図面の内容をほとんど理解できていないことがわかりました (図 1)。シャフトカラー（回転軸に取り付けてトルクを伝達する締結部品）の図面を与えて図面の基本的な理解を問い、回答を◯△×で評価しました。その結果、図面かプロンプトから読み取れた文字情報から連想した一般的な回答しか正解できていません。このように身体性のない AI は、たとえ機械図面に描かれた外形や穴を認識できたとしても、それらが実際に我々の 3 次元空間でどのように存在して、どのように回転し、荷重やトルクを伝えるかという物理的な理解まで到達できないのです。 この身体性の欠如は、AI が設計プロセスの核心部分を担うことを難しくしています。機械設計者が部品の形状と材質を決めるには、その形が物理世界でどのように機能するかを理解し、予測することが必須だからです。 身体性が、カオスから秩序を生む ここで、筆者がこれまで生きてきた中で、身体性知能と不思議な共通点を見た 3 つの面白いトピックをご紹介します。「製造業や生成 AI と何の関係があるのか？」と感じられるかもしれませんが、まずはお読みください。 物理リザバーコンピューティング (RC) 図 2: 物理リザバーコンピューティングの概念図 ここでご紹介したいのは、物理リザバーコンピューティング (RC) です。聞き慣れない言葉と思いますが、とても簡単に言えば「自然界の物理現象を計算に活用できる」というものです。例えば、水の波紋や柔らかいタコの足、光デバイスなど、複雑な動きをする（入力に対して非線形な出力を発生する）ハードウェアが「リザバー」になりえます。 このリザバーに何か信号を入力すると、複雑な（非線形で時間変化する）反応が起きます。その反応をいくつかのセンサーで測定し、それらの値に定数をかけて足し引きする（= 線形結合する）だけで、望みの出力を得られるように調整します。大事なポイントは、図 2 のようにリザバー層の挙動は物理現象で定義されており変えることはできないので、出力層だけを調整（学習）させる点です。一般的なニューラルネットワークでは、バックプロパゲーションという方法で、出力層から入力層に向かって全ての層を学習しますが、物理 RC では出力層以外は一切変更せずそのまま利用する点が興味深いです。 図 2 の左に示した原始的な人工知能モデルである「単純パーセプトロン」では XOR 問題 (「A か B のどちらか一方だけが真のとき真となる」という単純な論理) すら解けませんが、これは出力が入力の線型結合だけで作られるためです。より複雑な問題を解くことができる現代のニューラルネットワークは、非線形な関数（= 活性化関数）と線型結合を何層にも重ねることで、ある種のカオス（非常に複雑な挙動）を作り出しています。同様に、物理リザバーコンピューティング (RC) も実世界の非線形な物理現象を計算資源として活用していると理解できます。 身体性の観点から見れば、この類似性は、物理世界のカオス的な振る舞いの中に知能の萌芽が存在することを示すように思えます。 ビッグバンから知的生命 我々の知能がどのように形成されてきたかを、宇宙物理学者たちは宇宙の始まりから遡って考えています。 ビッグバンから元素や恒星が生まれ、惑星でアミノ酸が合成され、知的生命体が生まれた。カオスから秩序が生まれたということができます。偶然にしてはできすぎているので、「神が全て作った」というのは一つの説明の仕方ではありますが、物理学者たちはカオスから秩序が生まれるのは自然なことと解き明かしています。 皆様も家の中でハエなどの害虫を仕留め損なったことがあるのではないでしょうか。ハエもビッグバンから自然の流れの中で生まれ、発達してきた生き物です。我々が叩き潰そうとすると、ハエは素早くそれを察知し、脚や羽を的確に駆動して、逃げようとします。ロボット工学的に例えて、あの小さな体にセンサー、アクチュエータ、制御プログラムが全て入っていると考えると驚くべきことですが、これも身体性知能が為せる業です。 モリヌークス問題 モリヌークス問題は特に興味深い事例です。17 世紀、哲学者ウィリアム・モリヌークスが提起したこの問題は、「生まれつき盲目の人が、触覚で球体と立方体を区別できるようになった後、もし後天的に手術で視力を得たら、見ただけでそれらを区別できるだろうか？」というものです。 この問題の本質は、異なる感覚モダリティ（触覚と視覚）間での知識の転移可能性にあります。ニューラルネットワークの文脈で考えると、これは一つの入力形式（触覚データ）で学習したモデルが、別の入力形式（視覚データ）に対しても適切に一般化できるかという問題に相当します。 先天盲の人々は、生後に手術により視力を得ても、最初は視覚だけでは物体を識別できない、ということを示す認知科学研究の報告は多く存在します（ 一例 ）。これは、知覚が、身体を通じた環境との相互作用から生まれることを示唆しています。 このモリヌークス問題は、ブログ冒頭に書いた「生成 AI で機械図面を真に理解できるか？」に示唆を与えると考えています。画像入力に対応したマルチモーダル AI モデルは「目」を持つと言えますが、身体を持ちません。先述のように、身体を持って外界と相互作用して発達しながらこの世界を理解してきたわけではないので、図 1 のように「目」だけで図面をインプットしたとしても、その形状の部品が我々の生きる物理環境でどんな意味を持つのか、どう相互作用するかを真に理解することはできないのです。 まとめ 前編では、身体性の観点から、知能とはハードウェア（身体）に宿るものであり、現代の AI にも原理的な限界があること示しました。後編では、ハードウェア開発とソフトウェア開発の違いをさらに深掘りし、製造業のどの領域で AI が効果的に活用できるのかを考察します。 後編はこちら 著者紹介 中西 貴大 (Takahiro Nakanishi) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな AWS サービスは AWS IoT Core です。機械も含めてものづくり全般が好きで、自分と同い年の愛車を整備したり、計器デバイスを自作したりしながら大事に乗っています。

皆様こんにちは。プリンシパルソリューションズアーキテクトの梶本（かじもと）とソリューションアーキテクトの黒木（くろき）です。3月18日に AWS が主催する自動車業界向けイベント「AWS CES2025 Recap セミナー -Amazon for Automotive の最新自動車テクノロジー・ソリューションのご紹介-」を開催しました。 AWSでは、世界中で進む自動車業界のデジタル変革に向け、 2023 年より最新技術や先進事例の活用方法等のご紹介を目的に、グローバルイベント CES に出展しています。2025 年は、業界全体で加速するモビリティのデジタル化と SDV(ソフトウェア・デファインド・ビークル）の実現に向け、 先進的取り組みをご紹介させていただきました。 今回のイベントでは、 SDV の分野で協業させていただいているホンダ様の CES でのご報告をいただいた後、AWS としての CES でご紹介した内容、パートナー様協業について報告させていただきました。 オープニング ― 竹川 寿也　アマゾン ウェブ サービス　 シニア・ビジネスデベロップメント・マネージャ オープニングでは、CES の概要や自動車業界の会社様からリリースあったトピックのご紹介、また Amazon for Automotive としてどういった思いで CES に出展したのかなどを説明しました。特に SDV (Software Defined Vehicle) においては車載インフォテイメントだけではなく、安全基準も踏まえた自動車の運行制御（走る・曲がる・止まる）までのソフトウェア制御を行う車両を SDV と呼ぶという、AWS も委員として参加している経済産業省 モビリティ DXプロジェクトでの定義をふまえお伝えしました。 ホンダ × AWS CES で協同展示！爆速開発を支える両者での取組 ― 渡邊 将行 様　本田技研工業株式会社　 電動事業開発本部 SDV事業開発統括部 電動ソフトウェアソリューション開発部 チーフエンジニア ― 竹原 洋三 様　本田技研工業株式会社　 電動事業開発本 SDV事業開発統括部 コネクテッドソリューション開発部 アシスタントチーフエンジニア 本セッションでは CES 2025 で Amazon / AWS と協同展示いただいた本田技研工業株式会社様より爆速開発を支える両者での取組についてご登壇いただきました。 従来、本田技研工業株式会社様ではソフトウェアの設計をするためにはハードウェアを待たなければならない、ハードウェアごとの差異もある、といった課題を抱えられておりそれを解消するためにDPG(Digital Proving Ground)を構築されました。Proving Ground は研究所内のテストコースを指されておりそれをデジタルで実現するというコンセプトのものです。 開発者が統合コンソールにアクセスすることで必要な開発環境が立ち上がり、開発者が Amazon DCV でそこへアクセスできるというアーキテクチャについてご説明いただきました。またそれを用いた一例として充電の体験を良くするPoCとして Amazon Bedrock をご活用いただき CES でも展示された CHARGING UX をご紹介いただきました。 SDV 開発クラウドワークフロー最前線 ― 梶本 一夫　アマゾン ウェブ サービス　 プリンシバル・ソリューション・アーキテクト 本セッションでは、 CES において、 AWS の SDV 先進取組みとして展示した内容をご紹介しました。 昨今、自動車産業において言われる、「自動車は発売後も OTA 等によりアップデートされつづけお客様に価値を届け続ける」と言うライフサイクルに従い、そのライフサイクルに沿ったワークフローが、クラウド内の車両データを中心に循環する考え方をご紹介しました。この各ワークフローの実装に AWS のサービス群がインフラとして利用されています。さらに各ワークフロー全てにおいて AI による革新が及んでいます。 CES では、この循環するワークフローにおけるユースケースをいくつか展示しました。この展示においては、各ユースケースは、一つの共通 Web UI (Virtual Engineering Workbench) からデプロイすることができます。 Virtual Engineering Workbenchの導入により、高性能マシンや評価ボードがまだ入手できていない段階でも開発環境が構築でき、シフトレフトが可能となります。また、これまでサイロ化されることが多かった各分野間での連携開発が、クラウド上での車両データ連携やツール連携により可能になることを訴求しました。 具体的なケーススタディとして、例えばConnected開発環境において 、 ADAS の不具合に関係しそうな滅多に起きない特定シーンを AWS IoT FleetWise を用いた Campaign（車両に対するデータ取得の条件設定） により収集し、その内容を ADAS 開発環境と連携することを紹介しました。 ADAS環境では、自動運転学習モデルを検証するテストシナリオのデータセットを、自然言語から生成 AI を用いて生成する試作も紹介しました。 またIVIを事例に、 ECU の仮想化と生成 AI を組合わせることで、自然言語による仕様変更の表現から、要求仕様書の更新、ソースコードの更新、Virtual ECU 上での検証と、クラウド内で一連の開発ができることを示し、仮想化によるCut & Tryのしやすさも訴求しました。 EE Architecture 開発環境においては AWS Outposts を用いてクラウドをお客様環境まで延伸し、お客様の HILS 環境と組み合わせた試作環境も紹介しました。実際に全ての周辺回路などのハードウェアをクラウド上に仮想化することは、モデル設計など余分な工数もかかるため、現実解としてクラウドの仮想環境と周辺機器の実環境の連携の可能性を示しました。 AWS は、お客様が構築されるソリューション群において、共通的な部分をインフラサービスとして提供し、お客様には、より競争領域にてイノベーティブな業務に注力いただくとの考えで、今後ともお客様のパートナーとして併走させていただきたいと結びました。 AWS オートモーティブ パートナーのソリューション展示とアナウンスメント ― 橘 幸彦　アマゾン ウェブ サービス　 シニア パートナー セールス マネージャー 本セッションでは CES 2025 において Amazon for Automotive ブースにパートナー様としてデモ展示・協業いただきました NVIDIA 様、Siemens 様、 Capgemini 様、 HCLTech 様、 ZeroLight 様の展示内容についてご紹介しました。また CES 2025 でパートナー様から発表された AWS との協業ソリューション4事例についてもご紹介しました。このような自動車産業向けにケイパビリティを持ったパートナー様とのパートナーシップもあるという点をお伝えしました。 Amazonによる自動車販売への貢献 ― 茂手木 光一　Amazonジャパン　Account Executive ― 佐藤まさし　Amazonジャパン　 Senior Vendor Manager ― 飯塚 零 　アマゾン ウェブ サービス　 Senior Account Manager 本セッションでは Amazon を活用してのブランドロイヤリティの向上、ブランディングからセールスまでの統合的な施策、その中で AWS の生成 AI を用いてカーオーナーにどういった価値提供ができるかをご紹介しました。 車両販売を EC サイトから行うという響きは一見、自動車メーカー様と販売店様の関係に悪影響を与えかねないように誤解されることもありますが、あくまで EC サイトを接点の一つとしていただくだけで実際に販売されるのは販売店様であることなども質疑を通してお伝えしました。 おわりに 本ブログでは東京で開催した本セッションでは「AWS CES2025 Recap セミナー -Amazon for Automotive の最新自動車テクノロジー・ソリューションのご紹介- 」についてレポートしました。CES 2025 にも参加された方、CES 2025 にはご参加できなかった方など様々なお客様がいらっしゃる中で「クラウドを活用することで自動車の開発が加速する可能性を感じた」「自動車 OEM が目指そうとされている方向性を知ることでサプライヤーとして気づきを得ることができた」などのご評価をいただきました。ご参加いただいた皆様、本当にありがとうございました。本日の内容が少しでも今後の皆様の業務のお役に立てば幸いです。 著者について 梶本一夫（Kazuo Kajimoto） Principal Solutions Architect Amazon Web Services, Inc. 好きなOLP（ Our Leadership Principles ）はBias for Actionです。     黒木裕貴 (Yuki Kuroki) Solutions Architect ソリューションアーキテクトとして西日本の自動車OEM、サプライヤーなどのお客様を担当しています。

3 月 26 日、 AWS WAF と AWS Amplify ホスティング の統合の一般提供についてお知らせします。 ウェブアプリケーションの所有者は、さまざまな脅威からアプリケーションを保護する取り組みを続けています。以前は、Amplify でホストされたアプリケーションに強固なセキュリティ体制を実装するには、AWS WAF 保護機能を備えた Amazon CloudFront ディストリビューションを使用してアーキテクチャを作成する必要がありましたが、これには追加の設定手順、専門知識、そして管理オーバーヘッドが必要でした。 Amplify ホスティング内の AWS WAF の一般提供により、 Amplify コンソール でのワンクリック統合を介して、または Infrastructure as Code (IaC) を使用して、ウェブアプリケーションファイアウォールを AWS Amplify アプリに直接アタッチできるようになりました。この統合により、一般的なウェブエクスプロイトと SQL インジェクションやクロスサイトスクリプティング (XSS) などの脆弱性に対する保護を提供するマネージドルールを始めとする AWS WAF のすべての機能にアクセスできるようになります。特定のアプリケーションニーズに基づいて独自のカスタムルールを作成することもできます。 この新機能は、ウェブアプリケーションに多層防御セキュリティ戦略を実装するのに役立ちます。AWS WAF のレートベースのルールを利用して、IP アドレスからのリクエストのレートを制限することで、分散型サービス拒否 (DDoS) 攻撃から保護できます。さらに、ジオブロッキングを実装して、アプリケーションへの特定の国からのアクセスを制限できます。これはサービスが特定の地域向けに設計されている場合に特に役立ちます。 仕組みを見てみましょう Amplify アプリケーションの AWS WAF 保護は簡単に設定できます。Amplify コンソールから、アプリの設定に移動し、 [ファイアウォール] タブを選択し、設定に適用する定義済みルールを選択します。 Amplify ホスティングではファイアウォールルールの設定が簡素化されます。4 つの保護カテゴリを有効にできます。 Amplify が推奨するファイアウォール保護 – ウェブアプリケーションに見られる最も一般的な脆弱性から保護し、Amazon の内部脅威インテリジェンスに基づいて潜在的な脅威から IP アドレスをブロックし、悪意のある攻撃者がアプリケーションの脆弱性を発見するのを防ぎます。 amplifyapp.com へのアクセスを制限 – Amplify が生成したデフォルトの amplifyapp.com ドメインへのアクセスを制限します。これはカスタムドメインを追加してボットや検索エンジンがドメインをクロールするのを防ぐ場合に便利です。 IP アドレスの保護を有効にする – 指定した IP アドレス範囲からのリクエストを許可またはブロックして、Web トラフィックを制限します。 国の保護を有効にする – 特定の国に基づいてアクセスを制限します。 Amplify コンソールで保護を有効にすると、基盤となる ウェブアクセスコントロールリスト (ACL) が AWS アカウントに作成されます。きめ細かいルールセットには、AWS WAF コンソールのルールビルダーを使用できます。 数分経つとルールがアプリケーションに関連付けられ、AWS WAF は疑わしいリクエストをブロックします。 AWS WAF の動作を確認する場合は、AWS WAF リクエストインスペクション機能を使用して攻撃をシミュレートし、モニタリングすることができます。例えば、User-Agent 値が空のリクエストを送信することが可能です。その場合、AWS WAF のブロッキングルールがトリガーされます。 まず、有効なリクエストをアプリに送信してみます。 curl -v -H "User-Agent: MyUserAgent" https://main.d3sk5bt8rx6f9y.amplifyapp.com/ * Host main.d3sk5bt8rx6f9y.amplifyapp.com:443 was resolved. ...(redacted for brevity)... > GET / HTTP/2 > Host: main.d3sk5bt8rx6f9y.amplifyapp.com > Accept: */* > User-Agent: MyUserAgent > * Request completely sent off < HTTP/2 200 < content-type: text/html < content-length: 0 < date: Mon, 10 Mar 2025 14:45:26 GMT サーバーが HTTP 200 (OK) メッセージを返したことが確認できます。 次に、User-Agent HTTP ヘッダーに値が関連付けられていないリクエストを送信します。 curl -v -H "User-Agent: " https://main.d3sk5bt8rx6f9y.amplifyapp.com/ * Host main.d3sk5bt8rx6f9y.amplifyapp.com:443 was resolved. ... (redacted for brevity) ... > GET / HTTP/2 > Host: main.d3sk5bt8rx6f9y.amplifyapp.com > Accept: */* > * Request completely sent off < HTTP/2 403 < server: CloudFront ... (redacted for brevity) ... <TITLE>ERROR: The request could not be satisfied</TITLE> </HEAD><BODY> <H1>403 ERROR</H1> <H2>The request could not be satisfied.</H2> サーバーが HTTP 403 (Forbidden) メッセージを返したことが確認できます。 AWS WAF ではリクエストパターンを可視化できるため、時間の経過にしたがってセキュリティ設定をファインチューニングできます。Amplify ホスティングまたは AWS WAF コンソールからログにアクセスして、トラフィックの傾向を分析し、必要に応じてセキュリティルールを調整できます。 利用可能なリージョンと料金 ファイアウォールのサポートは、Amplify ホスティングが利用可能なすべての AWS リージョン で利用できます。Amazon CloudFront と同様に、この統合は AWS WAF グローバルリソースに該当します。ウェブ ACL は複数の Amplify ホスティングアプリに接続できますが、対象となるアプリは同じリージョンに存在する必要があります。 この統合の料金は、標準の AWS WAF の料金モデル に従います。ウェブ ACL、ルール、リクエストの数に基づいて、使用する AWS WAF リソースの料金をお支払いいただきます。さらに、AWS Amplify ホスティングでは、アプリケーションにウェブアプリケーションファイアウォールをアタッチすると、1 か月あたり 15 USD の追加料金が発生します。これは時間単位で計算されます。 この新機能により、個々の開発者から大企業まで、すべての Amplify ホスティングのお客様にエンタープライズグレードのセキュリティ機能が提供されます。同じサービス内でウェブアプリケーションを構築、ホスト、保護することができるようになったため、アーキテクチャの複雑さが軽減され、セキュリティ管理が合理化されます。 詳細については、 Amplify の AWS WAF 統合ドキュメント を参照するか、Amplify コンソールで直接試してみてください。 – seb ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

3 月 25 日より、AWS リージョンと AWS アベイラビリティーゾーン (AZ) の地理的位置情報をより詳細に可視化できるようになりました。この詳細情報は、規制、コンプライアンス、運用上の要件に即したリージョンと AZ を選択するのに役立ちます。 弊社は、お客様のビジネス要件を満たすように AWS のグローバルインフラストラクチャを継続的に拡張し、現在では 36 のリージョンにわたる 114 の AZ を保有しています。また、 ニュージーランド 、 サウジアラビア王国 、 台湾 、 AWS European Sovereign Cloud に 12 の AZ と 4 つのリージョンを追加する計画を発表しました。 お客様から学んだことの 1 つに、AWS リージョン内のインフラストラクチャの特定の場所をより詳細に把握する必要があるということがあります。これは、インフラストラクチャの物理的な配置に特定の要件がある金融業界やゲーム業界など、規制の厳しい業界のお客様にとって重要です。例えば、米国に拠点を置く大手スポーツゲーム企業の FanDuel は、米国とカナダで新しい市場に参入しています。同社は向上した地理的透明性を活用して、より多くの情報に基づいた意思決定を行い、事業の迅速なスケールに合わせてデータレジデンシーの要件を確実に満たしています。 AWS リージョンの地理 リージョンの地理情報を確認するには、 AWS グローバルインフラストラクチャのリージョンとアベイラビリティーゾーン のページを参照してください。このページでは、マップ上の任意のタブを選択して下にスクロールすると各リージョンの地理情報を確認できます。次の図は、北米リージョンの例を示しています。予想した通り、 米国西部 (オレゴン) リージョン のインフラストラクチャは 米国 にあり、 カナダ (中部) リージョン のインフラストラクチャは カナダ に位置しています。 アベイラビリティーゾーンの地理 AZ の特定の地理情報を確認するには、AWS ドキュメントの「 AWS Regions and Availability Zones 」のページを参照してください。目的のリージョンを選択すると、そのリージョンの地理を示す表が表示されます。次のスクリーンショットに示すように、AZ ID use1-az1 の AZ のインフラストラクチャは、 米国バージニア州 にあります。 引き続きご期待ください これらのページでは、AWS グローバルインフラストラクチャのフットプリントの拡大が継続し、AWS リージョンと AZ がさらに追加されるにつれて新しい地理情報が反映されます。 クイックリンク 詳細については、 AWS グローバルインフラストラクチャのリージョンとアベイラビリティーゾーン のページまたは AWS ドキュメントの「 AWS Regions and Availability Zones 」ページにアクセスしてください。フィードバックは、 AWS re:Post または通常の AWS サポートの連絡先を通してお寄せください。 – Prasad ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

2025 年 3 月の国際女性デー (IWD) を祝うにあたり、私は 3 月 17 日週末、深圳で「Women in Tech」ユーザーグループのミートアップに参加する機会に恵まれました。さまざまな業界から 100 人以上のテクノロジー分野で活躍している女性が集まり、女性の視点から AI 倫理について議論しているのを見て、感銘を受けました。私たちは一緒に、AI システムにおけるジェンダーバイアスの軽減や、モデルトレーニングデータにおける多様な視点の促進などの戦略を検討しました。 AWS Cloud Lab では、参加者は、 Amazon Bedrock と 大規模言語モデル (LLM) を使用してバラの花の動画を生成しました。これは、このミートアップで最も人気があったアクティビティでした。 これらの集まりは、AI テクノロジーの探求と開発における女性の関与を促進し、生成 AI 時代がジェンダーバイアスなしで発展するようサポートするための私たちの取り組みにとって非常に重要です。イベント全体を通して示された協力的な精神と技術的な探究心は、多様性に富んだチームがインクルーシブかつ効果的なソリューションを真に構築していることのさらなる証左です。 活発なコミュニティのエンゲージメントといえば、私は、今週末に開催された Kubernetes Community Day (KCD) Beijing 2025 で発表する機会もいただきました。コンテナテクノロジーへの熱意 は目を見張るものがあり、約 300 人のデベロッパーが集まり、経験やベストプラクティスを共有しました。 Amazon Web Services (AWS) の DoEKS プロジェクトをご紹介した私の基調講演において、私は、オーディエンスのマネージド Kubernetes サービスへの関心の深さに驚きました。オーディエンスの質問によって、 Amazon Elastic Kubernetes Service (Amazon EKS) や Amazon Elastic Container Service (Amazon ECS) などのサービスが、ミッションクリティカルなアプリケーションを構築する中国のデベロッパーの間でどれほど広く採用されているのかが明らかとなりました。このコミュニティの強い関心は、 Omdia Universe: Cloud Container Management & Services 2024–25 レポート の調査結果と完全に一致しています。パブリッククラウドでホストされているコンテナ管理ソリューションのこの包括的な評価において、AWS はリーダーとして認められました。このレポートでは特に、AWS が「クラウド、エッジ、オンプレミス環境全体で Kubernetes または独自のコンテナ管理サービスを使用するための極めて幅広いオプション」を提供していることが強調されています。 当社の包括的なコンテナポートフォリオの詳細や、ビルダーがスケーラブルで信頼性の高いコンテナ化されたアプリケーションをデプロイするのを当社がどのようにサポートしているのかの詳細については、 AWS のオファリングに関する詳細なレポート をお読みください。 3 月 17 日週のリリース インスピレーションに満ちたコミュニティイベントに加えて、私が注目した AWS のリリースをいくつかご紹介します。 Amazon Q Business ブラウザ拡張機能がアップグレード – Amazon Q Business ブラウザ拡張機能に、ブラウザベースのタスクを効率化するように設計された大幅な機能強化が導入されました。ユーザーは、ウェブコンテンツとともに会社のインデックス化された知識にアクセスできるほか、ブラウザ内での PDF の直接サポート、画像ファイルの添付機能、会話のコンテキストから無関係な添付ファイルを削除するコントロールを使用できます。拡張されたコンテキストウィンドウでは、より大きなウェブページとより詳細なプロンプトを表示でき、より役立つ応答を得ることができます。高度なニーズに対応するため、この拡張機能は、アクションと Amazon Q Apps へのアクセスを備えた完全な Amazon Q Business ウェブエクスペリエンスへのシームレスな移行を提供します。この発表の詳細については、ドキュメントの「 Enhancing web browsing with Amazon Q Business 」をご覧ください。同記事では、詳細なセットアップ手順と機能の説明が記載されています。 Amazon Bedrock RAG 評価の一般提供を開始 – LLM-as-a-Judge の手法を通じて、 Bedrock のナレッジベース とカスタム 検索拡張生成 (RAG) システムの両方の包括的な評価を提供します。このサービスは、関連性、正確性、ハルシネーション検出のメトリクスを使用して検索の質とエンドツーエンドの生成を評価します。また、新たに追加されたカスタム RAG パイプライン評価のサポートにより、独自の入力-出力ペアと取得したコンテキストを評価ジョブで直接使用できるほか、新しい引用精度メトリクスと Amazon Bedrock のガードレール の統合により、より柔軟な RAG システム最適化が可能になります。詳細については、ドキュメントの「 Amazon Bedrock の評価 」ページと「 What is Amazon Bedrock? 」にアクセスしてください。 Amazon Nova が Converse API のツール選択オプションを拡張 – Amazon Nova を強化し、 Converse API の ツール選択 機能を拡張しました。これにより、デベロッパーは、高度な AI アプリケーションをより柔軟に構築できます。この更新により、モデルはツールを使用するタイミングを決定し、ユーザーのリクエストをより効果的に満たすことができます。詳細については、 ツール選択オプションの拡張に関するお知らせ をご覧ください。 Amazon Bedrock のガードレールが責任ある AI のためのポリシーベースの強制適用を追加 – ビルダーは、Amazon Bedrock のガードレールの新しい AWS Identity and Access Management (IAM) ポリシーベースの強制適用機能を使用して、責任ある AI ポリシーを大規模に強制適用できるようになりました。この機能は、すべてのモデル推論呼び出しが組織の AI 安全基準に準拠するよう、 bedrock:GuardrailIdentifier 条件キーを使用して IAM ポリシーを通じて必要なガードレールを指定するのに役立ちます。チームが Amazon Bedrock の呼び出しまたは Converse API コールを実行すると、必須のガードレールが含まれていない場合、リクエストは自動的に拒否され、望ましくないコンテンツ、機密情報の漏えい、モデルのハルシネーションに対する一貫した保護が提供されます。 責任ある AI のためのポリシーベースの強制適用に関するお知らせ の詳細については、技術ドキュメントの「 Set up permissions to use Guaidrails for content filtering 」と、 Amazon Bedrock のガードレールの製品ページ をご覧ください。 次世代の Amazon Connect がリリース – 顧客関係を強化し、ビジネス成果を改善するよう設計された、AI を活用したインタラクションを特徴とする次世代の Amazon Connect をリリースしました。このメジャーアップデートにより、強化されたエージェントエクスペリエンス、顧客とのよりスマートなやり取り、運用に関するより深いインサイトが、あらゆる規模のコンタクトセンターにもたらされます。詳細については、AWS コンタクトセンターブログの 新しいリリースに関する記事 をご覧ください。 Amazon Redshift Serverless が Current リリーストラックと Trailing リリーストラックを導入 – Amazon Redshift Serverless は、ユーザーが更新の頻度をより細かく制御できるように、2 つのリリーストラックの提供を開始しました。Current トラックでは最新の機能とセキュリティ更新を含む最新の認証済みリリースが提供される一方で、Trailing トラックでは以前の認証済みリリースのままとなります。このデュアルトラックアプローチにより、組織は、新しいリリースを本番環境全体で実装する前に、選択した ワークグループ で検証できます。ユーザーは Amazon Redshift コンソールを通じてトラックを簡単に切り替えることができるため、ミッションクリティカルなワークロードの革新性と安定性のバランスを柔軟に調整できます。この機能は、Amazon Redshift Serverless が提供されているすべての AWS リージョン でご利用いただけます。Amazon Redshift Serverless の Current トラックと Trailing トラック の詳細については、「 Tracks for Amazon Redshift provisioned clusters and serverless workgroups 」をご覧ください。 AWS WAF が URI フラグメントフィールドのマッチングのサポートを開始 – AWS WAF は、URI フラグメントフィールドのマッチングを含むように機能を拡張しました。これにより、セキュリティチームは、URL のフラグメント部分を検査してマッチングするルールを作成できるようになりました。この機能強化により、URI フラグメントを使用してページ内の特定のセクションを識別するウェブアプリケーションのために、より正確なセキュリティコントロールが可能になります。セキュリティプロフェッショナルは、機密性の高いページ要素へのアクセスの制限、疑わしいナビゲーションパターンの検出、自動化された攻撃に特徴的なフラグメント使用パターンの分析によるボット緩和の強化など、よりターゲットを絞った保護を実装できるようになりました。この機能は、AWS WAF がサポートされているすべての AWS リージョンでご利用いただけます。マッチングのための URI フィールドの詳細については、「 AWS WAF デベロッパーガイド 」にアクセスしてください。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」をご覧ください。 AWS のその他のニュース その他の興味深いプロジェクトやブログ記事をいくつかご紹介します。 AWS Gen AI Loft で生成 AI スキルを強化 – AWS は 2025 年に、デベロッパーやスタートアップのためにトレーニングとネットワーキングを提供する 10 を超えるグローバルハブを設立しました。そこでは、最新の AI テクノロジーを実用的かつ実践的に体験できます。これらの改良されたスペースは、プロンプトエンジニアリング、 基盤モデル (FM) の選択、本番環境での AI の実装に関するワークショップに参加できる専用ゾーンを特徴としています。サンフランシスコ、ニューヨーク、東京、または AWS Gen AI Loft がある他の主要なテクノロジーハブのお近くにいる場合は、ぜひお立ち寄りいただき、これらの無料リソースにアクセスして、生成 AI 開発スキルの強化を加速してください。 AWS Gen AI Loft のすべての場所とイベントをご覧ください 。また、詳細については、「 5 ways to build your AI skills on AWS Gen AI Loft 」をお読みください。 数十億回の非同期呼び出しに対応する AWS Lambda のアーキテクチャ – 技術に関する最近の記事では、AWS Lambda が高度なエンジニアリング手法を通じて大規模な処理に対応する方法が明らかにされています。Lambda の非同期呼び出しパスは、複数のキューイング戦略、インテリジェントパーティショニングのための一貫性のあるハッシュ、ノイジーネイバーの影響を最小限に抑えるためのシャッフルシャーディング手法を採用しています。システムは、主要なオブザーバビリティメトリクス (AsyncEventReceived、AsyncEventAge、および AsyncEventDropped) に依拠して、最適なパフォーマンスを維持しています。これらのアーキテクチャに関する決定により、Lambda は、信頼性の高いスケーラビリティとパフォーマンスの分離を実現しながら、150 万のアクティブな顧客にわたる 1 か月あたり数十兆回の呼び出しを処理しています。詳細については、AWS コンピューティングブログの「 Handling billions of invocations – best practices from AWS Lambda 」をお読みください。 AWS は、すべてのリージョンと料金モデルで、 ハイメモリ U7i インスタンス の料金を 11% 超引き下げる予定です。この値下げは、u7i-12tb.224xlarge、u7in-16tb.224xlarge、u7in-24tb.224xlarge、u7in-32tb.224xlarge の 4 つのインスタンスに適用されます。共有、専用、ホストのテナンシーオプションをカバーする新しいオンデマンド料金は、2025 年 3 月 1 日まで遡って適用されます。Savings Plan の新規購入の場合、料金は即時有効になります。 AWS ビルダー ID を作成し、エイリアスを予約する – ビルダー ID はユニバーサルログイン認証情報です。これにより、ユーザーは、 AWS マネジメントコンソール だけでなく、600 を超える無料トレーニングコース、コミュニティ機能、 Amazon Q Developer などのデベロッパーツールを含む AWS のツール やリソースにアクセスできます。 community.aws より community.aws からの私のお気に入りの記事をいくつかご紹介します。 Model Context Protocol (MCP): Why it matters! – 最近導入された Model Context Protocol (MCP) は、AI アプリケーションが一貫したプロンプトとツールを使用して複数の FM と通信するための標準化された方法を生み出します。 Build Serverless GenAI Apps Faster with Amazon Q Developer CLI Agent – Amazon Q Developer CLI エージェントが、数日ではなく数分で完全なサーバーレス生成 AI アプリケーションを構築することで、クラウド開発に革命をもたらす方法をご覧ください。 Automating Code Reviews with Amazon Q and GitHub Actions – 新しいデベロッパー向けチュートリアルでは、Amazon Q Developer を GitHub Actions と統合して、プルリクエストを自動的に分析し、AI を活用したコードフィードバックを提供する方法を説明します。 DeepSeek on AWS – 新しい技術ガイドでは、 DeepSeek の強力なオープンソース AI モデルを AWS インフラストラクチャにデプロイする方法を説明します。このチュートリアルは、 Amazon SageMaker 、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと GPU を使用するか、または Amazon Bedrock との統合を通じて、これらの最先端のモデルをセットアップするためのステップバイステップの手順を提供します。このガイドは、最適化の手法、サンプルアプリケーション、パフォーマンスとコスト効率のバランスを取ることについてのベストプラクティスをカバーします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 Empowering Futures – Women Leading the Way in Tech and Non-Tech Careers – プロフェッショナルなつながりを広げたい方、AWS クラウドについて学びたい方、インスピレーションあふれる講演者から知恵を学びたい方など、このイベントにはあらゆる方に有益です。これは、シアトル地域のすべての方にご参加いただける、2025 年 3 月 27 日開催の無料の公開イベントです。 AWS at KubeCon + CloudNativeCon London 2025 – 4 月 1 日～4 月 4 日に開催される KubeCon London の Excel ブース S300 で、Kubernetes の運用を簡素化し、コストとパフォーマンスを最適化するとともに、 人工学習と機械学習 (AI/ML) の力を活用して、スケーラブルなプラットフォーム戦略を構築するのに役立つライブ製品デモをご覧ください。 3 月 24 日週のニュースは以上です。3 月 31 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Betty この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

本記事は 2025 年 3 月 11 日に公開された “ Take control of your code with Amazon Q Developer’s new context features ” を翻訳したものです。 このブログでは、開発者が自分の開発ワークフローを完全にコントロールできるようになる、 Amazon Q Developer の強力な新機能を紹介します。これらの機能は現在 Visual Studio Code で利用可能で、ワークスペースコンテキスト、明示的なコンテキスト指定、プロンプトライブラリ、プロジェクトルールの活用によるソフトウェアプロジェクトの効率化、コーディング標準の維持、生産性の向上を実現できます。他の IDE を使用している開発者向けにも、これらの機能のサポートは今後提供される予定です。経験豊富な開発者でも、これから始めようとしている方でも、これらの機能によって開発タスクへの取り組み方が大きく変わるはずです。 背景 過去 1 年にわたり、 Amazon Q Developer は統合開発環境 (IDE) におけるワークスペースコンテキストをサポートしてきました。この強力な機能により、Amazon Q Developer はコードファイル、設定ファイル、プロジェクト構成などを自動的に読み取り、インデックス化することで、AI を活用したアシスタントがアプリケーション全体にわたる包括的なコンテキストを把握できるようになります。 質問に @workspace 修飾子を追加することで、Amazon Q Developer はワークスペース内のコードから最も関連性の高い部分を自動的に追加コンテキストとして含めることができます。これにより、現在のファイルだけでなく、より広範なコードベースの理解が必要な質問に対しても、より正確で充実した回答を得ることができます。 この機能を説明するために、 AWS CDK Immersion Day Workshop のコードを使用してみます。たとえば、「Which resources are deployed by the workshop stack?（このワークショップスタックでデプロイされるリソースは何ですか？）」と Amazon Q Developer に質問したとします。通常であれば、アシスタントは IDE 上で開いている現在のファイルだけをコンテキストとして使用しますが、 @workspace を追加することで、Amazon Q Developer は、AWS Lambda 関数、 Amazon API Gateway 、 Amazon DynamoDB テーブルなど、プロジェクト内のすべてのリソースを含む、より完全なレスポンスを得られます。 この追加コンテキストにより、Amazon Q Developer はより包括的な回答を行うことができ、ワークショップスタックを構成するさまざまなリソースについて詳しく説明してくれます。 コンテキストの透明性 Amazon Q Developer は、大規模なプロジェクトのすべてのファイルをレビューすることはできません。すべてを読み込むには時間がかかりすぎるためです。アシスタントは、定期的に更新されるインデックスに基づいて関連性の高いファイルを判断しています。これは多くの場合うまく機能しますが、Amazon Q Developer がどのファイルを選んだのかを知りたい場合もあります。そんなときに役立つのが、新しく追加されたコンテキストの透明性の機能です。 Amazon Q Developerは、追加された各ファイルをリストアップし、レスポンスに直接コンテキスト情報を含めるようになりました。コンテキストの透明化機能により、アシスタントが回答を作成するために使用したファイルを正確に確認できます。以下の例では、Q Developer がプロジェクト内の 4 つのファイルを使用したことがわかります。 コンテキストセクションを展開することで、Amazon Q Developer が前回の回答を生成する際に使用したファイルを簡単に確認できます。これにより、アシスタントの意思決定プロセスについて、より深く理解することができます。 明示的なコンテキスト 通常、Amazon Q Developer は最適なファイルを自動で選択し、コンテキストを補強してくれますが、より細かくコントロールしたい場合もあります。そんなときに便利なのが、新しく追加された明示的なコンテキスト機能です。この機能を使えば、自分でコンテキストに含めたいファイルやフォルダを選択できます。 チャットで @ を入力すると、Amazon Q Developer はファイルやフォルダを選択できるユーザーインターフェースを表示します。これにより、質問に答えるために必要だと自分で把握している情報を、アシスタントに正確に渡すことができます。 前の例に戻ってみましょう。Q Developer はスタック内のリソースを正しく特定しましたが、DynamoDB テーブルが定義されている lib/hitcounter.ts はコンテキストに含まれていませんでした。回答としては正しいものの、私は Q Developer に HitCounter のソースも参照してほしいと考えています。そこで、以下の例では lib フォルダを明示的にコンテキストに追加しています。理由は、その中にリソース定義があると私自身が知っているからです。 Q にファイルの選択を任せるのではなく、自分でコンテキストに追加したいファイルやフォルダを明示的に指定することができます。以下の画像では、Q が今回も正しく質問に答えている様子が確認できます。ただし、両方のファイルのソースコードをコンテキストに含めたことで、前の例では抜けていた追加情報も含めることができました。たとえば、 HitCounterHandler には実行環境やバージョンに関する情報が新たに含まれていることがわかります。 コンテキストを明示的に指定できることで、Amazon Q Developer が使用する情報を自分のニーズに合わせて調整し、より関連性が高く正確な回答を得ることができます。 プロンプトライブラリ コンテキストをコントロールする機能に加えて、Amazon Q Developer では共通のプロンプトのライブラリを構築できるようになりました。これらのプロンプトは Markdown ファイルとして ~/.aws/amazonq/prompts フォルダに保存され、複数の会話やプロジェクト間で簡単に再利用できます。 たとえば、プロジェクトの README ファイルに図を追加したいとします。Amazon Q Developer の /doc 機能ではインフラストラクチャ図を生成できますが、頻繁に使う図として ER 図（Entity-Relationship 図）やシーケンス図などもあるかもしれません。そうしたプロンプトをライブラリに保存しておくことで、毎回プロンプトを入力し直すことなく、簡単にコンテキストに追加できます。以下の例では、シーケンス図を作成してみます。 前の画像では、保存済みのプロンプト「Create Sequence Diagram」に加えて、再び lib フォルダをコンテキストに追加している様子が確認できます。このように、必要に応じて複数の修飾子を組み合わせて、追加のコンテキストやプロンプトを柔軟に指定することができます。「Create Sequence Diagram」という保存済みプロンプトの内容は以下のとおりです。 Create a sequence diagram using Mermaid that shows the sequence of calls between resources. Ignore supporting resources like IAM policies and security group rules. ※日本語訳 Mermaid を使って、リソース間の呼び出しの流れを示すシーケンス図を作成してください。 IAM ポリシーやセキュリティグループのルールなどの補助的なリソースは無視してください。 Amazon Q Developer はこのプロンプトと、 lib フォルダ内の 2 つのソースコードファイルをもとに、以下のようなシーケンス図を生成しました。 プロンプトライブラリを使うことで、時間を節約でき、一般的な成果物を生成するときのミスの可能性も減らせます。その結果、より複雑で創造的な開発作業に集中できるようになります。 プロジェクトルール 最後に紹介する機能は「プロジェクトルール」です。プロンプトライブラリと同様、これらのルールは Markdown ファイルとして保存されます。プロンプトライブラリがユーザープロファイルに紐づくのに対し、プロジェクトルールはプロジェクト内の .amazonq/rules フォルダに保存されます。そのため、ソースコードを共有するすべての開発者にルールが適用されます。 これらのルールにより、チーム全体でコーディング規約やベストプラクティスを徹底できるようになります。たとえば、Python のコードには必ず型ヒントを付ける、Java のコードには Javadoc コメントを記述する、といったルールを設定できます。ルールをプロジェクトに保存することで、開発者の経験にかかわらず、コードの一貫性を保つことができます。 これを説明するために、若手の開発者が「Add an S3 bucket to the stack（スタックに S3 バケットを追加して）」とだけ Q に依頼したケースを考えてみましょう。このプロンプトはシンプルすぎて、私たちのベストプラクティスが反映されていません。 あいまいなプロンプトにもかかわらず、Q Developer の回答には「rules ファイル」に保存されたベストプラクティスへの言及が含まれていることに気づくかもしれません。また、プロンプトに修飾子を付けていないにもかかわらず、Q が cdk.md をコンテキストに追加していることにも注目してください。これこそがプロジェクトルールの強力さです。開発者が手動で追加するのを忘れても、自動的にコンテキストを補足してくれるのです。 .amazonq/rules/cdk.md には、次のような内容が記載されています。さらに、コンテキストの透明性の機能によって、そのルールがコンテキストに含まれていることが明確に表示され、開発者は適用されたルールが何かわかるようになっています。 All S3 Buckets must have encryption enabled, enforce SSL, and block public access. All DynamoDB Tables must have encryption enabled. All SNS Topics must have encryption enabled and enforce SSL. All SQS Queues must enforce SSL. ※日本語訳: すべての S3 バケットには暗号化を有効にし、SSL を強制し、パブリックアクセスをブロックすること。 すべての DynamoDB テーブルには暗号化を有効にすること。 すべての SNS トピックには暗号化を有効にし、SSL を強制すること。 すべての SQS キューには SSL を強制すること。 プロジェクトルールを活用することで、開発チーム全体でベストプラクティスやコーディングの一貫性を維持でき、コードベースの品質と保守性の向上につながります。 まとめ Amazon Q Developer の新機能により、ソフトウェア開発のワークフローを簡素化するための強力なツールを提供します。ワークスペースコンテキスト、明示的なコンテキスト、プロンプトライブラリ、プロジェクトルールを活用することで、AI アシスタントに正確で役に立つ回答を導くための情報を提供できるだけでなく、チーム全体でのベストプラクティスと標準の徹底も可能になります。 これらの機能を使い始めるには、 Amazon Q Developer の使用開始ガイド をご覧ください。開発をより効率的に、より優れたものにするためのさまざまな機能をぜひ体験してみてください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本ブログは 2025 年 3 月 21 日に公開された Blog “ Optimize your Amazon QuickSight implementation: a guide to usage analytics and cost management ” を翻訳したものです。 組織全体で Amazon QuickSight の利用状況を正確に把握し、最適化することは、コストを無駄なく管理し、BI への投資効果を最大化するためにとても重要です。QuickSight の導入が進み、さまざまな役割のユーザーが利用するようになるにつれて、「誰がどのように使っているか」を明確に可視化することの重要性が一層高まっています。 一方で、多くのお客様から、「ユーザーの利用状況を把握するのが難しい」というお声を頂いております。例えば、「過去90日間で追加された リーダープロ ライセンスの数は？」「セッションの利用パターンはどうなっているのか？」といった内容です。 こうしたニーズに応えるべく、QuickSight の利用状況を簡単に把握し、QuickSight のライセンスの棚卸しや最適化の意思決定をよりデータドリブンに行えるようにするソリューションをご紹介します。 AWS CloudFormation テンプレートを使って、以下のソリューションを簡単に導入できます。 AWS Glue と QuickSight API を活用して、QuickSight ユーザー情報を自動で抽出 Amazon Athena テーブルを作成し、QuickSight アカウントのユーザーデータや、 コストと使用状況レポート（AWS CUR） に基づいた集約ビューの作成 事前構築された QuickSight ダッシュボードをセットアップし、次のようなインサイトを提供 リーダーの利用状況と、非アクティブユーザーの特定 セッションの消費パターン（リーダー・匿名ユーザーの両方） SPICE（超高速インメモリ計算エンジン）、アラート、ピクセルパーフェクトレポート、Amazon Q の利用状況 コスト最適化に向けたインサイト 少人数のチームを管理している場合でも、企業全体に展開している場合でも、この分析ソリューションを活用することで、QuickSight の導入状況を把握し、データに基づいたライセンスの棚卸しが可能になります。さらに、今後予定されている価格変更への備えにもなります。 ソリューションの概要 このソリューションは、QuickSight と他の AWS サービスを組み合わせて、分析用データを作成します。導入をシンプルにするために、必要なリソースをすべて自動で作成する CloudFormation テンプレートを用意しています。 AWS Glue ジョブ： qs-usage-users-info という Python シェルスクリプトが毎日実行されるようにスケジューリングされており、QuickSight API を呼び出して、QuickSight アイデンティティリージョン内のユーザー情報を取得します。 S3バケット：Glue ジョブが取得した結果は、 qs-usage-{AWS::AccountId}-{AWS::Region} という名前の新しい Amazon Simple Storage Service (Amazon S3)  バケットに保存されます。 Athena テーブル・ビュー：上記の S3 データをもとに、Athena データベース qs-usage-db にテーブルが作成され、さらに AWS アカウント内の コストと使用状況レポート (CUR) データをベースにビューが作成されます。 QuickSight ダッシュボード：Athena のテーブルと ビュー を元にしたデータセットを使って、QuickSight ダッシュボードがデプロイされます。このダッシュボードが実際のデータを取り込み、視覚的なインサイトを提供します。 上記のアーキテクチャ図は、主に次の3つのステップで構成されています。 ETL（抽出・変換・ロード）ジョブによる QuickSight ユーザー情報の収集 AWS Glue が毎日 ETL ジョブを実行し、QuickSight アカウントに登録されているユーザー情報を収集します。これにより、常に最新の情報が意思決定者の手元に届くようになります。 Athena 上に集計ビューを作成し、QuickSight の利用傾向を可視化 既存の コストと使用状況レポート (CUR) データを元に、Athena に集計ビューを構築します。これにより、すべてのプロダクトグループを横断して、QuickSight の利用状況を俯瞰的に把握できます。 データを SPICE に取り込み、QuickSight Usage Analytics ダッシュボードで利用状況を分析 集めたデータを SPICE にインポートすることで、高速な分析が可能になります。QuickSight の使用状況を視覚的に分析できるダッシュボードを使って、利用パターンやコスト最適化のためのインサイトを得られます。 前提条件 この手順を進める前に、以下の準備が整っていることを確認してください。 AWS IAM（Identity and Access Management） の権限 CloudFormation を使って AWS リソースを作成するために、必要な IAM 権限を持っていることを確認してください。 コストと使用状況レポート (CUR) の設定 AWS Data Exports を使って AWS CUR を有効化してください。 ※ エクスポートタイプについては、 レガシーCUR エクスポート 、 標準データエクスポート のどちらの CUR でも対応可能ですが、本投稿で提示している手順はレガシーCUR エクスポートを前提としています。標準データエクスポートを利用される場合は、後述する Athena ビュー作成 SQL を修正頂く必要がございます。 詳細なデータを取得するために、リソースIDの出力を有効化しておくことが重要です。 CUR の Glue テーブル化 CUR ファイルを Amazon Simple Storage Service (Amazon S3) にエクスポートするジョブが作成されます。S3 に保存されたファイルは、AWS Glue の クローラ などを使ってカタログ化し、 Glue Data Catalog 上のテーブルとして利用できる状態にしておく必要があります。このテーブルは、後述のステップ2で使われる重要なデータソースとなります。 以下の AWS サービスにアクセス可能であること AWS CloudFormation AWS Glue Amazon QuickSight Amazon S3 Amazon Athena 導入 提供されているテンプレートを使えば、このソリューションは 次の3つのステップ で簡単にセットアップおよびデプロイできます。 ステップ 1: S3 バケットと Glue ETL ジョブの作成 この CloudFormation テンプレートを使用する際には、QuickSight のアイデンティティリージョン（アカウントが属するリージョン）を正しく指定することが重要です。このステップを適切に行うことで、QuickSight アカウント内のユーザー情報を正確かつ網羅的に取得できるようになります。 ※アイデンティティリージョンは必須であり、省略することはできません。 このテンプレートによって作成されるリソースは以下の通りです。 IAMロール: qs-usage-glue-role-{AWS::AccountId}-{AWS::Region} QuickSight と Amazon S3 にアクセスするための権限を持つ、AWS Glue ジョブ用の IAM ロール AWS Glue ジョブの Python シェルスクリプト: qs-usage-users-info QuickSight API を使用してユーザー情報を取得するスクリプト AWS Glue トリガー: QuickSightUsersExtractDailyTrigger 上記の Glue ジョブを米国東部時間（ET）で毎朝6時に自動実行するスケジュール設定 ※ こちらはデプロイ完了後に日本時間 (JST) でのスケジュール設定に変更をお願いいたします。 S3 バケット: qs-usage-{AWS::AccountId}-{AWS::Region} QuickSight ユーザー情報の抽出結果を保存するための専用バケット 以下、 「Launch Stack」 をクリックし、画面の指示に従ってこれらのリソースを作成してください。 QuickSight のアイデンティティリージョンを選択してください。 このパラメータは必須であり、QuickSight アカウントに登録されているユーザー情報を取得するために必要です。 「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」 にチェックを入れ、「Next (次へ)」を選択してください。 スタックの作成が完了したら、AWS Glue コンソールに移動し、ナビゲーションペインから 「ETL Jobs (ETL ジョブ)」 → 「Visual ETL」 を選択します。 次に、 qs-usage-users-info ジョブを選択し、 「Run job」 をクリックしてください。これにより、次回のスケジュール実行を待たずに、データセットをすぐに生成できます。 ETL ジョブの実行が完了すると、ユーザー情報が抽出され、 qs-users-info.csv というファイルとして、 S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} に保存されます。 S3 コンソールに移動し、該当のバケット内にデータファイルが正しく作成されていることを確認してください。 複数の AWS アカウントで QuickSight を管理している場合でも、このソリューションを使えば、自動化された ETL プロセスによりユーザー管理をシンプルに行えます。 それぞれのリンク済みアカウントにこのテンプレートをデプロイすることで、すべての QuickSight ユーザーデータを中央のアカウントに集約することができます。 このようにデータを一元管理することで、CUR（コスト＆使用状況レポート）との連携による包括的な分析が可能になり、QuickSight ダッシュボードを通じて全社レベルでの使用状況を可視化できます。 結果として、組織全体の利用傾向を把握しやすくなり、最適化やモニタリングが格段に効率化されます。 ステップ2: Athena テーブルを作成する 2つ目の CloudFormation テンプレートは、Athena に次の2つのオブジェクトを作成します。 Athena テーブル: qs_users_info このテーブルには、QuickSight のアイデンティティリージョンに存在するすべてのユーザープロファイルと、それぞれのロールが含まれています。 Athena 保存済みクエリ: qs_usage_cur_vw_query このクエリは、アカウント内の AWS CUR テーブル上に作成され、QuickSight のさまざまな機能（アラート、ピクセルパーフェクトレポート、Amazon Q、セッション消費など）の使用傾向を分析するのに役立ちます。 このクエリは、次のステップで Athena のビューを作成する際に利用します。 以下は、アカウント内で確認できる保存済みクエリの例です。 CREATE OR REPLACE VIEW "AwsDataCatalog"."qs-usage-db"."qs_usage_cur_vw" AS SELECT bill_payer_account_id, line_item_usage_account_id, concat(DATE_FORMAT(line_item_usage_start_date, '%Y-%m'), '-01') AS month_line_item_usage_start_date, line_item_usage_type, CASE WHEN LOWER(line_item_usage_type) LIKE 'qs-user-enterprise%' THEN 'Users - Enterprise' WHEN LOWER(line_item_usage_type) LIKE 'qs-user-standard%' THEN 'Users - Standard' WHEN LOWER(line_item_usage_type) LIKE 'qs-reader%' THEN 'Reader Usage' WHEN LOWER(line_item_usage_type) LIKE '%spice' THEN 'SPICE' WHEN LOWER(line_item_usage_type) LIKE '%alerts%' THEN 'Alerts' WHEN LOWER(line_item_usage_type) LIKE '%-q%' THEN 'QuickSight Q' WHEN LOWER(line_item_usage_type) LIKE '%-report%' THEN 'Paginated Reporting' WHEN LOWER(line_item_usage_type) LIKE '%-reader-pro%' THEN 'Reader PRO' WHEN LOWER(line_item_usage_type) LIKE '%-author-pro%' THEN 'Author PRO' WHEN LOWER(line_item_usage_type) LIKE '%-reader-enterprise%' THEN 'Reader Usage' ELSE line_item_usage_type END AS qs_usage_type, line_item_line_item_description, line_item_line_item_type, product_group, pricing_unit, line_item_resource_id, product_usagetype, line_item_unblended_rate, line_item_blended_rate, line_item_operation, SUM(CAST(line_item_usage_amount AS DOUBLE)) AS sum_line_item_usage_amount, SUM(CAST(line_item_unblended_cost AS DECIMAL(16, 8))) AS sum_line_item_unblended_cost, SUM(CAST(line_item_blended_cost AS DECIMAL(16, 8))) AS line_item_blended_cost FROM "billing"."cur" -- This is replaced by ${CURSourceTable} with your CUR database.table name provided as Input to a parameter WHERE (CAST(year AS INTEGER) >=2024 ) AND product_product_name = 'Amazon QuickSight' AND line_item_line_item_type IN ('DiscountedUsage', 'Usage') GROUP BY bill_payer_account_id, line_item_usage_account_id, DATE_FORMAT(line_item_usage_start_date, '%Y-%m'), 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 ORDER BY month_line_item_usage_start_date ASC, sum_line_item_unblended_cost DESC ORDER BY month_line_item_usage_start_date ASC, sum_line_item_unblended_cost DESC 以下、 「Launch Stack」 をクリックし、画面の指示に従ってこれらのリソースを作成してください。 このスタックをデプロイするには、AWS CUR のデータベース名とテーブル名を、 データベース名.テーブル名 の形式で指定する必要があります（※アカウント内で表示されている名称に従って入力してください。） スタックのデプロイが正常に完了すると、 qs-usage-db という名前のデータベースが作成されます。 このデータベースには、QuickSight アカウント内のすべてのユーザー情報を含む qs_users_info テーブルが作成されており、ユーザーの一覧とそのロールを確認できるようになります。 スタックによって Athena の保存済みクエリが作成されたら、次にビューを作成します。 Athena コンソールに移動し、ナビゲーションペインから 「Query editor（クエリエディタを起動）」 を選択します。 「Saved queries（保存したクエリ）」 タブを開き、 qs_usage_cur_vw_query という名前のクエリを選択してください。 クエリエディタで 「Run（実行）」 をクリックして、ビューを作成します。 クエリの実行が完了すると、 qs_usage_cur_vw という名前のビューが Athena に作成されます。このビューには、QuickSight ダッシュボードでの分析に必要な AWS CUR データがすべて含まれており、詳細な利用状況の把握に役立ちます。 Athena へのアクセスを有効にし、QuickSight に対して S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} へのアクセス権限を付与するため、以下の手順を実施します。 QuickSight コンソールにアクセスし、画面右上に表示されているユーザー名をクリックします。 ドロップダウンメニューから 「Manage QuickSight (QuickSight を管理)」 を選択します。 左側のナビゲーションペインから 「Security & Permissions（セキュリティとアクセス許可）」 をクリックします。 「管理」 をクリックし、Amazon Athena のチェックボックスを有効にします。 同様に 「Amazon S3」 をクリックし、CURが格納されているバケットにチェックを入れます。 ステップ3: QuickSight データセットとダッシュボードをデプロイする 3つ目の CloudFormation スタックでは、QuickSight に以下 3つのデータセットを作成します。 qs_usage_cur_vw ：Athena のビューに対応するデータセット qs_users_info ：Athena のテーブルに対応するデータセット qs-usage-custom-inactive ：Athena のテーブルとビューを参照して、QuickSight アカウント内の非アクティブなユーザーを特定するためのデータセット このデータセットの作成には、以下のようなサンプルクエリが使用されています。 SELECT u.userarn,u.username,u.useremail,u.userrole,u.useridentitytype,u.usernamespace,CAST(COALESCE(a.last_login, DATE '2020-01-01') AS DATE) as last_login FROM "AwsDataCatalog"."qs-usage-db"."qs_users_info" u LEFT JOIN ( SELECT line_item_resource_id, MAX(date_parse(month_line_item_usage_start_date, '%Y-%m-%d')) as last_login FROM "AwsDataCatalog"."qs-usage-db"."qs_usage_cur_vw" WHERE ( product_group = 'Reader Usage' OR product_group = 'Reader Subscription' ) AND LOWER(line_item_resource_id) NOT LIKE '%anonymous%' GROUP BY line_item_resource_id ) a ON u.userarn = a.line_item_resource_id WHERE u.userrole = 'READER' そして、3つのデータセットをもとに、テンプレートが 「QuickSight Usage Analytics Dashboard」 を自動的に作成し、リーダーアカウントのアクティビティなどを可視化します。このダッシュボードを活用することで、QuickSight アカウント内で非アクティブな リーダーアカウントを特定し、ライセンスの最適化などに役立てることができます。 以下、 「Launch Stack」 をクリックして、QuickSight のデータセットとダッシュボードをデプロイしてください。 その際、QuickSight 管理者ユーザーの ARNを以下の形式で指定する必要があります。 arn:aws:quicksight:us-east-1:12345678910:user/default/admin/xyz ※上記の例にある AWS アカウントID（12345678910）、リージョン（us-east-1）、および ユーザー名（admin/xyz） はダミー（プレースホルダー）です。ご自身の環境に合わせた実際の値に置き換えて入力してください。 3つのスタックのデプロイがすべて正常に完了すると、SPICE データセットの更新スケジュールをお好みの頻度で設定できるようになります。また、作成されたダッシュボードを、組織内の適切なメンバーと共有することも可能です。これにより、常に最新の利用状況を基にした分析や意思決定が行えるようになります。 このダッシュボードには 5つのシートがあり、シームレスに画面を行き来できる構成になっています。各シートをクリックするだけで、簡単に別のビューへ移動できます。 以下の図に示されているダッシュボードビューでは、QuickSight アカウント全体の主要な KPI（重要業績評価指標） や利用状況の概要を把握できます。 以下の図に示されているダッシュボードビューでは、リーダーセッションの利用状況（キャパシティ使用量）に関する詳細や、すべてのリンク済みアカウントのリソース情報を確認することができます。 以下の図に示されているダッシュボードビューでは、アラート、レポート機能、SPICE、PROユーザーなどの各種機能の利用状況を、より詳細に確認できます。さらに、すべてのリンク済みアカウントにおける該当リソースの情報もあわせて表示されます。 以下の図に示されているダッシュボードビューでは、QuickSight アカウント内に存在するすべてのユーザー一覧が表示されます。 以下の図に示されているダッシュボードビューでは、すべてのリンク済みアカウントにおける、アクティブな登録済みリーダーユーザーの情報が表示されます。この情報をもとに、非アクティブなリーダーアカウントの一覧が自動的に抽出され、必要に応じてどのユーザーを削除すべきか判断する際の参考として活用できます。 クリーンアップ このソリューションで作成されたすべてのリソースを削除する手順について 1. ダッシュボードスタックの削除 QuickSight の各種リソースをデプロイした CloudFormation スタック（デフォルト名は qs-usage-dashboard-stack 、またはデプロイ時に指定したカスタム名）を削除します。これにより、以下が削除されます。 QuickSight ダッシュボード: QuickSight Usage Analytics Dashboard 3つのデータセット: qs-usage-custom-inactive 、 qs-usage-cur-vw 、 qs-users-info QuickSight のテーマ: qs-usage-theme QuickSight の Athena データソース接続: qs-usage 2. Athena オブジェクトのスタックの削除 Athena リソースを作成した CloudFormation スタック（デフォルト名は qs-usage-athena-stack またはカスタム名）を削除します。これにより、以下のリソースが削除されます。 保存済みクエリ: qs_usage_cur_vw_query テーブル: qs_users_info ビュー: qs_usage_cur_vw Athena データベース: qs-usage-db 3. AWS Glue ジョブと S3 バケットのスタックの削除 まず、S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} の中身が空であることを確認してください。その後、Glue ジョブなどの基盤インフラを作成した CloudFormation スタック（デフォルト名は qs-usage-glue-stack またはカスタム名）を削除します。これにより、以下が削除されます。 Glue ジョブ qs-usage-users-info Glue トリガー QuickSightUsersExtractDailyTrigger IAM ロール qs-usage-glue-role-{AWS::AccountId}-{AWS::Region} S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} ※このクリーンアップ作業は、既存の AWS CUR の設定や QuickSight サブスクリプションには影響しません。 まとめ 本投稿では、Amazon QuickSight の利用状況を可視化し、特にリーダーアカウントに関するコスト最適化方法をご紹介しました。 コストと使用状況レポート (CUR) のデータを活用し、データ収集のプロセスを自動化することで、以下が可能になります。 リーダーの利用状況を把握し、活用されていないアカウントを特定 SPICE、アラート、Amazon Q、ピクセルパーフェクトレポートなど、QuickSight 機能ごとの使用傾向を分析 提供されている CloudFormation テンプレートを使えば、容易に本ソリューションを環境にデプロイでき、QuickSight の利用状況を 一元的に可視化 できるようになります。BI の導入規模が拡大する中で、こうした自動化された使用状況分析ツールは、コスト効率を保つためにますます重要な存在となってきています。 ご質問やご意見があれば、ぜひコメントをお寄せください。 また、さらに情報交換や質問をしたい場合は、 QuickSight コミュニティ もぜひご活用ください。 本ブログは プロフェッショナルサービス本部の 西澤 が翻訳しました。

本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社 服部 純一氏、畑山 洋平氏、浅香 樹氏、株式会社みずほフィナンシャルグループ 島浦 紳吾氏、翁 恒氏によって寄稿いただきました。 はじめに 企業のデジタル化が進み、クラウド活用の拡大を含め多くの業種で IT 予算、投資意欲が高まっています。 「企業 IT 動向調査報告書2024」によると、2023年度の IT 予算 DI 値(注1)は2011年度以降で最高値となっています。 IT 予算の重点領域として「セキュリティ強化」は「業務プロセスの効率化」に次いで高くなっていること、2022年度から割合を伸ばしていることからも企業のセキュリティに対する意識は高まっていると考えられます。 (注1) Diffusion Index ： IT 予算を「増加する」割合から「減少する」割合を差し引いた値 パブリッククラウドは、いまやビジネスに欠かせない IT インフラとなっています。アマゾン ウェブ サービス (AWS) は、俊敏性が高く、従量課金制で最先端のサービスを利用可能なため、アイデアをすぐにビジネスとして実現できイノベーションを加速できます。一方で、利便性が高いため、利用者は自身の管理領域の設定ミスなどによる情報漏洩などのリスクがあります。 そのため、責任共有モデルを正しく理解し、セキュリティ統制と対策を行う必要があります。 本ブログでは、AWS サービス利用時のセキュリティリスク評価とその対策として予防的統制と発見的統制の手法について紹介したいと思います。 AWS サービス利用時のセキュリティリスク評価の必要性と評価手法 パブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定や権限管理の不備に起因する事例も存在しています。 AWS を活用するうえで、責任共有モデルを前提としたセキュリティ・リスクマネジメントは不可欠となります。 <みずほ>では、 AWS サービスを安心・安全に活用するためのプロセスとして、(1) サービスを知る（ AWS ドキュメントや AWS Black Belt Online Seminar からサービスを把握する）、(2) リスクを知る（機密性・完全性・可用性それぞれの観点で整理する）、(3) 対策を練る（AWS Identity and Access Management (IAM) による権限管理や VPC エンドポイントでの通信経路の特定等）、(4) 対策を施す（予防的統制・発見的統制）を実施しています。 AWS サービス利用時のセキュリティリスク評価にあたり「利用シナリオと接続経路」、「セキュリティクライテリア」、「IAM アクション評価」を作成しています。 「利用シナリオと接続経路」は AWS サービスの使われ方を想定し、それぞれの利用者や関連するサービス、外部システムとの通信経路と通信方向を図示したものです。 「セキュリティクライテリア」は主要なリスクシナリオをベースにクラウド固有のリスクについて、AWS で実施可能な対策を整理したものです。機密性、完全性、可用性を観点として、セキュリティリスクに関する7評価観点19対策分類を定め、評価対象の AWS サービスで利用可能な予防的統制と発見的統制の情報を整理しています。 「IAM アクション評価」では、AWS サービスの IAM アクションを洗い出し、IAM アクションごとにセキュリティリスクを評価し、予防的統制と発見的統制を整理しています。 セキュリティリスク評価事例： AWS Lambda AWS ユーザーの多くの方が利用する AWS Lambda を題材にセキュリティリスク評価の手法をご紹介したいと思います。 利用シナリオと接続経路 金融機関は個人情報や決済情報など、多くの機密データを扱っています。想定外のインターネット経由の接続経路（例：外部 AWS アカウントからの不正なリモートアクセス経路など）が存在すると、不正アクセスによる機密情報の漏洩などにより業務停止を引き起こし、結果として顧客への影響や事業運営全体に深刻なリスクをもたらす可能性があります。 本観点では、AWS サービスの通信経路を洗い出し、どのようなアクセスがあるかを明らかにすることで、リスクとなる箇所を明確にすることを目的としています。 ネットワーク構成やセキュリティ要件を考慮しながら、AWS サービスを利用する場面で具体的な指針を示しています。 AWS Lambda では、 ①Lambda 関数の管理 と ②Lambda 関数の実行 という2つの主要な観点に基づいて構成されています。 以下は、そのうちの ①Lambda 関数の管理 の例です。 シナリオ番号 通信元 通信先 通信の目的 通信経路 考慮事項 1-① AWS 管理ユーザー AWS Lambda サービス Lambda 関数の管理 インターネット または AWS Direct Connect 経由で VPC エンドポイント経由のアクセス。 Lambda は VPC エンドポイントに対応しており、インターネット( Public )・VPC 内どちらのアクセスにも対応 1-② AWS サービス AWS Lambda サービス Lambda 関数の管理 AWS CodeBuild などの 各種 AWS サービスから Lambda サービスエンドポイントにアクセス。 AWS サービスによって、VPC エンドポイント経由で Lambda API エンドポイントにアクセス可否は異なる (例: CodeBuild は設定によってはビルド内処理から VPC 内リソースにアクセス可能、など) 1-③ ユーザー VPC AWS Lambda サービス Lambda 関数の管理 ユーザー VPC から VPC エンドポイント経由で Lambda サービスエンドポイントにアクセス。 同上 このように、通信元 / 通信先 / 通信の目的 / 通信経路 をもとに整理し可視化することで、アクセスルートに応じた権限や各種設定の具体的な考慮点を明らかにしています。 セキュリティクライテリア 本観点では、AWS サービスを運用する際に懸念されるセキュリティリスクを洗い出し、それに対する対策を整理することで、セキュリティ要件を満たしたシステム設計・運用に繋げることを目的としています。 以下の7評価観点・19対策分類で整理し、「予防的統制」と「発見的統制」の両側面から、具体的な設計・運用レベルでの対策を確認できるような構成としています。 No 大分類 評価観点 対策 1 機密性 (1) ポリシー/設定による保護 リソースベースポリシーによる保護 2 アイデンティティベースポリシーによる保護 3 サービスコントロールポリシー ( SCP )による保護 4 その他機能による保護 5 (2) 暗号化による保護 主データの暗号化 6 ログの暗号化 7 通信の暗号化 8 その他リソースの暗号化 9 (3) 閉域網での隔離による保護 VPC 機能による保護 10 VPC エンドポイント の保護 11 (4) サービス間連携機能の対策可否 リソース共有への対策 12 リソースコピーへの対策 13 データ連携への対策 14 独⾃ NW 経路敷設への対策 15 完全性 (5) 操作ログ取得 AWS API の操作ログ取得の確認 16 AWS API 以外の操作ログ取得の確認 17 サービス及びリソース設定のトレーサビリティの確認 18 可用性 (6) データバックアップ ユーザデータのバックアップ取得の確認 19 (7) 耐障害性 リソース障害への対策機能の有無の確認 以下は、そのうちの No.4 その他機能による保護 の例です。 対策 確認の目的 サービス機能 予防的統制 発見的統制 その他機能による保護 単体でセキュリティリスクがあり、運用上使用しない設定や機能の不正利用をサービス独自の機能で禁止する。 AWS Signer および Lambda 側コード署名設定との協調による制限が可能 (※ ZIP パッケージにのみ利用可能, コンテナイメージは未サポート)属性ベースアクセス制御(ABAC)による Lambda 関数のアクセス制御が可能 Lambda での属性ベースのアクセスコントロールの使用 関数 URL を利用する場合、アイデンティティベースのポリシー、リソースベースのポリシー設定に加えて、IAM ベースの認証による制限が可能。また、異なるドメインから関数 URL が呼び出される場合は、CORS 設定による制御が可能。 コード署名設定により、確認された ZIP パッケージのコードに基づく Lambda 関数のみにデプロイを制限する。 役割の変更や追加が頻繁にある場合には、ABAC によるタグを使用して Lambda 関数へのアクセスを制御する。 関数 URL は、Lambda 関数単位でのアイデンティティベースのポリシー、リソースベースの設定に加えて、IAM ベースでの認証を設定する( IAM ベース認証設定により、呼び出し時の SignV4 の署名が必須となる)。 認証設定を行わない( AuthType が NONE )場合には、Lambda 関数にて全ての認証・セキュリティの実装を行う。 また、異なるドメインから関数 URL が呼び出される場合は、CORS 設定により、呼び出し元やメソッド種別を制限する。 <設定の変更を検知> AWS Config での Lambda 関数リソース変更、 AWS CloudTrail での関連リソース・ IAM に関する更新系 API 呼び出しを検知 <AWS Signer 利用時> AWS Signer の発行する CloudWatch メトリクスで署名違反での関数作成試行を検知 <関数URL利用時> CloudTrail での関数 URL に関する更新系API呼び出しを検知 チェックリストのように評価観点とそれに対する予防的統制と発見的統制による対策を明らかにしています。 IAM アクション評価 本観点では、その時点における AWS サービスの IAM アクションを洗い出し、それぞれの具体的なリスクと統制内容を明らかにすることで、実装に繋げることを目的としています。 IAM アクションごとに、以下の観点で想定リスクを洗い出し、それに対するリスク低減方法を確認できるような構成としています。 [A] 権限が不正に利⽤され、データ持ち出しや破壊されるリスク [B] データの保管場所や伝送経路が危殆化した際にデータの持ち出しや破壊されるリスク [C] IP-NW 経由でのデータ持ち出しや破壊されるリスク [D] クラウドサービスの機能が悪⽤され、データ持ち出しや破壊されるリスク [E] 不正な操作やアクセスが検出ないしは記録されないリスク [F] 障害時にデータが失われるリスク [G] 障害時に業務継続性が失われるリスク [H] 多額の請求が発生するリスク( Savings Plans の契約など) [I] その他のリスク 以下の画像は、 AWS Lambda の IAM アクション一部抜粋です。 例えば lambda:CreateEventSourceMapping と lambda:CreateFunction であれば以下のようにリスクと対策をまとめています。 lambda:CreateEventSourceMapping 想定されるリスク [H] 高頻度のイベント発生など大きくリソース使用量を増加させるようなイベントソースのマッピングが作成され、それを処理する Lambda 関数が実行された場合に、多額の請求が発生するリスクがある リスク低減方法の例 [H] アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する 参考 イベントソースの実行ロールを最小限の権限設定とするなど、イベントソース側の権限も適切に統制する lambda:CreateFunction 想定されるリスク [D] VPC アクセスを指定せずに Lambda 関数を作成した場合、インターネットへアウトバウンド通信する経路が Lambda 関数を経由して生成されるリスクがある 想定されるリスク [G] VPC アクセスを指定して Lambda 関数を作成した際に、複数の AZ で構成されるように複数のサブネットを指定しなかった場合、AZ (単一)障害時に、業務継続性が失われるリスクがある ※不適切あるいは悪意のあるコードを含む Lambda 関数が作成されるリスクがある。詳細は右記「参考」を参照 リスク低減方法の例 [D] ドキュメント の例のように VPC に接続された関数の作成のみを許可する AWS Config で Lambda 関数リソース、VPC リソースへの変更を検出、CloudTrail での関連API呼び出しを検知する VPC 設定により Lambda 関数のアウトバウンド通信を制限し適切に監視・制御する リスク低減方法の例 [G] VPC Lambda とする場合、複数のAZで構成されるように複数のサブネットを指定する サービスヘルスダッシュボードで、サービスの状態を確認する アプリケーションとしてのログ、CloudWatch メトリクスをモニタリングする 参考 不適切あるいは悪意のあるコードを含む Lambda 関数が作成され、その関数が実行された場合、以下のようなリスクが想定される 関数ハンドラにて、AWS リソースを使って、ユーザー所有データを破壊あるいは AWS 内外の不適切な場所に送信し持ち出す [A][B][C] Lambda 関数あるいは依存する Lambda レイヤー内のライブラリやコードにセキュリティ脆弱性を含むレイヤーバージョンが作成された場合、これを悪用されてデータの持ち出しや破壊されるリスクがある [D] 大きくリソース使用量を増加させ、多額の請求を発生させる[H] 関数ハンドラにて、外部サイトへの攻撃や犯罪行為などを行い、意図せず犯罪に巻き込まれ、法的責任を問われ、信用失墜や損害賠償請求などにより、ビジネスへの影響が生じる[I] <リスク低減方法の例> [共通] アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する CI/CD パイプラインを導入するなど、第三者が介入できないコード作成、デプロイ自動化と承認のプロセスを確立し、アプリケーションの適切な開発・運用管理を行う 関数作成の IAM ポリシーの条件として、特定の署名コード設定付き関数しか作成できないよう制限する（ 参考ドキュメント ） Inspector を利用して、ワークロードに作成・変更時(初回作成、更新、CVE 公開)があったときに自動的に再スキャンするよう設定する[D] このように、IAM アクションごとにリスクの有無を整理することで、具体的な実装方法を明らかにしています。 セキュリティリスク評価による効果 セキュリティリスクの洗い出しやその対策を整理することで、各サービス利用時のリスク評価が可能になります。リスクとなる点は予防的統制による制限、発見的統制による検知の仕組みを導入します。一方で、相対的にリスクが低く評価される点については、権限移譲による利便性を高めることができ、より安心・安全にサービスを利用することが可能になります。 <みずほ>ではサービスごとのリスク評価に際して、本取り組みの内容をベースとし、セキュリティ基準を踏まえた評価を盛り込むことでサービスの評価として活用しています。また、実機検証や AWS サポートを活用し、セキュリティリスク評価と実装の精度を高める取り組みを取り入れています。 <みずほ>ではサービス評価のフェーズでは、アーキテクトだけでなくリスク管理部門といった2線部門(注2)とも連携を取りながら進めています。また、サービス評価完了後はシステムを所管するユーザー部門が設計・構築において参照したいといった要望挙がるなど、それぞれ異なる視点やニーズを持っています。本取り組みの成果物は、全員が共通理解を持つためのドキュメントとしても活用しています。 (注2)リスク管理・コンプライアンス所管部署：1線が行う自律的な統制活動を監視（モニタリング）・測定・評価するとともに、リスク管理・コンプライアンスの統制に係る基本方針等を策定・推進する責任を有する。 取り組み： AWS サービスリスク評価ワーキンググループについて AWS サービス利用時のセキュリティリスク評価を行うワーキンググループとして、現在11社、9金融グループ共同で評価する取り組み（セキュリティリスク評価ワーキンググループ）を行っています。 これまでの活動実績として2020年7月の第1回目以降、継続的に開催しており、2025年2月末時点で88回のワーキンググループを開催し、45の AWS サービス・シリーズについてリスク評価を実施してきました。また、AWS サービス利用時のリスク評価以外に、参加企業間での事例共有をテーマとした情報交換会も定期的に実施しています。 ワーキンググループでは、セキュリティリスク評価対象サービスについて参加企業各社のユースケースを共有し、AWS で「利用シナリオと接続経路」と「セキュリティクライテリア」を作成した後、参加企業各社がレビューを行います。参加企業によるレビューにより成果物をブラッシュアップし、質疑応答によりサービス仕様の理解を深めています。 セキュリティリスク評価について取り組み始めた頃は、これら全てを<みずほ>自身で実施していたため、多大な工数・期間を要していました。それが本取り組みにより、セキュリティリスク評価におけるベース部分の体力削減ができると共に、網羅性の観点でも高めることでき、より効率的にサービス評価が可能となりました。 AWS サービスリスク評価ワーキンググループの活用 ワーキンググループは、金融機関各社が個別に行っていたAWSサービス利用時のリスク評価を共同で実施することで、作業負荷の軽減と評価の網羅性向上を図る取り組みです。 これからサービス利用時のセキュリティリスク評価を行う参加企業ではリファレンスとして、既にセキュリティリスク評価が済んでいる企業では、評価の観点や判断軸を客観的に捉えることが出来るとの声があります。 ワーキンググループでは事例共有の場を設けており、自動化ツールや標準化の仕組み、IAM 設定などの具体的ノウハウを共有する場を定期的に設けています。AWS CloudFormation や AWS Service Catalog 等の活用事例、クロスアカウント間でのデータ連携など、各社の実運用で培った知見が共有されることで、セキュリティ水準の向上にも繋がっています。 まとめ AWS を含むパブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定ミスなどによる情報漏洩などのリスクも存在するため、責任共有モデルを正しく理解しセキュリティ統制と対策を行う必要があります。 金融機関でのセキュリティリスク評価共同化ワーキンググループのような手法は、多数の AWS サービス評価を効率的に進め、網羅性を高める有効な取り組みとして機能しています。 また、セキュリティリスク評価ワーキンググループの活動にご興味がありましたら、AWS 担当営業経由でご連絡ください。 免責文言 本稿は情報提供のみを目的として作成されたものであり、取引の勧誘を目的としたものではありません。本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を保証するものではありません。本稿のご利用に際しては、ご自身の判断にてなされますようお願い申し上げます。また、本稿に記載された内容は予告なしに変更されることもあります。 執筆者情報 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部 クラウド統括チーム 服部 純一 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 畑山 洋平 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 浅香 樹 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 島浦 紳吾 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 翁 恒 参考情報 AWS Lambda 開発者ガイド AWS Lambda APIリファレンス