本稿は、2024年7月15日に公開された “ Protect against bots with AWS WAF Challenge and CAPTCHA actions ” を翻訳したものです。 ボットの脅威から保護するためには、TCP や HTTP ペイロードの署名のようなリクエストのネットワークレベルでの特性を超えて、クライアント環境の洞察が必要とされます。 AWS WAF は、CAPTCHA や Challenge アクションを利用して、モバイルデバイスまたはブラウザ上でクライアント側とインタラクションを行い、AWS WAF による許可の前にクライアント環境を理解します。Challenge はクライアント(ブラウザまたはモバイルデバイス)がサイレントに課題を解決することを要求します。CAPTCHA はユーザーのブラウザに人間が解く必要がある課題を提示します。 これらのアクションは、ネットワークからのリクエストで得られる以上にリクエスト元のクライアント環境の可視性を高めることで、Allow、Count や Block アクションを補完します。この可視性は正当なユーザーへのインパクトを最小限に抑えながら、ボットトラフィックを特定して、管理するために有用なメカニズムです。 この投稿では、Challenge や CAPTCHA アクションの動作とそれらを利用した特定のボットの脅威の緩和について説明してします。 Challenge や CAPTCHA アクションがボットを特定し管理するための動作 Challenge や CAPTCHA アクションはブラウザまたはモバイルデバイスとのインタラクションを伴います。このインタラクションは、3 つのステージで構成されます : クライアントがサイレントに課題を解く必要があるチャレンジ (Challenge) またはパズルを解く人間とのインタラクションを必要とするチャレンジ (CAPTCHA) クライアント環境を調査してフィンガープリントを生成するクライアント側のスクリプト AWS WAF が課題の解答を検証してクライアントセッションを一意に識別するトークンを生成するためにフィンガープリントを使用する。このトークンは、以降のリクエストに含まれるもので、CAPTCHA や Challenge アクションをパススルーできるかを検証するためのもの このインタラクションは 2 つの方法で処理されます : AWS WAF 統合 SDKs : アプリケーションを AWS WAF に統合することで、これらのステージがアプリケーションやユーザー体験にどのように適合するかを明示的に管理できます。これは、AWS が推奨するアプローチです。 インタースティシャルなインタラクション : AWS WAF はページロードの際に課題を渡すインタースティシャルを含むカスタムレスポンスを提供することでインタラクションのステージを完了します。 これらの 2 つのケースで Challenge や CAPTCHA アクションがユーザーやクライアントとどのようにインタラクションするかを説明します。 Challenge アクションがクライアントとどのようにインタラクションするか Challenge アクションはユーザーの対応なしにクライアント環境でサイレントチャレンジを実行し、ユーザー体験に明らかな影響を与えることを意図しません。Challenge はクライアントが計算量の高いタスク (proof of work) を完了することを要求します。このアプローチは、アプリケーションにエンゲージしようと試みるボットオペレーターに対してコストを増大させながら、ユーザー環境を評価するためのシームレスなメカニズムを正当なユーザーに提供することを意図しています。 統合 SDK なしで Challenge アクションを利用する (インタースティシャルなインタラクション) デフォルトで、Challenge アクションはサイレントにチャレンジを完了する JavaScript チャレンジペイロードを利用して HTML リクエスト (Accept: text/html) に応答します。その後、ユーザーは Challenge を要求する後続のルールを通じてリクエストを許可するトークンを利用して、自動的にオリジナルページにリダイレクトされます。図 1 にこのインタラクションのワークフローを示します。 図 1 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間のインタースティシャルな Challenge のシーケンスダイアグラム アプリケーション統合 SDK を用いた Challenge アクションを利用する もし、アプリケーション統合 SDK にインテグレーションされていない場合、Challenge アクションをトリガーする非 HTML リクエストは、アセットやフェッチリクエストを中断する HTTP 202 レスポンスを返します。そのため、リクエストがサブミットされる前にクライアントがチャレンジを完了して、クライアントがトークンを取得できるようにアプリケーション統合 SDK をインテグレーションすることを推奨します。図 2 のワークフローでこのインタラクションを説明します。 図 2 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における SDK 統合利用時の Challenge のシーケンスダイアグラム アプリケーション統合 SDK を利用したインテグレーションでは、AWS WAF Bot Control または AWS WAF Fraud Control などの少なくとも一つの Amazon マネージドルールを使用する必要があります。投稿済みの「 Use AWS WAF CAPTCHA to protect your application against common bot traffic 」や「 Prevent account creation fraud with AWS WAF Fraud Control – Account Creation Fraud Prevention 」を参照してください。2 つのタイプのアプリケーション統合 SDK を利用できます。 JavaScript SDK : この SDK は、ブラウザベースのアプリケーション、特に AWS WAF のルールにより API エンドポイントが一般的にボットの攻撃から保護されているシングルページアプリケーション (SPA) に最適です。それぞれのリクエストで生成され、利用できるトークンを確保するために JavaScript SDK をインテグレートする 3 つのパートがあります。 必須: HTML の head に JavaScript を埋め込みます。これにより、ページロード時にチャレンジが実行されます。 推奨: フェッチ呼び出しを アプリケーション統合 SDK のフェッチラッパー (AwsWafIntegration.fetch) を使うように更新します。これにより、リクエストを送信する前に必ずトークンを取得できます。別の方法として、 AwsWafIntegration.getToken() を使って AWS WAF トークンを取得 し、x-aws-waf-token ヘッダーを設定できます。 アプリケーションがドメイン間でリクエストを行う場合、 トークンドメイン を設定します (例えば、www.example.com から api.example.com への API リクエスト)。 Mobile SDK : この SDK は、Android と iOS の両方で利用できます。基本的なワークフローは、 AWS ドキュメント で説明されている JavaScript SDK と同様です。 参考 : Challenge アクションを利用した DDoS 脅威からアプリケーションを保護する ボットオペレーターは、数万のボットを使って同時に小さなリクエストを起動することで、アプリケーションを標的にすることができます。すべてのボットからの同時リクエストの総数はアプリケーションを圧倒する可能性がありますが、IP 当たりのリクエスト数が AWS WAF のレートリミットルールの閾値である 1 分間に 100 リクエストを下回ります( 2024 年 8 月 30 日の アップデート により、レートリミットの最低閾値を 10 リクエストに設定できるようになりました)。リクエストがアプリケーションに転送される前にチャレンジを完了する必要がある AWS WAF ルールを設定することで、これらの脅威の影響を最小限に抑えることができます。これにより、ボットオペレーターが proof of work を完了する必要があり、オペレーターのコストが増加します。ここでは、エンドポイント /account に対して、すべてのリクエストでチャレンジの完了が必要となる独自のAWS WAFルールを設定します: AWS WAF Console を開き、次のいずれかを実行する 新しい web ACL を作成するために、 Create web ACL を選択する 既存の web ACL を編集するために、ACL の名前を選択する Rules タブより、Add Rules のドロップダウンから Add my own rules and rule group を選択する Rule 定義にて ルール名を Name に入力する ルールタイプを Regular rule のままにする Statement 定義にて図 3 で示すように次の情報を入力する Inspect では URI path を選択する Match type では Exactly matches string を選択する String to match では /account を入力する Action 定義では Challenge を選択する 図 3 : Challenge アクションに関する AWS WAF コンソールの構成 web ACL にルールを追加するために、 Add rule を選択する web ACL でのルールの優先順位を設定して、 Save を選択する オプション: AWS WAF Bot Control または AWS WAF Fraud Control rule group を利用するなら、AWS WAF アプリケーション統合 SDK をアプリケーションにインテグレーションする AWS WAF コンソールに戻る Application Integration を選択する アプリケーション統合を有効にする Web ACLs に対して構成 web ACL がデプロイされたリージョンをドロップダウンボックスから選択する Web ACL Name を選択する JavaScript SDK 構成を拡張する アプリケーションにコードをコピーする 先の説明のようにアプリケーション内で SDK を設定する CAPTCHA アクションがクライアントとどのようにやりとりするか CAPTCHA アクションでは、リクエストが成功する前に人間がパズルを解く必要があります。このパズルは、ユーザーが人間であることを証明することが目的です。図 4 は、ユーザーが解く必要のある 2 種類のパズルを示します。 図 4 : AWS WAF CAPTCHA の課題 アプリケーション統合 SDK を利用せず CAPTCHA アクションを使用する アプリケーションに対して統合 SDK を利用せず CAPTCHA アクションを使用する場合、CAPTCHA アクションをトリガーとする HTML(Accept: text/html) へのリクエストは、CAPTCHA パズルを提示するページを返し、バックグラウンドでチャレンジを解決します。CAPTCHA を解決した後、AWS WAF がトークンを発行し、トークンの有効期限まで CAPTCHA アクションを含むルールを通過する後続のリクエストを許可します。トークンについては後で詳しく説明します。図 5 のワークフローは、ユーザー、ブラウザ、AWS WAFの相互作用を示します。 図 5 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間におけるインタースティシャルな CAPTCHA でのインタラクションのシーケンスダイアグラム CAPTCHA JavaScript API を用いた CAPTCHA アクションを利用する CAPTCHA JavaScript API は、CAPTCHA アクションで保護されたリソースにリクエストが送信される前にいつでも、フロントエンド Web アプリケーション内で CAPTCHA パズルを表示する機能を提供します。これにより、バックグラウンドでもチャレンジが完了します。text/html ではないアセット(画像、JavaScript) やフェッチリクエストが、フロントエンド Web アプリケーションとユーザー体験を中断する可能性のある HTTP 405 レスポンスコードを受け取るため、これが推奨されるアプローチでです。図 6 のワークフローは、AWS WAF トークンを生成するために必要なインタラクションを示しています。投稿済みの「 Use AWS WAF CAPTCHA to protect your application against common bot traffic 」でアプリケーションに CAPTCHA JavaScript API をインテグレーションするための手順や React で CAPTCHA JavaScript API をインテグレーションする コードサンプル について記載しています。AWS WAF CAPTCHA は、モバイルデバイスではサポートされていません。 図 6 : ユーザーやブラウザおよびリソースを保護する AWS WAF 間における CAPTCHA SDK でのインタラクションのシーケンスダイアグラム 参考 : IP 評価に基づいて人間が CAPTCHA を完了することを要求する IP 評価ルールは、ボットや他の脅威トラフィックに一般的に関連付けられている IP アドレスを特定し、ブロックすることに役立ちます。例えば、AWSManagedIPDDoSList ルールを使用することで、AWS 脅威インテリジェンスが DDoS アクティビティを特定して関連する IP トラフィックをブロックできます。もし、正規のユーザーがボットオペレーターが管理するネットワーク上の別のデバイスと同じ IP アドレスを共有している場合、問題になる可能性があります。代わりに、アプリケーションへのリクエストを送信する前に CAPTCHA を解決することを正規のユーザーに要求することで、このルールを通じて正規のユーザーを許可できます。 AWS WAF Console を開き、次のいずれかを実行する 新しい web ACL を作成するために、 Create web ACL を選択する 既存の web ACL を編集するために、ACL の名前を選択する Rules タブより、Add Rules のドロップダウンから Add managed rule groups を選択する web ACL に Amazon IP reputation list ルールを追加する。そのとき、ルールを編集するために Edit を選択する Amazon IP reputation list rules に対して以下を参照 図 7 で示すように、 AWSManagedIPDDoSList に CAPTCHA を選択する 図 7 : CAPTCH で上書きした Amazon IP reputation rule の設定 設定を保存するために、 Save を選択する web ACL に Amazon IP reputation list rules ルールグループを追加するために、 Add rules を選択する web ACL でのルールの優先順位を設定して、 Save を選択する オプション: CAPTCHA JavaScript SDK を利用してアプリケーションにインテグレートする トークンがどのように動作するか Challenge および CAPTCHA アクションの結果、AWS WAF はトークンを生成します。トークン自体は暗号化、改ざん防止がされており、aws-waf-token の cookie として実装されます。トークンはユーザーには意識されないものですが、クライアントセッションを識別するのに役立つ詳細情報を含んでいます。これらの詳細には以下のものが含まれます: タイムスタンプ : トークンが生成された時間。デフォルトでは、クライアントは 5 分間再チャレンジされません。ウェブACL のためのイミュニティ時間の設定については、 AWSのドキュメント に記載があります。 ブラウザのフィンガープリント : クライアントのブラウザ環境のデータポイントの集合体から生成されたハッシュ。これにはブラウザのプラグイン、JavaScript の環境、および他の特性が含まれます。 解決済みのパズルタイプ : Challenge または CAPTCHA (あるいはその両方)が完了したかどうか。 トークンドメイン : AWS WAF が受け入れるリクエストを送信しているドメイン。デフォルトでは、クライアントのホスト名に、たとえば、www.example.com などに基づいて設定され、またトークンクッキーに対して使用するようにセットされます。このクッキーとトークンは、リクエストごとに www.example.com へ送信されます。 このドキュメント にあるようにフロントエンドアプリケーションや WebACL でトークンドメインを更新することができます。これは、www.example.com で実行されるシングルページアプリケーション (SPA) や api.example.com で実行される API などがある場合に便利です。トークンドメインを .example.com に設定するとブラウザが example.com 配下のすべてのサブドメインでトークン/クッキーを送信します。トークンドメインの設定の詳細については、 ドキュメント をご覧ください。 ボットトラフィックの管理のために、Challenge、CAPTCHA およびトークンがどのように使用されるか これらのアクションと生成されたトークンには、ボットトラフィックの識別と管理に役立つ以下のような特徴があります: 完全なクライアントを要求 : Challenge アクションと CAPTCHA アクションはクライアント側のスクリプトを実行できるクライアントを必要とします。これにより、JavaScript を実行できないシンプルな HTTP リクエストベースのボットを抑制します。 ボットオペレーターのコストを上げる : Challenge と CAPTCHA パズルを解決するためには、ボットオペレーターがより高度なボットの構築と運用に投資する必要があります。これは、アプリケーションを使うボットにとってさらなる参入障壁となります。 クライアントを一意に識別 : 同一の IP アドレスを共有したり、IP アドレスを切り替えたりするクライアントも一意のトークンによって区別できるため、単一のホスト/ IP から複数のクライアントを簡単に模倣することができません。 クライアント環境のフィンガープリント : トークンで提供されるフィンガープリントは、ボットの自動化の兆候となるブラウザやモバイルデバイスの設定を識別するのに使えます。 結論 この投稿では、AWS WAF を用いた Challenge や CAPTCHA の動作や高度なボットの脅威を緩和するためのこれらの使い方について説明しました。 CAPTCHA and Challenge actions best practices のドキュメントでは、これらのアクションを最大限に活用するガイダンスが提供されています。 著者について David MacDonald David は、ニュージーランドのスタートアップ企業がセキュアでスケーラブルなソリューションを構築できるよう支援をするシニアソリューションアーキテクトです。彼のキャリアのほとんどは、様々な業界に対してサービスを提供する SaaS プロダクトの構築と運用に費やされています。 Jess Izen Jess Izen は、AWS WAF のシニアソフトウェア開発エンジニアとして、Bot Control や Fraud Control のようなプロダクトを構築しています。彼女は、パフォーマス重視で同時実行される Rust サービスや Kafka や Redis/Valky などの技術を含む分散システムの開発に取り組むことを好みます。時間があるときには、自転車に乗ったり、アマチュアのムエタイに出場したりしています。 LinkedIn で彼女と繋がることができます。 翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。

11 月 27 日、 Amazon FSx for Lustre での Elastic Fabric Adapter (EFA) と NVIDIA GPUDirect Storage (GDS) のサポート開始を発表しました。EFA は、高レベルのノード間通信を必要とするアプリケーションを大規模に実行できるようにする、Amazon EC2 インスタンス用のネットワークインターフェイスです。GDS は、ローカルストレージまたはリモートストレージと GPU メモリ間の直接データパスを作成するテクノロジーです。これらの機能強化により、EFA/GDS サポートを備えた Amazon FSx for Lustre では、以前の FSx for Lustre バージョンと比較して、クライアントあたりのスループットが最大 15 倍 (最大 1,500 Gbps) 向上しました。 FSx for Lustre を使用すると、深層学習トレーニング、創薬、財務モデリング、自動運転車開発など、最も高いパフォーマンスが要求されるアプリケーションを構築して実行できます。データセットが増え、新しいテクノロジーが誕生するにつれて、Amazon EC2 P5 、 Trn1 、 Hpc7a などのますます強力な GPU インスタンスや HPC インスタンスを採用できるようになります。これまで、FSx for Lustre ファイルシステムにアクセスする場合、従来の TCP ネットワークを使用すると、個々のクライアントインスタンスのスループットは 100 Gbps に制限されていました。この採用により、大規模なデータセットにアクセスする際に、最先端の EC2 インスタンスの増加するネットワーク帯域幅を最適に活用するために必要となるパフォーマンスを提供する、FSx for Lustre ファイルシステムの必要性が高まっています。 FSx for Lustre の EFA と GDS のサポートにより、アプリケーションで P5 GPU インスタンスと NVIDIA CUDA を使用した場合、クライアントインスタンスあたり最大 1,500 Gbps のスループット (以前のスループットの 15 倍) を実現できるようになりました。 この新機能によって、最も強力なコンピューティングインスタンスのネットワーク帯域幅を最大限に活用し、 機械学習 (ML) と HPC のワークロードを高速化できます。EFA は、オペレーティングシステムをバイパスし、 AWS Scalable Reliable Datagram (SRD) プロトコル を使用してデータ転送を最適化することで、パフォーマンスを向上させます。GDS は、CPU をバイパスして冗長なメモリコピーを排除し、ファイルシステムと GPU メモリ間の直接データ転送を可能にして、パフォーマンスをさらに向上させます。 これが実際にどのように機能するかを見てみましょう。 EFA 対応の Amazon FSx for Lustre ファイルシステムの作成 はじめに、 Amazon FSx コンソール で、 [ファイルシステムを作成] を選択してから、 [Amazon FSx for Lustre] を選択します。 ファイルシステムの名前を入力します。 [デプロイとストレージタイプ] セクションで、 [永続的、SSD] と新しい [EFA 対応] オプションを選択します。 [ストレージ単位あたりのスループット] セクションで [1,000 MB/s/TiB] を選択します。これらの設定では、 [ストレージ容量] に 4.8 TiB と入力します。これは、これらの設定でサポートされる最小容量です。 ネットワーキングには、 デフォルトの仮想プライベートクラウド (VPC) と EFA 対応のセキュリティグループ を使用します。他のすべてのオプションはデフォルト値のままにします。 すべてのオプションを確認して、ファイルシステムの作成に進みます。数分後、ファイルシステムは使用できる状態になります。 Amazon EC2 インスタンスからの EFA 対応の Amazon FSx for Lustre ファイルシステムのマウント Amazon EC2 コンソール で、 [インスタンスを起動] を選択し、インスタンスの名前を入力して、Ubuntu Amazon マシンイメージ (AMI) を選択します。 [インスタンスタイプ] では、 [trn1.32xlarge] を選択します。 [ネットワーク設定] では、デフォルト設定を編集し、FSx Lustre ファイルシステムで使用されているのと同じサブネットを選択します。 [ファイアウォール (セキュリティグループ)] では、FSx for Lustre ファイルシステムが使用する EFA 対応のセキュリティグループ、デフォルトのセキュリティグループ、Secure Shell (SSH) アクセスを提供するセキュリティグループの 3 つの既存のセキュリティグループを選択します。 [高度なネットワーク構成] では、 [インターフェイスタイプ] として [ENA と EFA] を選択します。この設定がないと、インスタンスは従来の TCP ネットワークを使用し、FSx for Lustre ファイルシステムとの接続のスループットは 100 Gbps に制限されます。 スループットを向上させるには、インスタンスタイプに応じて EFA ネットワークインターフェイスを追加できます。 インスタンスを起動し、インスタンスの準備が整ったら、 EC2 Instance Connect を使用して接続し、 「FSx for Lustre ユーザーガイド」の Lustre クライアントのインストール と EFA クライアントの設定 の手順に沿って操作します。 次に、 EC2 インスタンスから FSx for Lustre ファイルシステムをマウント する手順に沿って操作します。 マウントポイントとして使用するフォルダを作成します。 sudo mkdir -p /fsx FSx コンソールでファイルシステムを選択し、 DNS 名 と マウント名 を検索します。これらの値を使用して、ファイルシステムをマウントします。 sudo mount -t lustre -o relatime,flock file_system_dns_name@tcp:/mountname /fsx EFA をサポートし、Lustre バージョン 2.15 以降を使用しているクライアントインスタンスから EFA 対応ファイルシステムにアクセスすると、EFA が自動的に使用されます。 知っておくべきこと EFA と GDS のサポートは、persistent 2 が提供されているすべての AWS リージョン の新しい Amazon FSx for Lustre ファイルシステムで、追加費用なしで今すぐご利用いただけます。顧客が EFA をサポートするクライアントインスタンスから EFA 対応ファイルシステムにアクセスすると、FSx for Lustre は、追加の設定なしで自動的に EFA を使用します。EFA をサポートしている EC2 クライアントインスタンスのリストについては、「Amazon EC2 ユーザーガイド」の サポートされているインスタンスタイプ を参照してください。この ネットワーク仕様表 では、高速コンピューティングカテゴリーのインスタンスタイプのネットワーク帯域幅および EFA サポートについて説明しています。 Lustre ファイルシステムの FSx で EFA 対応インスタンスを使用するには、カーネル 6.8 以降を搭載した Ubuntu 22.04 で、Lustre 2.15 クライアントを使用する必要があります。 クライアントインスタンスとファイルシステムは、 Amazon Virtual Private Cloud (Amazon VPC) 接続 内の同じサブネットに配置されている必要があることに注意してください。 GDS は EFA 対応のファイルシステムで自動的にサポートされます。GDS を FSx for Lustre ファイルシステムで使用するには、クライアントインスタンスに NVIDIA Compute Unified Device Architecture (CUDA) パッケージ 、 オープンソースの NVIDIA ドライバー 、 NVIDIA GPUDirect Storage Driver がインストールされている必要があります。これらのパッケージは AWS 深層学習 AMI にあらかじめインストールされています。その後、CUDA 対応アプリケーションを使用して、ファイルシステムと GPU 間のデータ転送に GPUDirect Storage を使用できます。 デプロイを計画する際には、EFA 対応のファイルシステムは、EFA 対応でないファイルシステムよりも最小ストレージ容量の増加が大きいことに注意してください。例えば、1,000 MB/s/TiB スループット階層を選択した場合、EFA 対応ファイルシステムの最小ストレージ容量は 4.8 TiB ですが、EFA が有効になっていない Lustre ファイルシステムの FSx では 1.2 TB です。既存のワークロードの移行を検討している場合は、 AWS DataSync を使用して、既存のファイルシステムから EFA と GDS をサポートする新しいファイルシステムへデータを移動できます。 柔軟性を最大限に高めるため、FSx for Lustre は EFA ワークロードと非 EFA ワークロードの両方との互換性を維持しています。EFA 対応のファイルシステムにアクセスすると、EFA 以外のクライアントインスタンスからのトラフィックは、 Elastic Network Adapter (ENA) を使用して自動的に従来の TCP/IP ネットワーク経由で流れるため、追加の設定なしですべてのワークロードにシームレスにアクセスできます。 詳細なセットアップ手順やベストプラクティスなど、FSx for Lustre での EFA および GDS サポートの詳細については、 Amazon FSx for Lustre のドキュメント をご覧ください。今すぐ使用を開始して、クラウドの GPU インスタンスで利用可能な最速のストレージパフォーマンスをご体験ください。 – Danilo 原文は こちら です。

Amazon Elastic Block Store (Amazon EBS) のスナップショットを AWS リージョンやアカウント内または AWS リージョンやアカウント間でコピーするときに、希望する完了時間 (15 分〜48 時間) を指定できるようになりました。これは、重要なワークロードの時間ベースのコンプライアンス要件とビジネス要件を満たすのに役立ちます。例: テスト – テストデータ管理 (TDM) 計画の一環として、最新のデータをタイムリーに配布する。 開発 – 定期的かつ頻繁に、更新済みのスナップショットデータを開発者に提供する。 ディザスタリカバリ – 目標復旧時点 (RPO) を満たすために、重要なスナップショットがコピーされていることを確認する。 どのようなユースケースでも、この新機能によって、一貫性のある予測可能なコピーが提供されます。これは、標準コピーのパフォーマンスや信頼性には影響しません。それぞれの状況に適したオプションとタイミングを選択できます。 時間ベースのスナップショットコピーの作成 時間ベースのスナップショットコピーは、 AWS マネジメントコンソール 、CLI ( copy-snapshot )、または API ( CopySnapshot ) から作成できます。この記事の執筆中に、2 つの EBS ボリューム (100 GiB と 1 TiB) を作成し、それぞれにファイルを格納して、スナップショットを作成しました。 時間ベースのスナップショットを作成するには、通常どおりソースを選択して、 [アクション] メニューから [スナップショットをコピー] を選択します。コピーの説明を入力し、送信先として us-east-1 AWS リージョンを選択して、 [時間ベースのコピーを有効にする] を選択し、(これは時間が重視されるスナップショットであるため) 15 分という 完了期間 を入力します。 [スナップショットをコピー] をクリックすると、送信先のリージョンで作成中の他のアクティブなコピーによって消費されるスループットが原因で、アカウントのスループットクォータをまだ超えていない場合にのみ、リクエストが受け入れられます (コピーは 保留中 になります)。アカウントレベルのスループットクォータを既に超えている場合は、コンソールにエラーが表示されます。 [コピー時間計算ツールを起動] をクリックすると、スナップショットで達成可能な最小コピー時間をより正確に把握できます。計算ツールを開き、アカウントのスループット制限を入力して、評価期間を選択します。 その後、計算ツールは、以前のスナップショットコピーの過程で収集された履歴データを使用して、達成可能な最小完了時間を提示します。この例では、過去 24 時間に 1,800,000 MiB をコピーしました。時間ベースのコピーがあり、現在のアカウントのスループットクォータが 2,000 MiB/秒の場合、これだけの量のデータを 15 分でコピーできます。 コピーの進行中は、コンソールを使用するか、 DescribeSnapshots を呼び出して結果の 進行状況 フィールドを調べることで、進行状況をモニタリングできます。次の Amazon EventBridge イベントを使用してアクションを実行することもできます (コピー操作が複数リージョンにまたがる場合、イベントは送信先リージョンに送信されます)。 CopySnapshot – コピー操作が完了した後に送信されます。 CopyMissedCompletionDuration – 期限が過ぎてもコピーがまだ保留中の場合に送信されます。 知っておくべきこと これでほぼすべてです! 時間ベースのスナップショットコピーについて知っておくべきことは次のとおりです。 CloudWatch メトリクス – SnapshotCopyBytesTransfer メトリクスは、送信先リージョンで出力され、ソースリージョンとターゲットリージョンの間で転送されたデータ量をバイト単位で反映します。 期間 – 所要時間は 15 分から 48 時間までで、15 分単位で指定できます。コピーごとに指定できます。 同時実行 – スナップショットをコピーしているときに、同じスナップショットのコピーを同じ送信先に 2 回目に開始した場合、2 つ目のコピーの保存期間は、最初のコピーが完了した時点で開始されます。 スループット – ソースと送信先の各ペアには、アカウントごとにデフォルトで 2,000 MiB/秒の制限があります。RPO を満たすためにスループットを増やす必要がある場合は、 AWS サポートセンター で増加をリクエストできます。スナップショットあたりの最大スループットは 500 MiB/秒で、これ以上増やすことはできません。 料金 – 料金情報の詳細については、 Amazon EBS の料金 ページを参照してください。 リージョン – 時間ベースのスナップショットコピーは、すべての AWS リージョンで利用できます。 – Jeff ; 原文は こちら です。

本記事は、2024/11/06 に公開された Reduce your compute costs for stream processing applications with Kinesis Client Library 3.0 の翻訳記事です。翻訳は Solutions Architect の Lee Rui が担当しました。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータを容易にキャプチャ、格納できるサーバレスのデータストリーミングサービスです。Kinesis Data Streams は、すぐに利用可能な多くの統合を使用してストリームに送信されたデータを処理する柔軟性を提供するだけではありません。コンピューティングフリートにデプロイ可能な、カスタムストリーム処理アプリケーションを構築する機能も提供しています。 カスタムストリーム処理アプリケーションを構築する際、開発者は通常、リアルタイムで高スループットデータを処理するために必要な分散コンピューティングの管理に課題に直面します。この課題に対処するのが Kinesis Client Library (KCL) です。多くの AWS 顧客が、KCL を活用して分散システムの複雑さを気にすることなく、Kinesis Data Streams でカスタムストリーム処理アプリケーションを運用しています。KCL は Kinesis Data Streams API を使用してストリームからデータを読み取り、複数のワーカー間でのストリーム処理のロードバランシング、フェイルオーバーの管理、処理済みレコードのチェックポインティングなどの複雑な処理の実装を肩代わりしてくれます。KCL はこれらの複雑な処理を開発者の代わりにハンドリングすることで、開発者がストリーミングデータ処理のコアビジネスロジックの実装に集中できるようになります。 アプリケーションが処理する時間あたりのデータ量が増加するにつれて、顧客はストリーム処理アプリケーションの計算コストを削減したいと考えるようになります。以前のバージョンの KCL と比較し、最大 33% のストリーム処理コストを削減することが可能な、Kinesis Client Library 3.0 のリリースを紹介できることを喜ばしく思います。KCL 3.0 は、新しいロードバランシングアルゴリズムを採用しています。このアルゴリズムは、ワーカーのリソース利用状況を継続的に監視し、処理を均等に再配布することで、同じデータをより少ない計算リソースで処理できるようにします。 この投稿では、サンプルワークロードをベースにストリーム処理におけるロードバランシングの課題について説明し、ワーカー間での不均一なロード分散がどのように処理コストを増加させるかを示します。次に、KCL 3.0 がこの課題にどのように対処して計算コストを削減するかを示しつつ、KCL 2.x から 3.0 へ容易にアップグレードできる手順を説明します。さらに、KCL 3.0 が提供する追加の利点についても説明します。これには、 AWS SDK for Java 2.x の使用と、AWS SDK for Java v1.x への依存の解消が含まれます。最後に、ストリーム処理アプリケーションを KCL 3.0 に移行する際のチェックリストも共有します。 カスタムストリーム処理アプリケーションの運用におけるロードバランシングの課題 リアルタイムのデータストリームを処理するお客様は、通常、高いスループットを並列処理するために、複数の計算リソースを利用します。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) などです。多くの場合、データストリームには、同じワーカーによって処理される必要があるレコードが含まれています。例えば、あるトラック会社が、数千台の車両から公開されるリアルタイムの位置座標を含むストリーミングデータを処理するために、それぞれ 1 つのワーカーを実行する複数の EC2 インスタンスを使用する場合があるとします。車両の経路を正確に追跡するには、各トラックの位置情報は同じワーカーによって処理される必要があります。このようなユースケースでは、お客様はデータストリームに公開される各レコードに対して、車両 ID をパーティションキーとして指定します。順序どおりに処理するために、Kinesis Data Streams は同じパーティションキーに属するデータレコードを単一のシャード (Kinesis Data Streams の基本的なスループット単位) に書き込みます。 ただし、ストリームのデータはパーティションキーに関連するトラフィックの変動により、シャード間で不均等に分散することがよくあります。たとえば、稼働中の車両は位置更新を頻繁に送信しますが、待機中の車両は更新頻度が低いといったことが考えられます。以前の KCL バージョンでは、ストリーム処理アプリケーションで各ワーカーが同数のシャードを並列処理していました。その結果、データの多いシャードを処理するワーカーはデータ処理の限界に達する一方で、データの少ないシャードを処理するワーカーは十分に活用されていませんでした。このワークロードの不均衡は、リソース活用とストリーム処理の効率化を目指すお客様にとって課題となっていました。 トラフィックがストリーム内のシャードで不均一な場合のサンプルワークロードを例として、KCL 2.6 でコンピューティングリソースの利用が不均一になる理由と、それがコストの増加につながる理由を一緒に見ていきましょう。 サンプルのワークロードでは、プロデューサーアプリケーションが 4 つのシャードに 2.5MBps のデータを発行しています。ただし、パーティションキーに関連するトラフィックパターンに基づいて、2 つのシャードが 1MBps ずつ、他の 2 つのシャードが 0.25MBps ずつ受け取っています。例のトラック運送会社であれば、2 つのシャードは稼働中の車両から、残りの 2 つのシャードは待機中の車両からデータを保存していると考えられます。このサンプルのワークロードでは、3 台の EC2 インスタンス (それぞれ 1 つのワーカーを実行) を使用して、KCL 2.6 でこのデータを処理しました。 最初は、3 つのワーカーに負荷が分散され、CPU 使用率は 50%、50%、25% で平均で 42% でした (次の図の 12:18 – 12:29 の時間枠を参照)。EC2 フリートが十分に活用されていないため、コスト効率を高めるために 1 つの EC2 インスタンス (ワーカー) をフリートから削除し、2 つのワーカーで運用してみました。しかし、ワーカーを削除すると、1 つの EC2 インスタンスの CPU 使用率がほぼ 100% に増加してしまいました。 これは、KCL 2.6 以前のバージョンでは、スループットやワーカーの CPU 使用率に関係なく、各ワーカーが同じ数のシャードを処理するように負荷を分散するためです。この場合、1 つのワーカーが 2 つの高スループットシャードを処理し、CPU 使用率が 100% に達し、別のワーカーが 2 つの低スループットシャードを処理し、CPU 使用率が 25% にとどまっていました。 一部のワーカーが過剰に利用され処理が遅延する可能性があるため、この CPU 使用率の不均衡によりワーカーコンピューティングフリートをスケールダウンできません。全体としてはフリートが十分に活用されていませんが、負荷の偏りがフリートのスケールダウンを妨げています。これにより、ストリーム処理アプリケーションの計算リソース費用が増えています。 次に、KCL 3.0 がこれらのロードバランシング課題にどのように対処しているかを見ていきたいと思います。 KCL 3.0 によるロードバランシングの改善 KCL 3.0 では、KCL ワーカーの CPU 使用率を監視し、ストリーム処理の負荷を再分散する新しいロードバランシングアルゴリズムが導入されました。新しいロードバランシングアルゴリズムでは、ワーカーがデータの処理限界に近いことや、ワーカー間の CPU 使用率の分散が大きいことを検知した場合、過剰に使用されているワーカーから使用率の低いワーカーへ負荷を再分散します。これにより、すべてのワーカー間でストリーム処理の負荷が均等化されます。その結果、ワーカー間の CPU 使用率の不均衡による過剰なキャパシティのプロビジョニングを回避でき、コンピューティングキャパシティを適切にサイジングすることで、コストを節約できます。 次の図は、KCL 2.6 と同じシミュレーション設定で KCL 3.0 の結果を示しています。 3 つのワーカーがある場合、KCL 3.0 は当初 KCL 2.6 と同様に負荷を分配し、平均 CPU 使用率は 42% でした (20:35 – 20:55 の時間枠)。しかし、1 つのワーカーを削除すると (赤い垂直点線で示されています)、KCL 3.0 はシャードの数だけでなく、シャードのスループット変動性も考慮して、1 つのワーカーから他の 2 つのワーカーに負荷を再配分しました。その結果、2 つのワーカーの CPU 使用率は約 65% となり、パフォーマンスリスクなしで計算リソースを安全にスケールダウンできました。 このシナリオでは、コンピューティングフリートのサイズを 3 つのワーカーから 2 つのワーカーに削減することができ、KCL 2.6 に比べて 33% のコンピューティングコストの削減を実現しました。 これはあくまでサンプルワークロードですが、1 秒あたり数ギガバイトのデータをストリーミングし、それを数百の EC2 インスタンスで処理する場合の潜在的なコスト節約効果はより高いものになるでしょう。 同じコスト削減の恩恵を、 Amazon Elastic Container Service (Amazon ECS)、 Amazon Elastic Kubernetes Service (Amazon EKS)、 AWS Fargate 、または自身で管理する Kubernetes クラスターなどのコンテナ化された環境にデプロイされた KCL 3.0 アプリケーションでも実現できます。 その他の KCL 3.0 の利点 ストリーム処理コストの削減に加えて、KCL 3.0 にはいくつかの利点があります: Amazon DynamoDB の読み取り容量ユニット (RCU) の削減 – KCL 3.0 は、メタデータを格納する DynamoDB テーブルに対する読み取り操作を最適化により、KCL に関連する Amazon DynamoDB のコストを削減します。KCL は、シャードとワーカーの割り当てやチェックポイントなどのメタデータを DynamoDB に格納しています。 ワーカー間でのシャードの円滑な引き継ぎ – KCL 3.0 は、リバランシングやデプロイ時に、ある 1 つのワーカーから別のワーカーにシャードの処理が引き継がれる際のデータの再処理を最小限に抑えます。現在のワーカーが処理済みのレコードのチェックポイントを完了し、新しいワーカーが前のワーカーの最新のチェックポイントから作業を引き継ぐことができます。 AWS SDK for Java 1.x への依存関係の除去 – KCL 3.0 は、AWS SDK for Java 1.x への依存関係を完全に除去し、AWS の最新の SDK バージョンの使用を推奨しています。この変更により、KCL アプリケーションのパフォーマンス、セキュリティ、保守性が向上します。AWS SDK for Java 2.x の利点の詳細については、 AWS SDK for Java 2.x の機能を使用する を参照してください。 KCL 3.0 への移行 現在 KCL 2.x バージョンを使用している場合、アプリケーションコードを変更する必要はありません! 次の手順で KCL 3.0 に移行できます。 Maven (またはビルド環境) の依存関係を KCL 3.0 に更新してください。 clientVersionConfig を CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X に設定してください。 コードをビルドしてデプロイしてください。 すべての KCL ワーカーが更新されると、KCL 3.0 は自動的に新しいロードバランシングアルゴリズムを実行し、ワーカーのリソースを平準化します。詳細な移行手順については、 以前の KCL バージョンからの移行 をご覧ください。 KCL 3.0 を使用する際の主なチェックリスト ストリーム処理アプリケーションで Kinesis Client Library (KCL) 3.0 を使用することを決めた場合、次の点を確認することをお勧めします: KCL 3.0 に必要な適切な権限を追加したことを確認してください。KCL 3.0 は、DynamoDB で 2 つの新しいメタデータテーブル (worker metrics table, coordinator state table) とリーステーブルのグローバルセカンダリインデックスを作成および管理します。追加する必要がある詳細な権限設定については、 KCL コンシューマーアプリケーションに必要な IAM 権限 を参照してください。 KCL 3.0 で導入された新しいロードバランシングアルゴリズムは、ワーカー間の CPU 使用率を均等にすることを目指しており、ワーカーごとのリース数を均等にすることを目指すわけではありません。 maxLeasesForWorker パラメーターを低く設定すると、KCL のワークロードバランシング効果が制限される可能性があります。 maxLeasesForWorker パラメーターを使用する場合は、最適なロード分散のために、その値を増やすことを検討してください。 KCL アプリケーションで自動スケーリングを使用している場合、KCL 3.0 にアップグレードした後はスケーリングポリシーを見直すことが重要です。具体的には、平均 CPU 使用率をスケーリングのしきい値として使用している場合、この値を再評価する必要があります。ロードバランシングの不均衡により、一部のワーカーが高負荷になることを防ぐために、必要以上に高いしきい値を設定していた場合、この値を調整できるかもしれません。KCL 3.0 では、ロードバランシングが改善されているため、ワーカー間のワークロードがより均等に分散されます。KCL 3.0 を展開した後、ワーカーの CPU 使用率を監視し、パフォーマンスを維持しながら、リソース使用量とコストを最適化するためにスケーリングのしきい値を下げられるかどうかを確認してください。この手順により、KCL 3.0 の強化されたロードバランシング機能を最大限に活用できるようになります。 リースを適切に他のワーカーに引き継ぐために、 RecordProcessor クラスの shutdownRequested() メソッド内にチェックポインティングロジックを実装していることを確認してください。詳細については、 KCL 2.x から KCL 3.x への移行 のステップ 4 を参照してください。 まとめ KCL 3.0 のリリースでは、KCL アプリケーションのコスト効率とパフォーマンスを最適化できる大幅な機能強化が導入されました。新しいロードバランシングアルゴリズムにより、ワーカーインスタンス間の CPU 使用率がより均等になるため、適切なサイズのストリーム処理システムを構築し、コストを最適化できる可能性があります。チェックリストを確認しつつ、KCL 3.0 の機能を最大限に活用し、Kinesis Data Streams で効率的で信頼性の高いコスト最適化されたストリーム処理アプリケーションを構築しましょう。 著者について Minu Hong は、AWS の Amazon Kinesis Data Streams のシニアプロダクトマネージャーです。ストリーミングデータに関する顧客の課題を理解し、最適なソリューションを開発することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。 Pratik Patel は、シニアテクニカルアカウントマネージャーであり、ストリーミング分析の専門家です。AWS 顧客と協力し、ベストプラクティスを使用してソリューションを計画および構築するための継続的なサポートとテクニカルガイダンスを提供し、顧客の AWS 環境を運用上健全に保つのを積極的に支援しています。 Priyanka Chaudhary はシニアソリューションアーキテクトでデータ分析の専門家です。顧客の信頼できるアドバイザーとして、ウェルアーキテクトされた革新的な業界ソリューションを構築するための技術的なガイダンスとサポートを提供しています。

このブログは 2024 年 9 月 6 日に Chandan Murthy、Tilman Schroeder と Yue Ning によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 製造業では製品品質の向上、効果的なコラボレーション、開発コストの削減、市場投入までの時間短縮といった理由から、製品ライフサイクル管理（PLM）ソフトウェアを活用しています。AWS における PLM ソリューションは、企業が可用性とコンプライアンス要件を満たすと同時に、PLM のパフォーマンスの向上、コスト削減、データのサイロ化解消の実現に役立ちます。 Amazon FSx for NetApp ONTAP ストレージサービスを利用した AWS における PLM ソリューション は、高性能でスケーラブルなストレージと PLM ソフトウェアの堅牢なデータ管理機能の組み合わせにより、コラボレーションの強化、開発サイクルの加速、コスト削減を実現します。この戦略的な統合により、エンジニアリングチームはデータの完全性、セキュリティ、可用性を確保しながら、全体的な運用効率を最適化し、より効果的にイノベーションを推進することができます。 製品ライフサイクル管理（PLM） 製品ライフサイクル管理（PLM）ツールは設計、エンジニアリング、製造、サプライチェーン、変更管理プロセス全体におけるコラボレーション、イノベーション、効率性の向上を促進することで、初期コンセプトから廃棄に至るまで、製品のライフサイクル全体を管理することを可能にしています。産業および製造業の企業は Siemens Teamcenter などの PLM ソリューションを AWS に移行することでモダナイズし、コンプライアンス要件を満たしながらグローバルに分散したチームをサポートしつつ、IT コストの削減、パフォーマンスの向上、拡張性とセキュリティの向上というメリットを得ることができます。 Amazon FSx for NetApp ONTAP NetApp はエンタープライズ環境におけるミッションクリティカルなアプリケーションのサポートに長年高い評価を得ており、信頼性と拡張性に優れたストレージソリューションを 30 年以上にわたって提供してきた実績があります。Amazon FSx for NetApp ONTAP は NetApp の ONTAP オペレーティングシステムが持つ堅牢性と高度なデータ管理機能をクラウドで実現し、PLM システムの性能と耐障害性を高めます。 Forrester 社の調査 によると、Amazon FSx for NetApp ONTAP を利用することで運用効率が最大 45% 向上し、NetApp の業界をリードする SnapMirror などのデータレプリケーション機能によって移行に要する時間が最大 40% 短縮されたと報告されています。こうした恩恵は、重要なデータやアプリケーションへの継続的かつ中断のないアクセスが求められる PLM 環境では特に重要です。Amazon FSx for NetApp ONTAP を活用することで PLM システムの信頼性とパフォーマンスが向上するだけでなく、製品のイノベーションと開発を推進する複雑でデータ集約的なプロセスをサポートし、最終的に製品の市場投入を加速、運用コストを削減し、グローバル市場における競争力を維持することができます。 製品設計とエンジニアリングにおけるコラボレーションとデータの完全性 製品の設計やエンジニアリングの段階ではスピード、コラボレーション、データの完全性が不可欠です。Amazon FSx for NetApp ONTAP は CAD、CAE、PLM アプリケーションの集中的なデータ処理に必要な高性能でスケーラブルなストレージソリューションを提供します。このストレージサービスを利用することで、エンジニアリングチームはリアルタイムでコラボレーションを行い、地理的な制約を超えてシームレスに設計ファイルにアクセスし、共有することができます。これにより設計の反復サイクルが短縮され、生産性が向上します。また、堅牢なデータ保護と災害復旧機能により、重要な設計データの可用性とセキュリティが常に確保されます。 製品のライフサイクル全体を通じて、コラボレーションと統合は非常に重要です。設計・エンジニアリングチームを超えて、さまざまな場所やシステムにまたがる社内のステークホルダーや外部パートナーも巻き込む必要があります。Amazon FSx for NetApp ONTAP は低レイテンシでコスト効率の高いデータアクセスを提供することで、PLM、ERP（Enterprise Resource Planning）、MES（Manufacturing Execution Systems）などのシステムとの容易な統合を可能にし、透明性を高め、生産性を向上させます。さらに柔軟なストレージアーキテクチャと高性能なファイルシステムは、 PLM システムの多様なデータタイプと I/O パターンに対応し、CAD/CAE/CAM ファイルや仕様書から部品表、製造工程計画など、製品のライフサイクル全体にわたる多様なデータのニーズに最適なパフォーマンスを提供します。 Well-Architected PLM Solution on AWS この ホワイトペーパー （エンタープライズ環境における Amazon FSx for NetApp ONTAP を使用した Siemens Teamcenter の導入）では、クラウドで PLM ワークロードを設計および実行するための主要な概念、設計原則、アーキテクチャのベストプラクティスについて説明しています。一般的に、重複排除、圧縮、自動データ階層化などの NetApp ONTAP の機能を有効にすることで、ストレージコストを最適化し、運用のオーバーヘッドが削減されます。NetApp ONTAP の高性能でスケーラブルなストレージにより、PLM アプリケーションの速度と応答性を向上させ、冗長性とディザスタリカバリによってデータの完全性と可用性が確保されます。暗号化、アクセス制御、監査、ロギングなどの重要なセキュリティ機能により、大切な PLM データの機密性、完全性、可用性を保護する安全な基盤を確立します。さらに、AWS クラウドの持続可能なインフラストラクチャを活用することができます。AWS クラウドの規模による恩恵として、一般的なオンプレミスのデータセンターよりも高いリソース利用率とエネルギー効率を達成することができ、ESG（Environmental Social and Governance）目標の達成に貢献します。 自動車業界のお客様事例 最近、PLM システムの近代化と最適化の必要性に直面していた大手自動車技術サプライヤーは、Siemens Teamcenter プラットフォームをオンプレミス環境から AWS に移行しました。この決断の背景には、クラウドの拡張性を活用し、業務効率を高め、製品の市場投入までの時間を短縮したいという要望がありました。同社は当初、他のストレージソリューションを検討しましたが、業務に不可欠なマルチプロトコルのサポートと効率的なクローン作成機能が不足していることがわかりました。マルチプロトコルのサポートや FlexClone テクノロジーなどの高度な機能により、Amazon FSx for NetApp ONTAP が最適な選択肢となりました。これらの機能は市場投入までの時間を短縮し、エンジニアリングチーム間のコラボレーションの強化に役立ちました。Amazon FSx for NetApp ONTAP の高いパフォーマンスと拡張性により、同社のエンジニアリングチームは大規模なデータでも遅延なく作業を進めることができます。また、Multi-Availability Zone オプションにより、ミッションクリティカルなワークロードに必要な高可用性とデータの耐障害性も実現しています。 図 1: Siemens Teamcenter アーキテクチャ Special thanks to: • Dimitrios Dovas (Teamcenter X Product Management, Siemens) • Donna Yasay (AWS Senior Leader, Solutions Architect – Automotive and Manufacturing) • Mekka Williams (Director – Innovation and Solutions, Office of the CTO, NetApp, Inc) • Yue Ning (AWS Senior Solutions Architect – Automotive and Manufacturing) • Charles Inglis (AWS Product Manager –- Technical for Amazon FSx for NetApp ONTAP) • Arunkumar Krishnan&nbsp;(AWS Senior Solutions Architect – HPC Storage SME) <!-- '"` --> 翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの向井が担当しました。 TAGS: AWS for Industrial , aws manufacturing , FSx NetApp , siemens Chandan Murthy Chandan Murthy は、AWSのシニアパートナーソリューションアーキテクトとして、AWSのパートナーが AWS プラットフォーム上で効率的でスケーラブルなソリューションを設計・構築するための支援に取り組んでいます。20 年の経験を持つ Chandan は、Teamcenter や Mendix などのプラットフォームにおける技術的なソリューション設計において堅実な経験を持っています。この専門知識と AWS での役割により、お客様が AWS のクラウドプラットフォーム上で PLM やローコード産業ソリューションを実装することを支援しています。 Tilman Schroeder 2018年から NetApp の Automotive &amp; Manufacturing 部門の CTO を務める Tilman Schroeder は、Automotive &amp; Manufacturing 部門における新たなテクノロジーの活用を主導しています。拡張性の高いサービスアーキテクチャの構築に注力し、製品ライフサイクル管理、HPC シミュレーション、機械学習オペレーション、自律走行などの重要な分野でイノベーションを推進しています。彼の仕事はグローバルな自動車会社がエンタープライズグレードの（ハイブリッド）クラウドソリューションを導入し、デジタルトランスフォーメーションを加速することを可能にします。その専門性と情熱は、企業がクラウドテクノロジーを活用して最も要求の厳しい最先端のワークロードを最適化できるよう支援することにあります。 Yue Ning Yue は、南カリフォルニアに在籍する AWS のシニアソリューションアーキテクトで、自動車および製造業のお客様を担当しています。深い技術知識と業界のトレンドに対する鋭い理解を組み合わせ、効率的で将来を見据えた製造プロセスを推進し、従来の製造プラクティスと新たなテクノロジーのギャップを埋め、AWS のお客様の全社的なデジタルトランスフォーメーションを促進することで知られています。

本稿は、2024 年 11 月 25 日に AWS Blog で公開された “What’s Next for VMware Workloads on AWS?” を翻訳したものです。 AWS と VMware (現在は Broadcom の一部) は、VMware のお客様が、クラウドのスケーラビリティ、俊敏性、コスト面でのメリットを実現し、VMware ベースのワークロードを AWS へ簡単に移行・モダナイズできるようにするため、2016 年から投資とイノベーションを行ってきました。過去 1 年間に行われた VMware 関連の何百件もの会話の中で、お客様もパートナーも、AWS で VMware ベースのワークロードを実行する際のエクスペリエンスを向上させるオプションを探している、という声を多くいただきました。 AWS は、VMware ベースのワークロードをクラウドで実行するにあたり、VMware のお客様に最も多くの選択肢と柔軟性を提供することに全力を注いでいます。また、お客様のニーズをサポートするために、移行とモダナイゼーションのパス、プログラム、パートナーシップを拡大し続けています。Broadcom の VMware Cloud on AWS マネージドサービスを選択したお客様以外にも、使い慣れた VMware ツールと組み合わせて AWS の弾力性と拡張性を簡単に利用できる、ファーストパーティの AWS サービスを好むお客様もいると聞いています。 AWS における VMware のニーズへの対応 — Amazon Elastic VMware Service Amazon Elastic VMware Service (Amazon EVS) のプレビューを開始したことをお知らせできることを嬉しく思います。これは、お客様が Amazon Virtual Private Cloud (Amazon VPC) 内で VMware Cloud Foundation (VCF) を実行するための新しいネイティブ AWS サービスです。この新しいサービスにより、お客様は VMware Cloud Foundation のライセンスポータビリティ資格を利用して、VMware ベースのワークロードを AWS の他のアプリケーションと並行して AWS 上で実行できます。Amazon EVS はデプロイを簡素化し、すぐに使用できる VCF 環境を提供するため、お客様はオンプレミスで既に使用しているものと同じ VCF ソフトウェアを使用しながら、VMware ベースの仮想マシンを AWS へ迅速に移行できます。 Amazon EVS は、リファクタリングやプラットフォーム変更を行わずに、AWS の俊敏性、コスト削減、拡張のメリットを引き出します。お客様は、Amazon EVS のガイド付き設定と自動デプロイを使用すれば、わずか数時間で完全な VCF 環境をセットアップでき、AWS 上でアプリケーションを移動、拡張、スケーリングできます。Amazon EVS を利用すると、お客様固有のワークロードに合わせて高度に最適化されたインフラストラクチャを柔軟かつ制御できるようになり、IP アドレスの変更、スタッフの再トレーニング、運用ランブックの書き直しを行うことなく、オンプレミスネットワークの拡張やワークロードの移行を自由に行えます。Amazon EVS のお客様は、バックアップ、ディザスタリカバリ、ストレージ用のサードパーティ製ツールを含め、使い慣れた VCF の機能やツールを管理、監視、自動化に使用できます。お客様は、他の AWS ネイティブ機能を使用してこれらのワークロードを簡単に強化し、時間をかけてモダナイズすることを検討できます。 お客様やパートナーにネイティブの AWS ソリューションを提供すると同時に、AWS サービスによるモダナイゼーションへの道筋を提供することで、VMware ユーザーに最高のクラウド体験を提供するという取り組みを継続できることを嬉しく思います。 re:Invent 2024 で詳細をご確認ください Amazon Elastic VMware Service は re: Invent 2024 でプレビュー版としてリリースされる予定です。Amazon EVS の特徴と機能に関する詳細なセッションに、対面またはオンラインで参加してください。 Amazon EVS に関心のあるお客様やパートナー様は、AWS の担当者にお問い合わせください。 マイグレーション &amp; モダナイゼーション イノベーショントーク 太平洋標準時 12 月 3 日（火） | 午後 5 時 30 分 – 午後 6 時 30 分 スピーカー：Asa Kalavede, バイスプレジデント, マイグレーション &amp; モダナイゼーション, AWS AWS for VMware エキスポ・ブース AWS Expo Hall ではデモンストレーションや、Amazon Elastic VMware Service の専門家に会って話を聞くことができます。 AWS for VMware 専用ブレイクアウト・セッション Amazon EVS ブレイクアウトを含む、AWS for VMware に特化したテクニカルセッションにご参加ください。 AWS for VMware re:Invent 2024 参加者ガイド re:Invent における AWS for VMware 関連のすべての学習機会をご活用ください。 この投稿の翻訳は Solutions Architect の有岡が担当させていただきました。原文記事は こちら です。 Steven Jones Steven は EC2 の商用アプリケーション担当ゼネラルマネージャーとして、SAP、VMware、Red Hat Open Shift on AWS の製品戦略、エンジニアリング、カスタマーサクセスチームを率いています。AWS 内のこれらの事業分野により、エンタープライズのお客様は、最も要求の厳しいワークロードをクラウド上で実行できます。AWS で 13 年の経験を持つ Steven は、革新的なソリューションを提供し、パフォーマンスを拡大し、複数のセグメントや業種にわたる成長を促進してきた実績があります。スティーブンは、AWS を最も顧客中心のクラウドプラットフォームにし、ビジネスクリティカルなワークロードを実行するのに最適な場所にすることに情熱を注いでいます。彼は AWS の SAP 技術戦略の原動力となり、ハイパースケールプラットフォーム上における SAP ワークロードの一般的なサポートや、メモリ量の多い SAP HANA ワークロードをサポートするクラウドネイティブインフラストラクチャなど、業界初となる数々の成果を市場にもたらしてきました。また、お客様が VMware ベースの環境を AWS にシームレスに移行および拡張できるようにする VMware ビジネスの監督も行っています。クリエイティブなアイディエーション、抽象化、システムパフォーマンスのスキルを活かして、お客様、パートナー、そして AWS に価値を創造しています。

はじめに みなさん、こんにちは。ソリューションアーキテクトの稲田です。AWS のソリューションアーキテクトとして三菱電機グループを 3 年間担当してきました。この記事では、三菱電機グループで生まれつつあるエンジニアコミュニティの物語をお伝えします。 日本を代表する総合電機メーカーである 三菱電機 。その名を聞けば、誰もが家電製品や電気設備を思い浮かべるでしょう。しかし、三菱電機グループの様々な部門の方々をご支援させていただいているうちに、私が目にしたのは、その印象とは少し異なる姿でした。 「 9 つの事業部と本社組織に分かれている ので、部門を超えたエンジニアの交流が難しいです。」と、 DX イノベーションセンター の辻尾さんは語りました。 通信システムエンジニアリングセンター の相川さんは次のように付け加えました。「クラウドに詳しくない部門では、他部門で解決済みとなっている悩みを抱えていたりすることが多いです。それぞれの部門が独自に問題解決を図っているのを見ると、もったいないと感じることがあります。」 図1 : 国内の主な事業所一覧 コングロマリット企業ならではの多様性。個別生産と量産、顧客層、技術、さらには物理的な距離。あらゆる面で「遠い」存在だった各部門を、どうやって「近く」することができるのか。そこに大きな可能性が眠っていました。 IoT・ライフソリューション新事業推進センターの小川さん が印象的な言葉を残しました。「三菱電機として AWS だけでなく、事業部門や製作所を超えた技術交流に可能性があると感じています。」小川さんは続けて、「各部門には素晴らしい技術や知見があります。それらを共有し、活用できれば、三菱電機全体としての競争力が大きく向上するはずです。ただ、これはおそらくコングロマリット製造業ではよくある課題だと思います。」と指摘しました。 この小川さんの言葉は、三菱電機が直面している状況と、そこに潜む可能性を端的に表していました。各部門には確かな技術力と豊富な経験を持つエンジニアたちがいます。彼らの力を結集できれば、どれほどの相乗効果が生まれるでしょうか。 その実現への道のりは、新たな挑戦の連続でした。長年培われてきた組織文化や、部門間の距離。それらを橋渡しし、エンジニアたちを繋ぐには、何か新しい仕掛けが必要でした。そして、その答えは意外なところから生まれることになります。 私が担当してからすぐの 2022 年 9 月、エンジニアたちの自発的な動きが始まりました。それが、Mitsubishi Electric AWS User Group (通称: MAWS-UG) の誕生につながります。MAWS は、三菱電機のエンジニアたちが AWS に関する知識や経験を共有し、部門を超えて交流するためのコミュニティです。 本記事は MAWS の誕生までの道のりや、具体的な活動内容、それがもたらした変化、直面している課題、そして今後の展望について深掘りしていきます。 Viva Engage チャンネルの立ち上げ：コミュニティの芽生え 三菱電機の各部門で個別に進められていた AWS 活用。その状況を変えるきっかけは、小川さんのちょっとした行動から始まりました。 2022 年 9 月、小川さんが Viva Engage チャンネルを立ち上げました。「最初は本当に手探りでした」と小川さんは当時を振り返ります。「AWS に関するちょっとした Tips を投稿し始めたのですが、しばらくは誰からも反応がなくて(笑)。でも、諦めずに続けました。」 図2: 小川さんが 1 人で投稿し続けた Tips 転機が訪れたのは、その 2 ヶ月後のことです。小川さんが AWS 主催のプライベート GameDay で優勝したことをきっかけに、社内でのプレゼンスが一気に高まりました。「優勝の報告を投稿したら、突然いろんな部門の方から連絡をもらえるようになりました。」と小川さんは嬉しそうに語ります。 この出来事を皮切りに、グループ会社との交流も始まりました。2023 年 10 月には re:Invent 事前交流会を開催。ラスベガスでの現地交流も実現し、部門を超えたエンジニアの輪が急速に広がっていきました。 AI 戦略プロジェクトグループの塚田さんは、この動きに早くから注目していました。「小川さんの GameDay 優勝のニュースを聞いて、すぐに Viva Engage チャンネルに参加しました。そこで初めて、他部門にも AWS に詳しい仲間がいることを知りました。」と語ります。 こうした動きは、AWS アカウントチームの目にも留まりました。AWS の担当者たちは、同じような悩みや課題を持つメンバーを積極的に引き合わせる役割を果たし、地理的に離れた拠点のエンジニアたちのコミュニティへの参加を実現しました。 MAWS の誕生：公式コミュニティへの進化に向けた挑戦 Viva Engage チャンネルの立ち上げをきっかけに、少しずつ交流や情報交換の文化が作られてきました。しかし、オフラインでの交流の場はまだ無く、まだ部署やグループ会社を跨いだ仲間としての意識ができづらいと感じていました。そこで、「僕らからその場を作っていきましょう！」と IT ソリューションビジネス・業務改革推進本部の紅林さんから小川さん、相川さんに話を持ちかけ、社内交流の場を作るべく動き出しました。 ここからすんなりと MAWS 設立かと思いきや、早速の壁にぶち当たります。「最初は場所を取ることすら大変でした。会議室のルールを見ると交流会の用途では借りることができなかったです(笑)。 そのため有志でひっそりと休憩スペースで集まりました。それが記念すべき第 0 回です。」と紅林さんは当時を振り返りました。 図3: 会議室が借りれずに休憩スペースで開催した第 0 回 MAWS-UG そんな中、転機が訪れました。DX イノベーションセンター長 朝日宣雄 氏が MAWS のエグゼクティブスポンサーとして名乗り上げたのです。 AWS Summit Tokyo 2019の基調講演 や AWS Executive Insights などの多数の登壇実績を持つ朝日氏は当時をこのように振り返ります。 「AWS は、 家電や設備機器のための IoT 共通プラットフォーム Linova の開発や家電統合アプリケーション MyMU 上の様々なサービス開発 において、大変お世話になってきました。また、三菱電機内の AWS 活用事例を共有するための MELCO Day も開催や Working Backwards 研修などを通じて、社内の AWS 利用も広がっていく中、社内のユーザーネットワークを小川さんはじめ若手エンジニアの皆さんが自発的に拡大されているのを知り、是非とも正式な活動となるようにお手伝いをしたいと思いました。組織の壁を越えたこのような活動は、まさに DX イノベーションセンターが目指す Serendie の想いと合致していますので、私も可能な限り参加したいと思っています。」 スポンサーを獲得したことで一気に加速し、その後 MAWS-UG と命名、Amazon Bedrock を使ってキャラクターも作成し、2024 年 4 月には念願の第 1 回を開催します。 図4: 三菱電機の「ワクワク コツコツ」 とマウスをかけ合わせたマスコットキャラクタ 「本当に感動的な瞬間でした。これまで孤軍奮闘してきた人たちが一堂に会して、同じ悩みや課題を共有し合う。そこには確かな手応えがありました。」と小川さんは語ります。 三菱電機インフォメーションネットワーク株式会社 の太田さんは「ずっとコミュニティ活動に憧れはありました。2019 年から JAWS-UG の支部運営に参加していたものの、社内へのアピールを上手くすることができず、プライベートでの個人参加を続けていました。遂に三菱電機グループ内 AWS ユーザーグループができて嬉しいです。」とコメントしました。 MAWS の誕生は、三菱電機グループのエンジニアたちにとって新たな時代の幕開けを意味します。部門の壁を越えて知識と経験を共有し、共に成長していく。そんな可能性がここから広がっていったのです。 図4: 第 1 回 MAWS-UG MAWS の成長と活動：エンジニアの輪の広がり MAWS の正式発足から、三菱電機のエンジニアコミュニティは急速な成長を遂げました。当初わずか数十人だったメンバーは、瞬く間に 300 人近くまで増加。この数字は、エンジニアたちの間で潜在的に存在していた「つながりたい」という願望を如実に表しています。 図5: MAWS メンバー数の推移と主要イベント 「最初は正直、これほど多くの人が集まるとは思っていませんでした。でも、蓋を開けてみれば、様々な部門から予想以上の参加があって。みんな同じような悩みを抱えているのだなと実感しました。」」と、MAWS の運営メンバーの一人、塚田さんは語ります。 MAWS の中核となる活動は、3ヶ月に一度開催されるLT 会と懇親会です。これらのイベントは、本社、横浜、関西、さらには AWS 目黒オフィスなど、様々な場所で開催されています。 「オフラインでの交流にこだわっています。」と小川さんは説明します。「確かにオンラインの方が参加しやすいかもしれません。でも、実際に顔を合わせて話すことで生まれる化学反応はやはり特別です。」 LT 会では、スポンサーによる 10 分間のプレゼンテーションと一般参加者による 5 分間の LT が行われます。テーマは多岐にわたり、最新の AWS 技術から業務での活用事例、さらには個人的な失敗談まで。「回を重ねるごとに LT の内容が濃くなっています。」と紅林さんは嬉しそうに語ります。「参加者からも『刺激になる』という声をよく聞きます。」 図6: 第 4 回 MAWS UG では KAG みのるん氏に特別 LT をしていただきました 特筆すべきは、これらのイベントの雰囲気づくりです。「あえて『三菱電機らしくない』雰囲気を作るように心がけています。」と紅林さんは笑います。「飲み物を片手に、リラックスした雰囲気で LT を聞く。そうすることで、より自由な発想や意見交換が生まれます。」 日常的なコミュニケーションの場としては、Microsoft Teams が活用されています。ここでは、AWS に関する質問や情報共有、さらには AWS アカウントチームとの直接対話も行われています。「以前は個別に問い合わせていた内容も、ここで共有することで、みんなで知見を蓄積できるようになりました。」と辻尾さんは評価します。 もちろん課題もあり、「まだまだ社内での認知度は十分とは言えません。」と相川さんは指摘します。「特に管理職層への浸透が今後の課題です。彼らの理解と支援があれば、より多くのエンジニアが参加しやすくなるはずです。」と紅林さんは加えます。 MAWS の活動は単なる情報共有の場を超えて、三菱電機のエンジニア文化を変革する原動力となりつつあります。部門の壁を越えた知識の共有、新たな技術への挑戦、そして何より「つながる」ことの喜び。MAWS は、三菱電機の未来を担うエンジニアたちの新たな絆を紡ぎ出しているのです。 MAWS がもたらした変化 MAWS の誕生から約 1 年。この短い期間で、三菱電機のエンジニアコミュニティは目に見える変化を遂げました。その影響は、個々のエンジニアのスキルアップだけに留まらず、部門を超えた協業にまで及んでいます。「例えば、ある案件で AWS サービスの使い方で悩んでいたときに、MAWS のコミュニティで質問したところ、別の部門の方から即座に解決策を教えてもらいました。これまでだったら、何日もかけて自分で調べていたでしょうね。」と小川さんは語ります。 このような事例は、MAWS がもたらした最も直接的な効果の一つです。さらに、その影響はより深いところにも及んでいます。 「エンジニアとしての自信にも繋がっています。」と、塚田さんは目を輝かせて話します。「MAWS での LT 会で発表する機会をいただいて、最初はうまく話せるのかと悩みましたが、多くの方から前向きなフィードバックをいただきました。それが自信になって、今では社外イベントの登壇や AWSのハッカソンにも参加するようになりました。」 実際、MAWS のメンバーによる社外活動も増えています。 JAWS-UG &nbsp;や、 Bedrock Night in 大阪 、AWS Summit での展示やセッション、さらには技術ブログの執筆など、三菱電機のエンジニアの存在感が、業界全体で高まっています。 MAWS が直面している課題 MAWS の活動は着実に成果を上げ、三菱電機のエンジニアコミュニティに新たな風を吹き込んでいます。しかし、その過程は決して平坦ではありません。 「最大の課題は、やはりコミュニティの存在や、技術的・文化的メリットをグループ内に周知していくことです」と相川さんは率直に語ります。「現在コミュニティに加入しているメンバーは、活動に関心がある人たちがメインです。しかし、グループ内には AWS をディープに利用していて困っている人や、知見を有する人たちがもっと沢山いるはずです。その人たちにも、もっと参加してほしいと考えています」 この課題に対して、MAWS は新たなアプローチを検討しています。「ついつい見過ごされがちな社内周知よりも、外部発信の方が効果的だと思い、今回のブログ化に踏み切りました」と相川さんは続けます。 もう一つの大きな課題は、新規参加者の継続的な獲得です。「初心者層に、『参加そのもののハードルが高そう』と敬遠されがちなので、定期的に社内向けに声がけを行っています」と小川さんは説明します。「特に、業務でクラウドに触っている人の参加が増えたらうれしいですね。困りごとや事例をたくさん持っているはずですから」と通信システムエンジニアリングセンターの杉村さんはコメントします。 組織文化の変革も重要な課題の一つです。「社風かもしれませんが、『とりあえずやってみよう、参加してみよう』という風潮があまりありません。この文化を変えていく必要があります。」と辻尾さんは指摘します。 MAWS の今後の展望：さらなる成長への道 MAWS の今後の展望について、辻尾さんは次のように語ります。「三菱電機のエンジニアを社外とつなげるためのコネクタになりたいと考えています。内製化やソフトウェア開発の文化が全く根付いていない現状を変えたいです。これから SaaS を展開していくためには、アジリティが大事。自分で判断して手を動かせるように、社外から直接情報を仕入れられるエンジニアを増やしたい。ソフトウェアに強くなることが重要です」 さらに、辻尾さんは具体的な目標も示します。「 2030 年までに 20,000 人の DX 人財を育成する 必要があります。このコミュニティで DX 人財育成の柱の一部を担いたいと考えています。できる人財がリードする、そんな環境を作りたいです。」 図7: 三菱電機が掲げる DX 人財強化 「MAWS は単なる技術コミュニティではありません」と紅林さんは締めくくります。「私たちは、三菱電機の未来を創造する原動力になりたいと考えています。エンジニア一人一人が自分の可能性を最大限に発揮できる環境を作り、そこから生まれるイノベーションで社会に貢献する。それが MAWS の究極の目標なのです」 MAWS の挑戦は、まだ始まったばかりです。課題は多いものの、そこには三菱電機の未来を変える大きな可能性が秘められています。エンジニアたちの情熱と創意工夫が、この巨大な組織にどのような変革をもたらすのか。その答えは、彼らの手の中にあるのです。 おわりに 本記事では、三菱電機グループにおける AWS ユーザーコミュニティ”MAWS”の誕生から現在までの軌跡をお伝えしてきました。一人のエンジニアの小さな行動から始まり、現在では 300 人を超えるメンバーを擁するコミュニティへと成長した MAWS の歩みは、大企業における草の根のエンジニアムーブメントの可能性を示しています。 部門の壁を超えた知識共有、技術交流の促進、そして何より「つながる」ことの価値。MAWS の活動は、三菱電機グループのエンジニア文化に確実な変化をもたらしています。 本記事では一部のメンバーの声しか紹介できませんでしたが、MAWSの活動は、実際にはより多くのメンバーによって支えられています。イベントの企画や運営に携わる方々、積極的に質問や情報共有をしてくださる方々、さらには静かにコミュニティを見守り支援してくださる方々など、様々な形で関わる全てのメンバーの存在が、MAWS の成長を支える原動力となっています。 課題はまだ残されていますが、それらに立ち向かう情熱と創意工夫は、このコミュニティの大きな強みとなっています。MAWS は今後も、三菱電機グループの DX 推進とエンジニア育成の重要な基盤となることでしょう。 最後に、本記事を通じて、大企業における技術コミュニティ形成のヒントを少しでも共有できていれば幸いです。MAWS の挑戦は、同様の課題を抱える他の組織にとっても、参考になる事例となるのではないでしょうか。 図8: 第 2 回 MAWS UG AWS Summit 前夜祭 今回インタビューをさせて頂いた MAWS の運営メンバーの方々 小川 雄喜 IoT・ライフソリューション新事業推進センター/IoT 推進部/PF 開発グループ所属。三度の飯より AWS とビールが好き！ JAWS-UG 第 1 回 Bedrock Claude Night や、 JAWS Festa 、 AWS Innovate など最近は色んな登壇にチャレンジしています。 相川 奈槻 通信システムエンジニアリングセンター ネットワークシステム部所属。三菱電機のテクニカルアーキテクト？です。社内 DX 部門に対する技術的な支援を行いながら、ネットワーク市場に関する動向調査とサービスの拡販支援を推進しています。好きなサービスは AWS IAM です。週末は美味しいものを食べ過ぎてしまいます。最近丸くなり過ぎました。 2024 Japan AWS All Certifications Engineers に選出されました。 辻尾 良太 DXイノベーションセンター プラットフォーム設計開発部所属。三菱電機のデジタル基盤「 Serendie 」の開発に携わっています。普段は鶏肉とたまごをよく食べます。悩みはカラスやハトによく糞を落とされることです。 2024 Japan AWS All Certifications Engineers に選出されました。JAWS-UG (E-JAWS) での登壇発表にもチャレンジしています。 紅林 俊之 ITソリューションビジネス・業務改革推進本部所属。旅とカメラと AWS が好き。訪問国数 50 カ国以上。2023 年に三菱電機に AWS エンジニアとして入社したばかりのソリューションアーキテクト？です。改善すること盛り沢山で社内で動き回っており、色々な人を巻き込みながら少しずつ改善に取り組んでいます。「やったほうがいい」と自分で思えることを仕事にしています。 杉村 みさき 通信システムエンジニアリングセンター ネットワークシステム部所属。ネットワーク・セキュリティシステムの提案支援を行っています。カメラが趣味で、MAWS のイベントでは写真撮影を担当しています。 2024 Japan AWS All Certifications Engineers に選出、「 IoT 技術者向け AWS セミナー 〜スマート製品・サービス開発の勘所〜 」で登壇。 塚田 真規 AI 戦略プロジェクトグループ所属。生成 AI 利活用を推進するために、生成 AI 開発基盤の整備や LLMOps の推進、普及を担当しています。アプリケーション開発よりもプラットフォーム構築が好きです。 JAWS-UG での登壇発表 にもチャレンジしています。 2024 Japan AWS All Certifications Engineers に選出されました。 太田 亮 三菱電機インフォメーションネットワーク株式会社、経営システム事業部所属。三菱電機およびグループ会社向けのシステム開発を行うシステムエンジニアです。主にビル事業向けのシステム提案・開発・保守を担当しています。2019 年から JAWS-UG 初心者支部 に運営として参加しています。 インタビュアー 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the second half of that. The following articles have also been published as serialized articles, so please be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half) ” Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 2) — First half ” 4. Key points of cloud utilization As introduced in the third chapter of the second blog in this series, the philosophy for our cloud-based smart meter relies on three main factors: flexible scalability through loosely-coupled architectures, realizing a high level of availability in our system, and having agility through our use of managed services. In order to maximize the benefits of the cloud (including TCO reduction) to the best of our ability, we’ve found that it is important to proceed development with the optimal combination of AWS services. However, AWS provides a wide variety of services which each have different features and usages, so it’s essential to master AWS’s full offerings so that you can match them to your own requirements along with correctly implementing appropriate security measures such as data protection and access control. Based on this approach, I think the following three points are particularly important when developing on the AWS cloud: First, properly understanding system and cloud architectures ourselves, as end-users Also making sure that your vendors correctly understand the cloud, embrace it, and have the proper workflow in place to implement it Finally, continuously making efforts to acquire new skills while improving your existing ones together as both end-users and vendors In other words, having the will to properly use the cloud is essential, but you can’t successfully use the cloud by will alone. After all, you have to select the appropriate system vendors that will actively accompany your company throughout your cloud journey, and make sure that they proceed with the development of your system while closely collaborating with your business. 4-1. Correctly understanding the cloud as end-users Looking back on the history of conventional system development, I believe that you have to correctly grasp the “big picture” of the application that you’re developing, so we are consistently making efforts to deepen our understanding of the system that we have in use from both a business and technology perspective in line with the above policy. At the same time, in order to talk about cloud, we ourselves must first understand the cloud (as we introduced in detail the fifth chapter of the second blog , Introduction of Common Infrastructure and System Control). In other words, I believe that by correctly understanding the underlying infrastructure, and by understanding it in depth, you can proceed with developing applications based on those layers and successfully cooperate with your system integrators. I’ve sometimes heard people say things such as “there’s no need to worry about the details – we own the system!” raised as a common discussion point related to using the cloud, but as a result of our efforts so far, we believe that by correctly understanding the cloud it’s possible to enjoy many benefits beyond mere ownership of the system itself. Speaking of security aspects that are particularly easy to focus on, when using AWS, AWS itself has obtained a wide variety of security measures and certifications to guarantee them. If we want to implement these measures, I believe we need to spend time examining and trying them out for ourselves. However, at the same time, in Japan we sometimes say “let the mochi shop take care of the mochi”, or as we might say in English: “leave it to the experts.” This means leaving the actual infrastructure development, maintenance, and operation (including security) to your system vendors while you focus on the business outcomes that you originally wanted to achieve, and making sure to prepare an environment for your vendor partners so that you can ensure those outcomes together as is mentioned in the shared responsibility model . 4-2 Vendors correctly understanding the cloud In order to properly utilize the cloud, it is very important to formulate your reasons and motives for using the cloud in the first place, such as how you’re going to tackle the overall transition to the cloud, your policies around the shift, and very importantly – organizing what you want to communicate to your system vendors. For example, if your messaging on what you want is unclear from the get-go, you might end up with a case of your servers having been simply migrated over to Amazon EC2 ; but in the case that your system has middleware, you of course wouldn’t be able to properly enjoy the intrinsic benefits of the cloud. In order to fully reap the cloud’s benefits, companies need to proceed with development while selecting various services and functions in the right places, such as creating a system concept that is rooted in the idea of a microservices architecture and which will make full use of AWS managed services as the building blocks of the system. Traditionally, I feel that vendors that have developed on on-premise server environments tend to move in the direction of building more similarly conventional systems on the cloud, so if you don’t clearly show and communicate your needs and intentions as users to those vendors, I think it is common to see situations where you could hit road bumps at even the brainstorming stage. As users, it is essential to actively and comprehensively encourage vendors to understand why using the cloud is necessary in specific cases. Equally important is encouraging vendors to consider the future potential of the system from the design stage. In other words, I think a change of mind from having a sense of security and focusing purely on what advantages there are with the cloud, to actually using the cloud yourself, is an important point. Additionally, since system vendors are responsible for development, it’s clear that not only end-users but also system vendors should realize this mindset change with their customers together. Therefore, you have to select system vendors that can run side by side with your company throughout the process, as proper use of the cloud cannot be realized unless you’re cooperating and coordinating together. As a major prerequisite for this, it is essential that the development vendor correctly understands the cloud in the first place. First, you can prevent a few problems and obstacles from occurring in system migration and operation by making sure that the systems your vendor has designed so far work correctly on the cloud, and appropriately incorporate and that cloud system’s specifications and requirements. Also, you can set yourself up for success in the long run by proceeding with a design and development philosophy that takes advantage of ideas such as microservices and serverless architecture, so that your managed services can be enjoyed to the fullest through a correct understanding of AWS services and their functions. Finally, a proper understanding of cloud security is also essential for building a robust system. In deepening such collaborative relationships, I think it is also effective for us to have a common infrastructure as explained in the fifth chapter of the second blog , which describes organizing a collaborative system in a way that shares an environment with your vendors. AWS Professional Services was key in their cooperation with us on this project by encouraging our vendors to make autonomous efforts, giving them technical support, and by supporting us through overall project promotion and management while constantly staying in close contact with us. 4-3. Continuously improving your cloud skills In general, it is extremely important to adopt technologies that are compatible with cloud services (such as containers or serverless setups), but it’s also extremely important that we’re continuously learning about those technologies. If we have a goal to adopt a new technology we can achieve that goal by merely introducing it into the system, but as mentioned in the my explanation relating to common infrastructure in the fifth chapter of the second blog , brushing up your technical skills is key. It’s essential to actually understand the AWS cloud while you use it, but in most cases, acquiring a new skillset such as this tends to come down to individuals taking their own time to learn the technology. However, I believe it’s key that you motivate those involved with the project to continuously be learning themselves and make it an essential part of your organizational strategy; this is what we’re trying to do with our smart meter project and the proper use of its data moving forward. 5. Conclusion In this blog we have introduced our smart meter system initiatives, mainly regarding our points of view and what to keep in mind in regard to how two projects with different personalities are being carried out simultaneously in parallel: a current generation system being shifted to the cloud, and the development of a next-generation system that’s cloud-native. The decision that both systems would involve the cloud was a major decision, and as introduced in the blog, after thorough internal discussions we were finally able to establish a consensus and begin moving forward. There have of course been many in-depth discussions from both the cloud-promoting side and the more conservative side, but so far, so good although there’s been great difficulty along the way. One additional story that I’d like to share is how we were able to exchange opinions with industry peers overseas through AWS’s introduction, and how it was interesting to hear stories of companies having had internal discussions similar to ours that still ended up with those companies adopting the cloud. I’ve always had the impression that corporations overseas are more progressive in comparison to those in Japan, but regardless of the country, I understood that companies around the world experience similar difficulty to ours when it comes to adopting the cloud, as in the end, it seems that no matter where you are there’s no such thing as a “hands off” approach to cloud migration. Also, depending on the country, we also learned that there are situations where regulators are restricting cloud use, or situations where OT systems can’t be integrated with the cloud in the first place. Thus, of course there are still issues that arise when it comes to introducing the cloud such as navigating discussions with cautious stakeholders or the existence of regulations, etc., but as indicated in this blog, I believe from the view point of future scalability, system flexibility, and having a proper environment for proper data utilization – utilizing the cloud is essential. I believe that in order to really use the cloud, both end users such as us and system vendors will continue to deepen our mutual understanding, and continue to refine our knowledge around the cloud. That knowledge and those skills will be continuously questioned though, with questions around what we’re aiming for and what kind of system we’re trying to introduce to accomplish that, etc, but I think the idea of a common infrastructure like with what we’ve implemented, and the account management and control that accompanies it, we’ve managed to give form to these ideas in one way. Also, regarding that philosophy, we owe a great deal to AWS, and above all, to the folks from AWS’s Professional Services team, who are truly experts among experts in the cloud space, without whom I think our activities would have easily come to a standstill. Our project is still a work-in-progress, but I would like to take this opportunity to thank them once again. I hope this blog will help our readers think about using the cloud for future system development. Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the third of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the first half of that. The following articles have also been published as serialized articles, so please be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half) ” Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (Part 2) — First half ” 1. Introduction In this article, we have introduced our efforts in three parts. In the first session , we introduced the overall picture of discussions aimed at utilizing the cloud in our smart meter system. In the second session , we introduced the overall picture of next-generation smart meter systems, including technical perspectives, and our current efforts. The 3rd session, which is the last one, will focus on cloud migration of current smart meter systems, and introduce our thoughts and commitments related to cloud utilization and our efforts. 2. From on-premise to cloud utilization Our current smart meter system, as described in the first blog, is partly due to the background at the time when development was proceeding ahead of other electric power utility companies, and while there is no package solution for meter data collection and management systems like these days, we proceeded with system development through trial and error in cooperation with multiple system vendors, and built a system assembled based on the system vendor’s technology and specifications at our data center. Full-scale introduction of smart meters to customers began in 2012, and until implementation was completed in 100% households in March 2023, we have achieved continuous stable operation while the number of servers used in the current system has also increased along with the expansion in the number of smart meters installed. On the other hand, since it is a system developed in such situation, it is facing issues such as economic efficiency and future sustainability issues associated with adopting proprietary OS, commercial databases, and middleware, system blackboxing associated with dependency on system vendors for development and operation, and concealment of business processing logic, etc. Furthermore, the increase in server hardware associated with the expansion of smart meter deployment, and continuous occurance of the termination of server manufacturer maintenance. The impact range was wide, such as technical verification of OS and middleware associated with the outbreak, and not only in terms of cost but also in terms of human workload, both of which were increasing. In addition, due to recent major changes in social conditions, various issues have also become apparent, such as future uncertainty represented by delays in server hardware procurement delivery due to lack of semiconductors. And this complex situation has been a barrier to the expansion of flexible and advanced utilization of data collected from smart meters. If we operate the system in our own on-premise environment, we will fall into a situation similar to ours, and I think there are many cases where people experience to fall into a situation similar to ours and face issues of the same kind if operating the system in their own on-premise environment. We thought that utilizing cloud technology would be an option as a comprehensive solution to these issues, so we decided to aim for a cloud shift in the current smart meter system. 3. Cloud Utilization Policy for Current Smart Meter Systems In this chapter, we will introduce how to utilize AWS functions and services in our current system and our system migration policy. There are 3 policies we have set out. Initiatives for migrating current systems to the cloud Leave it to AWS to offload things that can be replaced with AWS cloud services Take full advantage of the flexibility unique to the AWS Cloud Incorporate technological innovations and new services from the AWS Cloud appropriately while proceeding with development 3-1. Offload to AWS cloud services On premises, it is necessary to individually deal with daily hardware failures such as disk failures, etc., but in the cloud, such failure response is offloaded to AWS, so we don’t need to be aware of it. Also, by increasing the offloading rate, infrastructure construction and operation and maintenance can be replaced by simply using services. In other words, there is no need to even set up a database, and the system and way of thinking about system construction will change drastically, such as simply selecting and using services (Figure 1). In our on-premise server system, middleware such as cluster software necessary to ensure reliability has been adopted by each system vendor, but we first positioned this kind of middleware as a target to break away from it. To achieve this, we will implement application improvements including Various things from each company using Amazon Elastic File System (EFS) , Amazon FSx , etc., and health checks of server groups utilizing Elastic Load Balancing (ELB) . In combination, while multi-AZ redundancy between sites has also been realized, the system reliability of the system as a whole has been improved. At the same time, it is also basic to break away from commercial databases. We did not take any way of thinking about DB on Amazon EC2 from the beginning of the study, and we are conducting migration studies that assume the use of Amazon Aurora or Amazon RDS like AWS managed services. This way of thinking about actively utilizing various managed services on AWS is the result of evaluating that utilizing managed services will surely lead to an improvement in reliability, operation maintainability, and a reduction in operational load. Figure 1. Offload IT infrastructure operations to AWS by utilizing AWS managed services 3-2. Utilizing the Flexibility Unique to the AWS Cloud In the cloud, there is the lightness of using resources when they are needed and discarded when they are no longer needed, and there is an advantage of “being able to go back.” For example, in the past, server resource sizing was carried out precisely, and then server procurement and implementation were carried out over time, but in the cloud, based on the idea of pay-as-you-go billing, where “you can use your favorite resources, when you like, and for as long as you like,” you can flexibly change the configurations and solutions decided at that point to better ones (Figure 2). In our study, changing instances is also flexible and simple, so we are proceeding with instance type selection while proceeding with desk studies and actual machine verification without closely performing resource sizing. Figure 2. Advantages of utilizing AWS from an IT infrastructure procurement perspective Also, in the past, it took a lot of time and money to set up the production environment and development environment, respectively. We are now actively utilizing Infrastructure as Code (IaC) in building IT infrastructure. By automating IT infrastructure deployment using IaC, human errors can also be avoided, and system configuration reviews can be handled flexibly while proceeding with application development (Figure 3). Figure 3. IaC benefits on AWS 3-3. Appropriately incorporating technological innovation and new services Even if the architecture was determined to be appropriate at the time of implementation, due to technological innovation associated with the passage of time since implementation, there are more options than at that time, so the range of considerations has expanded, and there is a possibility that a better configuration can be selected (Figure 4, Figure 5). For example, as we proceed with our consideration, there was an announcement in August 2023 that “ Network Load Balancer (NLB) will begin supporting security groups. ” At that time, NLB was not covered by security group chains, but as a result of design changes in response to this announcement, it was possible to ensure security with a simple mechanism by incorporating the chaining of security groups across the entire system. In the construction of next-generation smart meter systems that are currently underway, if better services and functions are similarly provided, the direction is to proceed with development while utilizing them. Figure 4. Expanding the provision of new services and features through technological innovation at AWS Figure 5. Expanding AWS services to include the field of analytics (excerpt) In this article, we have introduced the first three chapters regarding our efforts aimed at cloud adoption of smart meter systems. For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems at Kansai Transmission and Distribution, Inc. (Part 3) — Second half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the second half of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article will be in the latter half. Check out this link for the first half. Also, for the first contribution, please refer to “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. (First half). ” 4. System Architecture Next, we’ll give you an overview of the next generation smart meter system architecture we’re considering. When implementing a loosely coupled architecture in line with the development policy described above, cooperation between subsystems is based on loose coupling. Specifically, in collaboration between subsystems from HES to MDMS and from MDMS to a meter data utilization platform that centrally manages data, it was designed so that data transfer with high elasticity and high real-time can be realized simultaneously while asynchronously linking between systems using Amazon SQS. By constructing a mechanism based on SQS, it is possible to receive meter reading values that occur in large quantities on a regular basis and event information that is transmitted in large quantities during power outages or restoration while buffering, can be linked to subsequent processing at high speed, and has an architecture that enables near real-time processing that maintains elasticity against large amounts of burst traffic. Also, within subsystems based on loosely coupled architectures, we will promote the use of microservices. Business logic is reviewed, functions are broken down, etc., using AWS Lambda etc. for usage calculation and instrument event processing, etc., a package-like application execution environment is realized in a container environment based on Amazon ECS and AWS Fargate, and then a loosely coupled architecture is built by linking APIs with Amazon S3, Amazon DynamoDB, etc. For future implementation of new functions for which the current system has not been decided, we will achieve flexible and agile development while utilizing serverless and containers with segmented functions. Keeping in mind improvements in operation and maintainability related to database security and version upgrades, etc., the policy is to set up a system centered on AWS managed services, etc., and along with this, not only S3, but also databases such as Amazon Aurora, Amazon KeySpaces, DynamoDB, and Amazon RDS for PostgreSQL We utilize various managed services, such as Amazon API Gateway for data linking. Toward future advanced utilization of meter reading value data, equipment information, etc. collected by smart meter systems and its revitalization, we will first centrally manage such information in a data store based on meter data utilization, and then advance develop a data utilization mechanism starting from this while using Lambda, API Gateway, etc. In order to advance data utilization, we plan to create an environment where easy data analysis is possible by linking Amazon QuickSight etc. with this data store, and also utilize AI/ML services from the trial and error stage so that they can be applied to business. Figure 6 shows an overall overview of the system we are developing. Figure 6. Architectural Overview of Our Next Generation Smart meter system 5. Introduction of common infrastructure and system control In our 15 years of smart meter work, we have faced various challenges. These included, for example, issues that lack flexibility in data utilization, such as overlapping functions between systems and complex collaboration methods etc., issues of economy and future sustainability associated with adopting system vendors’ own OS, commercial databases, and middleware, issues such as system blackboxing and concealment of business processing logic, and further future uncertainty, such as delays in server hardware procurement delivery due to semiconductor exhaustion. We believe that the root cause of these issues is that we were unable to develop under a unified system concept, and this time we are focusing on incorporating our own development concept. For that, it is necessary to correctly understand the system infrastructure on the AWS cloud, which we will now use as our development platform. In other words, instead of entrusting everything from the application layer to the infrastructure layer supporting it to the system vendor to develop the system, this time, after organizing the cloud infrastructure layer and common functions related to the entire system, such as AWS account management for applications on it, network functions, security measures, etc. as a “common foundation”, then we decide that we will control the whole thing including the development direction of the application layer by managing this common foundation. We believe that by correctly understanding the infrastructure layer and understanding it in depth, we can proceed with the development of applications based on this while firmly cooperating with system vendors. Since system vendors will also be able to focus on application development linked to business, we believe that as a result, it will be possible to secure system quality even more than before, and we will be able to obtain a reliable path for future data utilization. There are three points of effort for us to correctly understand and manage the cloud infrastructure layer, and to internalize future data utilization. The first is to split AWS accounts based on AWS’s multi-account strategy. By doing so, we will clarify the scope of responsibility and strengthen security aspects. Specifically, after managing the common infrastructure, AWS accounts are divided for each system vendor, and vendors are required to carry out system construction and maintenance within the account. Furthermore, connection points between systems are minimized and responsibility demarcation points are clarified. Necessary user IDs are also provided from the common infrastructure side. Figure 7 shows how to organize this based on the way of thinking about AWS’s multi-account strategy (*2). (*2) Decide Your AWS Environment Using Multiple Accounts In this way, the environments for development, testing and operation are separated and maintained, and the breakdown of responsibilities for each common infrastructure and subsystem within each environment is clearly divided by AWS accounts. As a result, system vendors will able to focus on application system development within the granted account, and they will also be responsible for system operation and maintenance. Figure 7. Splitting AWS accounts between systems to clarify areas of responsibility and enhance security The second is to clarify the scope of responsibility between AWS, system vendors, and us, based on the AWS shared responsibility model. Along with this, we manage things that require standardization, such as OS, as a common infrastructure and provide them to vendors. Variations between systems related to OS types and versions can be eliminated, which also leads to a reduction in TCO. The specific image is shown in Figure 8. Figure 8. Role and responsibility base on AWS shared responsibility model The third is getting help from AWS Professional Services. In order to achieve full use of the cloud, it is essential to introduce a common infrastructure, and on top of that, I think it is important to cooperate more closely with system vendors. This requires us as stakeholders to correctly understand the system and steadily respond to system expansions and changes associated with environmental changes; in other words, it is essential that we correctly understand AWS, and with the cooperation of AWS Professional Services, we are accelerating studies and acquisition of skills and knowledge. While cooperating with the members of AWS Professional Services from time to time, we are accelerating system development and proceeding with initiatives by receiving comprehensive support, such as PMO support for project promotion and education support for our members, while appropriately understanding a wide range of technical issues and trying to resolve them in a flexible and accurate manner. 6. Conclusion In this contribution, I introduced the status of efforts for next-generation smart meter systems utilizing AWS, including technical perspectives. Next time, I would like to introduce the cloud shift of the current smart meter system. The 3rd installment has been published as a serialized article below, so please be sure to check it out. Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article is the first half of the second efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution, Inc. We received a contribution from Mr. Yasuo Matsuura, an executive officer. The introduction will be divided into 2 parts: the first half and the second half. This article is the first half of that. The serial articles have also been published as serialized articles, so be sure to check them out. Article #1 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” 1. Introduction In this article, we will introduce our efforts in three parts. In the first session, we introduced the overall picture of discussions aimed at utilizing the cloud in our smart meter system. This time, I would like to introduce the overall picture of a next-generation smart meter system using AWS, and the current status of our efforts, including technical perspectives. (Figure 1) Figure 1. Smart meter system and scope of explanation in this article 2. Next Generation System Requirements In developing a next-generation smart meter system, we discussed the development concept internally based on 15 years of experience in the development, maintenance and operation of current smart meter systems, the summary contents of the next-generation smart meter system review meeting, external needs, and the latest technology trends. 15 years ago, when the current system was developed, basically only an on-premise environment was available, and although applications were developed from our point of view, the architecture, such as function arrangement and inter-system cooperation methods, depended on different vendors for each system, and the entire system was constructed through inter-vendor coordination. In other words, unified system development based on our concept was impossible, and as a result, there were overlapping functions between systems and complex inter-system cooperation, and as a result, restrictions on flexible data utilization. At the next generation smart meter system review meeting, it was pointed out that lower costs of renewable energy, advanced energy management, heightened interest in strengthening resilience, and furthermore, progress in introducing and expanding the distributed energy resources against the backdrop of the 2050 Carbon Neutrality Declaration etc. is expected more than ever. As a result, in next-generation power distribution platforms that aim for decentralization and multilayering, the necessity of upgrading to a new specification smart meter system has been compiled with the aim of responding to increased operation of power networks utilizing data, expansion of use of power data outside of the power sector, and diversification of transaction needs associated with the expansion of demand side resources. Based on changes in the internal and external environment, we established the Kansai Electric Power Transmission and Distribution Group Vision in August 2023, and announced our idea that we would like to continue evolving into an energy platformer that not only provides a stable supply of electricity, but also provides new value to customers and society by deepening and expanding the platforms that the transmission and distribution group has, such as network equipment, human resources and technology, and connections with customers and society all around the Kansai region. I believe that the key tool for this is a smart meter and a system for utilizing that data. Based on this background, the basic concept of a next-generation smart meter system is “unified management of data,” “consolidation of similar functions,” and “loosely coupled function arrangement that is difficult to influence each other,” and based on renewal plans for peripheral systems connected to smart meter systems, smooth transition from current smart meter systems to next-generation systems etc., a system capable of flexible and efficient operation into the future will be realized simply and at low cost It was also touted as a concept, and an RFP was carried out. To put it more simply, the system requires thorough expandability, flexibility for function development, and usability, leading to future transitions to current systems, requests for additional functions to smart meters, implementation of smooth business operations during a migration period from current to next generation systems, and furthermore, promoting cooperation between smart meter systems and peripheral systems, expanding the introduction of renewable energy, strengthening resilience, and steady response to diverse customer needs I would like to go ahead. Based on our 15 years of experience in developing and operating smart meter systems, we thought it was necessary to radically review the way we think about system development in order to realize what we are aiming for. While we understand that risk reduction can be achieved by continuing to adopt proven conventional technology, we recognize that there is a direction to correctly evaluate new technology and utilize it while controlling risk, and we believe that it is desirable to implement all systems to be built on the AWS cloud and use AWS services as much as possible, so we have begun development. The specific thoughts will be described in the next chapter and later. 3. Next Generation Smart Meter System Development Policy As introduced in the previous chapter, in next-generation smart meter systems, it is required that the usability of this system, which supports implementation flexibility and agility related to new function development, and resilience in the power transmission and distribution business, can be realized at a high level over the future, in anticipation of future systems that are currently uncertain, etc. When following the conventional way of thinking of monolithic system architectures, scaling up, function addition, and modifications require a lot of time for sizing and integrated function development, etc., and there is a tendency that restrictions on flexibility and agility of response occur. This time, we chose an approach using modern application development methods that aim to realize flexible system development while ensuring quality. By modularizing and dividing applications into smaller functional units using microservices and containers, which are important components of the idea of modern applications, we achieve scalability as a system and high flexibility and agility for future function implementation. Furthermore, by appropriately incorporating a loosely coupled architecture, the scope of influence during work or failure is limited, and the overall availability of the system is enhanced (Figure 2). Figure 2. Implementation image of loose coupling in our smart meter system Within the subsystem, attention is paid to ensuring loose coupling and scalability. Specifically, for example, data is placed in a database or S3, data transfer and reception are based on API collaboration, and an event-driven mechanism that triggers data events is adopted to achieve asynchronous inter-function collaboration. This makes it possible to simultaneously achieve fault tolerance, scalability, and flexibility even in large-scale, complex systems such as next-generation smart meter systems (Figure 3). Figure 3. Features of event-driven architectures Also, during system development, we actively utilized serverless and containers so that system vendors could focus on application development, and the basic principle was to use AWS managed services rather than individually constructed infrastructure, including databases, by system vendors. By utilizing various managed services of AWS, while ensuring scalability and security support with AWS services, we are also aiming to reduce the workload on our side by offloading the maintenance and operation of systems related to databases etc. to AWS, and the direction is to enjoy cloud benefits to the fullest (Figure 4). Figure 4. Benefits of Utilizing AWS Managed Services Furthermore, by centrally managing data on the AWS cloud, we will utilize AWS’s cutting-edge technology, such as data analytics services centered around that data lake and AI/ML services that continue to expand, and embody a path towards advanced data utilization in the future. By utilizing AWS analysis services, it is possible to determine usefulness and direction through trial and error immediately, easily, and easily from the initial stage where a need occurs without taking steps such as requirement definition, design, and construction. Use cases of meter data analysis have also been introduced on AWS (*1, Figure 5), and by referring to these, we will proceed so that we can work on data analysis and data utilization by using cutting-edge technology “when necessary, anytime, and easily” (*1) https://aws.amazon.com/jp/solutions/guidance/meter-data-analytics-on-aws/ Figure 5. Solution on AWS for Meter Data Analysis Based on this review background, we have formulated our system development policy as follows. Loosely coupled architecture enables scalability, flexibility for system development, and high availability Achieve scalability, agility, and operational optimization by utilizing managed services Utilizing AWS Data Analysis Services to Analyze and Utilize Smart Meter Data While sharing our system development policy with system vendors, we are proceeding with the development of next-generation smart meter systems on the AWS cloud. In this article, we have introduced the first three chapters regarding our efforts aimed at cloud adoption of smart meter systems. For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems at Kansai Transmission and Distribution Inc. (Part 2) — Second half ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article was contributed by Mr. Yasuo Matsuura, an executive officer, efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. The introduction will be divided into 2 parts: the first half and the second half. This article is the second half of that. The serial articles have also been published as serialized articles, so please be sure to check them out. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Examination of directions in the current smart meter systems As a response to current smart meter system issues described in “Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc.” , clouds utilization, mainly AWS, which have advanced widely as a technological trend in the IT field would be an option. By utilizing the cloud, almost all “hardware replacements” associated with running out of maintenance of server hardware, which are unavoidable in on-premise equipment, are unnecessary, and related operations are expected to be drastically reduced. Also, even in response to server enhancements associated with an increase in system load, in the case of cloud utilization, server resources can be changed simply by setting resources on the GUI, and depending on the design, there is no need to consider even scaling out the server due to the autoscaling function. Furthermore, by placing data on the cloud, various data analytics services can also be used with agility, so flexible and advanced expansion of data utilization can also be realized. Additionally, as a basis for the study, Kansai Electric Power, Inc., which is our parent company, completed research aimed at utilization and technical verification related to applicability based on trends in cloud market expansion, and as a result, decisions were made regarding the introduction and use of the cloud, such as having already decided to adopt AWS standards (*1). (*1) AWS Summit 2022 “Cloud Standardization and Guideline Formulation Initiatives Supporting Kansai Electric Power Inc’s Digital Transformation and AWS Use Cases” Partly against this background, it was a natural progression to begin investigating and examining cloud utilization in order to solve various issues in the on-premise environment in smart meter systems. Internal discussion related to cloud conversion From the background described above, it was decided to proceed with technical research and studies on the conversion of smart meter systems to the cloud, but at first, there were strong opinions within the company that felt a vague sense of anxiety about the cloud. In a situation where stable operation has been achieved over 10 years by constructing equipment on-premise and establishing business schemes, it is natural to feel uneasy about daring to choose the cloud, so we decided to proceed with a careful exchange of opinions, including pros and cons. As for a vague sense of anxiety, for example, “Is the security aspect of the cloud OK?” , “Can it also be used in core business systems?” , “Are there any concerns about business withdrawal, etc.?” , “Are there any concerns about aggressive price increases peculiar to foreign capital?” , “Is quality guaranteed?” , “Are maintenance and technical support reliable?” There were things like that. In response to vague anxiety and questions, we collected knowledge about cloud services, information related to industry trends, and examples of AWS and various companies, etc., proceeded with fact-checking, deepened the understanding of stakeholders through information sharing, and dispelled the sense of anxiety at the initial stage of the study. Also, with regard to the security aspect and the basic appropriateness of cloud utilization, a situation was fostered where awareness can be shared within the company and can be thoroughly examined and exchanged, such as “ensuring security in system construction depends on the design of cloud users and is definitely feasible,” and “even in core business systems in financial institutions and companies related to social infrastructure, there are no barriers to introduction in terms of technology,” etc. In-depth discussions on going to the cloud have progressed. For example, “How does the cloud specifically deal with the risk of intrusion from the internet?” , “Won’t disaster recovery take longer in the cloud? Isn’t disaster recovery faster with our dedicated hardware?” , “By moving the system to the cloud, network costs will remain high, and overall costs will not be high?” We discussed various questions such as these and exchanged opinions. After collecting information on each point of discussion by referring to AWS cloud implementation cases, opinions from both sides were carefully sorted out, and discussions continued in a frantic manner. As a result, there was a shared perception that in addition to security aspects, cloud can ensure quality equal to or higher than that of on-premise in terms of availability. In the study on network cost aspects, it is clear that a network linked line with the cloud would increase costs by itself, and it was clarified that there is a need for a comprehensive evaluation from the viewpoint of TCO of the entire system rather than an individual evaluation. Next, discussions moved on to choosing a cloud service, but as described above, Kansai Electric Power Inc. had already adopted AWS as a standard cloud, and as a result of a comprehensive examination of its performance evaluation, market share, cost, customer-oriented way of thinking in service development and provision, support aspects, and ease of obtaining technical information etc., we also shared our understanding in the direction of adopting AWS. Based on the discussion within the company relating to a wide range of cloud conversion as described above, internal understanding, including technical aspects, was fostered about the transition to the AWS cloud, and the direction was solidified. Regarding cost estimation and economic evaluation What I focused on and was aware of during approximate cost calculation and economic evaluation related to the migration of smart meter systems to AWS was to identify the types of “costs that increase” and “costs that decrease” with the transition to the cloud. At this time, we are referring to prior cases and achievements within the Group. In particular, as our prior example, we placed importance on the fact that by utilizing not only IaaS (Infrastructure as a Service) but also PaaS (Platform as a Service), we were able to achieve cost reduction while realizing improvements in flexibility and availability, which are advantages of the cloud. AWS managed services are a mechanism that supports this. Another aspect of the benefits of utilizing managed services is that you can enjoy a pay-as-you-go (pay only for what you use) way of thinking when using the cloud. It helped reduce costs by eliminating the need for procurement that anticipates the moment when resource consumption is maximum, such as conventional hardware batch procurement. On the other hand, there were also items that could not be fully evaluated by our desk study. Specifically, although it is possible to implement functions in the current environment directly into the cloud, there is a possibility that greater effects can be obtained in terms of cost by reviewing the implementation method itself in line with the AWS migration. Although we have organized and recognized these items, since it takes time to determine technical feasibility, including security aspects, we have decided to temporarily remove them from cost evaluation targets at the initial stage of the study. As a result of cost estimation in line with this fixed way of thinking, we were able to establish the outlook that cost advantages can always be secured. Determination of a major direction based on the initial review results Based on such a wide range of research studies on cloud conversion and internal discussion based on it, we came to a management decision on the direction of “promoting AWS migration on the premise of cost reduction” for the current smart meter system in April 2022. Establishing a Project Management formation and Accelerating Examination to the cloud 　 When promoting this project in line with the precondition of “promoting AWS migration on the premise of cost reduction,” the point of “reliably achieving economic rationality” became a very important theme in deepening AWS migration studies. In order to realize a cloud migration that can reliably ensure economic rationality, we invited AWS Professional Services from this phase to the position of proactively promoting project management in both technology and business, and we decided to accelerate project promotion by carrying out overall control over each system vendor that has jurisdiction over the subsystem from the same standpoint as our company. Since then, in promoting the project, we have clarified the basic stance and implementation policy related to the AWS migration effort, clearly message it to each system vendor, and consider and promote it based on that, so we went in and discussed with AWS Professional Services on everything from organizing the basic stance to the content of the message. In particular, we have vigorously examined policies to migrate to the cloud. For example, at the beginning of the study on migrating the current system to AWS, I thought that the idea of simply migrating servers to the cloud without putting as much effort as possible on applications and middleware would be optimal in terms of cost and lead time. However, we have come to the conclusion that it is not simply a “cloud lift” that migrates servers to the cloud, but rather the idea of a “cloud shift,” which actively utilizes managed services and optimizes the structure on AWS, can enjoy advantages unique to the cloud and secure high economic rationality, including investments related to improving maintenance and operability and ensuring availability. (Figure 1) Figure 1 Reducing the load on construction and operation by utilizing managed services In other words, we have decided to stop implementing applications that have developed their own server environments on-premise on AWS in the same way as before, and those that can be replaced with cloud services will actively switch to service use. In order to implement this implementation policy, modifications to the current system will occur. In this process, in parallel with accelerating technical studies for active adoption of managed services, we identified functional requirements that were no longer needed, sorted out and reviewed system requirements based on that, and sorted out the direction of system improvement that was conscious of the transition to next-generation systems. After clearly establishing such an implementation response policy and unifying decisions with each vendor, it was decided to step into the design phase for the cloud shift. Our examination direction on next-generation systems In parallel with the consideration of adopting AWS for the current smart meter system, the study of a next-generation smart meter system also progressed. From a system development perspective, as AWS adoption studies are progressing with the current system, the next generation did not deny this, but rather proceeded with the study in the direction of enjoying even more cloud benefits. In particular, in next-generation smart meter systems, in order to respond to environmental changes toward carbon neutrality, strengthen power resilience by flexibly utilizing data obtained from smart meters, realize further advancement of distribution grids that contribute to mass introduction of renewable energy, and further improvements in customer service are inevitable, so we believe it is essential to develop flexible systems that can steadily respond to these requirements. (Figure 2) Figure 2 Promoting Electric Power DX Using Next-Generation Smart Meters Direction of next-generation system development In order to realize the development stance for next-generation smart meter systems, internal discussions were conducted in the direction of adopting a more modern approach in system development. While steadily realizing the robust security measures required for smart meter systems and the high resilience that supports transmission and distribution business continuity, it is necessary to create a system that can respond to additional tasks and requirements anticipated in the future. In order to realize this idea, in our next-generation smart meter system, we aim to expand functions and minimize the area of influence when a failure occurs while introducing the idea of microservices and loosely connecting each component. Additionally, in order to steadily realize microservices, we have introduced a serverless architecture, utilized managed services more actively than current systems, and set out a direction aimed at reducing operational load. (Figure 3) While steadily implementing these policies, we aim to realize an even more robust and flexible smart meter system by fully utilizing cutting-edge technology in cloud services. Based on these ideas and policies, our next generation smart meter system development project is still underway. Figure 3. The direction of our smart meter system development Migrations of our current systems and next-generation systems Finally, I will mention future prospects for current systems and next-generation systems. As of 2025, our smart meter system is scheduled to run in parallel with the current system and the next-generation system. This direction was based on the fact that the characteristics required for each are different, and that they aim to improve customer service by quickly utilizing next-generation smart meters. Meanwhile, we will consider reducing TCO, including operating load etc., and aim to migrate current systems to next-generation systems at an early stage. Even in examining the direction of migration, we have examined the current system by incorporating the idea of “cloud shift” which optimizes the system on AWS by actively utilizing managed services, rather than a “cloud lift,” so we have come to see the feasibility of a system that takes into consideration the smooth degeneration of the current system with an eye on the transition to a next-generation system. Conclusion In this article, I have introduced the overall picture of discussions on cloud utilization in our smart meter systems. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” is also published, so please be sure to check it out as well. Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000’s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

This article was contributed by Mr. Yasuo Matsuura, an executive officer, efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. The introduction will be divided into 2 parts: The first half and the second half. This article is the first half of that. The serial articles have also been published as serialized articles, so please be sure to check them out. Article #2 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 2) — First half ” Article #3 “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Part 3) — First half ” Introduction Kansai Transmission and Distribution Inc. (hereafter, our company) inherited the general transmission and distribution business from The Kansai Electric Power Co, Inc. in April 2020 in line with the revision of the Electric Power Business Law to ensure even greater neutrality in the transmission and distribution business, and commenced operations. In the process of depicting what our company aims for in the future and working company-wide on digital transformation (DX) where we transform ourselves toward that form, we have now decided to develop a smart meter system centered on the cloud, which is the first in Japan (*1). We plan to blog about this initiative in a trilogy series as a whole. This time, as the first part, I will tell you about the progress of internal discussions leading up to decisions related to cloud and AWS adoption in smart meter systems. From the next session onwards, I will introduce specific directions and initiatives for next-generation smart meter systems that assume the use of AWS, and the situation of solving issues related to the cloud shift of current smart meter systems (*2). (*1) “ We have decided to develop a cloud-centered system for the first smart meter system in Japan (Japanese) ” (our website,2023/3/31) (*2) The installation of our current smart meter was completed in March 2023. After that, as the validity period (10 years) of current smart meters gradually expires, replacement with next-generation smart meters is scheduled to begin in 2025. Figure 1 Excerpt from our company’s press release What is a smart meter system A smart meter system is a system that collects and stores customer electricity usage remotely, automatically, and regularly via a communication network, and consists of a smart meter, a communication network, a system that manages the collected data (meter data collection/management system), and a system (business system) that is responsible for operations related to electricity usage. A smart meter consists of a metering unit that measures and records the customer’s electricity usage and a communication unit that transmits the measured electricity usage data to a higher-level server. (Figure 2) Figure 2 What is the smart meter system Not only has significant progress been made from the previous generation meter once a month to remote/automatic meter reading every 30 minutes, but by transmitting electricity usage data from smart meters to terminal devices (home energy management systems, building energy management systems, etc.) in the customer’s home, it is possible to grasp the time periods when electricity usage is high, etc., and achieve more effective energy saving It became. The introduction of next-generation smart meter systems with revised specifications and improved functionality is scheduled to begin in 2025 compared to the current smart meter system, which was introduced in the first half of the 2010’s and is expected to be completed in all households throughout Japan in early 2020’s. Moreover, that smart meters are the accuracy and the appropriateness as metering devices are guaranteed by the certification, and since the validity period of this certification is 10 years, it will basically take 10 years to replace all meters with smart meters. Implementation history and actual situation We have been proceeding with research and development of communication systems since the late 1990’s, with the aim of improving the efficiency of operations around measuring instruments. This development concept later became a general-purpose concept called a smart meter. At that time, running costs for communication networks such as mobile phone systems were high, so the major issue was how to build a communication network with connectivity and high reliability, using self-operated communication networks as the main focus. Also, at that time, analog measuring instruments called mechanical ones were the mainstream. In 2005-2006, when a certain level of research and development aimed at making measuring instruments smart was established, discussions were held within the company, and full-scale studies aimed at making smart meters began. At that time, the term “smart meter” did not exist, and within our company, smart metering systems were called “new metering systems” and development was promoted. At that time, it was natural to visually check the meter’s display and meters, and to work on the meter side for connection/disconnection associated with moving etc., but since these operations changed drastically due to being replaced by a new metering system, dozens to one hundred dozen internal stakeholders went through one place, accumulated discussions, and repeated discussions decided the desired form of work one by one. Based on these discussions, as for system development, development vendors were decided in 2006, system requirements were also determined, development with each vendor was carried out in 2007, multi-vendor tests from communication networks to systems were carried out at the end of the same year, trial implementation began in April 2008, and full implementation began in 2012. At the beginning of implementation, we faced many new issues, such as communication congestion events in communication networks that could not be anticipated at the time of development, and we faced great hardships, but by resolving them, we steadily improved the reliability of the new metering system. After that, momentum for the introduction of smart meters increased throughout Japan, and full-scale implementation by the 10 electric power companies at the time began in 2014, and was gradually developed, and we completed the introduction of all households in March 2023. Until now, we have been actively working to realize safe and reliable meter reading work, improve convenience for customers, and rationalize the configuration of power distribution equipment based on accumulated electricity usage data by utilizing smart meter systems. Utilization of electricity usage data We began full implementation of smart meters in 2012, and completed the introduction to all households in March 2023. We have been working on utilizing electricity usage data collected every 30 minutes from the beginning of implementation, and we have promoted data utilization in a practical manner, such as the normalization and rationalization of power distribution equipment. On the other hand, as described later, there was not the concept of a cloud system at the time of development, so an on-premise data collection system is being built in the current smart meter systems. For this reason, there were issues with the scalability of server systems to accommodate smart meters that are gradually expanding. Furthermore, detailed specification adjustments between vendors associated with system construction by multiple vendors are necessary, and furthermore, since it is composed of vendor-specific specifications, there are issues with flexible data extraction and processing according to needs, and there were hurdles in realizing thorough data utilization. In this situation, based on recent heightened interest in strengthening resilience and progress in the introduction and expansion of the distributed energy resources, starting with renewable energy etc., the Agency for Natural Resources and Energy established a next-generation smart meter system review meeting in September 2020 as a forum for discussions on advanced use of smart meter systems, and new specifications of smart meter systems suitable for the carbon neutral era and new functions that should be provided It was discussed and examined. Based on current system issues and discussions at the Next Generation Smart Meter System Review Meeting, we have decided to realize both the current system and next-generation system with a full cloud based on AWS, with the aim of improving service levels and social resilience for customers using power networks by flexibly utilizing data obtained from smart meters, and improving social resilience. (Figure 3) Figure 3 Full Cloud Transition of Current and next-generation system The scope of our smart meter systems on this article The overall overview of smart meter systems, as shown in Figure 2, generally consists of smart meters installed in each home, communication networks, data centers that collect and store data, and various business systems that are responsible for related tasks. This article focuses on systems configured on AWS, so in this article, as shown in Figure 4, the head end system (Head End System) is responsible for collecting data from smart meters among smart meter systems.(Hereafter, HES), and meter data management systems (Meter Data Management Systems), which are responsible for utilization of collected data and meter management. (The description is specific to MDMS) below. For this reason, unless otherwise indicated, only HES and MDMS are described as smart metering systems in this article. Figure 4 The smart metering system covered in this article Our challenges of the current smart meter systems Since the term “smart meter” did not exist, we have been promoting development by calling it a new metering system. As there is currently no smart meter package software, etc., we have received cooperation from multiple system vendors and have been searching for system configurations and function arrangements through trial and error. As a result, we have succeeded in implementing the system by configuring a system with vendor-specific technology and specifications in an on-premise environment. Since the start of operation of this system, the server scale has continued to expand gradually along with the increase in the number of smart meters installed, while continuous stable operation has been achieved. Our current smart meter systems are facing issues such as economic efficiency and future sustainability issues associated with adopting proprietary OS, commercial databases, and middleware, system blackboxing, and concealment of business processing logic against the backdrop of centralized outsourcing to system vendors due to systems created through these situations. These issues have become extremely important issues for our company, which aims to make advanced use of the huge amount of electricity usage data collected after 100% implementation of smart meters has been completed. Also, in contrast to smart meters, which are being introduced and expanded over 10 years, it was also a major issue that the number of servers increased as the capacity increased, related OS and middleware were out of maintenance, license updates, and server replacement work occurred every year. Regarding these issues, verification work etc. occurred each time, so there were not only economic issues, but also an issue where the workload of members involved in our server maintenance relationship was increasing. Furthermore, in recent years, various issues, including future uncertainty, have become apparent, such as delays in server hardware procurement delivery due to semiconductor exhaustion. Conclusion This article, we have introduced our efforts aimed at cloud adoption of smart meter systems, “up to issues with current smart meter systems.” For the latter half, please see “ Contribution: Introduction of efforts aimed at cloud adoption of smart meter systems by Kansai Transmission and Distribution Inc. (Second half). ” Author Yasuo Matsuura Executive Officer (Power Distribution Department, Information Technology Department), Kansai Transmission and Distribution Inc. Since the early 2000s, he has been involved in technology development for communication media applied to next-generation distribution networks, and has been in charge of smart meter system development and implementation projects since 2010. Based on this experience, they investigated and presented issues related to data utilization from the overall picture of smart meter systems at domestic and international venues, such as setting up a working group on smart meter data utilization at CIGRE (International Council on Large Electric Systems), and contributed to raising awareness of smart meters in Japan as an important key device essential for realizing a decarbonized society, improving resilience and improving efficiency. In 2020, I participated as a committee member in the next-generation smart meter system review meeting that was resumed under the call of the Agency for Natural Resources and Energy, and led discussions on the structure, function, performance, etc. required for next-generation smart meters by utilizing the experience of introducing current smart meters and knowledge from foreign surveys. In fiscal 2022, in addition to completing the introduction of all of the company’s current smart meters, a next-generation smart meter system concept that could be a data platform was drawn up, and the company promoted studies. This article was translated by AWS Blake Horike, Riho Matsui, and Satoshi Aoyama.

本ブログは 2025 年 11 月 25 日に公開された「 AWS achieves ISO/IEC 42001:2023 Artificial Intelligence Management System accredited certification 」を翻訳したものになります。 アマゾン ウェブ サービス（AWS）は、主要なクラウドサービスプロバイダーとして初めて、AI サービスに対する ISO/IEC 42001 認証を取得したことをお知らせします。対象となるサービスは、 Amazon Bedrock 、 Amazon Q Business 、 Amazon Textract 、および Amazon Transcribe です。 ISO/IEC 42001 は、組織が AI システムの責任ある開発と使用を促進するための要件とコントロールを概説した国際的なマネジメントシステム規格です。 責任ある AI は、AWS の長期にわたるコミットメントです。当初から、AWS は責任ある AI イノベーションを優先し、公平さ、説明可能性、プライバシーとセキュリティ、安全性、制御性、正確性と堅牢性、ガバナンス、透明性を考慮して AI サービスを構築・運用するための厳格な方法論を開発してきました。 AWS はグローバル標準を策定する組織と積極的に協力するステークホルダーです。開発するガイドラインは、明確さ、定義、スコープを改善し、責任ある AI の実践のベンチマークを確立し、リスクに対処するための効果的なオプションに業界の取り組みを集中させることで重要な役割を果たします。私たちのゴールは、リスク管理、データ品質、望ましくないバイアスの緩和、説明可能性など、いくつかの重要な領域で AI 規格の改善に貢献することです。 ISO/IEC 42001 のような技術的な規格は、責任ある AI の開発と展開のための共通的なフレームワークを提供し、ますますグローバル化し AI ドリブンな技術環境における信頼性と相互運用性を育むために重要です。ISO/IEC 42001 認証を取得したということは、AWS が AI の開発、展開、運用に関連するリスクと機会を管理するために積極的な措置を講じていることを、独立した第三者が検証したことを意味します。この独立した検証により、お客様は AWS の責任ある AI へのコミットメントと、AWS サービスを使用して責任を持って AI アプリケーションを構築・運用する能力について、さらに確信を持てるようになります。 Snowflake 社の米国公共部門の VP である Tim Tutt 氏は次のように述べています。「Snowflake では、お客様に AI 機能を提供することが最優先事項です。私たちの製品チームは、責任を持って AI を構築・展開する必要があり、技術的な複雑さがあるにもかかわらずサプライヤーにも同様のことを期待しなければなりません。これが ISO 42001 が私たちにとって重要である理由です。ISO 42001 認証を取得しているということは、その企業が思慮深い AI マネジメントシステムを実装していることを意味します。AWS が ISO 42001 認証を取得したサービスを提供していると知ることで、AWS のサービスの責任ある開発と展開へのコミットメントに自信を持つことができ、私たち自身のお客様への信頼に繋がります」。 ISO/IEC 42001 のような認証は、国内または国際的な認定機関によって認められた認証機関によって発行されます。これは、その認証が信頼でき、独立した検証に基づいていることを示しています。今回の場合、ANSI National Accreditation Board（ANAB）によって認定された ISO 認証機関である Schellman Compliance, LLC が認証を付与しました。 本ブログはプロフェッショナルサービス本部の藤浦 雄大が翻訳しました。

このブログでは、テクノロジーリーダーやフロントエンド、フルスタック、バックエンドの開発者にとって最もエキサイティングなセッションを紹介します。セッションは、中級（200）から上級（400）レベルの内容で、インタラクティブなチョークトーク、ハンズオンワークショップ、コードトーク、講義形式のブレイクアウトセッションを組み合わせたものとなっています。TypeScript、JavaScript、iOS、Android、React Native、Flutter などの開発者がアプリケーションを構築し、テストする際に役立つ最新の AWS ツール、サービス、機能を取り上げます。参加者は、フロントエンド開発者のためにクラウドでの開発者体験がどのように見直されているのかを知り、あらゆる規模のビジネスを強化する方法を発見し、フルスタック AI が Web 開発の未来をどのように形作っているかについての洞察を得ることができます。 AWS re:Invent とは AWS re:Invent はグローバルなクラウドコンピューティングコミュニティのための学習カンファレンスです。このイベントは 2024 年 12 月 2 日 ~ 12 月 6 日まで開催されます。リアルイベントでは、エキサイティングなキーノートアナウンス、ネットワーキング、トレーニング、認定資格の機会、2,000 を超えるテクニカルセッション、 Vendor Expo 、楽しい夜のイベントなどが用意されています。 AWS re:Invent 2024 の開催地 re:Invent がネバダ州ラスベガスに戻ってきました! 会場、ホテル、周辺情報については キャンパスページ をご覧ください。現地に行けない場合はオンラインで参加するのがお勧めです。キーノート、イノベーショントークのライブストリーミング、ブレイクアウトセッションへのアクセスなどがオンラインで体験できます。オンライン re:Invent の詳細や登録は、 登録ページ をご覧ください。 フロントエンド Web &amp; モバイルアプリ ブレイクアウトセッション ブレイクアウトセッションとは AWS re:Invent のブレイクアウトセッションは講義形式で 60 分間行われます。ブレイクアウトセッションは AWS の専門家が講演を行い、通常最後の 10 〜 15 分間が質疑応答の時間に充てられます。ブレイクアウトセッションは録画され、イベント後にオンデマンドで視聴できるようになります。 中級 — レベル 200 FWM202 | &nbsp; Fullstack AI with AWS Amplify Generative AI はフルスタック開発を変革しています。このセッションでは、AWS Amplify、Amazon Q、Amazon Bedrock がどのように連携して、Generative AI アプリの構築を合理化するかを学びます。Amplify が Amazon Bedrock によってサポートされた、インテリジェントサーチ、要約、コンテンツ生成、対話型チャットボットなどの AI 主導の機能を開発者が構築できるようにする方法を確認します。また、Amplify と Amazon Q を使用すれば、開発プロセスを加速できることも示します。 日時: 12 月 2 日 (月)&nbsp; 15:00 – 16:00 &nbsp;(PST) 場所: Mandalay Bay | Lower Level North | Islander&nbsp;G FWM203 | &nbsp; I didn’t know AWS AppSync could do that! AWS AppSync は、アプリをクラウドのデータ、イベント、AI モデルに接続するための開発者向けの管理サービスです。もはや GraphQL API サービスだけではなく、AWS AppSync を使えば、サーバーレス WebSockets を利用してリアルタイムイベント API を作成したり、Amazon Bedrock への安全なアプリケーションアクセスを簡素化するための AI ゲートウェイを構築したりできます。今年リリースされた AWS AppSync の新機能についてお話しますので、ぜひご参加ください。 日時:&nbsp; 12 月 2 日 (月) 13:30 – 14:30&nbsp;(PST) 場所: Mandalay Bay | Lower Level North | South Pacific E | Purple FWM204 | Optimizing the world’s top apps: How Meta tests using AWS Device Farm このセッションでは、AWS Device Farm を使ってリアルデバイスでのテストを大規模に実行することで、モバイルアプリおよび Web アプリの品質を向上させる方法を学びます。主要なソーシャルメディア企業である Meta から、同社が Device Farm を活用してモバイルアプリのテストプロセスの合理化、モバイルアプリと SDK の品質向上、クラウド上のリアルデバイスでの自動テストと手動テストの実行、課題の特定と修正の迅速化、更新リリースの頻度向上を図っている事例を聞いていただけます。 日時: 12 月 4 日 (水) 10:30 – 11:30 (PST) 場所: MGM Grand | Level 1 | Grand 119 FWM205 | Startup to enterprise: Build frontend and fullstack apps that scale AWS Amplify は、プロの開発チームに対して、エンドツーエンドの経験と検証済みのパターンを提供し、AWS インフラストラクチャの速度と信頼性を活かしてプロダクティビティを加速し、構築することを可能にします。組織の成長を妨げることのないアプリを構築するために、Amplify に組み込まれたこれらのパターンと、CDK で AWS バックエンドをカスタマイズする Amplify の柔軟性を活用する方法を学びましょう。このセッションでは、実際のシナリオのウォークスルーを行い、AWS 上でセキュアで拡張性があり、クラウドに接続されたアプリケーションを構築、デプロイ、ホストすることをこれまでにないほど容易にする、Amplify の新しいエンタープライズ重視の機能をご紹介します。 日時: 12 月 4 日 (水) 16:30 – 17:30&nbsp;(PST) 場所: MGM Grand | Level 1 | Grand 116 上級（レベル 300 ） FWM302 | Real-time event patterns with WebSockets and AWS AppSync AWS AppSync は、開発者がリアルタイムデータの更新やイベント (ライブスポーツのスコアや統計、グループチャットのメッセージ、価格、または位置情報やスケジュールの更新など) を消費するアプリケーションを構築するのを容易にします。AWS AppSync の管理対象の WebSocket チャネルを使えば、数百万人のユーザーに接続して数十億単位のメッセージを配信するのを簡単にスケーリングできます。このセッションでは、PGA ツアーなどの組織が、AWS AppSync を利用して実時間のイベント更新をアプリユーザーに配信する方法を学びます。さらに、拡張されたフィルタリングオプションや Amazon EventBridge との組み込み統合などの新機能の概要も説明します。 日時:&nbsp; 12 月 2 日 (月) 8:30 – 9:30 (PST) 場所: MGM Grand | Level 3 | Chairmans 370 FWM310 | Build an AI gateway for Amazon Bedrock with AWS AppSync 生成 AI をアプリケーションに統合することは複雑で、開発者は AI バックエンドにアクセスする際に、複雑な権限、公開された認証情報、ID 管理の課題に対処する必要があることが多くあります。このセッションでは、AWS AppSync を使用して Amazon Bedrock などの AI バックエンドとの統合を簡素化する方法、ユースケースに合わせてクエリをカスタマイズする方法、本番利用可能な API をデプロイするためのセキュリティ機能を活用する方法、生成 AI リソースへのアクセスを制御する方法について説明します。これは、同期および非同期のユースケースの両方をカバーします。 日時: 12 月 2 日 (月) 10 :30 – 11:30 (PST) 場所: Wynn | Level 1 | Lafite 4 | Content Hub | Orange Screen FWM311 | What’s new in AWS for frontend developers AWS Amplify は、フロントエンド Web およびモバイル開発者が最小限のクラウドの専門知識で数時間でフルスタックアプリケーションを構築できるようにしています。このセッションでは、認証、データ、ストレージで簡単にバックエンドを構成する方法、フロントエンド UI を作成する方法、Next.js で サーバーサイドレンダリングの Web アプリをホストする方法など、Amplify の機能を紹介します。開発者とチームがイノベーションのペースを加速し、データを活用して差別化されたアプリケーション体験を構築し、リモートワーク環境でも個々のエンジニアが開発しやすくなる、興味深い新機能についても学びます。 日時: 12 月 4 日 (水) 13:30 – 14:30 (PST) 場所: MGM Grand | Level 1 | Grand 122 DEV304 | Build a cloud-powered cross-platform app with AWS Amplify AWS Amplify は、AWS 上でフルスタックアプリケーションを構築するための開発者体験を再構想しました。Amplify の次世代バックエンド構築体験では、すべての フロントエンドとバックエンド定義を TypeScript で記述することができます。これにより、コーディング中にスキーマの検証、入力補完、エンドツーエンドの型付けが可能になります。また、開発者ごとのクラウドサンドボックスや他の多くのツールや機能も利用できます。このセッションでは、AWS Amplify の次世代、バックエンド構築方法、AWS CDK を利用した Amazon Bedrock などの生成 AI サービスを含む他の AWS サービス拡張方法について学びます。 日時: 12 月 5 日 (木) 13:00 – 14:00 (PST) 場所: Mandalay Bay | Level 2 South | Mandalay Bay Ballroom L | Content Hub | Orange Screen DEV305 | Building an educational startup on AWS: A heroic journey クラウドの世界を旅するふたりの AWS の英雄の物語をご覧ください。目標は、AWS で AWS の教育プラットフォームを構築してデプロイすることです。彼らは、Amazon Cognito での MFA の開発、AWS Amplify の利用、AWS WAF によるセキュリティ強化、Amazon DynamoDB でのユーザー持続化、Amazon API Gateway での要求処理、AWS Lambda と Powertools を使ったビルドなど、さまざまな丘や谷を案内します。冒険家たちがその任務に成功したのか、それとも最後に全然違うところに辿り着いて諦めてしまったのか、ぜひお確かめください。 日時: 12 月 3 日 (火) 13:00 – 14:00 (PST) 場所: MGM Grand | Level 1 | Grand 120 フロントエンド Web &amp; モバイルチョークトーク チョークトークとは チョークトークは小人数を対象とした、非常にインタラクティブなセッションです。専門家が議論の流れに応じてデジタルホワイトボードに問題と解決策を説明していきます。各セッションでは、最初に AWS の専門家が 10 ~ 15 分の短い講義を行い、その後 45 ~ 50 分の質疑応答セッションで参加者との議論が行われます。 中級者向け FWM201 | Deliver reliable generative AI mobile apps: A testing architecture このチョーク・トークでは、AWS Device Farm の力を活用して、モバイルテストの戦略を変革する方法を見つけましょう。Adobe は、Device Farm を使って、AI 対応アプリをテストするための標準化されスケーラブルなモバイルテストフレームワークを構築する方法を共有します。次のことを学びましょう。物理デバイスを所有または管理しなくても、さまざまな iOS と Android デバイス間でテストを実行できる方法。テスト パイプラインに新しいアプリを導入する時間を短縮する方法。アプリの機能、パフォーマンス、リソース使用状況についての洞察を得る方法。 日時: 12 月 4 日 (水) 17:30 – 18:30 (PST) 場所: MGM Grand | Level 1 | Boulevard 167 FWM206 | Accelerate frontend delivery with AWS Amplify Hosting このセッションでは、AWS Amplify Hosting がいかに高パフォーマンス、信頼性、スケーラビリティの高い Web 体験をより早く提供するためのサポートを行えるかを探ります。Amplify Hosting は、Next.js などの一般的な開発フレームワークをサポートする、完全マネージド型のホスティングサービスです。CI/CD 機能、フレームワークとの統合、スケーラブルなインフラストラクチャを活用して、品質を落とすことなく Web アプリケーションを迅速に提供できます。組織がイノベーションをより早く行えるよう、モダン Web 開発のベストプラクティスと手法について説明します。AWS Amplify Hosting を使用して、静的レンダリングやサーバーサイドレンダリングのフロントエンドアプリを手軽に構築、デプロイ、スケーリングするための知識を得られます。 最初のセッション 日時: 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所: Wynn | Convention Promenade | Lafleur 2 リピート 日時: 12 月 4 日 (水) 8:30 – 9:30 (PST) 場所: Caesars Forum | Level 1 | Academy 411 レベル 300 — 上級者向け FWM301 | Go from idea to AI-powered app in minutes with AWS Amplify AWS Amplify は最近、AWS 上で本番環境に向けたアプリケーションを構築するための完全な TypeScript 機能を備えた第 2 世代の開発者エクスペリエンスを発表しました。第 2 世代は AWS Cloud Development Kit (AWS CDK) 上に構築されており、生成 AI ユースケースのための Amazon Bedrock を含む 200 を超える AWS サービスをすべて Amplify アプリケーションに追加できるようになりました。このチョークトークでは、AWS CDK と Amazon Bedrock を使って、次世代の革新的なアプリケーションエクスペリエンスを作成するための戦略について議論します。Amplify のフルスタック TypeScript 機能を拡張する方法についても扱います。 最初のセッション 日時: 12 月 2 日 (月) 10:30 – 11:30 (PST) 場所: Wynn | Convention Promenade | Latour 5 リピート 日時: 12 月 4 日 (水) 9:00 – 10:00&nbsp; (PST) 場所: Caesars Forum | Level 1 | Forum 126 FWM314 | AWS Amplify: Integrating data sources, authentication &amp; AWS services AWS Amplify の最新のアップデートで、フルスタックアプリケーションの機能を拡張しましょう。このチョークトークでは、Amplify が幅広い既存のデータソース、認証プロバイダー、AWS インフラストラクチャとシームレスに統合できることを探ります。Amplify が持つデータモデリングと API 生成機能を活用し、Amplify で開発したアプリケーションを PostgreSQL や MySQL データベースに接続することができます。任意の OpenID Connect (OIDC) または SAML プロバイダーでユーザー認証を行うこともできます。AWS CDK を使えば、Amazon S3 バケットや Amazon DynamoDB テーブルなどの Amplify リソースをカスタマイズすることができ、プロジェクトにカスタム AWS リソースを追加することもできます。 日時: 12 月 2 日 (月) 16:30 – 17:30 (PST) 場所: Caesars Forum | Level 1 | Forum 126 FWM315 | Build a BFF API layer for your AI models, data, and events AWS AppSync を使えば、複数のデータベース、マイクロサービス、イベント、AI モデルを 1 つの backend-for-frontend (BFF) endpoint に統合できます。このチョークトークでは、AWS AppSync を使って Amazon Bedrock、Amazon SageMaker、サードパーティのモデルの使用を管理・調整する単一の API エンドポイントを作成する方法に焦点を当てています。これにより、アプリケーション開発者はユースケースに合わせて適切なモデルを簡単にアクセスでき、新しいモデルが登場した際にもすばやく切り替えられます。また、同じエンドポイントを拡張してエンタープライズデータやイベントを AI のプロンプトとレスポンスに取り入れる方法も学べます。 日時: 12 月 4 日 (水) 15:00 – 16:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 305 FWM316 | Fullstack deployment strategies for teams of all sizes AWS Amplify は最近、Gen 2 の開発者体験を発表し、AWS で本番環境に対応したアプリケーションを構築するための、TypeScript を全面的にサポートしたフルスタック開発の機能を提供しています。Gen 2 は AWS CDK 上に構築されており、Amplify アプリに 200 以上の AWS サービスを追加できるようになっており、生成 AI 用途では Amazon Bedrock を追加できます。このチョークトークセッションでは、異なる Git 戦略、モノレポとマルチレポ、複数の AWS アカウントで Amplily フルスタックの TypeScript 機能を拡張する戦略について議論します。 日時: 12 月 4 日 (水) 12:00 – 13:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 305 フロントエンド Web &amp; モバイルワークショップ ワークショップとは ワークショップは、AWS のチームが設計したハンズオン形式のセッションです。ワークショップの目的は、ビジネスの問題を解決するのに役立つ、実践的なスキル、手法、コンセプトを教えたり、紹介したりすることです。 上級編 FWM303 | Build server-side rendered (SSR) apps with AWS Amplify and Next.js Next.js は フロントエンドおよびフルスタック Web 開発者に最適な、サーバーサイドレンダリング (SSR) React フレームワークとして勢いを増しています。このワークショップに参加し、新しい AWS Amplify Gen 2 の開発体験で、Next.js アプリケーションを開発およびデプロイする方法を学んでください。ラップトップをご持参ください。 最初のセッション 日時: 12 月 4 日 (水) 16:00 – 18:00 (PST) 場所: MGM Grand | Level 1 | Grand 111 リピート 日時: 12 月 5 日 (木) 15:00 – 17:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 FWM306 | Building GraphQL APIs with AWS AppSync 本ワークショップでは、GraphQL API の開発を簡単にする、フルマネージドサービスの AWS AppSync の機能について学びます。AWS AppSync が Amazon DynamoDB、Amazon Bedrock、AWS Lambda などのデータソースへのセキュアな接続の重荷を処理する方法を学びます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 15:30 –&nbsp; 17:30 (PST) 場所: Caesars Forum | Level 1 | Summit 216 FWM308 | Go from idea to app in hours using AWS Amplify and Amazon Q Developer AWS Amplify と Amazon Q Developer を使えば、フルスタックアプリをアイデアから現実のものへと、より早く作り上げることができます。このワークショップでは、AWS Amplify を使ってフルスタックアプリを構築・デプロイし、Amazon Q Developer がどのようにソフトウェア開発ライフサイクル全体を加速するかを確認します。このワークショップを終えると、クラウドに接続されたアプリケーションの構築と立ち上げ方法を習得できます。ラップトップをご持参ください。 最初のセッション 日時: 12 月 4 日 (水) 8:30 – 10:30 (PST) 場所: MGM Grand | Level 1 | Grand 113 リピート 日時: 12 月 5 日 (木) 12:00 – 14:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 FWM309 | Build real-time applications with AWS Amplify &amp; AWS AppSync WebSockets リアルタイムデータを利用してユーザーエンゲージメントを高めるアプリケーションの作成方法を学びます。このワークショップでは、ライブスコア更新とグループチャット機能を備えたマルチプレイヤー形式の簡単なクイズゲームアプリを構築します。AWS Amplify を使用してフロントエンドアプリケーションを AWS AppSync WebSockets で構築されたサーバーレスバックエンドに接続します。ラップトップをご持参ください。 日時: 12 月 4 日 (水) 12:30 – 14:30 (PST) 会場: Wynn | Upper Convention Promenade | Cristal 1 FWM313 | Test your web and mobile applications with AWS Device Farm AWS Device Farm は、デスクトップブラウザやリアルモバイルデバイスの広範な種類の上で、アプリケーションをテストできるサービスです。このサービスを利用することで、テストインフラを自前で用意したり管理したりすることなく、幅広いデスクトップブラウザや実際のモバイルデバイスでウェブアプリケーションやモバイルアプリケーションをテストでき、アプリケーションの品質向上に役立ちます。このワークショップでは、ソフトウェアエンジニア、品質保証エンジニア、ソフトウェアテスター、プラットフォームエンジニア、アーキテクトの方々に、AWS クラウドでホストされたアプリケーションをテストするための Device Farm の使い方をハンズオンで学んでいただきます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 8:00 – 10:00 (PST) 場所: MGM Grand | Level 3 | Premier 312 ENU314 | Bring AWS IoT SiteWise visualizations into web applications AWS IoT SiteWise Monitor を使用すると、AWS IoT SiteWise で監視するアセットの測定値を視覚化するためのポータルやダッシュボードを構築できます。AWS IoT Application Kit は、産業用 IoT Web アプリケーションを構築するための開発ライブラリで、AWS IoT SiteWise や AWS IoT TwinMaker からデータを取得するのに役立ち、フロントエンド用のコンポーネントやユーティリティを提供します。このワークショップでは、AWS Amplify と React で Web アプリケーションを構築し、AWS IoT Application Kit のコンポーネントを使用して AWS IoT SiteWise に接続し、テレメトリデータのライブ視覚化をアプリケーションに組み込みます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 8:30 – 10:30 (PST) 場所: Wynn | Convention Promenade | Margaux 2 ビルダーセッションとは これらの 60 分のグループセッションは AWS のエキスパートが主導し、AWS での構築に向けたインタラクティブな学習体験を提供します。ビルダーセッションは、質問を歓迎する実践的な体験を作ることを目的としています。 上級者向け 300 レベル FWM304 | Build generative AI applications with full-stack TypeScript AWS Amplify の TypeScript ベースの開発者体験を使って、パワフルな生成 AI Web アプリケーションを構築しましょう。このハンズオンビルダーのセッションでは、インテリジェントサーチ、要約、コンテンツ生成、対話型 AI アシスタントなどの AI 駆動型の機能を構築します。データ管理とユーザー認証を含むコアとなるアプリケーションコンポーネントとの統合方法を学びます。セッションの最後には、完成したアプリケーションをクラウドにデプロイし、フルスタック AI アプリケーションの開発と起動の実践的な経験を得ることができます。ラップトップをご持参ください。 最初のセッション 日時 : 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所 : Caesars Forum | Level 1 | Alliance 311 リピート #1 日時: 12 月 5 日 (木) 11:30 – 12:30 (PST) 場所: Mandalay Bay | Level 2 South | Surf E リピート #2 日時: 12 月 5 日 (木) 15:30 – 16:30 (PST) 場所: Mandalay Bay | Level 2 South | Surf B FWM305 | Best practices for creating and testing cross-platform apps on AWS 異なるコードベースを維持する手間をかけずに、Android、iOS、Web アプリケーションの開発方法を学びます。AWS Amplify の React Native ライブラリを使用し、クラウドサポートされた機能豊富なアプリケーションを作成します。認証、API およびデータの連携、生成 AI、メディア/ファイル格納などの機能を追加する方法を学びます。また、AWS Device Farm でアプリケーションをテストします。ラップトップをご持参ください。 最初のセッション 日時: 12 月 2 日 (月) 9:00 – 10:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 311 リピート #1 日時: 12 月 3 日 (火) 12:00 – 13:00 場所: Caesars Forum | Level 1 | Summit 232 | Content Hub | Builder’s 2 リピート #2 日時: 12 月 5 日 (木) 14:00 – 15:00 (PST) 場所: Mandalay Bay | Level 2 South | Surf B NTA308 | Build a secure GraphQL with AWS AppSync このセッションでは、AWS Amplify Studio と AWS AppSync を使用して、セキュアでスケーラブルな GraphQL API を構築する方法を学びます。まず GraphQL ベースのアーキテクチャの利点とアプリケーション開発の簡素化にどのように役立つかを確認します。次にハンズオンセッションで、参加者自身の GraphQL API の作成、認証と認可の設定、プロダクション環境へのデプロイを行います。ラップトップをご持参ください。 最初のセッション 日時: 12 月 2 日 (月) 13:00 – 14:00 (PST) 場所: Caesars Forum | Level 1 | Alliance 315 リピート 日時: 12 月 3 日 (火) 17:30 – 18:30 (PST) 場所: Caesars Forum | Level 1 | Summit 232 | Content Hub | Builder’s 1 ARC301 | Rapidly build a generative AI-based full-stack application on AWS フルスタックアプリケーションを構築するには、複数のコンポーネントと、幅広い技術スキルとツールが必要です。これは経験豊富な開発者にとっても非常に困難で時間がかかる作業です。このビルダーセッションでは、生成 AI ベースのデジタルトレーニングプラットフォームを迅速に構築する戦略を探ります。新しいコードファーストの開発者体験 AWS Amplify Gen 2 とオープンソースのデザインライブラリ Cloudscape を組み合わせ、フルスタックアプリケーションを迅速に構築してデプロイします。Amazon Bedrock の優れた機能を使用して、プラットフォームにアップロードされたコンテンツの概要を生成します。実用的な e-ラーニングプラットフォームの構築とデプロイ方法を学びます。ラップトップをご持参ください。 日時: 12 月 2 日 (月) 14:30 – 15:30 (PST) 場所: Caesars Forum | Level 1 | Alliance 315 ライトニングトークとは ライトニングトークは、ステージ上で行われる短い 20 分間のデモです。 AIM246 | Securing AI-driven applications with Auth0 by Okta and Amazon Bedrock 今日のデジタル環境では、アプリケーションのセキュリティ確保が不可欠です。この講演では、開発者が Okta の Auth0 の ID 管理ソリューションを Amazon Bedrock と併用して、セキュアなアプリケーションを構築、スケーリングする方法を解説します。Auth0 の認証、認可、ユーザー管理機能を Amazon Bedrock のセキュア基盤にどのように統合するかについて説明します。また、AWS Amplify がフロントエンドとバックエンド サービスを堅牢な ID 管理機能と統合して開発を簡素化する方法についても触れます。クラウド上で効率的にモダンでセキュアなアプリケーションを構築するための、主要なユースケース、ベストプラクティス、技術的な統合について実践的な知識を得ることができます。このセッションは AWS のパートナーである Okta 様にご登壇いただきます。 日時: 12 月 3 日 (火)&nbsp; 10:30 – 10:50 (PST) 場所: Venetian | Hall B | Expo | Theater 1 コードトークとは コードトークは 60 分間の、ハイレベルなインタラクティブディスカッションで、実際にコーディングを行います。参加者は、スピーカーのアプローチについて質問したり、掘り下げたりすることが推奨されています。 Level 300 — 説明セッション FWM312 | Best practices for building full stack multi-tenant apps on AWS スケーラブルな、マルチテナントのアプリケーションを開発するのは複雑です。このコードトークでは、AWS Amplify と AWS AppSync を使用して、セキュリティが確保され、パフォーマンスが高いマルチテナントのフルスタック環境を簡単に構築する方法を学びます。Amplify のフロントエンドホスティングと AWS AppSync の管理型 GraphQL サービスを活用し、AWS 上でマルチテナント基盤を設計するためのベストプラクティスを発見できます。ライブデモと例を通して、Amplify と AWS AppSync が協調して、企業レベルのマルチテナント環境の提供を早めるのを確認できます。スケーラブルなマルチテナントアプリケーションを構築し、お客様のニーズを満たす知識を得られます。 時間: 12 月 3 日 (火) 16:30 – 17:30 (PST) 場所: Wynn | Convention Promenade | Lafite 2 最新情報を取得するには? フロントエンド Web およびモバイルアプリ開発者の最新情報を入手するには、 X をフォローしたり、 Discord に参加したり、 re:Invent &nbsp; Web サイトでセッションを確認したりしてください。 本記事は「 The frontend web and mobile app developer’s guide to AWS re:Invent 2024 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

このブログは 2024 年 10 月 30 日に Jay Horne (Principal Solutions Architect) と Randy Seamans (Principal Solutions Architect) によって共同執筆された内容を日本語化したものです。原文は こちら を参照してください。 過去 20 年以上にわたり、VMware などの市販のコンピューティング仮想化ソリューションは、コストの削減、効率性の向上、管理タスクの簡素化、オンプレミスの柔軟性の向上に使用される強力なツールとなっています。時間の経過とともに、ほとんどのクラウドプロバイダーは無数のクラウドネイティブサービスへの直接アクセスを提供しながら、従来のオンプレミス仮想化スイートで利用できる機能と同等かそれ以上の高度なストレージ、効率性、管理機能をハイパーバイザーに加えてきました。並行して、Broadcom による VMware の最近の買収により、クラウドとオンプレミスの両方で VMware の販売とライセンスの方法に多くの変更がもたらされました。代わりのハイパーバイザーを検討している場合、幸いなことに、関連するストレージを同時に移行しながらあるハイパーバイザーから別のハイパーバイザーへ移動することは、もはや危険で途方もない作業ではありません。 本日、 図 1 に示すように、既存の VMware VM (仮想マシン) とストレージを、あらゆるクラウドベースの VMware ソリューションまたはあらゆるオンプレミスの VMware 環境から、 Amazon Elastic Compute Cloud (Amazon EC2) と Amazon Elastic Block Store (Amazon EBS) および Amazon FSx for NetApp ONTAP の組み合わせに移行するための、シームレスで自動化されたソリューションを紹介します。移行プロセスは、カットオーバーを完了するための短時間の停止まで中断されることなく実行され、ソース上のあらゆるタイプのブロックデバイスをサポートします。最終的に、仮想化環境はハイパーバイザーとストレージデバイスの両方にわたって真に身軽で俊敏になります。このソリューションがどのように実現されるかみていきましょう。 図 1: VM とストレージを自動移行するソリューションのコンセプト 直接的な移行 これまでにクロスプラットフォームの大規模な仮想化移行を行ったことがあるなら、移行プロジェクトの企画を管理するために必要な労力、それに伴うリスク、複雑さをご存知でしょう。AWS パートナーの Cirrus Data Solutions は最近、Amazon EC2 ハイパーバイザー、Amazon EBS、Amazon FSx NetApp for ONTAP ブロックのサポートを Cirrus Migrate Cloud (CMC) に追加しました。Cirrus は、 図 2 に示すように、エンタープライズ級の移行を直接行っています。MigrateOPs によるワンクリックの大規模なエンタープライズ移行をぜひご検討ください。 図 2: Cirrus Migrate Cloud のアーキテクチャ MigrateOPs は、YAML ドリブン (migration-as-code: 移行のコード化) な移行オーケストレーションツールです。これは理論上は十分なものであり、こちらの デモビデオ では、Windows と Linux の VMware VM とそのゲストストレージを AWS にライブ移行する様子を公開しています。デモでは移行された VM は 2 つだけですが、MigrateOPs は大規模なエンタープライズ環境をオーケストレーションできるため、人的リスク要因やデータ損失や移行失敗となるその他の原因を排除できます。 皆さんが何を考えているかはわかります。ストレージ環境はもう少し複雑かもしれません。ここで、オンプレミス環境のデータストアに現在使用している可能性のあるストレージプロトコルを見てみましょう。最新のブロックプロトコル (iSCSI、SCSI over Fibre Channel、NVMe over Fibre Channel、NVMe over TCP) や NFS などが考えられます。ここで紹介するアプローチでは、 表 1 に示すように、前述のプロトコルの任意の組み合わせから自動的に移行できます。 表 1: 移行元ストレージ、AWS 上の移行先ターゲットストレージ、移行ツール 右端の列に示されているように、 Amazon Machine Image (AMI) を使用して EC2 インスタンスを起動するには、Amazon EBS が必要です。ただし、前の表では、特定のワークロードに最適なブロックサービスがどれであるかに応じて、ブロックデータを FSx for ONTAP ブロックサービスまたは Amazon EBS に移行できます。一部のアプリケーションは Amazon EBS に最適ですが、マルチ アベイラビリティ ゾーン (AZ) とシングル AZ のサポート、大規模なスケールアップとスケールアウトのパフォーマンス機能、レプリケーション、シンクローン、およびデータ削減テクノロジが必要な場合は、FSx for NetApp のブロックストレージを検討する必要があります。CMC は、ベストプラクティスに従いながらパフォーマンスと容量に合わせて AWS ブロックストレージを構成することで、移行元ストレージに合わせて FSx for ONTAP ブロックストレージや Amazon EBS を自動的に構築/構成し移行をシームレスに実行します。実際、Amazon EBS のデプロイメントも対象としている場合、このソリューションを使用できます。 上の表の最後の 2 行は、移行元ストレージが VM に共有をプロビジョニングしていることを示しています (データストアの VMDK ではありません)。この場合、ブロックベースの移行ツールは OS ボリュームのみを移行でき、NFS に基づくデータ共有は移行できません。移行元 NFS ストレージが NetApp ONTAP で、移行先が AWS の FSx for ONTAP である場合は、 NetApp SnapMirror タスクを Cirrus の 自動移行に組み込みます。移行元 NFS データストアが NetApp ベースでない場合は、 AWS DataSync を使用して適切なファイルを FSx for ONTAP のファイルマウントポイントに移動し、最終的な DataSync 同期ポイントを Cirrus の自動化された移行タスクに組み込むことができます。 これでストレージをスムーズに移行できたので、次は AMI を使用する Amazon EC2 ハイパーバイザー で使用できるように VMware VMDK ファイルをどのように変換すればよいでしょうか。従来、ストレージの移行には EC2 Import/Export サービスと別のツールを使用してきました。しかし、ストレージと VM の移行を 1 つのユニットとして網羅する完全なソリューションの提供をお約束しました。VMware の vMotion ホットマイグレーションに精通している場合、Cirrus のアプローチは同様のパスを取ります。つまり、VM の実行を継続しながら、基盤となる OS ディスクをビットごとに移行します。OS ディスクとその他の補助ストレージがバックグラウンドで移行されたら、VM を停止し、最終的な同期を実行して EC2 インスタンスに切り替えます。何よりも優れているのは、vMotion とは異なり、この移行環境は真のクロスプラットフォームであるため、VM をハイパーバイザータイプ間で確実に移動できることです。移行の一環として、CMC は、FSx for ONTAP ブロックデバイスに必要な正しいマルチパスおよび iSCSI 構成に各 VM を自動的に修正します。たとえば、VM が新しい自動プロビジョニングされた適合した FSx for NetApp ONTAP ブロックデバイスにアクセスできるようにアクセスグループを構築します。この高度な自動化により、組織は移行方法ではなく、移行対象に集中できます。もう 1 つ詳細があります。移行中の VM とストレージの両方がスナップショットによって保護され、必要に応じて移行をシームレスにロールバックできます。 おめでとうございます。データと VM を手軽で俊敏にする方法を学びました。それだけでなく、将来 AWS から移行することに決めた場合も、同じように直接移行でき、 離脱に伴うペナルティや料金は一切発生しません 。AWS へようこそ！ クリーンアップ AWS への移行が完了したら、Cirrus Migration ソフトウェアを完全にアンインストールできます。実際のワークロードを移行するのではなく、AWS アカウントで移行をテストする場合は、移行したインスタンスと関連する Amazon FSx for NetApp ONTAP リソースを必ず削除してください。最後に、概念実証 (PoC) を実行する予定がある場合は、AWS の無料利用枠と無料の Cirrus デモライセンスを使用できることを忘れないでください。 学習したこと 本日、CMC を使用して VMware VM をどこからでも Amazon EC2 および FSx for NetApp ONTAP に安全に移行する方法を学びました。他のユーザーが VMware 環境にこのオプションを選択しているさまざまな理由の詳細については、こちらの NetApp の記事 と NetApp ソリューションガイド をご覧ください。 AWS アカウント をお持ちでないが、これが組織でどのように機能するかを評価したい場合は、今すぐ AWS アカウント を利用して開始できます。AWS の Amazon FSx NetApp for ONTAP の機能に詳しくない場合は、 ユーザーガイド をご覧ください。 AWS パートナーマーケットプレイス で CMC の価格などの詳細を確認したり、 無料の 1 TB ライセンス を開始することができます。Cirrus と AWS は、複雑な VM 移行を支援する完全なターンキーソリューションも提供しています。最後に、ユーザーが 1 回限りの移行コストを排除または削減できるように、Amazon は AWS VMware Migration Accelerator を導入しました。これは、任意の VMware Cloud on AWS 環境から Amazon EC2 および FSx for ONTAP に移行した VM 1 台あたり最大 400 ドルのクレジットを提供します。既存のオンプレミス環境の場合は、Amazon EC2 および Amazon FSx for NetApp ONTAP の移行クレジットの利用可能性について AWS の担当者に確認してください。 このソリューションが意味すること 新しい時代が到来しました。もはやデータと VM はハイパーバイザー間で移動可能になり、AWS ではデータとコンピューティングを別の場所に移行する場合でも料金はかかりません。FSx for ONTAP、Amazon EBS、Amazon EC2 の高度なストレージ機能を使用することで、コスト効率の高い方法で、エンタープライズクラスの高性能な高可用性 (HA) および災害復旧 (DR) 対応環境を構築できます。VM 環境を AWS Storage と Amazon EC2 に移行する可能性を検討している組織は、この記事の著者またはお近くの AWS 担当者にお問い合わせください。AWS は、VMware 環境の包括的な評価を実行し、費用対効果が高くシームレスな移行プランを作成できます。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Cloud Support Engineer の戸松が担当しました。 Jay Horne Jay Horne は、AWS のワールドワイドスペシャリスト組織における Amazon FSx for NetApp ONTAP サービスのグローバルテクニカルリーダーおよびサービス連携ソリューションアーキテクトです。テネシー州ナッシュビルを拠点とする Jay は、さまざまなクラウド、ストレージ、サーバー、ネットワークインフラストラクチャに携わった 15 年以上のエンタープライズコンサルティング経験を持っています。世界中のストレージおよびクラウドカンファレンスで頻繁に講演を行っています。 Randy Seamans Randy はストレージ業界のベテランであり、高性能ストレージ、コンピューティング (HPC)、および災害復旧を専門とする AWS のプリンシパルストレージスペシャリスト兼アドボケートです。ストレージに関する洞察や楽しみをさらに知るには、https://www.linkedin.com/in/storageperformance で彼をフォローしてください。 &nbsp;

この記事は、” Jumpstart your HPC journey with the AWS Parallel Computing Service getting started kit ” を翻訳したものです。 先日、AWS は ハイパフォーマンスコンピューティング の領域の革新的なサービス、 AWS Parallel Computing Service（AWS PCS）のローンチを発表 しました。AWS PCSは、インフラストラクチャの管理に煩わされることなく、HPC ワークロードの実行とスケーリングをこれまで以上に容易にする管理サービスです。気象パターンのシミュレーション、次世代車両の設計、がん治療法の探索など、あらゆる研究や革新的な取り組みを加速させるために、AWS PCS は設計されています。 AWS PCSのローンチに伴い、すぐに使いこなせるよう、豊富なリソースをご用意しました。マニュアルを読むのが好きな方、動画で学びたい方、実践的なアプローチを好む方など、様々なニーズに対応しています。 本記事では、これらのリソースをご紹介し、PCS をスムーズに始められるようサポートいたします。 1 クリックで PCS についてよく学ぶことができるリソース 最初に紹介するリソースは、最短でひらめきを得られるかもしれません。HPC Recipes Library(詳細は後述)の PCS recipe をワンクリックすると、事前に用意されたサンプル AMI をベースとした Amazon FSx for Lustre scratch filesystem、小規模な x86 インスタンスのノードグループが実装された HPC cluster を最短で試すことができます。 これが本番環境用のクラスターになるとは考えていませんが、最も早く Slurm コマンドラインを試すことができ、どういったものが最適かを見つけることができます。このレシピを使うと、わずか15分でクラスターを試しに動かすことができます。古典的な学習方法、つまり作って壊しながら学ぶことができます。 AWS PCS User Guide 他の AWS サービスと同様に、AWS PCS にも 詳細なユーザーガイド があります。このガイドは、サービスの開発に携わっているテクニカルライター、ソフトウェアエンジニア、プロダクトマネージャーによって作成されています。ガイドでは、PCS を利用するための AWS アカウントの設定方法をはじめ、用途に合ったクラスターサイズの選び方、クラスターの運用管理、PCS が他の AWS サービスとどのように連携し統合されるかなど、幅広いトピックを網羅しています。 さらに、「 Getting started with AWS PCS 」という一歩ずつ学べるチュートリアルも含まれており、PCS クラスターの基本的な構成要素（クラスターのプリミティブ、コンピュートノードグループ、キュー、外部ファイルシステムなど）について解説しています。また、シンプルながら実用的な HPC 環境を構築するための手順も詳しく説明されています。 HPC Tech Shorts 時には、単に手順を読むだけでなく、実際のデモンストレーションを見たり、より広い文脈でのサービスの利用法を聞いたりすることが役立つことがあります。 PCS の使い方をより深く理解するために、 YouTube の HPC Tech Shorts チャンネル で 2 時間以上の実践的な動画コンテンツが公開されています。現在 6 本の動画が用意されており、今後数週間から数ヶ月にわたってさらに追加される予定です。 動画コンテンツは以下の通りです。 Introducing AWS Parallel Computing Service (9分) – この動画では、PCS の位置付けを紹介し、仕組みや他の AWS サービスとの連携について概観しています。 Your first AWS PCS cluster (43分) – この動画では、ユーザーガイドの Getting started with AWS PCS チュートリアルに沿って、ステップ・バイ・ステップで解説しています。ネットワークの設定から、ストレージのプロビジョニング、クラスターの構築まで、各ステップで何をどのように行うのか、なぜそうするのか、を詳しく説明しています。この最初の２本の紹介動画を見れば、PCS の機能について良く理解でき、実際の動作も確認できるでしょう。 さらに深く掘り下げたい場合 は、PCS を用途に応じてカスタマイズする上で重要なトピックを扱う 4 本の動画があります。これらは順番に視聴することをお勧めします。 Launch templates, instance profiles, security groups, and AMIs (17分) – この動画では、PCS にどのように様々な AWS の基本的な要素が組み合わさって、HPC ジョブを実行するインスタンスに特定の機能や動作を可能にするかを紹介しています。 Configuring Elastic Fabric Adapter (EFA) and multi-NIC instances (20分) – 100 種類以上の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプで EFA（Elastic Fabric Adapter）を使用して高速・低遅延のネットワーキングが可能です。中には複数のネットワークカードを搭載し、さらに高いスループットを実現するものもあります。この動画では、EFA を最大限に活用するためのPCSの設定方法を詳しく説明しています。また、気軽に試すための AWS CloudFormation テンプレートについても紹介します。 Create and use a custom AMI for AWS PCS (29分) – PCS では、カスタム AMI を利用して高度にカスタマイズされたソフトウェア環境を構築できます。この動画では、Rocky Linux 9 のベースラインイメージから始まり、 Spack を使用してユーザーランドソフトウェアを管理する AMI の作成まで、プロセスの各ステップを詳しく解説します。さらに、作成した AMI を PCS で実際に使用する方法もご紹介します。 Bring your own login node (21分) – AWS PCS にアクセスノード(ログインノード)を提供する方法は2つあります。PCS にログインインスタンスの管理を任せるか、自分でインスタンスを設定してクラスターの Slurm コントローラーに接続するかのいずれかです。この動画では、スタンドアロンの EC2 インスタンスを PCS クラスターとその共有している Lustre ファイルシステムに接続する方法を解説しています。 今後数ヶ月にわたって、このような解説動画がさらに追加される予定です。 HPC Recipes for AWS 昨年のこの時期に、 community recipe library for HPC infrastructure on AWS をリリースしました。このライブラリには、AWS で HPC を学んだり、概念実証(PoC)やデモを構築したりするのに使えるパターンや Infrastructure as code のリソースが含まれています。リリース以来、このライブラリは大きく成長し、いくつかの AWS HPC ブログ 記事で重要な役割を果たしてきました。今回、このライブラリに PCS-specific channel を追加しました。これにより、PCS に特化したレシピやリソースにアクセスしやすくなりました。 この PCS チャンネルは急速に成長しています。現時点での内容を少しご紹介すると、 Getting started with AWS PCS をサポートするレシピや、スタンドアロンのログインノードのセットアップ方法、さらには簡単な CFD 用クラスターの構築方法を示すレシピなどが含まれています。このリポジトリにあるレシピは、私たちのチュートリアルや動画で広く使用されています。 是非 HPC Recipes に注目してください（是非 GitHub でスターを付けてください）。HPC Recipesでは、PCS クラスターの運用に関する様々な側面を段階的に仕組み化する方法を紹介しています。 Next Steps AWS Parallel Computing Service (AWS PCS)は、AWS での HPC クラスターの管理を簡素化し、研究やイノベーションを加速させるために設計されています。利用し始めるための包括的なリソースを用意しました： 一歩ずつ学べるチュートリアルを含む詳細な ユーザーガイド YouTube の HPC Tech Shorts チャンネル にある 6 本の詳細な動画 PCS に特化したテンプレートを含む、順次拡大中の HPC Recipes for AWS ライブラリ これらのリソースは、ドキュメントを読むのが好きな方、デモを見るのが好きな方、実践的な例に直接取り組むのが好きな方など、さまざまな方の好みの学習スタイルに対応しています。 是非 AWS PCS を試してみて、HPC ワークフローをどのように変革できるか確かめてみてください。入門ガイドから始めるか、紹介動画を見るか、HPC Recipes の 1 つに取り組んでみてください。AWS PCS 上で HPC 環境を構築・拡張していく中で、科学的・工学的ブレークスルーを加速させる新しい方法を発見できるでしょう。 HPC の旅の次のステップに進む準備はできたでしょうか。 AWS Parallel Computing Serviceの製品ページ にアクセスして、詳細を確認し、今すぐ始めましょう。 試してみて、感想を ask-hpc@amazon.com までお聞かせください。AWS PCS でどんなことを成し遂げられるか、楽しみにしています。 本ブログ記事は、ソリューションアーキテクトの池田が翻訳しました。原文は こちら です Matt Vaughn Matt Vaughn は、HPC および科学計算分野の Principal Developer Advocate です。ライフサイエンスのバックグラウンドを持ち、長期的に利用してくださるユーザーのために使いやすい HPC やクラウドシステムの構築に携わってきました。仕事以外の時間は、絵を描いたり、読書をしたり、世界中を旅したり、近くにいる犬と遊んだりして過ごしています。 Brendan Bouffler Brendan Bouffler は、AWS の HPC エンジニアリング部門で Developer Relations の責任者を務めています。これまで、あらゆる環境で数百もの HPC システムの設計と構築に携わってきました。クラウドが、世界を変える発見をもたらすために全世界の研究者やエンジニアが必要とする卓越したツールになることを確信し、AWS に入社しました。 物理学の学位を持つブレンダンは、自転車にまつわる物理法則のを実験的に検証することに興味を持っています。この趣味が原因で、しばしば入院することになっています。

お客様は、 Amazon Elastic Compute Cloud (Amazon EC2) を使用して、ウェブホスティング、ビッグデータ処理、ハイパフォーマンスコンピューティング (HPC)、仮想デスクトップ、ライブイベントストリーミング、データベースなど、考え得るあらゆるタイプのワークロードを実行しています。これらのワークロードの中には非常に重要なものがあり、お客様はキャパシティを予約する機能を求めていました。 お客様が柔軟にキャパシティを予約できるようにするために、2018 年に EC2 オンデマンドキャパシティ予約 (ODCR) をリリースしました。それ以来、お客様はキャパシティ予約 (CR) を使用して、消費者向けウェブサイトのホスティング、ライブスポーツイベントのストリーミング、金融取引の処理などの重要なアプリケーションを実行してきました。 11 月 25 日、CR を使用して将来のワークロードのためにキャパシティを取得するための機能を発表しました。多くのお客様は、製品のリリースまたは大規模な移行などのイベントや、サイバーマンデーやディワリなどの年末セールイベントを予定しています。これらのイベントは重要であり、お客様は必要なときに必要な場所でキャパシティが確実に使用できる状態にしておきたいと考えています。 CR はお客様がこれらのイベントのためにキャパシティを予約するのに役立ちましたが、ジャストインタイムでしか利用できませんでした。そのため、お客様は事前にキャパシティをプロビジョニングして料金を支払うか、またはイベントの開始時に CR をジャストインタイムでプロビジョニングするように正確に計画する必要がありました。 今回の発表により、最大 120 日前まで CR を計画してスケジュールできるようになりました。使用を開始するには、必要なキャパシティ、開始日、提供の詳細設定、キャパシティ予約を使用することをコミットする最小期間を指定します。キャパシティ予約のスケジュールに前払い料金はかかりません。Amazon EC2 がリクエストを評価して承認すると、開始日に予約がアクティブ化され、お客様はそれを使用してすぐにインスタンスを起動できます。 将来の日付のキャパシティ予約の開始方法 将来の日付のキャパシティを予約するには、 Amazon EC2 コンソール で [キャパシティ予約] 、 [オンデマンドキャパシティ予約を作成] 、 [使用を開始] の順に選択します。 キャパシティ予約を作成するには、インスタンスタイプ、プラットフォーム、アベイラビリティーゾーン、プラットフォーム、テナンシー、およびリクエストするインスタンスの数を指定します。 [キャパシティ予約の詳細] セクションで、 [キャパシティ予約の開始] オプションの [将来の日付] を選択し、開始日とコミットメント期間を選択します。 キャパシティ予約を特定の時刻に終了したり、手動で終了したりすることもできます。 [手動] を選択した場合、予約に終了日はありません。手動でキャンセルするまで、アカウントでアクティブなままになり、引き続き課金されます。このキャパシティを予約するには、 [作成] を選択します。 キャパシティリクエストを作成すると、ダッシュボードに [評価中] ステータスで表示されます。この状態になっている期間中、AWS システムはリクエストがサポート可能かどうかを判断します。これは通常 5 日以内に完了します。リクエストがサポート可能であるとシステムが判断すると、ステータスは [スケジュール済み] に変更されます。まれに、リクエストがサポートされない場合があります。 スケジュールされた日付に、キャパシティ予約は [アクティブ] 状態に変わり、インスタンスの合計数はリクエストされた数まで増加し、インスタンスをすぐに起動できます。 アクティブ化後、少なくともコミットメント期間中は予約を保持する必要があります。コミットメント期間が経過した後は、必要に応じて引き続き予約を保持して使用することも、不要になった場合はキャンセルすることもできます。 知っておくべきこと 将来の日付の CR について知っておくべきことをいくつかご紹介します。 評価 – Amazon EC2 はリクエストを評価する際に複数の要素を考慮します。Amazon EC2 は、予測される供給量に加えて、キャパシティを保持する予定の期間、開始日からどの程度早期にキャパシティ予約を作成するか、およびリクエストの規模を考慮します。Amazon EC2 がお客様のリクエストをより良くサポートできるようにするには、開始日の少なくとも 56 日 (8 週間) 前に予約を作成してください。C、M、R、T、I インスタンスタイプについてのみ、少なくとも 100 vCPU のリクエストを送信する必要があります。ほとんどのリクエストで推奨される最小コミットメントは 14 日間です。 通知 – コンソールまたは Amazon EventBridge を通じてリクエストのステータスをモニタリングすることをお勧めします。これらの通知を使用して、オートメーションをトリガーしたり、E メールまたはテキスト更新を送信したりできます。詳細については、「Amazon EventBridge ユーザーガイド」の「 Amazon EventBridge を使用してイベントが発生したときに E メールを送信する 」にアクセスしてください。 料金 – 将来の日付のキャパシティ予約は、通常の CR と同様に課金されます。リザーブドキャパシティでインスタンスを実行するかどうかにかかわらず、同等のオンデマンド料金が課金されます。例えば、20 個のインスタンスの将来の日付の CR を作成し、15 個のインスタンスを実行した場合、最小期間を含む予約内のアクティブなインスタンス 15 個と未使用のインスタンス 5 個について課金されます。Savings Plans は、未使用の予約と予約で実行されているインスタンスの両方に適用されます。詳細については、「Amazon EC2 ユーザーガイド」の「 キャパシティ予約の料金と請求 」にアクセスしてください。 今すぐご利用いただけます 将来の日付の EC2 キャパシティ予約は、Amazon EC2 キャパシティ予約が利用可能なすべての AWS リージョン で 11 月 25 日からご利用いただけます。 Amazon EC2 コンソール で Amazon EC2 キャパシティ予約をお試しください。詳細については、「Amazon EC2 ユーザーガイド」の「 オンデマンドキャパシティ予約 」にアクセスし、 AWS re:Post for Amazon EC2 または通常の AWS サポートの連絡先を通じてフィードバックを送信してください。 – Channy 原文は こちら です。

2024 年 7 月 5 日に開催された「第19回情報危機管理コンテスト」決勝戦にて AWS 賞を受賞したチーム GH05TBUSTERS (ゴーストバスターズ) の皆様にインタビューを行いました。 今回の情報危機管理コンテストは 2 部制になり、前半は AWS 上に構築された Web サーバ, CDN, WAF を舞台にして行われました。情報危機管理コンテストは、参加チームは発生した事象について調査を行い、コンテスト主催者が用意したプレイスホルダーへの報告を行う実践的なコンテストになります。GH05TBUSTERS は調査や対策が困難である状況において、プレイスホルダーへの報告書が理解し易く丁寧であったことが AWS 賞受賞の決め手でした。 GH05TBUSTERS の皆様から情報危機管理コンテストへの参加の経緯や意義について、お話をお聞きすることが出来ましたので、インタビュー記事を通してそこで得た学び、これからの IT 、クラウドや AWS への期待をうかがいできればと思います。 (写真左から) GH05TBUSTERS 名古屋工業大学 齋藤掛井研究室 情報工学科 4 年 東 政澄 氏 情報工学科 4 年 斎藤 勇斗 氏 情報工学科 4 年 佐藤 優樹 氏 情報工学科 4 年 佐々木 康太 氏 コンテストに参加したきっかけ AWS : 今回の危機管理コンテストに参加するきっかけをお聞かせいただけますか。 佐々木 : 研究室の先輩が年々通過していて、去年( 2023 年)の 12 月ごろに先輩から来年はぜひ参加しようと言われました。ちょうど人数が一杯だったので、未経験のチームを作ろうということになりました。 AWS : 未経験のチームとのことで、本選の準備を進める上でどのような苦労がありましたか？ 佐々木 : 一次予選は先輩のアドバイスもなく、過去問を見て対策するくらいでした。通るかなと思いながらビクビクしていました。でも、自分たちの力だけで一次予選を通過することが出来ました。本戦で実際に攻撃を受けて対処するのは初めての経験でした。練習した時は、攻撃が分かっても、そこからどうすればいいのか分からず探り状態でした。そこに慣れていくのが大変でした。 AWS : 練習について教えてください。 佐々木 : 過去に大会に出た先輩たちが本番に似た環境を独自で作ってくれていました。そこで先輩が用意した攻撃スクリプトを受けて、それに対応するような練習をしました。 AWS : 決勝戦での分担はどのように決められたのでしょうか？ 佐々木 : サークルで渉外対応をしていたので、ある程度慣れていたから電話担当になりました。 東 : トラブルチケットを最後に提出するので、聞きながら書く人がいないと難しいと思い、書記を担当をしました。 佐藤 : その他のメンバーがログの監視と分析を担当することにしました。 AWS : 電話対応や書記が選任なのは大切だからということでしょうか？ 佐々木 : 先輩からログ監視と電話対応を二人でやるのが効率的と言われたので、得意な人がそちらを担当しました。未経験なので、レベル差はあまりありませんでした。 本戦で工夫したところ 佐藤: ユニフォームのTシャツを作りました(一同 笑) 東 : Discord で画面共有をしながら進めました。全員が同じ画面を見られるようにしていました。ただ、解像度が良くなかったので、事前に打ち合わせをしておけば良かったです。でも、大体の概要は把握できたので、指示を出し合えました。 AWS : 指示は誰が出していましたか？ 佐々木: 私がリーダーにはなっていましたが、リーダーが判断して回すよりは、4 人で各自のアイデアを話し合って決めていく感じでした。誰か一人が動かすのではなく、チームで動いていました。 AWS : プレイスホルダーへの報告書が AWS 賞の決め手でしたが、報告書で工夫したことはありますか？ 佐々木 : 時間が短かったので、みんな急かされている状態だったと思います。そういう中で、できるだけ分かりやすく伝えようと心がけました。みんなも同じようにわかり易くしたので、それが反映されたのだと思います。一旦冷静に構えるのも大切だと感じました。 東: レポートを報告する際も、難しい単語は事前に説明を入れるなど、大学一年生くらいに分かりやすいように心がけました。 AWS : サポート役の AWS の社員とのやり取りでは、コミュニケーションで何を気をつけましたか？ 斎藤 : 現在どういう状況に困っているのかを簡潔に分かりやすく伝え、アドバイスをもらって、早く戻って実行することを意識しました。 東 : 「AWS のサポートの方だから分かるだろう」ではなく、AWS を知らない人でも分かるように伝えました。 後輩や今後参加される方に対して 佐々木: 授業で習っただけでは、攻撃が来た時にどういうものが映るのか経験する機会がありません。本番に行けなくても練習だけでも良い経験になると思います。一次予選の内容もコンサルっぽい業務で、リスクマネジメントの面でセキュリティの分野に行かなくても良い経験になると思うので、色んな人に参加してほしいです。 東 : 同感です。 AWSやクラウドに感じる可能性 AWS : 事前ワークショップ 以前にクラウドについては触ったことがありましたか？ 東 : 実験の一環で一度だけ触った程度でした。 佐々木, 斎藤, 佐藤 : 触ったことは無かったです。 AWS : 事前ワークショップの内容はどうでしたか？ 佐々木 : クラウドを使うと言われても、別の企業が持っているサーバーを使うくらいの認識しかありませんでした。実際にどういう操作をすればできるのかを体験できて面白かったです。 AWS : クラウドの触った後でイメージに変化はありましたか？ 斎藤 : コンテストが終わった後に EC2 を使ってウェブアプリケーションを公開したいと頼まれ、ワークショップの資料を見ながら RDS などを構築しました。 斎藤 : サービスがこんなにたくさんあると思っていませんでした。公開するのは簡単だと思っていましたが、セキュリティを強化するためには、複数のサービスを組み合わせる必要があり、拡張性が高いと感じました。 AWS : 逆にクラウドのイメージで変わらなかったところは何でしたか？ 東 : サーバーの動作自体は変わっていないと感じました。オンプレミスの環境とクラウドの環境で大差なく動くのは便利だと思いました。 将来のキャリアイメージ AWS : 将来のキャリアイメージについてお聞きしたいと思います。皆さんはどのようなキャリアを考えていますか？ 佐々木 : まずは大学院に行って、今の研究を発展させてセキュリティ分野の知識をつけたいです。その後は、コンサル系の仕事でお客様と話ができるような仕事に就きたいです。コンテストでお客様対応が楽しかったので、そういう仕事がしたいです。 斎藤 : 私もインシデント対応やお客様と話しながらセキュリティを強化する仕事ができたらと思っています。 東 : 私は作る側に回りたいと思っています。サービスを作っていく人間になりたいです。 佐藤 : セキュリティ系がカッコいいので、職種は限らずセキュリティ関係の職業に就きたいです。 AWS : 皆さんにとってセキュリティを学ぶことにはどのような価値がありますか？ 東 : セキュリティは範囲が広いので総合格闘技の様です。幅広く学んでいく必要があると思います。様々な知識を身につけて、それを開発に活かしていけたらと考えています。 佐々木 : サークルで使う Web アプリを作っています。公開範囲を設定する際の要望と影響範囲をコントロールするために、説得するための知識をつけたいです。 おわりに チーム GH05TBUSTERS の方々、お忙しい中インタビューに快く対応いただいてありがとうございました。 このブログは、2024 年 10 月 25 日時点の情報に基づいてソリューションアーキテクト 押川、深井 が執筆しました。

この記事は Serverless containers at AWS re:Invent 2024 (記事公開日: 2024 年 11 月 1 日) を翻訳したものです。 AWS re:Invent は、AWS が主催するグローバルなクラウドコンピューティングコミュニティ向けの大規模な学習カンファレンスです。今年は、 Amazon Elastic Container Service (Amazon ECS) チームと AWS Fargate チームが、生産性の向上、コストの最適化、ビジネスの俊敏性向上に役立つ最新のトレンド、イノベーション、ベストプラクティス、ヒントを共有します。2024 年 12 月 2 日から 12 月 6 日の期間、是非ラスベガスにてご参加ください。 Expo Hall の AWS サーバーレス kiosk または AWS モダンアプリケーションとオープンソースゾーンにアクセスして、AWS でのモダンアプリケーションの構築について専門家に質問したり、デモンストレーションを見たり、オープンソースチームと交流したりできます。ぜひお立ち寄りください！ 参加いただけるセッション Amazon ECS と AWS Fargate のセッションは、今年は SVS – サーバーレスコンピュート&amp;コンテナトラックの一部として実施されます。「“Celebrating 10 years of pioneering serverless and containers” (サーバーレスとコンテナのパイオニアとしての 10 周年を祝う)」 ( SVS211 ) や「 “Compute innovation for any application, anywhere” (あらゆるアプリケーションのためのコンピューティングイノベーション)」( CMP215 ) などのリーダーシップセッションにも是非ご参加ください。今年のトラックのハイライトには、Fannie Mae のサーバーレスコンテナジャーニーを特集した「“Unleashing the power of Amazon ECS for platform teams”(プラットフォームチームのための Amazon ECS の力を解き放つ)」（ SVS330 ）、「 “Navigating the cloud compute landscape with Amazon ECS” (Amazon ECS におけるクラウドコンピューティングの世界を探る)」（ SVS327 ）、「“Simplifying multi-tenancy with SaaS applications on AWS Fargate” (AWS Fargate でのSaaSアプリケーションによるマルチテナンシーの簡素化)」（ SVS329 ）などがあります。セッション ID をクリックして予約してください。 これまでと同様に、カンファレンスではさまざまなセッション形式が提供されています。 ブレイクアウトセッション: AWS エキスパート、ビルダー、お客様による講義形式のプレゼンテーション チョークトーク: さまざまなトピックに関する専門家によるインタラクティブなセッション。自分の経験やフィードバックを共有するセッション ワークショップ: 新しいテクノロジーの探求に役立つハンズオン形式の学習セッション。ご自身のラップトップ PC をご持参ください ビルダーセッション: AWS エキスパートが行う小規模なセッションで、自分のラップトップ PC で何らかのプロジェクトを構築します ライトニングトーク: Expo Hall で開催されるこの 20 分間のプレゼンテーションです。特定の顧客事例、サービスデモ、AWS パートナーサービスなどに特化しています プラットフォームチーム向けの Amazon ECS コア機能 SVS327 | Navigating the cloud compute landscape with Amazon ECS (Amazon ECS におけるクラウドコンピューティングの世界を探る) (ブレイクアウト) SVS329 | Simplifying multi-tenancy with SaaS applications on AWS Fargate(AWS Fargate 上の SaaS アプリケーションによるマルチテナンシーの簡素化) (ブレイクアウト) SVS330 | Unleashing the power of Amazon ECS for platform teams (プラットフォームチーム向けの Amazon ECS の力を解き放つ) (ブレイクアウト) コスト最適化とレジリエンシー SVS334 | Optimizing workloads for speed &amp; cost using Amazon ECS and AWS Fargate (Amazon ECS と AWS Fargate を使用してワークロードをスピードとコストに合わせて最適化する) (チョークトーク) SVS409 | Deep dive into Amazon ECS resilience and availability (Amazon ECS のレジリエンスと可用性を深く掘り下げる) (ブレイクアウト) オブザーバビリティ SVS328 | Enhancing observability in Amazon ECS to gain actionable insights (Amazon ECS のオブザーバビリティを強化して実用的な洞察を得る) (ブレイクアウト) SVS413 | Unveiling Amazon ECS workloads with managed open source observability (マネージド型オープンソースオブザーバビリティによる Amazon ECS ワークロードの紹介) (チョークトーク) セキュリティとネットワーク SVS301 | Architecting for data protection and compliance with Amazon ECS (Amazon ECS のデータ保護とコンプライアンスのためのアーキテクチャ) (ビルダーセッション) SVS309 | Securing application networking with Amazon ECS Service Connect (Amazon ECS サービスコネクトによるアプリケーションネットワークの保護) (ワークショップ) SVS341 | Achieving a secure microservices architecture on Amazon ECS (Amazon ECS での安全なマイクロサービスアーキテクチャの実現) (ブレイクアウト) SVS342 | Securing Amazon ECS workloads with AWS Signer and Amazon GuardDuty (AWS Signer と Amazon GuardDuty による Amazon ECS ワークロードの保護) (ブレイクアウト) アプリケーション開発のための Amazon ECS モダナイゼーション SVS310 | Learn multi-tier application architectures on Amazon ECS (Amazon ECS の多層アプリケーションアーキテクチャを学ぶ) (ワークショップ) SVS302 | Migrate and modernize your containerized workloads with AWS Fargate (AWS Fargate を使用してコンテナ化されたワークロードを移行およびモダナイズする) (チョークトーク) SVS332 | Build secure &amp; performant apps easily with Amazon ECS &amp; AWS Fargate (Amazon ECS と AWS Fargate を使用して、安全でパフォーマンスの高いアプリを容易に構築) (チョークトーク) スケーリングとパフォーマンス SVS335 | Scaling to 1000s of containers in minutes with Amazon ECS (Amazon ECS を使用して数分で数千のコンテナにスケーリング) (チョークトーク) SVS402 | Lazy loading container images with Seekable OCI (SOCI) (Seekable OCI (SOCI) によるコンテナイメージの遅延読み込み) (ワークショップ) SVS414 | Building resilient Amazon ECS applications with chaos engineering (カオスエンジニアリングによる回復力のある Amazon ECS アプリケーションの構築) (チョークトーク) デプロイメント SVS308 | Demystifying Amazon ECS deployments for secure and automated releases (安全で自動化されたリリースのための Amazon ECS デプロイの謎を解き明かす) (ワークショップ) SVS338 | Continuous deployment on Amazon ECS (Amazon ECS での継続的デプロイ) (ライトニングトーク) SVS340 | Deployment best practices for reliable rollouts using Amazon ECS (Amazon ECS を使用して信頼性の高いロールアウトを行うためのデプロイのベストプラクティス) (ブレイクアウト) イベント駆動型アーキテクチャとデータ処理 SVS333 | Common patterns for storing data for Amazon ECS workloads (Amazon ECS ワークロードのデータを保存するための一般的なパターン) (チョークトーク) SVS336 | Serverless data ingestion and processing using containers on Amazon ECS (Amazon ECS 上のコンテナを使用したサーバーレスデータの取り込みと処理) (チョークトーク) SVS339 | Building event-driven architectures using Amazon ECS with AWS Fargate (AWS Fargate で Amazon ECS を使用してイベント駆動型アーキテクチャを構築する) (ブレイクアウト) 生成 AI SVS304 | Extend generative AI capabilities with serverless containers and RAG (サーバーレスコンテナと RAG による生成 AI機能の拡張) (ビルダーセッション) SVS331 | Supercharge your AI and ML workloads on Amazon ECS (Amazon ECS で AI と ML のワークロードを強化する) (ブレイクアウト) 現地で参加できない場合でも、基調講演とリーダーシップセッションのライブ配信に参加できます。イベントに登録して、バーチャル専用パスを選択してください。ブレイクアウトセッションは、re:Invent 終了後に AWS イベントの YouTube チャンネル でご覧いただけるようになります。 これらのセッションについて詳しく知りたい場合、または弊社の専門家とのミーティングを手配したい場合は、AWS アカウントチームにお問い合わせください。また、イベント中に Expo Hall を訪れて、AWS のスペシャリストと直接お話いただくこともできます。 re:Invent 2024 でお会いできるのを楽しみにしています！その他の学習リソースについては、 Amazon ECS にアクセスして開始してください。 翻訳はパートナーソリューションアーキテクトの高橋達矢が担当しました。原文は こちら です。