ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。過去の記事はこちらになります。 ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 ガバメントクラウド活用のヒント『ガバメントクラウド上で CIDR 重複を起こさないために！』(本ブログ) ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である CIDR 設計に関して扱っていきます。ガバメントクラウド特有の制限ではなく、オンプレミスとAWS 環境をハイブリッドに構成するネットワーク設計では一般的な内容です。 ガバメントクラウドのネットワーク設計で生じうる課題 地方公共団体がガバメントクラウドで AWS を利用する場合、AWS 上で使用する IP アドレス範囲はお客様側で自由に決定が可能です。一方で、AWS とオンプレミス (庁舎など) は L3 レベルで接続されるため、AWS に割り当てる IP アドレスは オンプレミスで使用していない IP アドレス である必要があります。 そこで、ガバメントクラウドを利用するにあたってはオンプレミスで使用していない IP アドレス範囲を確認し、各利用領域に割り当てる必要があります。理由としては、IP アドレス範囲すなわち CIDR が重複してしまうと、通信に不具合が生じてしまうからです。また VPC の CIDR ブロックは 1 度作成すると変更することが困難 のため、CIDR 設計は、十分な検討が必要不可欠です。 どの事業者がネットワークの全体設計を考えるのか ガバメントクラウド上では誰がこの役割を担うべきなのかという点ですが、庁内ネットワークを管轄している事業者やネットワーク構築運用補助者が想定されます。ネットワーク構築運用補助者の詳細については、こちらの ブログ でご確認ください。 Amazon VPC の CIDR ブロック VPC を作成するときは、 RFC 1918 に指定されているように、プライベート IPv4 アドレス範囲からの CIDR ブロックを指定することをお勧めします。 VPC の CIDR ブロックは/16 から/28 の範囲で選択できます。 十分な数の IP アドレスを確保するため、/16から/20程度の CIDR ブロックを選択することが一般的です。 将来の拡張性を考慮した、大きな CIDR ブロックを選択することをお勧めします。 CIDR の重複を回避するには ネットワーク設計時に使用する CIDR を慎重に選定し、重複がないことを確認する CIDR の割り当てを一元的に管理し、重複を防止する ネットワーク変更時には、既存の CIDR との重複がないかを必ず確認する 万が一 CIDR 重複してしまった場合には、オンプレミス側で NAT 変換するという方法がありますが、ネットワーク設計が複雑となります。さらに高価な機器が必要になる場合もあり、デメリットがあります。また、 AWS PrivateLink を用いて接続する方法がありますが、アプリケーション側が AWS PrivateLink での接続に対応していない場合があります。そのため、重複を回避する十分な検討が必要不可欠です。 ネットワーク全体設計のポイント 以下の情報を整理して、全体の CIDR 設計を考える必要があります。そしてすべての IP アドレス範囲が重複しない形で全体ネットワークを考慮する必要があります。(共同利用方式のアプリケーション分離方式で提供される場合は除く) オンプレミス (庁舎など) で利用している IP アドレス 各 ASP 事業者の接続先のアプリケーション VPC の IP アドレス 単独利用方式、共同利用方式問わずすべての接続先 共通機能 VPC や運用管理 VPC を含む 東京リージョン、大阪リージョンを含む 他のクラウドサービスプロバイダで利用するシステムの IP アドレスを含む 将来の拡張性を踏まえたシステム用の VPC の IP アドレス ガバメントクラウド上のシステムの追加用の IP アドレス 各 ASP 事業者の接続先の VPC の IP アドレスに関してですが、オンプレミスと重複しない IP アドレス帯で ASP 事業者の VPC が構築されれば問題ありません。しかし、自由に ASP 事業者が各地方公共団体の環境を作成する場合は、CIDR 重複が起こる可能性が極めて高いと考えます。そういったことを防ぐために、全体の CIDR 設計をまず一番最初に行い、 オンプレミスや他 VPC と重複しない IP アドレスで単独利用方式及び共同利用方式の ASP 事業者に対して VPC を作成いただくような調整 が必要不可欠です。 全体設計の具体的なイメージ例 クラス B ( 172.16.0.0 – 172.31.255.255) の中からオンプレミスと AWS 上で利用する IP アドレスを考えた場合、どのようにネットワーク範囲を考えれば良いかのサンプル例を示します。(もちろん特定のクラスに絞る必要はございません。AWS 上で利用できる IP アドレス範囲は こちら です。) 一番最初に考えることとして、AWS 以外で利用する CIDR と AWS 上で利用する CIDR を適切に区切ることです。オンプレミスと重複しない AWS 上で利用するアドレス帯を決めます。これでオンプレミスと AWS 上の IP アドレスは重複しない設計になります。 オンプレミス: 172.20.0.0/14 172.20.0.0 – 172.23.255.255 AWS : 172.24.0.0/14, 172.28.0.0/15 172.24.0.0 – 172.27.255.255 172.28.0.0 – 172.29.255.255 その他クラウドサービスプロバイダ: 172.30.0.0/15 172.30.0.0 – 172.31.255.255 その上で、AWS 用に区切って用意しておいた CIDR から、ASP 事業者との調整の中で都度 IP アドレスを割り振るような形で全体設計を進めていきます。そうすることで ASP 事業者側も、指定された IP アドレス帯でシステムの構築ができます。ASP 事業者側で作成できる CIDR に制約がある場合もあると思いますので、複数の IP アドレス帯を用意しておくと良いと思います。 例えば、アプリケーションベンダー A に対して、172.25.0.0/16の IP アドレス範囲を利用して AWS 上にアプリケーションの構築を委託するイメージです。地方公共団体とアプリケーションベンダー A で合意の上、アプリケーションベンダー A は指定された IP アドレス範囲でシステム構築を行います。 オンプレミス: 172.20.0.0/16 ネットワークアカウント: 172.24.0.0/16 アプリケーションベンダーA: 172.25.0.0/16 アプリケーションベンダーB: 172.26.0.0/16 アプリケーションベンダーC: 172.27.0.0/16 また、IP アドレスの一元管理ですが、既存の管理方法があればその方法をご利用頂ければと思います。AWS のサービスとしては、 Amazon VPC IP Address Manager (IPAM) があります。AWS ワークロードの IP アドレスを計画、追跡、監視する機能があります。IPAM を使用して、IP アドレスを効率的に管理できます。AWS の Amazon VPC IP Address Manager (IPAM) の知識を深めたい方は [AWS Black Belt Online Seminar] Amazon VPC IP Address Manager (IPAM) をご覧ください。 まとめ 本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である CIDR 設計で検討すべきポイントをご紹介しました。重要なポイントとしては、以下の 3 点です。 現在使用している IP アドレスを把握しておくこと。 AWS に割り当てる IP アドレス範囲を決定すること。 ASP 事業者と調整を行い、適切なネットワーク設計を行うこと 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

AWS Summit は、世界中のさまざまな場所でイベントが開催されるなど、世界を揺るがし続けています。AWS Summit London（4月24日）は4月最後の開催で、5月には AWS Summit Berlin （5月15-16日）、 AWS Summit Los Angeles （5月22日）、 AWS Summit Dubai （5月29日）など9つの開催が予定されています。つながり、コラボレーション、そして AWS について学ぶために参加してください！ どのサミットに参加するかを決めるにあたり、4月15日週の新しい発表を見てみましょう。 4月15日週のリリース 4月15日週は、人工知能 (AI) の世界でもまた忙しい週でした。私が注目したリリースを以下に記載しました。 Anthropic’s Claude 3 Opus が Amazon Bedrock で入手可能になりました – Claude 3 Sonnet と Claude 3 Haiku の後、Anthropic’s Claude 3 の3つの最新モデルのうちの2つ、Opus が Amazon Bedrock で入手可能になりました。Cluade 3 Opus は生成 AI の最前線に立ち、人間に近いレベルの複雑なタスクに対する理解と流暢さを示しています。他の Claude 3 ファミリーと同様に、Opus は画像を処理してテキスト出力を返すことができます。Claude 3 Opus では、難しいオープンエンドの質問に関して、Claude 2.1 に比べて推定 2 倍の精度の向上を実現しています。これにより、誤った応答の可能性が低減されます。 Meta Llama 3 が Amazon SageMaker JumpStart で利用できるようになりました — Meta Llama 3 は、ML ジャーニーを加速するのに役立つ機械学習 (ML) ハブである Amazon SageMaker JumpStart で利用できるようになりました。Llama 3 基盤モデル (FM) は、 Amazon SageMaker Studio でいくつかの手順を実行するか、 Amazon SageMaker Python SDK を使用してプログラムでデプロイして使用できます。Llama には、8B と 70B の 2 つのパラメーターサイズがあり、推論、コード生成、命令フォローが改善され、幅広いユースケースをサポートできます。モデルはお客様の VPC 管理下にある AWS の安全な環境にデプロイされ、データセキュリティの確保に役立ちます。 Amazon SageMaker Studio ノートブックに組み込まれた SQL 拡張機能 — SageMaker Studio の JupyterLab には、SQL と Python を使用してノートブック内で直接、さまざまなソースからのデータを検出、検索、変換するための組み込み SQL 拡張機能が組み込まれました。一般的なデータサービスにシームレスに接続し、データベース、スキーマ、テーブル、ビューを簡単に参照および検索できるようになりました。ノートブックインターフェイスでデータをプレビューすることもできます。SQL コマンド補完、コードフォーマット支援、構文強調などの新機能により、開発者の生産性が向上します。詳細については、「 データを簡単に探索：Amazon SageMaker Studio Jupyter Notebook で SQL と Text-to-SQL を使用 」と「 SageMaker Developer Guide 」を参照してください。 AWS Split Cost Allocation Data for Amazon EKS – AWS Cost and Usage Reports (CUR) で Amazon Elastic Kubernetes Service (Amazon EKS) の詳細なコストを可視化し、Kubernetes アプリケーションのコストと使用量を分析、最適化、チャージバックできるようになりました。Kubernetes アプリケーションが共有されている Amazon EC2 CPU およびメモリリソースをどのように消費するかに基づいて、アプリケーションコストを個々のビジネスユニットやチームに割り当てることができます。これらのコストをクラスター、名前空間、その他の Kubernetes プリミティブごとに集計して、個々のビジネスユニットまたはチームにコストを割り当てることができます。これらの費用の詳細は、オプトインしてから24時間後にCURに表示されます。 Containers Cost Allocation ダッシュボード を使用して Amazon QuickSight でコストを可視化し、 CUR クエリライブラリ を使用してAmazon Athenaでコストをクエリできます。 AWS KMS の自動キーローテーションの強化 – AWS Key Management Service (AWS KMS) は、自動対称キーローテーションのためのより高速なオプションを導入します。90 日から 7 年の間でローテーション頻度をカスタマイズしたり、顧客が管理する AWS KMS キーのキーローテーションをオンデマンドで呼び出したり、ローテーションされた任意の AWS KMS キーのローテーション履歴を表示したりできるようになりました。 セキュリティブログには、暗号化に関するちょっとした歴史など、この機能の詳細を知ることができる素晴らしい投稿 があります。 Amazon Personalize の自動ソリューショントレーニング – Amazon Personalize では、ソリューションの自動トレーニングが提供されるようになりました。自動トレーニングでは、データセットグループの最新データを使用して自動的に再トレーニングするように Amazon Personalize ソリューションのスケジュールを設定できます。このプロセスにより、新しくトレーニングされた機械学習 (ML) モデル (ソリューションバージョンとも呼ばれます) が作成され、エンドユーザー向けの Amazon Personalize の推奨事項の関連性が維持されます。自動トレーニングによりモデルのドリフトが軽減され、ユーザーの行動や好みの変化に合わせて推奨事項が確実に反映されます。Amazon Personalizeを使用すると、Amazonが使用しているのと同じ機械学習技術を使用して、ウェブサイト、アプリ、広告、電子メールなどをパーソナライズすることができます。Amazon Personalize の利用を開始するには、 弊社のドキュメント をご覧ください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon RDS for Oracle は、x2iedn のサポートをアジアパシフィック (ハイデラバード、ジャカルタ、大阪)、ヨーロッパ (ミラノとパリ)、米国西部 (北カリフォルニア)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) で拡張しています 。X2IEDN インスタンスは、高い計算能力（最大 128 vCPU）、大容量メモリ（最大 4 TB）、およびストレージスループット要件（最大 256,000 IOPS）を備え、メモリと vCPU の比率が 32:1 のエンタープライズクラスの高性能データベースを対象としています。 Amazon MSK がカナダ西部 (カルガリー) リージョンで利用できるようになりました 。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、Apache Kafka と Kafka Connect 向けのフルマネージド型サービスです。これにより、Apache Kafka をデータストアとして使用するアプリケーションの構築と実行が容易になります。 Amazon Cognito が欧州 (スペイン) リージョンで利用できるようになりました 。 Amazon Cognito を使用すると、Apple、Facebook、Google、Amazon などのソーシャル ID プロバイダーや、SAML 2.0 や OpenID Connect などの標準によるエンタープライズ ID プロバイダーへのサインインをサポートするウェブアプリやモバイルアプリに、認証、承認、ユーザー管理を簡単に追加できます。 AWS Network Manager がAWS イスラエル (テルアビブ) リージョンで利用できるようになりました 。AWS Network Manager は、プライベートネットワークのグローバルビューを 1 つにまとめることで、AWS とオンプレミスのロケーションにわたるグローバルネットワークの管理に伴う運用上の複雑さを軽減します。 AWS Storage Gateway が AWS カナダ西部 (カルガリー) リージョンで利用できるようになりました 。 AWS Storage Gateway は、オンプレミスのアプリケーションにクラウド上の事実上無制限のストレージへのアクセスを提供するハイブリッドクラウドストレージサービスです。 Amazon SQS は、AWS GovCloud (米国) リージョンでの FIFO デッドレターキューリドライブのサポートを発表しました 。デッドレターキューのリドライブは、 Amazon Simple Queue Service (Amazon SQS) のお客様のデッドレターキュー管理エクスペリエンスを向上させるための拡張機能です。 Amazon EC2 R6gd インスタンス が欧州 (チューリッヒ) リージョンで利用可能になりました 。R6gd インスタンスは AWS Graviton2 プロセッサを搭載し、AWS Nitro System 上に構築されています。これらのインスタンスは、最大 25 Gbps のネットワーク帯域幅を、 Amazon Elastic Block Store (Amazon EBS) に最大 19 Gbps の帯域幅、最大 512 GiB の RAM、最大 3.8 TB の NVMe SSD ローカルインスタンスストレージを提供します。 Amazon Simple Email Service が AWS GovCloud (米国東部) リージョンで利用できるようになりました 。 Amazon Simple Email Service (SES) は、スケーラブルで費用対効果の高い、柔軟なクラウドベースの E メールサービスで、マーケティング、通知、トランザクションに関する E メールを任意のアプリケーション内から送信できます。詳細については、 Amazon SES ページにアクセスしてください。 AWS Glue Studio Notebooks は現在、中東 (UAE)、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、イスラエル (テルアビブ)、欧州 (スペイン)、欧州 (チューリッヒ) の各リージョンでご利用いただけます 。AWS Glue Studio Notebooks では、AWS Glue でインタラクティブなジョブオーサリングが可能なため、データ統合ジョブの開発プロセスを簡素化できます。詳細については、 AWS Glue Studio ノートブックでのコードのオーサリング をご覧ください。 Amazon S3 Access Grants は現在、中東 (UAE)、アジアパシフィック (メルボルン)、アジアパシフィック (ハイデラバード)、欧州 (スペイン) の各リージョンでご利用いただけます 。 Amazon Simple Storage Service (Amazon S3) のアクセス権限付与は、Microsoft Entra ID や AWS Identity and Access Management (IAM) プリンシパルなどのディレクトリ内の ID を S3 内のデータセットにマップします。これにより、企業のアイデンティティに基づいてエンドユーザーにS3アクセスを自動的に付与することで、データ権限を大規模に管理できます。詳細については、 Amazon S3 アクセス権限 のページをご覧ください。 その他の AWS ニュース 興味深いと思われるその他のニュースをいくつかご紹介いたします。 PartyRock Generative AI Hackathon の受賞者 – PartyRock Generative AI Hackathon は、7,650 人以上の登録者が 4 つのチャレンジカテゴリーにわたって 1,200 のプロジェクトを提出し、 Parable Rhythm – The Interactive Crime Thriller 、 Faith – Manga Creation Tools 、 Arghhhh! のような上位入賞者を擁し、幕を閉じた Zombie 。参加者は驚異的な創造性と技術力を発揮し、賞金総額は 60,000 USD の AWS クレジットを獲得しました。 娘のAryaが作り上げたストーリーやアイデアを使って、Faith — Manga Creation Toolsアプリを試してみましたが、その結果は非常に印象的でした。 アプリを自分で試す方法の詳細については、 Jeff Barr の投稿 をご覧ください。 AWS オープンソースのニュースと更新  – 同僚の Ricardo は、AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をチェックしてください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市、 シンガポール (5月7日)、 ソウル (5月16日～17日)、 香港 (5月22日)、 ミラノ (5月23日)、 ストックホルム (6月4日)、 マドリード (6月5日) で登録してください。 AWS re:Inforce – 6 月 10～12 日に米国ペンシルバニア州で開催される、ビジネスイニシアティブの推進を支援するように設計された 2 日半の没入型クラウドセキュリティ学習のための AWS re:Inforce で、生成 AI 時代のクラウドセキュリティに関する知識を深めましょう。 AWS Community Days  – トルコ (5 月 18 日 )、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) のエキスパートによる、専門的な AWS ユーザーや業界リーダーによるコミュニティ主導のカンファレンスに参加しましょう。 こちらでは、近日開催される AWS 主導の対面および仮想イベント と デベロッパーに焦点を合わせたイベント のすべてを閲覧できます。 4月22日週のニュースは以上です。4月29日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

画像生成 AI は、テキストからリアルな画像を生成できる革新的な AI モデルです。Diffusion モデルによる技術的なブレイクスルーにより注目を集め、派生技術や関連技術の研究開発が活発化し、日進月歩で新たな技術が生まれています。画像生成 AI を利用するには、現状いくつかの方法があります。 Adobe や Canva のようなアプリケーションに組み込まれている生成 AI 機能で利用する方法もあれば、 Amazon Bedrocks の Amazon Titan Image Generator や、 Stable Diffusion のように、API を経由してモデルをシステムに組み込んで利用する方法もあります。さらに OSS モデルや OSS アプリケーションをローカルやクラウドにデプロイして利用することもできます。 OSS アプリケーション/モデルには、利用できる派生モデルの種類が豊富で、カスタマイズ性が高く、OSS コミュニティが開発した新機能を素早く活用できるというメリットがあります。しかし、OSS モデルの推論やファインチューニングには、GPU などの計算リソースが必要となります。ローカルやオンプレミスのハードウェアリソースには限界があるため、小規模な PoC を超えて制作スタジオ等で複数人で大規模に利用する場合はクラウドのスケーラブルなコンピューティングリソースを活用することで、OSS モデルのワークロードをより効率的に実行できます。 AWS では、 Extension for Stable Diffusion on AWS というソリューションを提供しています。このソリューションは OSS の Stable Diffusion Web UI の拡張機能で、モデルのファインチューニングと推論をクラウド上のリソースにオフロードすることで、複数ユーザーによる大規模な利用を可能にします。この拡張機能を使用すると、お客様は UI 上から Amazon SageMaker による Stable Diffusion のモデルトレーニング、ファインチューニング、推論を簡単に実行できます。SageMaker のマネージドな分散学習と高性能の GPU インスタンスを活用することで、必要な時だけ高パフォーマンスのリソースを利用できます。また、 CloudFormation テンプレートを使ってリソースをプロビジョニングすることで、手動設定に伴う複雑さやミスを回避できます。 本記事では、Extension for Stable Diffusion on AWS の概要、アーキテクチャ、主要機能、導入手順について詳しく解説します。 使い方 ソリューションのデプロイ 本ソリューションは「バックエンドの API を提供するミドルウェア」部分と「フロントエンドとなる Extension for Stable Diffusion on AWS 拡張機能をインストールした Stable Diffusion Web UI 」の二つのコンポーネントに分かれています。それぞれ CloudFormation でデプロイし拡張機能の画面からバックエンド API の URL を登録することで設定することができます。詳細なデプロイ手順は ドキュメント および レポジトリ をご確認ください。 ユーザーの管理 Stable Diffusion Web UI はシングルユーザー向けのアプリケーションですが、拡張機能を利用することで複数のユーザーを管理することが可能です。ロールでの権限管理が可能で、学習・チェックポイントのアップロード・推論・エンドポイントの立ち上げ・ユーザーの変更・ロールの変更などのアクションごとに権限を設定することが可能です。 モデルとエンドポイントの管理 画像生成モデルは多くのモデルが出ており、またモデルをカスタマイズできる LoRA などのモデルも多数存在します。拡張機能を利用することで、Web UI の組み込みのモデル、ローカルのチェックポイント、URL から複数のモデルをアップロードし利用することが可能です。アップロードされたモデルは S3 に配置され、必要に応じてバックエンドの SageMaker に読み込まれいつでも呼び出しが可能です。 バックエンドの SageMaker のエンドポイントも拡張機能で管理することが可能です。リアルタイムエンドポイントと非同期エンドポイントに対応しており、オートスケーリングを設定することができます。非同期エンドポイントの場合は、使わない時は自動で 0 にスケールダウンしコストを抑えて利用することが可能です。 モデルの推論 モデルの呼び出しを行ってみましょう。txt2img ページの下部に拡張機能で追加された Amazon SageMaker Inference セクションがあります。モデルを指定してリクエストを送ることでバックエンドで指定したモデルで推論が実行され生成された結果が表示されます。 また、生成されたモデルは S3 に保存されており後から見返すことが可能です。 ControlNet も利用することが可能です。以下の例では国土交通省が公開している都市 3D データ PLATEAU （CC-BY-4.0） を使用し街並みを生成しています。 Stable Diffusion Turbo や Stable Diffusion LCM などの高速化技術も利用可能です。 モデルの学習 また、データセットを登録し LoRA でファインチューニングすることが可能です。まずは、Dataset Management ページでローカルから画像をアップロードしデータセットを作成します。以下の例では AWS のプロダクションチームが作成した CG アニメーション の背景を学習させています。 Train Management ページでモデルと作成されたデータセットを指定しモデルのファインチューニングジョブを作成することができます。学習は裏側では SageMaker Training ジョブで OSS ライブラリの kohya-ss/sd-scripts を使用しています。パラメータなども指定することが可能です。 学習結果および途中のチェックポイントは S3 に自動でアップロードされ、推論で利用することができます。Amazon SageMaker Inference セクションの LoRA のドロップダウンで選択すると反映されます。以下の例では、学習させた CG アニメーション風のスタイルで生成されていることが確認できます。 まとめ この記事では AWS が開発している Stable Diffusion Web UI の拡張機能 Extension for Stable Diffusion on AWS について紹介しました。このソリューションにより、複数ユーザーによる大規模な利用が可能になり、必要な時だけ高パフォーマンスのリソースを活用してモデルの学習、推論で利用することが可能です。ロールベースのアクセス権限管理、複数モデルの管理、リアルタイムおよび非同期の推論エンドポイント作成、ControlNet や LCM 等の高度な生成オプション、データセットの登録とLoRAによる転移学習などクリエイター向けに必要な機能と複数ユーザーで利用するための機能を備えており、これからも継続的な開発により新たな機能が追加されていく予定です。 ぜひ実際に Extension for Stable Diffusion on AWS をデプロイし、様々な機能を試してみてください。まずは小規模な環境で評価し、本番環境での運用を検討するとよいでしょう。このブログで紹介した Extension for Stable Diffusion on AWS の レポジトリ と ドキュメント なども参考にしてください。 著者プロフィール 前川 泰毅 (Taiki Maekawa) は AWS Japan のソリューションアーキテクトでメディア領域のお客様中心にアーキテクチャ設計や構築を支援しています。機械学習領域を得意としておりソリューションやサンプルコードの作成を行っています。

企業は、よくある質問 (FAQ) やナレッジ記事などのセルフサービス機能をウェブサイトやモバイルアプリに公開し、顧客の疑問の解決を支援しています。 このとき、解決しなかった疑問について顧客がエージェントに問い合わせると、ウェブサイトやアプリで入力または閲覧した内容を、再度尋ねられることがよくあります。 このため、企業はサードパーティのウェブ通話、画面共有、またはビデオ通話アプリケーションを導入し、顧客がウェブサイトやモバイル機器から電話をかけられるようにしています。 その結果、エージェントは従来の電話とウェブベースの通話をサポートするために、さまざまなアプリケーション間を行き来しなければなりません。さらに企業は、平均処理時間などの基本的なカスタマーサービス指標を把握するために、さまざまなデータソースを集計する必要があります。 Amazon Connect では、ウェブサイトやモバイルアプリケーションからパーソナライズされた音声およびビデオエクスペリエンスを提供できる アプリ内通話、ウェブ通話、ビデオ通話 の機能が提供されました。 この機能は、 マネージド通信ウィジェット または ソフトウェア開発キット (SDK) を使って簡単に実装できます。 顧客は、ウェブサイトやモバイルアプリを切り替えることなく、エージェントと通話を開始できます。 また、 コンテキスト情報 をエージェントのソフトフォンに渡すこともできます。 これを利用し、顧客の情報、認証ステータス、アプリ内の過去のアクションなどの属性に基づいて、顧客体験をカスタマイズできます。この結果、エージェントの処理時間の短縮と顧客満足度の向上が期待できます。 このブログ記事では、お客様がウェブページからウェブ通話とビデオ通話を開始する場合のサンプルユースケースを順に説明します。また、Amazon Connect の アプリ内通話、ウェブ通話、ビデオ通話 を使用して、顧客情報をエージェントに転送する方法を示します。 ソリューションの概要 図 1 . フォームを備えたウェブサイトとAmazon Connect のアプリ内通話、ウェブ通話、ビデオ通話を統合したソリューションのアーキテクチャ このソリューションでは、サンプルウェブサイトを Amazon CloudFront でホストし、静的なウェブサイトのコンテンツを Amazon S3 に格納します。 顧客がウェブサイトのフォームを送信すると、属性が Amazon API Gateway 経由で AWS Lambda に送信されます。 その後、 AWS Lambda は新しいリクエストに対して JSON Web トークン (JWT) を発行し、認証資格情報を AWS Systems Manager パラメータから取得します。 コミュニケーションウィジェットの JavaScript がウェブサイトに読み込まれ、Amazon Connect へ通話を開始します。 これにより、顧客とエージェントが音声とビデオでシームレスにつながります。 前提条件 このハンズオンチュートリアルでは、読者が次のリソースについて理解し、アクセスできることを前提としています。 Amazon Connect、Amazon API Gateway、AWS Lambda、AWS CloudFormation、Amazon CloudFront に管理者権限のある AWS アカウントを利用できること Amazon Connect インスタンス が構築済みであること ローカル環境に AWS CLI がインストールされ設定済みであること AWS Cloud Development Kit (CDK) 環境がインストール済みであること。インストールされていない場合は Step 1の構築手順を実行してください。また、AWS Cloud9 を利用することもできます。 ウォークスルー Step 1: 準備 AWS CDK をインストール (すでにインストール済みの場合はスキップ) し、CDK 環境を構築してください。 npm -g install typescript npm -g install aws-cdk cdk bootstrap aws://ACCOUNT_ID/AWS_REGION Git を利用して、GitHub からリポジトリをクローンしてください。 git clone https://github.com/aws-samples/web-voice-video-calling-blog CDK プロジェクトと AWS Lambda 関数の依存関係をインストールします。 cd web-voice-video-calling-blog mkdir -p lambda-layers/jwt-layer/nodejs npm install jsonwebtoken --prefix lambda-layers/jwt-layer/nodejs npm install AWS CLI プロファイルを使って CDK プロジェクトをデプロイします。 これにより、プロジェクトに必要な Amazon CloudFront、Amazon API Gateway、AWS Lambda、AWS Systems Manager のリソースがデプロイされます。 cdk deploy Do you wish to deploy these changes (y/n)? には y を入力します。 (このプロジェクトでは cdk バージョン 2.127.0 を使用しています。アップグレードが必要な場合は、 npm install -g aws-cdk —force を実行してください) CDK のデプロイが完了したら、このスタックの `出力` タブを開き、Amazon API Gateway エンドポイントと Amazon CloudFront ウェブサイトの URL の値を書き留めてください。 AcWebCallingStack.Endpoint8024A810 = https://aaaaaaaa.execute-api..amazonaws.com/prod/ (あなたの Amazon API Gateway) AcWebCallingStack.websiteURL = https://aaaaaa.cloudfront.net (あなたの Amazon CloudFront ウェブサイトの URL) Step 2: コミュニケーションウィジェットの設定 Amazon Connect インスタンス を開き、チャネル > コミュニケーションウィジェット に移動します。 ウィジェットを追加をクリックします。 名前に「ac_widget_webcalling」と入力し、説明フィールドに「Widget for web and video calling」と入力してください。 コミュニケーションのオプションの 「チャットを追加」のチェックを外します。 図 2 . Amazon Connect コミュニケーションウィジェット作成画面 ウェブ通話コンタクトフロー で、「 Sample inbound flow (first contact experience) 」を選択します。 保存して続行 をクリックします。 次の画面のオプションはすべてデフォルトのまま下までスクロールして、 保存して続行 をクリックしてください。 コミュニケーションウィジェットに必要なドメインを追加する において、Step 1.5 でメモしておいた Amazon CloudFront ウェブサイトの URL のドメインを記入します。 新しいコミュニケーションウィジェットのリクエストにセキュリティを追加するは「 はい 」を選択してから、 保存して続行 をクリックしてください。  次の画面のウィジェットのスクリプトで スクリプトをコピー をクリックして、テキストエディタにコピーしてください。 コピーされたスクリプトから widgetId を控えておいてください。この widgetId は後のStep 4.5 で使用します。widgetId を見つけるには、 コミュニケーションウィジェットスクリプトの例 （リンク先のアンダーライン部分）を参照してください。 キーをコピー をクリックし、テキストエディタに保存します。これは後のStep 4.3 で使用します。 Step 3: index.html の API エンドポイントとウィジェットスクリプトの値を編集 Step 1.2 でクローンしたフォルダ内の「website」フォルダにある index.html ファイルを編集します。 127 行目の apiEndpoint を自分の環境の Amazon API Gateway Endpoint の値で更新します (Step 1.5 を参照) 図 3 . index.html の更新 index.html の 115 行と 123 行の間に、手順 2.10 (コミュニケーションウィジェット設定) でコピーした スクリプト を追加し、ファイルを保存します。 重要 :コピーしたスクリプトから 最初の行の</script>および最後の行の<script>を削除してください。 AWS CLI から、CDK プロジェクトを再デプロイしてください。これにより、リソースの変更が反映されます。 cdk .. cdk deploy Step 4: AWS Systems Manager のセキュリティキーと Widget ID の更新 AWS マネジメントコンソール にログインし、 AWS Systems Manager に移動して、メニューから アプリケーション管理 の下にある パラメータストア をクリックしてください。 一覧から /Blog/AcWebCalling/AmazonConnect/ConnectSecret をクリックし、 編集 をクリックしてください。 値 フィールドに、Step 2.12 (コミュニケーションウィジェットの設定) で保存したセキュリティキーを入力し、 変更を保存 をクリックします。 図 4 . パラメータストア内のセキュリティキーの更新 /Blog/AcWebCalling/AmazonConnect/WidgetId をクリックし、 編集 をクリックしてください。 値 フィールドに、Step 2.11 で保存した widgetId を入力し、 変更を保存 をクリックしてください。 Step 5: Amazon Connect ステップバイステップガイドの設定 Amazon Connect ステップバイステップガイド を使用すると、ウェブサイトから渡された属性をエージェントワークスペースで確認できます。今回は、以下に記載する 2 種類のフローをインポートして設定します。 5.1 ステップバイステップガイドのビューフローの作成: ac_webcalling_SBSguide_view フロー をダウンロードします。リンク先の git ページから raw ファイルをダウンロードしてください。 Amazon Connect インスタンス を開き、 ルーティング > フロー を選択し、 フローを作成 を選択してください。 右上のドロップダウンの矢印を押して インポート (ベータ) を選択し、Step 5.1.1 でダウンロードしたフローをインポートします。 公開 をクリックします。 5.2 着信コールフローの作成 ac_webcalling_SBSguide_handler フロー をダウンロードしてください。リンク先の git ページから raw ファイルをダウンロードしてください。 Amazon Connect インスタンス を開き、 ルーティング > フロー を選択し、 フローを作成 を選択してください。 右上のドロップダウンの矢印を押して インポート (ベータ) を選択し、Step 5.2.1 でダウンロードしたフローをインポートします。 公開 をクリックします。 5.3 着信コールフローとステップバイステップフローの更新 Step 5.1 で作成した ac_webcalling_SBSguide_view フローを開きます。 フローエディタの左下にある 追加のフロー情報を表示 をクリックして展開します。 作成した ac_webcalling_SBSguide_view フローの フロー ID をコピーします。 Step 5.2 で作成した ac_webcalling_SBSguide_handler フローを開きます。 コンタクト属性の設定 ブロックを開きます。 図 5 . 着信コールフローの更新 Step 5.3.3 でコピーしたフロー ID を DefaultFlowForAgentUI の値に設定します。この属性は、通話がエージェントにルーティングされたときに、エージェントに表示されるステップバイステップのガイドを指定します。注: 「ENTER ac_webcalling_SBSguide_view FLOW ID HERE」を ac_webcalling_SBSguide_view のフロー ID に置き換えてください。 コンタクト属性の設定ブロックを 保存 して閉じます。 作業キューの設定 ブロックを開きます。 このブロックでは、ソリューションのテスト中に使用するキューを設定します。既存のコンタクトセンターの運用に影響を与えないキューを選択することをお勧めします。 作業キューの設定 ブロックを保存して閉じ、 公開 をクリックして更新したフローを発行します。 Step 6: コミュニケーションウィジェットの更新 Amazon Connect インスタンス を開き、 チャネル > コミュニケーションウィジェット を選択します。 ac_widget_webcalling をクリックし、詳細セクションで 編集 をクリックしてください。 ウェブ通話コンタクトフローで、フローを ac_webcalling_SBSguide_handler に変更し、 保存して続行 をクリックしてください。 図 6 . Amazon Connect のコミュニケーションウィジェットの更新 保存して続行 をクリックします。 保存して続行 をクリックします。 Step 7: Amazon Connect セキュリティプロファイルの更新 エージェントがビデオ通話とステップバイステップのガイドを利用できるようにするには、セキュリティプロファイルにコンタクトコントロールパネル (CCP) とエージェントワークスペースの権限を追加する必要があります。権限の追加には次の手順を実行します。 Amazon Connect インスタンス を開き、 ユーザー > セキュリティプロファイル を選択します ステップバイステップガイドの作成とアクセスを許可するセキュリティプロファイルをクリックします。 数字とフロー をクリックして展開します。 ビュー の横にある「 すべて 」のチェックボックスをクリックします。 エージェントアプリケーション をクリックして展開します。 カスタムビュー の横にある「 すべて 」のチェックボックスをクリックします。 コンタクトコントロールパネル (CCP) をクリックします。 ビデオ通話 の横にある「 アクセス 」のチェックボックスをクリックします。 図 8 . セキュリティプロファイルのコンタクトコントロールパネル設定 右上の 保存 をクリックします。 テスト 上記のステップで設定したセキュリティプロファイルを使用したエージェントとして Amazon Connect エージェントワークスペース にログインします。 ブラウザで Amazon CloudFront の URL (Step 1.5 参照) を開き、Contact Us フォームに任意の情報を入力・選択します。 Submit をクリックしてください。 図 9 . Amazon Connect in-app, web, and video callingの通話開始デモ画面 画面右下の電話アイコンをクリックするとエージェントとの通話が開始します。ビデオ通話を開始するには、 Start Video アイコンをクリックしてください。 通話がエージェントワークスペースに着信したら、通話を受信 をクリックします。エージェント側でもビデオを有効にします。ウェブサイトで入力・選択した値がエージェントワークスペースにビデオや音声通話とともに表示されます。 図 10 . Amazon Connect in-app, web, and video callingのエージェント側画面 ウェブサイト上では、顧客はエージェントとビデオや音声で対話ができます。 図 11 . Amazon Connect in-app, web, and video calling の顧客側デモ画面 クリーンアップ AWS CLI から、web-voice-video-calling-blog ディレクトリに移動してください。 cd web-voice-video-calling-blog 「cdk destroy」を実行すると、Amazon CloudFront、Amazon API Gateway、AWS Lambda、AWS Systems Manager にインストールされたリソースが削除されます。 cdk destroy  [ オプション ] ac_webcalling_SBSguide_handler フローと ac_webcalling_SBSguide_view フローの両方について、 delete-contact-flow コマンドを実行します。 結論 このブログ記事では、新しい Amazon Connect のアプリ内通話、ウェブ通話、ビデオ通話機能 について説明しました。 完全にマネージドされたコミュニケーションウィジェット を使用することで、企業はウェブサイトやモバイルアプリケーションにこの機能を数クリックで実装できます。 顧客が接続されると、顧客情報 (VIP 会員など) や他の情報 (ウェブサイトのページなど) に基づいて顧客体験をパーソナライズできるようになります。 これにより、コンタクトに優先順位を付けたり、可能な場合は自動的に解決したり、必要な場合は最適なエージェントにルーティングすることができます。 著者について​ Pavan Dusanapudi  は、イギリスのマンチェスターを拠点とするアマゾン ウェブ サービスの AWS アプリケーションセールスに所属するスペシャリストソリューションアーキテクトです。彼は、カスタマーエクスペリエンスソリューションとデジタルトランスフォーメーションを通じて、顧客がビジネス成果を達成できるよう支援しています。余暇には、家族でのハイキング、クロスフィットワークアウトを楽しみ、心の平穏を見つけています。 Prabhakar Rajasekar は、ドイツのアーヘンを拠点とするアマゾン ウェブ サービスの AWSI アプリケーションセールスに所属するスペシャリストソリューションアーキテクトです。顧客のデジタルトランスフォーメーションを支援する傍らで、庭や森の中で子供たちと時間を過ごすことを楽しんでいます。 翻訳は Amazon Connect スペシャリストソリューションアーキテクト清水が担当しました。原文は こちら です。

はじめに クラウドガバナンスに生成 AI を組み込むことで、AWS アカウントの管理をより自動化された効率的なプロセスに変えることができます。 Amazon Bedrock  の生成 AI 機能と、 AWS Control Tower や  Account Factory for Terraform (AFT) などのツールを活用することで、お客様は AWS アカウントのセットアップと管理プロセスを迅速化し、ベストプラクティスを守りながら開発工数を最小限に抑えることができます。 お客様は、AWS アカウントをプロビジョニングする際に、様々な組織の要件と AWS のベストプラクティスを考慮して設定を行う必要があります。そのため、AWS アカウントのカスタマイズに少なからず開発工数を費やすこととなります。 本ブログでは、AWS アカウント作成プロセスのオーケストレーションにおける  Agents for Amazon Bedrock の優秀性について解説します。Agents for Amazon Bedrock は、新しい AWS アカウントの作成リクエストやアカウントカスタマイズ用コードの作成など、お客様から要求されたタスクのオーケストレーションを自動化し、そのためのプロンプトを自動的に作成します。さらに、エージェントが Knowledge Bases for Amazon Bedrock  で作成されたナレッジベースに接続されている場合は、ナレッジベースから取得した情報（例: お客様固有の情報）をプロンプトに追加し、お客様に自然言語で応答するための API を呼び出します。また、AWS アカウントをプロビジョニングする際には AFT も利用します。AFT は Terraform パイプラインを設定し、AWS Control Tower 内で AWS アカウント作成とカスタマイズを行います。AFT を使用するには、お客様は Terraform 設定ファイルに AWS アカウントの作成で 必要となる情報 を記載し、リポジトリにコミットする必要があります。リポジトリにコミットされると Account Factory ワークフローが自動的に実行され AWS アカウントが作成されます。Account Factory ワークフローの完了後に追加のカスタマイズのステップを自動的に実行します。 次のセクションでは、Agents for Amazon Bedrock と基盤モデル ( Claude 2.1 ) を使用し、 AWS セキュリティリファレンスアーキテクチャ (SRA) における「 セキュリティツールアカウント 」をプロビジョニングするユースケースにおいて IaC を加速させる方法について詳しく説明します。最後に、Amazon Bedrock から生成された IaC コードをデプロイする方法と、AFT を通じてインフラストラクチャのデプロイをスケールする方法を学びます。 ソリューションの概要 訳者注: 本ソリューションは、非 IT 技術者がチャットインタフェースを通して AWS アカウントを作成するような Agents for Amazon Bedrock の社内利用におけるユースケースのサンプルとして捉えていただければと思います。本ブログではセキュリティツールアカウントのプロビジョニングに焦点を当てておりますが、AWS のセキュリティサービスは Organizations と連携することで、個々の AWS アカウントでセキュリティサービスを有効化することなく複数のメンバーアカウントに対して一括で有効化することも可能です。 ソリューションのデプロイ方法について詳しく説明する前に、本ブログで構築する図 1 のアーキテクチャにおける各処理について見ていきましょう。 図1：AFT と Amazon Bedrock を利用した「セキュリティツールアカウント」作成の例 ユーザーは Agents for Amazon Bedrock のマネジメントコンソールにあるチャットを利用して、作成する AWS アカウントの要件を入力します。例えば、「セキュリティツール用の AWS アカウントを作成する」と入力します。エージェントには、AFT を利用して AWS アカウントを作成・カスタマイズするためのプロンプトと Knowledge Bases for Amazon Bedrock の設定が行われています。 上記例のような入力を受け取ると、エージェントは、セキュリティツール用の AWS アカウントに推奨される AWS セキュリティサービスをナレッジベースから取得します。エージェントは、推奨される AWS サービスをユーザーに提示します。ユーザーは提示された AWS サービスから、AWS アカウント作成時に有効化しておきたい AWS サービスの名前を入力します。 次に、エージェントはアカウント作成に必要な情報をユーザーの入力から収集します。ユーザーが選択した AWS サービスに基づき、エージェントは AWS サービスの情報をアクショングループに渡し、 AWS Lambda 関数を呼び出します。Lambda 関数は、Terraform モジュールとパラメータをナレッジベースから取得し Terraform 設定ファイルを作成します。作成したコードを AFT アカウントカスタマイズリポジトリ ( learn-terraform-aft-account-customizations  からクローンした自身のリポジトリ) にプッシュします。次のアカウント作成のステップに進む前に、エージェントはユーザーに AFT アカウントカスタマイズリポジトリにプッシュした Terraform 設定ファイルで問題ないかを確認します。 ユーザーから「確認」の入力を受け取ると、エージェントは AFT による AWS アカウント作成用の Terraform 設定ファイルを作成し、AFT アカウントリクエストリポジトリ ( learn-terraform-aft-account-request  からクローンした自身のリポジトリ) にプッシュする Lambda 関数を呼び出します。リポジトリにプッシュされると  AWS Control Tower Account Factory for Terraform (AFT) パイプラインがトリガーされます。 次に、AFT パイプラインはサービスカタログ製品を呼び出します。この製品により、特定の OU に AWS アカウントが登録され、 AWS Control Tower と AWS Organizations を利用したガードレールが適用されます。 最後に、セキュリティツール用の新しい AWS アカウントがプロビジョニングされ、Security OU に登録されます。プロビジョニングされた AWS アカウントでは、ユーザが入力した AWS セキュリティサービスが有効化されています。 前提条件 1. このワークフローを使用して AWS アカウントを管理するには、Organizations 管理アカウントの Admin 権限、AWS アカウント設定を行うための Terraform の知識、および適切な AWS Identity and Access Management (IAM) の権限が必要です。また、AWS Control Tower と AFT が設定されており、AFT リポジトリと AWS Control Tower のマルチアカウント環境における役割を理解している必要があります。 2. 以下の理解も必要になります。 Agents for Amazon Bedrock 、 プロンプト 、 Knowledge Bases for Amazon Bedrock AFT モジュールのサンプル および チュートリアル learn-terraform-aft-account-request  リポジトリ learn-terraform-aft-account-customizations  リポジトリ デプロイ手順 このソリューションは、 AWS セキュリティリファレンスアーキテクチャ (SRA) に従い、セキュリティツール用、インフラストラクチャ用、ワークロード用などの各種 AWS アカウントを作成し、それぞれに対応する AWS サービスをデプロイするのに活用できます。本ブログでは、セキュリティツール用アカウントの作成と、推奨される AWS セキュリティサービスのデプロイにフォーカスして説明します。このソリューションをデプロイするには、以下の 4 つのステップを実施します。 ステップ 1 : ナレッジベースを設定する:  ナレッジベースを設定することで、エージェントが AWS アカウントのプロビジョニングに必要な情報にアクセスできるようになります。ナレッジベースを設定するには、次の手順に従います。 Amazon Bedrock コンソール を開き、左側のナビゲーションパネルで [ナレッジベース] を選択し、 [ナレッジベースを作成] を選択します。 [ナレッジベース名]  にナレッジベースの名前を入力します。「AWS-Account-Setup-Knowledge-Base」のように、ナレッジベースの目的を明確に表す名前にすることを推奨します。 [IAM 許可]  では IAM ロールを選択します。 [既存のサービスロールを使用]  から必要な権限を有する既存の IAM ロールを選択することもできますが、 [新しいサービスロールを作成して使用]  を選択し、適切な権限を有する IAM ロールを作成するのが推奨されます。 [データソースを設定]  では、データソースを定義します。セキュリティのため、暗号化を有効にした Amazon Simple Storage Service (Amazon S3)  バケットを作成し、 [S3 URI] に指定します。Amazon S3 バケットには、AWS サービスと対応する Terraform モジュールのリストが記載されている JSON ファイルをアップロードします。JSON ファイルの構造については、リポジトリで提供されている サンプル を参照してください。 訳者注：利用する際は、ModuleSource などをお客様が利用している実際のモジュールにあわせて変更してください [埋め込みモデル]  では、埋め込みモデルとして  [Titan  Embeddings G1 – Text] を選択します。 [ベクトルデータベース]  では、ベクトルストアを選択します。ここでは、 [新しいベクトルストアをクイック作成 – 推奨] を選択し、Amazon Bedrock に Amazon OpenSearch Service  を利用したベクトルストアの作成と管理を任せます。 レビューして最終確認をします。入力した全ての情報を正確性の観点から確認します。特に Amazon S3 バケット URI と IAM ロールを注意深く確認してください。問題なければ [ナレッジベースを作成] を選択します。 以下のバナーが表示されたら、 [同期] を選択します。  ステップ 2 : エージェントを設定する: Amazon Bedrock コンソール を開き、左側のナビゲーションパネルで [ エージェント] を選択し、 [エージェントを作成] を選択します。 [エージェント名] 、 [エージェントの説明 – オプション ] などのエージェントの詳細を入力します。 [IAM 許可]  では IAM ロールを選択します。 [既存のサービスロールを使用]  から必要な権限を有する既存の IAM ロールを選択することもできますが、 [新しいサービスロールを作成して使用]  を選択し、適切な権限を有する IAM ロールを作成するのが推奨されます。これにより、エージェントに AWS Lambda などの必要なサービスへのアクセス権が与えられます。 [モデルの詳細] から [Anthropic] 、 [Claude V2.1] を選択します エージェントを介して AFT を実行するために、以下のプロンプトを [エージェント向けの指示] に入力します “ Assist users in creating AWS accounts based on account type. Ask user which AWS account type(customization name) they would like to create: Security or Infrastructure AWS account. Ask user which AWS services they would like to deploy for their chosen account type. DO NOT assume AWS services for account type, ask user. Query the knowledge base for the approved AWS services list for the selected AWS account type. Present the AWS services to the user for service selection. Collect required user details for the account creation, for e.g.; “Please provide first name, last name, organization unit, account email and name”. Upon AWS services selection, invoke the account customization Lambda to generate the appropriate Terraform code. After successful execution of account customization lambda provide users repository link and ask for user confirmation of terraform code before triggering the AWS account creation lambda. Ask user to update code if needed. DO NOT trigger account creation lambda unless you receive confirmation from user. After user confirmation, initiate the account creation Lambda. Let the user know the account has been created with the customization. “ ステップ 3 : アクショングループを設定する:  AFT による AWS アカウント作成とカスタマイズを可能にするために、エージェントに 2 つのアクションを追加します。 アカウントカスタマイズ用のアクショングループ:  アカウントカスタマイズ用の Terraform 設定ファイルを生成する Lambda 関数（Lambda 関数を作成するには こちら の手順を参照）にリンクされたアクショングループを作成します。このアクショングループは、AWS アカウントにプロビジョニングする必要がある AWS サービスをユーザーが入力した後、エージェントによって呼び出されます。Terraform 設定ファイルは「learn-terraform-aft-account-customizations」リポジトリにプッシュされます。AFT はこのリポジトリを使用して、新しく作成された AWS アカウントに特定の設定を適用します。Lambda 関数のコードは、 こちら のリポジトリを参照してください。 アカウント作成用のアクショングループ: AFT を使用して AWS アカウントを作成する Lambda 関数にリンクされたアクショングループを作成します。このアクショングループは、ユーザーが Terraform 設定ファイルを確認し、「確認」と入力した後に呼び出されます。Lambda 関数のコードは、 こちら のリポジトリを参照してください。 ステップ 4 : アクショングループをエージェントに追加する: [アクショングループ名を入力] にアクショングループ名を入力し、 [説明 – オプション] に各アクションの動作の説明を記述します。 [ Lambda 関数を選択] では、適切な Lambda 関数を選択します。Lambda 関数は、アクションの呼び出し時に実行されるビジネスロジックを提供します。 [関数のバージョン] から使用する関数のバージョンを選択します。詳細については、「 Amazon Bedrock でエージェントのアクショングループの Lambda 関数を定義する 」をご覧ください。 [API スキーマを選択] では、アクショングループの API の説明、構造とパラメータが定義された OpenAPI スキーマの Amazon S3 URI へのリンクを定義します。API はユーザーの入力を受け取り、アカウント作成とカスタマイズの Lambda 関数を呼び出すロジックを管理します。API は、ユーザー入力値の検証、Terraform 設定ファイルの作成プロセスの開始、アカウントプロビジョニングのステータス監視など、さまざまなタスクを処理できるよう設計する必要があります。詳細については、「 Amazon Bedrock でエージェントのアクショングループの OpenAPI スキーマを定義する 」をご覧ください。 [別のアクショングループを追加]  を選択して、もう 1 つのアクショングループを設定します。アカウントカスタマイズ用およびアカウント作成用のアクショングループを追加後、 [次へ]  を選択します。 [ナレッジベースを追加 – オプション] では、 [エージェント向けのナレッジベースの指示] に「Retrieve AWS services for AWS Account type such as Security or Infrastructure」と入力します。 エージェントの作成完了後、 [テスト] と表示されたウィンドウよりエージェントの動作確認を行うことができます。 図 2 は、Amazon Bedrock を使ってユーザーが「セキュリティツール用アカウント」を払い出すときの操作画面のスクリーンショットです。 図 2 : AFT を利用した「セキュリティツール用アカウント」作成における Amazon Bedrock とユーザの対話例 クリーンアップ 不必要な課金を避けるために、テスト中に作成したリソースを削除してください。リソースをクリーンアップするには、以下の順序どおりに手順を実行します。 ナレッジベースの削除 エージェントから関連付けられているナレッジベースを削除するには、次の手順を実行します。 Amazon Bedrock コンソール を開きます。 左側のナビゲーションペインから [エージェント] を選択します。 ナレッジベースを削除したいエージェントの [名前] を選択します。 [Edit in Agent Builder]  を選択します。   削除するナレッジベースの横にあるラジオボタンを選択し、 [Delete]  を選択します。 削除の確認画面が表示されるため、「delete」と入力し [Delete]  を選択します。 左側のナビゲーションペインから [ナレッジベース] を選択します。 削除したいナレッジベースの [名前] を選択します。 データソースを削除するには、データソースの横にあるラジオボタンを選択して [削除] を選択します。 データソースの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「削除」と入力し、 [削除] を選択して確定します。 削除するナレッジベースの横にあるラジオボタンを選択し、 [削除]  を選択します。 ナレッジベースの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「削除」と入力し、 [削除] を選択して確定します。 訳者注: 翻訳時点では、警告に記載の「削除」ではなく「delete」と入力することで削除可能です。 Amazon OpenSearch Service コンソール より、Amazon OpenSearch Serverless のコレクションを削除します。 訳者注: 原文にはございませんが、コレクションを削除しない限り 料金 が発生し続けてしまいますのでご注意ください。  次の「エージェントの削除」手順を実行する前に、エージェントから関連付けられているナレッジベースを削除していることを改めて確認してください。 エージェントの削除 Amazon Bedrock コンソール を開きます。 左側のナビゲーションペインから [エージェント] を選択します。 削除するエージェントの横にあるラジオボタンを選択します。 エージェントの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「delete」と入力し、 [Delete] を選択して確定します。 エージェントが削除されていることを知らせる青色のバナーが表示されます。削除が完了すると、成功を知らせる緑色のバナーが表示されます。 その他すべてのリソースを削除 これには AWS Lambda 関数と AFT が利用している AWS サービスが含まれます。 まとめ 生成 AI の統合により、AWS アカウント管理がより自動化され、効率的なプロセスに変革します。 Amazon Bedrock の生成 AI 機能と、AWS Control Tower や Account Factory for Terraform (AFT) などのツールを活用することで、組織は開発工数を最小限に抑えつつ、ベストプラクティスに沿った AWS アカウントのセットアップと管理を迅速に行えるようになります。このアプローチは、単に運用を効率化するだけでなく、AWS 環境の構築において、セキュリティとコンプライアンスを開発のあらゆるフェーズに埋め込むことができます。 本ブログのソリューションは、AWS のベストプラクティスに従ってクラウドリソースを効率的かつ安全にプロビジョニングするための Amazon Bedrock と AFT を組み合わせたアーキテクチャ、デプロイメントコード、プロンプトをお客様の組織に提供しています。 著者について Shiva Vaidyanathan Shiva Vaidyanathan は AWS のプリンシパルクラウドアーキテクトです。AWS での成功を確実にするため、技術ガイダンスを提供し、お客様への実装プロジェクトの設計と指導を行っています。クラウドネットワーキングを誰にとってもシンプルなものにするために尽力しています。AWS に入社する前は、パブリッククラウドインフラストラクチャにおける安全なコンピューティングの実行に関する NSF の資金提供を受けた複数の研究イニシアチブに携わってきました。ラトガーズ大学でコンピューターサイエンスの修士号を、ニューヨーク大学で電気工学の修士号を取得しています。 Ebbey Thomas Ebbey Thomas は、生成 AI を活用してクラウドインフラストラクチャの自動化を強化することに重点を置いたカスタム AWS ランディングゾーンの戦略立案と開発を専門としています。AWS プロフェッショナルサービスでは、クラウドの導入を効率化し、AWS ユーザーに安全で効率的な運用フレームワークを提供するソリューションを設計する上で、Ebbey の専門知識が中心となっています。彼はクラウドの課題に対する革新的なアプローチと、クラウドサービスの機能をさらに発展させることへの取り組みで知られています。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 この1,2週、寒暖差のせいか周りに体調を崩す人が増えているように思います。みなさんもお気をつけください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月15日週の主要なアップデート 4/15(月) AWS PrivateLink now supports Amazon QuickSight AWS PrivateLinkがAmazon QuickSightをサポートしました。これにより多くのトラフィックをパブリックインターネットに公開することなくアクセスすることや、VPCエンドポイントポリシーを使用して承認されていないQuickSightアカウントへのアクセスを制限することができます。注意点として、静的コンテンツの取得には引き続きcloudfrontへのアクセスは必要になります。この新機能は、Amazon QuickSightとAWS PrivateLinkが利用できるすべてのAWSリージョンで利用いただけます。 Amazon QuickSight now supports account instances of IAM Identity Center Amazon QuickSightがIAM Identity Centerのアカウントインスタンスをサポートしました。これまではIAM Identity Centerの組織インスタンスが必要でしたが、今回のアップデートによりスタンドアロンのAWSアカウントや組織のメンバーアカウントでもIAM Identity Center経由の管理が可能になります。すでにアカウントインスタンスを利用の場合、Redshift、Lake Formation、Athena、EMR、CodeCatalystなどその他の対応アプリケーションと管理を合わせることができます。この新機能は、Amazon QuickSightとIAM アイデンティティセンターが利用できるすべてのAWSリージョンで利用可能です。 Amazon RDS for Oracle extends support for x2iedn in additional AWS regions 大阪リージョンを含む8のリージョンで新たにAmazon RDS for OracleのX2iednインスタンスをご利用いただけるようになりました。Amazon RDS for Oracle X2iedn は、高い計算能力 (最大128vCPU)、大容量メモリ (最大4TB)、およびストレージスループット要件 (最大256,000IOPS)を備え、 大量のデータセットをメモリで処理するワークロードに高速なパフォーマンスを提供するように設計されています。 Amazon RDS Custom for Oracle now supports Oracle Database Standard Edition 2 Amazon RDS Custom for OracleがOracle Database Standard Edition 2 (SE2)をサポートしました。Amazon RDS Custom for Oracle は、Oracle データベースエンタープライズエディション (EE) に加え、今回SE2をサポートしましたが、EE、SE2ともBring Your Own Media （BYOM）モデルでのみ使用できます。詳細については Amazon RDS Custom for Oracle ユーザーガイド をご確認ください。 4/16(火) Anthropic’s Claude 3 Opus model now available on Amazon Bedrock Anthropic社の最も先進的で高性能なモデルであるClaude 3 OpusがAmazon Bedrockで利用可能になりました。これによりAnthropic社の最先端モデルのClaude 3 ファミリー(Claude 3 Opus, Claude 3 Sonnet, and Claude 3 Haiku)が全てAmazon Bedrock経由でご利用いただけます。Claude 3 Opusは米国西部 (オレゴン) リージョンでご利用可能です。詳細については ドキュメント の他、 ブログ もご確認ください。 Monitor internet outage using the weather map in CloudWatch Internet Monitor Amazon CloudWatch Internet Monitorでインターネットウェザーマップを無料でご利用いただけるようになりました。インターネットウェザーマップでは、インターネットのレイテンシーと可用性の停止に関する 24時間のグローバルスナップショットを共有しています。このマップでは、特定の都市やサービスプロバイダーを含む、世界中の最近のインターネット問題を一目で確認できます。詳細については ドキュメント と、こちらの ブログ もご確認ください。 Amazon MWAA adds larger environment sizes Amazon Managed Workflows for Apache Airflow (MWAA)でより大きな環境サイズが提供されました。これまではsmall, medium, largeの中から選択可能でした。これらに加えてlargeの2倍のXL, 及びlargeの4倍の2XLが新たに追加されました。新規の作成もしくはアップグレードで選択可能です。このアップデートはすべてのAmazon MWAA提供リージョンで利用可能です。詳細についてはこちらの ブログ をご確認ください。 AWS CloudFormation ChangeSets now offer enhanced change visibility for deployments AWS CloudFormationの変更セットが強化され、デプロイ時に実行されるアクションの詳細をプレビューできるようになりました。これによりデプロイによって実行中のリソースに意図しない変更が発生するかどうかを評価しやすくなります。今回の強化では!Refや!GetAtt などによる参照やAWS Secrets Manager and Parameter Store、Systems Managerの動的参照もプレビューすることができるようになります。変更セットの強化は、コンソールのほか、AWS CLIまたはSDKからの場合は、DescribeChangeSet APIの呼び出し時に–include-property-valuesパラメータを含めてください。このアップデートはCloudFormationが利用可能なAWSリージョンでご利用いただけます。 Amazon Athena announces federated query pass-through Amazon Athenaのfederated query pass-throughが発表されました。Athenaには従来からfederated queryというAmazon Redshift、Amazon DynamoDBなどのデータソースのデータを抽出する機能がありました。今回のリリースではこの機能が強化され、SQLをデータソースにパスし、データソース独自のSQLが実行できるようになりました。federated query pass-throughはAthenaが利用可能なすべてのAWS リージョンで利用できます。詳細については ドキュメント をご確認ください。 4/17(水) AWS launches Split Cost Allocation Data for Amazon EKS AWS コストと使用状況レポート (CUR) でAmazon EKSのコストを詳細に把握できるようになりました。Amazon EKS の分割コスト配分データを使用すると、コンピューティングとメモリの使用率に基づいてポッドレベルのコストをきめ細かく把握できるので、これらのコストをクラスタ、名前空間、その他の Kubernetes プリミティブごとに集計して、個々のビジネスユニットやチームにコストを割り当てることができます。加えてお客様は未使用のCPUまたはメモリリソースを特定できるため、クラスター構成を最適化して非効率性を最小限に抑えることができます。これらのコストデータは設定後24時間以内にAWS CURで利用できるようになります。このアップデートは中国を除くすべてのAWS商用リージョンで利用できます。詳細については こちらのブログ をご確認ください。 Amazon SageMaker Studio Notebooks supports interactive data exploration and SQL query execution Amazon SageMaker StudioのJupyterLab ノートブックに拡張機能が組み込まれました。これによりノートブックからSQLとPythonを使用して複数データソースを検索、調査、変換することが可能になります。今回の拡張機能によりAWS Glue 接続を介して Amazon Athena、Amazon Redshift、Snowflake などの一般的なデータサービスにシームレスに接続できるようになりました。機械学習をノートブックの統一されたユーザーインターフェイスに統合することで、分析や機械学習のタスクに取り組む際にツールを切り替える必要性を減らし、時間を大幅に節約し、生産性を向上させることができます。この機能は、SageMaker Studio が利用可能なすべての商用 AWS リージョンで利用できます。詳細については、 ブログ もご確認ください。 Announcing Accessibility Conformance Reports (ACRs) in AWS Artifact Announcing Accessibility Conformance Reports (ACRs)がAWS Artifactで利用できるようになりました。ACRは AWSサービスのアクセシビリティを実証する文書で、ITI自主製品アクセシビリティテンプレート (VPAT®) を利用し、セクション 508 (米国)、EN 301 549 (EU)、ウェブコンテンツアクセシビリティガイドライン (WCAG) などのさまざまなアクセシビリティ基準を参照しています。 4/18(木) Meta Llama 3 foundation models now available on AWS Meta社の最新世代のファンデーションモデルであるLlama 3がAmazon SageMaker JumpStartで利用いただけるようになりました。東京を含む5つのリージョンでご利用いただけます。このアップデートの詳細は ブログ も出ているのでそちらもご確認ください。 AWS Neuron introduces speculative decoding and vLLM support AWS Neuronの２．１８がリリースされました。NeuronはAmazon EC2 Inferentia and TrainiumのためのSDKで、PyTorch や TensorFlow などの一般的なMLフレームワークと統合されています。またTrn1 インスタンスと Inf2 インスタンスでのジェネレーティブ AI モデルの高性能トレーニングと推論をサポートするコンパイラ、ランタイム、ツール、およびライブラリが含まれています。Neuron 2.18ではPyTorch 2.1のベータが外れた他、vLLMサポートによる継続的バッチ処理などが追加されています。詳細は リリースノート をご確認ください。 Amazon WorkSpaces helps simplify Bring Your Own License (BYOL) account management Amazon WorkSpacesで、同じリージョン内のAWSアカウントをリンクするAPIが提供されました。リンクされたアカウントは同じ専用のインフラストラクチャを使用できるため、Bring Your Own License (BYOL) WorkSpacesの管理が簡素化されます。詳細に関しては APIのリファレンス をご確認ください。 AWS IAM Identity Center adds independent 90-days session duration for Amazon CodeWhisperer AWS IAM Identity CenterでAmazon CodeWhispererのセッション期間を独立して設定できるようになりました。セッション時間は15分から90日の間で設定可能ですが、以前はAWSアクセスや他のアプリケーションと同様の時間が設定されるためにIDE経由で使う際も頻繁な再認証を求められることがありました。一方で、Amazon CodeWhispererに関しては同じ頻度の再認証が必ずしも必要ではないケースもあり、今回のアップデートで個別に設定できることで、開発者体験の柔軟性が増します。 4/19(金) AWS Elastic Disaster Recovery now supports AWS Outposts Racks AWS Elastic Disaster Recovery (AWS DRS) がAWS Outposts ラックに対応しました。これまではOutposts ラックのレプリケーションを取る際、またはリカバリ先として利用する際はCloudEndure Disaster Recoverを使う必要がありました。今回のアップデートはAWS DRSが利用可能なすべてのAWSリージョンでご利用いただけます。 Amazon Personalize now offers automatic solution training Amazon Personalizeでソリューションのトレーニングを自動で行うスケジュール設定をできるようになりました。より簡単にデータセットの情報をもとにユーザーの行動や好みの変化に合わせたリコメンデーションが可能になります。新しく作成されたソリューションは7日に1回自動的にトレーニングされる設定がされ、頻度の変更や設定の削除が可能です。また、アップデート前に作成された既存のソリューションは影響を受けず、自動で変更されません。詳細は ドキュメント をご確認ください。 Amazon EMR on EKS now supports Apache Livy Amazon EMR on Amazon EKSでApache Livyがサポートされました。Apache LivyはRESTインターフェイスを介してSparkクラスターと簡単にやり取りできるようにするサービスです。Amazon EMR on Amazon EKSではこれまでもStartJobRun APIおよびインタラクティブエンドポイント経由でRESTでのワークロードの実行ができましたが、より簡単に、アプリケーションの変更なく利用できるようになります。また、Kerberos、Custom AuthなどのサポートされるプロトコルでLivyエンドポイントへのアクセス制御も可能です。Apache Livyを搭載したAmazon EMR on Amazon EKSは現在サービスが利用可能なリージョンのEMR 7.1リリース以降でご利用いただけます。詳細は ドキュメント もご確認ください。 GW前後のAWSのイベントのアナウンスが出ています。AI関連が多いですが、よかったらぜひご登録ください。 ——————– ◆2024 年 4 月 25 日 (木) 10:00 – 11:15 生成 AI の業務活用に向けて考える “責任ある AI” ◆2024 年 5 月 9 日 (木) 10:00 – 11:10 流通・小売・消費財業界向け：クラウドと生成 AI による顧客接点改革 ◆2024 年 5 月 16 日 (木) 10:00 – 12:00 生成 AI の価値を最大限に引き出すためのデータ基盤 ◆2024 年 5 月 17 日 (木) 10:00 – 12:00 AWS メディアセミナー ～ NAB 2024 の recap と最新事例のご紹介 ～ ——————– 週刊AWSの更新ですが、次週はお休みして次回はGW明けになります。 それでは、また次回！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

デジタルトランスフォーメーションとは、デジタル技術を活用した戦略的なビジネス施策であり、ビジネスの成果を最大化することを目的としています。このブログでは、デジタルトランスフォーメーションへの反復的アプローチ、すなわちデジタルトランスフォーメーション・フライホイールを紹介します。Stellantis社との協業（ 2022年のアマゾンのプレスリリース を参照）の中から厳選した事例は、このフレームワークが Stellantis のデータドリブンかつソフトウェアにフォーカスしたモビリティ企業への変革をどのように可能にしたかを示しています（ 2024年のStellantis社 デア・フォワード2023 を参照）。 一般に、組織がデジタルトランスフォーメーションを必要とする背景には、いくつかのコンペリングイベント (差し迫った理由) があります。例えば、1/前年比の収益成長を促進する、2/変化のスピードや業界からのプレッシャーに対応するために事業ポートフォリオを最適化する、3/新しいデジタル製品やサービスを追加することによって事業やオペレーティングモデルを刷新する [2023年のHBRの記事 などを参照]、4/製品開発を加速するためにビジネスの俊敏性とスピードを向上させる[ 2008年のHBRの記事 などを参照] などがあります。このデジタルトランスフォーメーションで成功するために極めて重要な鍵は、長期におよぶトランスフォーメーションの戦略のための枠組み (ガードレール) を提供し、経営陣からのトップダウンに基づくデジタルトランスフォーメーションのためのビジネスケースを形成する企業のリーダーシップによる経営ビジョンです。 アマゾンが1994年に書籍のオンライン販売を開始し、2006年にクラウドサービスを提供して以来、デジタルトランスフォーメーションは私たちのDay 1 文化の中心であり [ 2024年 AWS Executive Insights を参照]、お客様を第一に考えることは不変の信念です。そのため、私たちはそれぞれの顧客のイニシアチブ (取り組み) を “Why？(なぜ？)”という質問から始めます。「Right thing (正しいもの) 」を構築することは、「Popular thing(人気のあるもの)」を構築することよりも重要だからです。デジタルトランスフォーメーションの枠組みの中では、デジタル変革の原動力となるコンペリングイベントを明確に理解しなければなりません。そのために、我々は以下の5つの質問に答えることを目的とした、一連のお客様から逆算するワークショップを実施しました [ 2021年 Working Backwards at AWS を参照] 。： お客様は誰か？ お客様の問題や機会は何か？ 最も重要なお客様の利益は何か？ お客様は何を望んでいるのか？ お客様の体験とはどのようなものか？ このお客様から逆算する方法論に裏打ちされた反復的な製品開発は、一つの円として循環し、一巡ごとにビジネス成果の価値をスケールアップさせます。アマゾンでは、この効果をフライホイールまたは好循環と呼んでおり[ 2012年 Youtube を参照]、アマゾンのイノベーション文化の最も古いコンセプトの一つです[ 2020年 Youtube を参照]。このコンセプトは、もともとジェフ・ベゾスがナプキンの上で考案したもので、お客様の体験を継続的に改善しながら顧客に執拗にこだわることで、企業の成長を実現するために用いられました。今日に至るまで AWS のイノベーション文化の一部であり続けています。 一般的にフライホイールという用語は、各構成要素がエネルギーを加えることで加速しながら回転する閉じたループのプロセスを指します。例えば、最初のループで顧客がウェブページ上で商品を返品できるようにした場合、2回目のループでは顧客が返品状況を追跡できるようにし、3回目のループでは顧客がオンラインで購入した商品をより良く評価できるようにするかもしれません。その結果、顧客返品プロセスは時間の経過とともに、より多くの機能によってより豊かになり、将来的には返品の数を減らすこともあるでしょう。 デジタルトランスフォーメーションそのものを反復的な変革プロセスとして捉えれば、同じ反復的なプロセスを継続的に適用することができます。ここでは、規模の大きな企業に対してデジタルトランスフォーメーションを開始し加速させるために、構築によって変革を進めるアプローチ (a transform-by-build approach)として「デジタルトランスフォーメーション・フライホイール」を紹介します。この新しいアプローチを図 1 に示します。デジタルトランスフォーメーション・フライホイールは、デジタルトランスフォーメーションを6つの相互に補強し合う連続した構成要素としてまとめられてます： 1/ 戦略的OKR (Objectives and Key Results 目標と主要な成果）、2/デジタル製品とサービスをスケールさせる、3/ビジネスプロセスを改善する、4/関係者をエンパワーメントする、5/組織を再構築する、6/イノベーション文化を醸成する。 図1：デジタルトランスフォーメーション・フライホイールは、戦略的OKR から始まる6つの相互に補強し合うドメインに沿ってデジタルトランスフォーメーションを説明します 01｜ 戦略的OKR (Objectives and Key Results 目標と主要な成果） フライホイールは、戦略的 OKR から始まります。戦略的 OKR とは、企業の経営層がデジタルトランスフォーメーションによって達成したいと考えるビジネス成果です。すでに述べてきたように、デジタルトランスフォーメーションは2020年のコロナウイルスの大流行による自動車サプライチェーンの混乱など、いくつかのコンペリングイベントによって引き起こされることもあります。テクノロジーを活用したデジタルトランスフォーメーションはそれ自体が目的ではなく、むしろ具体的なビジネス成果を実現するものだからです。そのためビジネス成果は組織のビジネスモデルと密接に結びついており、ビジネスモデルは顧客と従業員のために価値を創造する方法を定義しています。なお、ビジネス成果につながる活動にはインパクトの大きな活動とそうではない活動があるため、コスト削減の可能性やその他のKPIなどビジネスへのインパクトに応じて優先順位をつけることが重要です。 Stellantis との協業が始まった当初、私たちはエグゼクティブ ビジョニング ワークショップを開催し、説得力のある目指すべきビジョン (North star) のナラティブを作りました。それは Stellantis のデジタル化のミッションに対して、ビジネス成果のリストと優先順位で説明し、AWSがどのように支援できるかを説明しています。代表的なビジネス成果の1つは、 Stellantis の VEW (Virtual Engineering Workbench 仮想エンジニアリング ワークベンチ) と呼ばれる仮想シミュレーション環境を提供することで、自動車の製品開発を加速させることがあげられます。VEW は、オープンで自動化されスケーラブルなエンドツーエンドの開発者ツールとツールチェーンのまとまりから成り立ちます。そして、それらは自動車のハードウェアとソフトウェアのコンポーネントに対する仮想シミュレーション、テスト、検証、妥当性確認、機能統合のために使用されています [ 2024年 AWS Blogの投稿 , 2023年 AWS Blogの投稿 , 2023年 Youtube を参照]。もう一つの代表的なビジネス成果は、Stellantis の DIA (Data Infrastructure Architecture データ基盤のアーキテクチャ)を通して、Stellantis にコネクテッドビークルのデータの可視性を与えることです。DIA は、一元的に管理され、高いセキュリティを備えたスケーラブルなクラウド環境のことであり、コネクテッドビークルから生じるデータを Stellantis とそのパートナーやサプライヤー間で保存、処理、分析、共有するために設計されました。それによって、データの収益化を含む新しいビジネスのユースケースの実現を支援します [ 2022年 AWS Blogの投稿 を参照]。 目指すべきビジョンのナラティブを土台として、 Stellantis のデジタルビジョンを実現するために VEW と DIA を構築するロードマップに落とし込んだ PR/FAQ [ 2006年 Working Backwards を参照] を作成しました。この PR/FAQ は顧客のニーズ、ベネフィットおよびお客様の体験を説明するプレスリリース（PR） と呼ばれるセクションと、VEW と DIA のユーザーが考える可能性のあるよくある質問（FAQ）から成り立ちます。この特徴ある PR/FAQ の構造によって、私たちは考えのギャップを認識することができます。さらにエンドユーザーの課題に対応しながら、経営層が思い描くビジネス成果を実現するための技術的なソリューションを開発する優れた土台となりました。 02｜デジタル製品・サービスをスケールする このPR/FAQの作成で得られたインサイトに基づき、最初のプロトタイプを開発しました。そのプロトタイプによって、双方のメンバーが最適なテクノロジーのスタックを選択し、選択したクラウドのアーキテクチャが望ましいビジネス成果を提供できることを検証しました。この時点では、まだ図 1 に示すデジタルトランスフォーメーション・フライホイールのグレー部分のループにいます。プロトタイプは Stellantis からのフィードバックに基づき、価値を提供する最小限の製品（MVP）として構築され、受け入れ基準が満たされるまでフェイルファストで反復的に改良されました。独立してデプロイでき、要求に基づいて自動的に規模を拡大できるように、各プロトタイプはモノリシックなサービスではなく、セルフサービスのポータルと使いやすいAPIを備えた分散型のマイクロサービスから構成されています。デジタルトランスフォーメーション・フライホイールのこのフェーズは 「デジタル製品・サービスをスケールする」と呼ばれ、顧客中心の製品開発サイクルを完結させました [ 2024年 AWS Executive Insights を参照]。 本番環境へのデプロイ後、私たちは Stellantis のユーザーから選ばれたベータテスターに MVP を利用していただき、ユーザーからのフィードバックの収集を開始しました。このフィードバックは、パフォーマンスやユーザビリティなどの製品改良に反映されました。さらに新しい機能の開発にインスピレーションを与え、その機能がバックログに追加され、その後に実装されました。それぞれの主要なビルドや改良のステップは、Stellantis と AWS のチームによってハッカソンと呼ばれる 1 週間のスプリントのような共同のワークショップで実施されました。これによってチーム内の連携を強化し、社内外に VEW と DIA に対する熱意を伝えました [ 2023年 Stellantis 社のプレスリリース を参照]。また、AWS のブログ「 Hackathons for Accelerated Vehicle Software Development at Stellantis 」[2023年]もご参照ください。 03 | ビジネスプロセスを改善する アジャイル開発の方法論を使ってデジタル製品やサービスを開発し本番環境にデプロイすることは、開発をサポートするさまざまなプロセス変更への圧力となりました。例えば、VEW のデプロイを成功させるために、関連するStellantis のオペレーションチームはユーザーからのフィードバックを収集し、タイムリーかつフレキシブルに対応するためにチケットシステムを導入する必要がありました。このようにチーム間の効果的なコラボレーションには、常に効率的なビジネスプロセスによってサポートされるべきです。そして効率的なビジネスプロセスとは、意思決定を行い組織のリソース（人材、予算などを含む）を配置し、合意されたビジネス成果を提供するための構造化された活動や（自動化された）ワークフローのことです。このようなプロセスは、組織内の責任や役割がデジタルトランスフォーメーションのジャーニーに沿って変化するにつれて、継続的に見直され、改善される必要があることにも注目すべきでしょう。このように効率的なビジネスプロセスを確立することは、デジタルトランスフォーメーション・フライホイールのもう1つの核となる要素です。これは、デジタル技術を活用したプロセスの合理化によってオペレーショナルエクセレンス (運用上の優秀性) を達成するために、組織のオペレーティングモデルを見直す、として表現されることもあります。 04 | 関係者をエンパワーメントする ビジネスプロセスの改善に加えて、デジタルトランスフォーメーション・フライホイールのもう1つの重要な要素は、継続的なトレーニングと能力開発による社員の能力強化です。最終的には人が変化を起こすので、この意味は計り知れません。例えば、Stellantisの VEW と DIA が提供するサービスを利用するためには、自動車開発者やエンジニアが AWS クラウドの基本的なスキルを習得するだけでなく、AWS Cloud Adoption Framework（CAF）、Scaled Agile Framework (SAFe)、スクラム [ AWS Website など参照] などのアジャイルな働き方、オープンイノベーションやコラボレーションを促進する方法論に関する知識も必要となります。これらの分野で従業員を効果的にトレーニングをするために、Stellantis は AWS のトレーニングの担当チーム (AWS Training and Certification) と共同で TechXelerateと呼ばれるトレーニングプログラムを開始しました [ 2023年 AWS Training and Certification の投稿 を参照]。このプログラムは、2024年までに5,000人以上のStellantisの開発者とエンジニアのスキルアップとリスキルを目指し、Stellantisのデータドリブンかつソフトウェアにフォーカスした企業への変革を加速させることを目指すものです [ 2022年 Stellantis Press Release を参照]。 05 | 組織を再構築する ミラーリング仮説（コンウェイの法則としても知られています）によれば、組織のコラボレーションやコミュニケーションの構造は、その製品やサービスのアーキテクチャに反映します［ 2016年 HBR記事 を参照］。言い換えれば、組織を横断して相互に関連するようなタスクは、エンドツーエンドのユースケースに焦点を当てた組織横断のチームによって実装されるのが最適ということになります。そのタスクには、例えば VEW における自動車ソフトウェア開発のためのエンドツーエンドのツール間連携の実装や、DIA におけるコネクテッドビークルのデータ用の自動 ETL (抽出-変換-ロード) パイプラインの構築があげられます。したがってデジタルトランスフォーメーションの成功には、ユースケースに焦点を当てたコラボレーションを確立するために組織を再構築することが必要です。革新的な VEW と DIA の機能を開発するために Stellantis と AWS の両組織の技術専門家を集めた様々な組織横断的プロジェクトチームを設立しました。これには、例えば Stellantis のSoftware Driven Experience, Global Analytics & Data Products, Information Communication & Technology, Global Security Operations、AWSプロフェッショナルサービス（AWS ProServe）のメンバーが含まれます。多くのチームは革新的な製品やサービスを迅速に立ち上げ、マイクロサービスのアーキテクチャが提供する俊敏性とスピードを最大限に活用するために、ピザ 2 枚チームの小規模な組織横断のチームで編成されています [ 2024年 AWS Executive Insights を参照]。 06｜イノベーション文化を醸成する デジタルトランスフォーメーションを成功させるためには、組織全体でアジャイルなコラボレーションに基づくオープンイノベーション文化を確立することが極めて重要であり、それはフライホイールのもうひとつの中核的な要素です。この文脈においてイノベーション文化とは、顧客と従業員のために価値を創造する組織の能力を指します。ハーバード・ビジネス・スクールのクレイトン・クリステンセンはかつて、あらゆる組織に不可欠なこの文化の部分を次のように定義しました： 「文化とは、共通の目標に向かって協力し合う方法であり、それが常に守られ、成功しているため、人々は別の方法で物事を進めようとは考えようともしません。文化が形成されていれば、人々は成功するために必要なことを自律的に行うようになります」［2012年 C. M. クリステンセン他『 How Will You Measure Your Life 』ハーパー・ビジネス社を参照］。 Stellantis と AWSは、さらに外部パートナーも含めた自動車のエンジニアリングチームとのハッカソンを頻繁に開催することで、オープンイノベーションの文化を醸成してきました。協業の開始時に作成された目指すべきビジョンのナラティブとPR/FAQは、エグゼクティブとの Think Big ワークショップで定期的に見直され、さまざまなチーム間のコラボレーションを戦略的OKRに整合させています。また、カンファレンス [ re:Invent 2022 や Automobil Elektronik Kongress 2023 などを参照] やその他の業界イベントにおいてサードパーティの開発者、サプライヤー、独立系ソフトウェアベンダー、 AWSパートナーネットワーク（APN） の外部コンサルティングやテクノロジーパートナーとも関わっています。このようにして私たちは、デジタルトランスフォーメーション・フライホイールの次の反復のための基礎となる新しいデジタル製品、サービス、機能、能力のアイデアを継続的に開発しています。 まとめ Stellantis との協業から得られた事例は、AWS が VEW や DIA のようなクラウドネイティブの製品やサービスを構築することで、よりデータドリブンかつソフトウェアにフォーカスした組織へのデジタルトランスフォーメーションを支援していることを示しています。また、デジタルトランスフォーメーションは、1つの反復から次の反復へと加速する好循環と見なすことができることも実証しています。本ブログで紹介するデジタルトランスフォーメーション・フライホイールは、アマゾンのイノベーション文化に着想を得ており、その好循環を大規模な企業に対しても役立てることができます。また、デジタルトランスフォーメーションに対する全体的、構造的、反復的なアプローチを提供し、より現代的なデータドリブンかつソフトウェアにフォーカスした組織になるためのデジタルトランスフォーメーションのジャーニーを示しています。 本ブログはAWS Blog の “ The Digital Transformation Flywheel: How AWS Helps Accelerate the Digital Transformation of Stellantis ” をソリューションアーキテクトの藤井が翻訳しました。 Volker Lang Volker Lang は、アマゾン ウェブ サービス（AWSプロフェッショナルサービス）のストラテジック プログラム リーダーです。シングルスレッド リーダーとして、彼自身、彼の顧客対応チーム、デリバリーチームは世界中の自動車業界で、私たちの最も戦略的なお客様のデジタルトランスフォーメーションの実現を可能にします。AWS入社以前は、ドイツの自動車業界において、電動化とデジタル化に焦点を当てた様々な大規模なビジネス変革をリードしてきました。オックスフォード大学で量子物理学の博士号を取得し、著書「Digital Fluency」を出版しました。 John Valent John Valent は、エンタープライズの変革のエキスパートであり、EMEA (ヨーロッパ、中東およびアフリカ) における AWS プロフェッショナルサービス（ProServe）のオートモーティブ・プラクティスをリードしています。自動車業界に関する深い専門知識を持ち、さまざまなOEMと密接に連携してデジタルトランスフォーメーションによる課題の克服に取り組み、企業全体のビジネス成果を加速させています。ジョンは2018年7月に AWS に入社し、以前は Teradata Germany でプロフェッショナルサービス（自動車）のディレクターを務めていました。

インターネットには、ハードウェア側のルーター、スイッチ、ハブ、地上/海底ケーブル、コネクタ、そしてソフトウェア側の複雑なプロトコルスタックや設定といった、多数の可動部分があります。お客様に影響を及ぼす形でインターネットを減速または停止させる問題が発生したときには、可能な限り早急に問題の場所を特定して理解できるようにしておく必要があります。 新しい天気図 そんなときに役に立つのが、Amazon CloudWatch の新しいインターネット天気図です! AWS が運営する一群のグローバルモニター上に構築されたこの天気図は、インターネット気象の広範なグローバルビューとともに、特定の都市に影響を及ぼすパフォーマンス問題や可用性問題をクローズアップして理解する機能を提供します。天気図にアクセスするには、CloudWatch コンソールを開き、左側にある [ネットワークモニタリング] を展開して、 [インターネットモニター] をクリックします。世界中の気象が反映された天気図が表示されます。 赤と黄色の円はそれぞれ、可用性またはパフォーマンスに影響を及ぼす現行のアクティブな問題を示しています。灰色の円は過去 24 時間内に解決された問題を表し、青いひし形は AWS リージョン を表しています。天気図を画面に表示したままにしておくと、15 分ごとに自動更新されます。 各問題は特定の都市ネットワークに影響を及ぼし、クライアントが AWS リソースにアクセスする場所と、AWS リソースへのアクセスに使用された AS 番号 (ASN) の組み合わせを表しています。ASN は通常、個別のインターネットサービスプロバイダー (ISP) を表します。 天気図の右側にあるリストには、最上部にアクティブなイベントが表示され、その下に最近解決されたイベントが 24 時間前までさかのぼって表示されます。 インジケーターのいずれかにカーソルを合わせることで、その地域内の都市ネットワークのリストを確認できます。 1～2 回ズームインすると、これらの都市ネットワークが米国全土に展開されていることがわかります。 さらにズームインして、単一の都市ネットワークを表示することもできます。 この情報は、プログラム的に利用することも可能です。新しい ListInternetEvents 関数は、1 コールあたり最大 100 件のパフォーマンスまたは可用性イベントを返し、オプションで時間範囲、ステータス ( ACTIVE または RESOLVED )、タイプ ( PERFORMANCE または AVAILABILITY ) によるフィルタリングを使用できます。各イベントには、緯度や経度などの詳細情報が含まれています。 新しい天気図はすべての AWS リージョンからアクセスでき、使用料金はかかりません。将来に向けて、ロードマップでは皆さんのフィードバックに基づく優先順位に従った多数の強力な追加機能が計画されています。現在は、以下を検討中です。 DDoS 攻撃、BGP ルートリーク、ルートの相互接続問題など、特定の障害タイプの原因の表示。 選択された ISP に固有のビューの追加。 パブリック SaaS アプリケーションに対する影響の表示。 この機能に関するフィードバックは、いつでも internet-monitor@amazon.com までお寄せください。 CloudWatch Internet Monitor 天気図内の情報は、AWS 上に構築されたアプリケーションを使用するすべての人を対象としています。インターネット気象が特定の AWS アプリケーションにどう影響するかを理解し、 ヘルスイベント通知 や トラフィックインサイト などのその他機能を利用したいという場合は、CloudWatch Internet Monitor を活用できます。2022 年後半に この機能がリリース されたとき、私の同僚である Sébastien はこのように言いました。 インターネットに接続するアプリケーションを監視するときの課題のひとつは、AWS 外のデータを収集して、地理的に離れた複数のインターネットプロバイダーに接続する顧客に対してアプリケーションがどのように動作するかに関する実態を把握することだというご意見をいただいています。インターネットトラフィックがインフラストラクチャに到達する前に、そのデータをキャプチャして監視することは難しく、そうでなくとも非常に高いコストがかかります。 天気図を確認したら、 [モニターを作成] をクリックして、CloudWatch Internet Monitor の使用を開始できます。 その後、モニターの名前を入力し、監視する AWS リソース (VPC、CloudFront ディストリビューション、Network Load Balancer、Amazon WorkSpace ディレクトリ) を選択してから、監視するインターネット接続トラフィックのパーセンテージを選択します。モニターは数分内で監視を開始し、VPC フローログ、CloudFront アクセスログ、およびその他テレメトリからの入力を使用して、最も関連性の高い都市ネットワークを特定します。 以下は、この機能の詳細を学ぶために役立つリソースです。 Amazon CloudWatch Internet Monitor プレビュー – アプリケーションのインターネットパフォーマンスをエンドツーエンドで可視化 Amazon CloudWatch Internet Monitor の紹介 Easily set up Amazon CloudWatch Internet Monitor Using Amazon CloudWatch Internet Monitor for enhanced internet observability Use Amazon CloudWatch Internet Monitor for greater visibility into online experiences ドキュメント: Amazon CloudWatch Internet Monitor の使用 動画: Amazon CloudWatch Internet Monitor その他の質問やコメントについては、internet-monitor@amazon.com までご連絡ください。 – Jeff ; 原文は こちら です。

2024 年 2 月と 3 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon EMR EMR Serverless 編 Amazon EMR Serverless は Amazon EMR のサーバーレスオプションです。データアナリストやエンジニアが、クラスターやサーバーを設定、管理、スケーリングすることなく、オープンソースのビッグデータ分析フレームワークを簡単に実行できます。AWS Black Belt Online Seminar では Amazon EMR Serverless の概要や使いどころについて説明します。 資料（ PDF ） 対象者 Amazon EMR の利用を検討されている方、利用されている方。 Amazon EMR Serverless について学びたい方。 サーバーレスで簡単にビッグデータ分析フレームワークを実行したい方。 本 BlackBelt で学習できること Amazon EMR Serverless を利用する上で知っておくべきサービスの概要と使いどころ、利用料金やサービスを利用する上での考慮事項について学ぶことができます。 スピーカー 川村 誠 ソリューションアーキテクト Amazon EMR コスト最適化編 Amazon EMR は Apache Spark、Apache Hive、Presto などのオープンソースフレームワークを使用して、ペタバイトスケールのデータ処理、相互分析、機械学習を行なう業界をリードするクラウドビッグデータソリューションです。AWS Black Belt Online Seminar では Amazon EMR を利用する際のコスト最適化について説明します。 資料（ PDF ）  対象者 Amazon EMR の利用を検討されている方、利用されている方。 Amazon EMR について学びたい方。 コストを抑えてビッグデータを活用したソリューション開発を検討されている方 本 BlackBelt で学習できること Amazon EMR の利用コストを最適化するために必要な Amazon EMR が提供する機能について学ぶことができます。 スピーカー 川村 誠 ソリューションアーキテクト Amazon EventBridge Pipes Amazon EventBridge Pipes は、イベントプロデューサーとイベントコンシューマーをポイントツーポイントで統合する機能です。統合のためのコードを記述したり、インフラを準備する必要はなく、迅速なイベント駆動アプリケーションの開発を可能にします。この動画では、EventBridge Pipes の基本的な使い方やユースケースについて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EventBridge について深く学びたい方 イベント駆動型アプリケーションの開発に興味をお持ちの方 ノーコード/ローコードでのシステム間連携を実現したい方 本 BlackBelt で学習できること EventBridge Pipes を活用した効率的なイベント駆動アプリケーションの開発方法 スピーカー 櫻谷 広人 パートナーソリューションアーキテクト AWS SAW – セルフサービスなトラブルシューティングと運用の自動化 Amazon Elastic Compute Cloud (Amazon EC2) – Windows 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは Amazon Elastic Container Cloud(Amazon EC2) で利用可能な 3つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon EC2 – Windows を利用した運用を実施されている方 Amazon EC2 – Windows のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること AWS Nitro System 上で動作するインスタンスタイプをご利用いただくことのメリット AWS SAW を活用して EC2 インスタンスのトラブルシューティングを行う方法 AWS SAW を活用して EC2 インスタンスを AWS Nitro System 上で動作するインスタンスタイプへの変更するプロセスを簡略化する方法 スピーカー 和田 智優 クラウドサポートエンジニア AWS SAW – 旧世代から最新世代 (AWS Nitro System 世代) への移行タスクの自動化 Amazon Elastic Compute Cloud (Amazon EC2) – Linux 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは、Amazon Elastic Compute Cloud (Amazon EC2) において、AWS Nitro System 上で動作するインスタンスタイプへの移行を簡略化する 2 つの SAW ランブックをご紹介します。AWS Nitro System を用いることのメリットとこれらのランブックを用いた具体的な移行方法などの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 旧世代のインスタンスタイプで Amazon EC2 – Linux を運用されている方 Amazon EC2 – Linux 環境の最新世代のインスタンスタイプへの移行に興味のある方 本 BlackBelt で学習できること AWS Nitro System 上で動作するインスタンスタイプをご利用いただくことのメリット AWS SAW を活用して EC2 インスタンスを AWS Nitro System 上で動作するインスタンスタイプへの変更するプロセスを簡略化する方法 「AWSSupport-CheckXenToNitroMigrationRequirements」ランブックの設定方法と活用方法 「AWSSupport-MigrateXenToNitroLinux」ランブックの設定方法と活用方法 スピーカー 渡邉 亮藏 シニアクラウドサポートエンジニア AWS SAW – セルフサービスなトラブルシューティング Amazon Simple Storage Service (Amazon S3) + AWS Lambda 編 AWS SAW (AWS Support Automation Workflows) は AWS サポートチームが作成した自動化ランブックのコレクションです。AWS SAW を活用することで AWS 環境の一般的な問題の解決やログの収集、分析などを自動的に実行することができます。本セッションでは Amazon Simple Storage Service (Amazon S3) と AWS Lambda で利用可能な 4 つの SAW について概要や利用ユースケースなどの詳細を解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon S3 や AWS Lambda を利用した運用を実施されている方 Amazon S3 や AWS Lambda、Amazon S3 と AWS Lambda を組み合わせて使用する際のトラブルシューティングの効率化に興味のある方 本 BlackBelt で学習できること Amazon S3、AWS Lambda 向けに利用可能な4つの AWS Support Automation Workflows(SAW) について利用ユースケース及び概要を理解する スピーカー 石川 直哉 / 藤原 弘樹 クラウドサポートエンジニア AWS への大規模移行のための戦略とベストプラクティス 多くのお客様は、ビジネスへの影響を最小限に抑えながら、できるだけ早く AWS に移行したいと考えています。本セミナーでは、大規模移行の初期段階にあるお客様を支援するため、大規模移行のベストプラクティスについて説明し、様々なお客様の移行事例や、お客様が移行中に得た教訓を紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから AWS への移行を予定している組織のリーダー層の方 大規模移行を担当するプロジェクトマネージャーやプロジェクトリーダーの方 本 BlackBelt で学習できること 大規模移行のベストプラクティス お客様の移行事例や、お客様が移行中に得た教訓 スピーカー 大熊　正浩 カスタマーソリューションマネージャー AWS Key Management Service Part.1 基礎編 AWS Key Management Service (AWS KMS) は、暗号化操作に使用される暗号鍵を簡単に作成および管理できるマネージドサービスです。本セッションでは、データ保護のユースケースに焦点を当てつつ、AWS KMS を利用したデータ暗号化の仕組み、暗号化を支える鍵管理の仕組み、そして、AWS KMS での暗号鍵の保管や管理の信頼性についての仕組みを学んでいただけます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 環境における保管中データ暗号化に関心をお持ちの AWS Key Management Service をご利用予定の方 AWS Key Management Service について理解を深めたい方 本 BlackBelt で学習できること データ保護のユースケースに焦点を当てつつ、AWS KMS を利用したデータ暗号化の仕組み、暗号化を支える鍵管理の仕組み、そして、AWS KMS での暗号鍵の保管や管理の信頼性についての仕組みを学んでいただけます。 スピーカー 平賀 敬博 セキュリティソリューションアーキテクト Amazon Elastic File System クラウドネイティブなワークロードに最適なファイルストレージサービスである Amazon Elastic File System (EFS) について詳しく紹介します。Amazon EFS の概要、便利な機能、パフォーマンス向上のポイントについて学習することができます。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS のグローバルインフラストラクチャやマネージドサービスの概念と AWS IAM や Amazon VPC などの基盤となるサービスについての知識が必要です。 Amazon EFS の活用を考えている方と Amazon EFS に詳しくなりたい方を対象としております。 本 BlackBelt で学習できること Amazon EFS の概要とレプリケーション機能やストレージの階層化機能といった便利な機能について学習できます。 Amazon EFS を利用する際、パフォーマンスを向上できるポイントについても解説します。 スピーカー 佐藤 真也 ソリューションアーキテクト Amazon Connect 注目 Update 10 選 !! (2023 年1月～ 2024 年1月 ) Amazon Connect が東京リージョンでローンチされてから5年が経ちたくさんの新機能が追加されてきました。それらの中から 2023 年1月から 2024 年1月までに発表された特に注目の Top10 について振り返っていきます。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のエンドユーザー/パートナーの方 Amazon Connect のご利用をご検討中の方 Amazon Connect のアップデートを知りたい方 本 BlackBelt で学習できること 2023 年1月から 2024 年までに発表された Amazon Connect の注目アップデートを振り返ることができます。 スピーカー 黒木 裕貴 ソリューションアーキテクト

はじめに クラウド上でライブ動画の放送、ストリーミング、配信を行う場合、ワークフローの構築、テスト、セキュリティ対策に時間を費やしてきたことでしょう。Amazon Web Services (AWS) はこれらの作業を簡単にし、視聴者に高品質な体験を提供できます。しかし、ワークフローの継続的なモニタリングにどれだけ時間を割いてきましたか? モニタリングに取り組むと、各 AWS サービスに固有のアラートやダッシュボードがあることがわかります。しかし、メディアワークフロー全体のアラーム、メトリクス、リソースアラート、ヘルスを一覧で確認できるものはありません。リソース間の関係が明確でないと、問題が発生したときに時間のかかる手作業での切り分けや対処が必要になります。また、モニタリングに最適なメトリクスがわからず、複数のワークフローにアラームと通知ルールを展開・維持する事が必要になることもあります。 Workflow Monitor でライブ映像を検出し、可視化する これらの問題を解決するために、AWSは AWS Media Services と Amazon CloudFront をモニタリングできる Workflow Monitor を発表しました。この新機能はライブ映像のワークフローを検出、可視化、監視をするために設計されています。Workflow Monitor  はメディアワークロードのベストプラクティスモニタリングを展開・維持でき、 AWS マネジメントコンソール 、 AWS Elemental MediaLive API 、 AWS CDK からアクセスできます。 Workflow Monitor が検出可能なサービス。 わずか数クリックで、Workflow Monitor はメディアワークフローに関連するリソースを検出して可視化します。検出は対応するサービスから開始でき、リソースを選択すると Workflow Monitor はエンドツーエンドのグラフィカルなシグナルマップを作成します。シグナルマップにはワークフロー内のリソースを AWS Elemental MediaConnect 、 AWS Elemental MediaLive 、 AWS Elemental MediaPackage にわたって Amazon Simple Storage Service ( Amazon S3 )バケットと Amazon CloudFront ディストリビューションと共に表します。 シグナルマップ上では、一目で利用中のリソースとそれぞれのステータスを確認できます。このステータスは1秒ごとに更新されます。また、複数のコンソール画面を行き来することなく、各リソースがどのように接続されているかを確認できます。MediaLive チャネルや MediaPackage エンドポイントなどでは、利用可能な場合にライブ動画のサムネイル画像が動的に更新されます。 ライブ映像配信を示すシグナルマップ（画像をクリックすると拡大します）。 業界設計のベストプラクティスに基づいたモニタリングとアラートの適用とカスタマイズ シグナルマップを作成したら、 Workflow Monitor を使ってアラームと通知テンプレートを作成し、問題発生時にアラートを受け取れるようにします。モニタリングとアラートには Amzon CloudWatch アラームと Amazon EventBridge ルールを使用しますが、これらのリソース設定は Workflow Monitor コンソールで管理され、 Amazon CloudFormation を通じて展開されます。つまり、映像関連のエンジニアリングチームがこれらのサービスに精通する必要はありません。同様のワークロードのモニタリングを繰り返し行えるよう、 Workflow Monitor ではテンプレートとテンプレートグループの概念を採用しています。テンプレートは CloudWatch アラームまたは EventBridge ルールの設定を記述し、グループ化された階層オブジェクトを形成し、1つ以上のシグナルマップに関連付けられます。 テンプレートグループは、運用モデルに合わせて柔軟に分割できます。例えば、アラームテンプレートを重大度別、ワークフローの重要度に基づいて、または地域差に基づいてグループ化することができます。さらに、 Workflow Monitor では業界の専門家チームが作成したベストプラクティスの推奨事項をインポートして独自のアラームテンプレートグループに追加できます。インポート後はワークフローの要件に合わせてテンプレートを変更できます。例えば、映像フレームレートを 60fps から 50fps に変更したり、特定の許容範囲に基づいて継続時間のしきい値を調整したりすることができます。 1 つ以上のテンプレートグループをシグナルマップに関連付けると、 Workflow Monitor から素早くデプロイすることができます。バックグラウンドでは、CloudFormation Stack が作成され S3 に保存された後、展開されます。この Stack は後から参照したり、別の CloudFormation デプロイの一部として活用したりできます。展開完了後、ワークロードがモニタリング対象となります。 映像ワークフロー全体のステータスを一覧表示 Workflow Monitor の概要ページでは、すべてのシグナルマップのヘルスステータスを一目で確認できます。リストはさまざまな条件でフィルタリング可能です。例えば、ステータスでフィルタリングすれば、アラーム状態のシグナルマップのみを表示する「ペナルティボックス」を作成できます。この例外ベースのモニタリングは、シグナルマップが多数ある場合に、オペレーターの対応が必要なものだけを表示したいときに便利です。 概要ページには、各シグナルマップのステータスが表示されます（画像をクリックすると拡大します）。 モニタリング中のシグナルマップをクリックすると、アクティブなアラームがあるリソースを確認できます(リソースの背景が赤で示されます)。リソースを選択すると、そのリソースに適用されているアラームのみがシグナルマップのアラームリストに表示されるようフィルタリングできます。これにより、特定のワークフローで問題が発生している場所を素早く特定し、視覚的にデバッグできます。次に、組み込みリンクを使ってリソース自体、CloudWatch、CloudWatch Insights にすばやくアクセスし、ログをクエリできます。以前は、問題の切り分けと適切なコンソール画面への移動には、ワークフローに関する専門知識が必要でした。 モニタリングの一貫性を保つ Workflow Monitor は、ベストプラクティスモニタリングの作成と展開だけでなく、運用の一貫性の維持にも役立ちます。アラームテンプレートグループがシグナルマップに関連付けられると、アラームテンプレートはいつでも更新でき、新しい設定がシグナルマップに反映されます。例えば、アラームをノイズから守るためにしきい値を変更する必要がある場合、アラームが使用されているすべてのリソースでそのしきい値を個別に変更する代わりに、アラームテンプレートで 1 回変更してからモニタリングを再展開します。また、テンプレートグループによって、すべてのワークロードで効率的に変更を段階的に行い、適切なタイミングでデプロイすることができます。例えば、映像エンコーディングを AVC から HEVC に更新する際、特定のアラームのビットレート設定を調整する必要がある場合です。その際、個々のアラームを更新する代わりに、アラームテンプレート1か所ですべてを更新でき、準備ができたら展開します。 Workflow Monitor ユーザーガイド には、IAM ロールの提案も記載されています。アクセス許可境界により、オペレーターのために Workflow Monitor を安全に使用できるロールを作成できます。さらに、経験豊富なエンジニアがモニタリングを作成、更新、展開できるロールの提案もあります。これら 2 つのロールにより、 Workflow Monitor を安全に使用するための出発点が提供されます。 結論 AWS Media Services と Amazon CloudFront の Workflow Monitor は、ライブ動画のストリーム、放送、配信に関連するリソースを検出、可視化、監視します。リソース間の関係をグラフィカルなシグナルマップで表示するため、使用中のリソースとそれらの接続関係を確認できます。ベストプラクティスのモニタリングと通知テンプレートから始めるか、独自のテンプレートを作成し、問題発生時にアラートを受け取るよう映像をモニタリングすることができます。 詳しくは、 ユーザーガイド をお読みください。開始するには Workflow Monitor コンソール にアクセス下さい。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は SA 金目、SA 石井が担当しました。原文は こちら をご覧ください。

様々な形式の大量の文書を分類し、その分析を行いたいと様々な業種の企業が考えています。これらの文書を手作業で処理して分類・情報抽出を行うことは、費用がかかり、ミスが生じやすく、スケーリングが難しい作業です。 生成 AI (generative artificial intelligence) 技術の発展により、文書の分類を自動化できる、インテリジェントドキュメント処理 (IDP) ソリューションが登場しました。こうしたソリューションは、非構造化された様々な企業文書に対して、低コストで効率的な分類機能を提供します。 文書を分類することは、IDP システムにおける重要な最初のステップです。文書を分類することで、種類に応じた次に取るべき一連のアクションを決定しやすくなります。例えば、請求審査プロセスでは、会計チームが請求書を受け取り、請求処理部門が契約書や文書を管理します。従来のルールエンジンや ML ベースの分類機能で文書を分類できますが、対応できる文書形式の種類に制限があり、新しい分類を都度追加する対応をすることがあります。詳細については、 こちらのブログ をご覧ください。 この投稿では、 Amazon Titan マルチモーダル埋め込みモデル を使用したドキュメント分類について説明します。このモデルを使えば、トレーニングを行うことなく、あらゆるタイプのドキュメントを分類することができます。 Amazon Titan マルチモーダル埋め込み Amazonは、 Amazon Bedrock で Amazon Titan マルチモーダル埋め込みモデル を導入しました。このモデルは画像とテキストの埋め込みベクトルを作成できるため、新たな文書分類ワークフローで使用する文書ベクトルの作成が可能になりました。 Amazon Titan マルチモーダル埋め込みモデルを使用することで、画像としてスキャンされた文書の最適化されたベクトル表現を生成します。画像とテキストの両方の意味を含む単一の数値ベクトルに変換することで、高速な索引、強力な文脈検索、正確な文書分類を可能にします。 ビジネスワークフローで新しい文書テンプレートや様式が現れた場合、 Amazon Bedrock API を呼び出すだけでそれらをベクトル化し、IDPシステムにおける文書分類を迅速に強化することができます。 ソリューションの概要 以下のドキュメント分類ソリューションを Amazon Titan マルチモーダル埋め込みモデルで検討しましょう。最適なパフォーマンスを得るには、自身の特定のユースケースや既存の IDP パイプラインの設定に対してソリューションをカスタマイズする必要があります。 このソリューションは、入力文書を既にインデックス化された文書と照合することで、埋め込みベクトルのセマンティック検索を使用して文書を分類します。分類には、以下の主要コンポーネントを使用します: 埋め込み – 埋め込み は、人間が複雑な情報を理解するように、単語、文章、画像などの情報を数値化して機械学習 (ML) や AI システムが理解するために用いる表現方式です。 ベクターデータベース – ベクターデータベース は、ベクトルを保存するために使われます。ベクターデータベースは、ベクトルを効率的にインデックス化し、整理することで、ユークリッド距離やコサイン類似度などの距離の尺度に基づいて類似したベクトル を高速に検索できるようにします。 セマンティック検索 – セマンティック検索は、入力クエリの文脈と意味、および検索されたコンテンツの関連性を考慮して動作します。ベクトル埋め込みは、テキストや画像の文脈上の意味を的確に捉え、保持するための効果的な方法です。このソリューションでは、アプリケーションがセマンティック検索を実行したい場合、まず検索文書をベクトルに変換します。次に、関連するコンテンツを含むベクターデータベースを照会して、最も類似したベクトルを見つけます。 ラベリングプロセスでは、請求書、銀行明細書、規定などのビジネス文書のサンプルが、Amazon Titan マルチモーダル埋め込みモデルを使用してベクトル化され、事前に定義されたラベルに対してベクトルデータベースに保存されます。Amazon Titan マルチモーダル埋め込みモデルはユークリッドの L2 アルゴリズムで学習されているため、良い結果を得るためには、ベクトルデータベースがこのアルゴリズムをサポートしている必要があります。 次の アーキテクチャ図は、 Amazon Simple Storage Service (Amazon S3) バケット内のドキュメントと Amazon Titan マルチモーダル埋め込みモデルを使って画像ギャラリーを作成する方法を表しています。 ワークフローは次のステップで構成されます: ユーザーまたはアプリケーションが、分類メタデータを付けたサンプル文書画像を文書画像ギャラリーにアップロードします。ギャラリー画像の分類には S3 プレフィックスまたは S3 オブジェクトメタデータが使用できます。 Amazon S3 オブジェクト通知イベントによって AWS Lambda 関数が呼び出されます。 Lambda 関数は、Amazon Bedrock を呼び出して Amazon Titan マルチモーダル埋め込みモデルを用いて、文書画像をベクトルに変換します。 文書の分類と共に、画像埋め込みがベクターデータベースに保存されます。 新しい文書を分類する必要がある場合、同じ埋め込みモデルを使用し、クエリ文書を埋め込みに変換します。その後、クエリの埋め込みを使ってベクトルデータベースに対してセマンティック類似検索が実行されます。 最も類似度が高い埋め込みに対応するラベルが、クエリ文書の分類ラベルとなります。 以下のアーキテクチャ図は、S3 バケット内のドキュメントに対して Amazon Titan マルチモーダル埋め込みモデルを使用し、画像分類を行う方法を示しています。 ワークフローは次のステップで構成されています: 分類が必要な文書を、入力用の S3 バケットにアップロードします。 Lambda 関数が Amazon S3 オブジェクト通知を受け取ります。 Lambda 関数が Amazon Bedrock API を呼び出して、画像をベクトルに変換します。 ベクターデータベースで、セマンティック検索を使用して一致する文書が検索されます。一致する文書の分類を使用して、入力文書を分類します。 入力文書を、ベクターデータベース検索から取得した分類を使用して、対象の S3 ディレクトリまたはプレフィックスに移動します。 自身の文書でこのソリューションをテストできるよう、Python の Jupyter ノートブックのサンプルを GitHub で公開しています。 前提条件 ノートブックを実行するには、 AWS アカウント が必要で、そのアカウントには Amazon Bedrock を使用するための適切な AWS Identity and Access Management (IAM) 権限が必要です。 また、Amazon Bedrock コンソールの Model access ページで、Amazon Titan マルチモーダル埋め込みモデルへのアクセスが許可されていることを確認してください。 実装 以下のステップでは、ユーザー入力を示すプレースホルダーを自身の情報に置き換えてください: ベクトルデータベースを作成します。このソリューションでは、インメモリ FAISS データベースを使用しますが、別のベクトルデータベースを使うこともできます。Amazon Titan のデフォルトの次元数は 1024 です。 index = faiss.IndexFlatL2(1024) indexIDMap = faiss.IndexIDMap(index) ベクターデータベースを作成した後は、サンプル文書を列挙し、それぞれの文書の埋め込みベクトルを生成して、ベクターデータベースに保存します。 文書を用いてテストしてください。次のコードのフォルダは、自身の文書を保存したフォルダに置き換えてください: DOC_CLASSES: list[str] = ["Closing Disclosure", "Invoices", "Social Security Card", "W4", "Bank Statement"] getDocumentsandIndex("sampleGallery/ClosingDisclosure", DOC_CLASSES.index("Closing Disclosure")) getDocumentsandIndex("sampleGallery/Invoices", DOC_CLASSES.index("Invoices")) getDocumentsandIndex("sampleGallery/SSCards", DOC_CLASSES.index("Social Security Card")) getDocumentsandIndex("sampleGallery/W4", DOC_CLASSES.index("W4")) getDocumentsandIndex("sampleGallery/BankStatements", DOC_CLASSES.index("Bank Statement")) Boto3 ライブラリを使用して、Amazon Bedrock を呼び出します。変数 inputImageB64 は自身の文書を表す base64 でエンコードされたバイト配列です。Amazon Bedrock からの応答には、埋め込みが含まれています。 bedrock = boto3.client( service_name ='bedrock-runtime', region_name ='Region' # AWS のリージョン名を指定 ) request_body = {} request_body["inputText"] = None # not using any text request_body["inputImage"] = inputImageB64 body = json.dumps(request_body) response = bedrock.invoke_model( body = body, modelId ="amazon.titan-embed-image-v1", accept ="application/json", contentType ="application/json") response_body = json.loads(response.get("body").read()) ドキュメントの種類を表すクラス ID を付与し、ベクターデータベースに埋め込みを追加します: indexIDMap.add_with_ids(embeddings, classID) ベクターデータベースに (ギャラリーを表す) 画像が格納されると、新しい文書との類似性を発見できます。たとえば、検索に使用される構文は次のとおりです。k = 1 は、FAISS から上位 1 件の結果を返すことを意味します。 indexIDMap.search(embeddings, k = 1) さらに、入力画像と検出された画像間のユークリッド L2 距離も返されます。画像が完全一致する場合、この値は 0 になります。この値が大きいほど、画像の類似度が低くなります。 追加の検討事項 このセクションでは、ソリューションを効果的に利用するための追加の考慮事項について説明します。データプライバシー、セキュリティ、既存システムとの統合、コスト見積もりなどが含まれます。 データプライバシーとセキュリティ AWS の 責任共有モデル は、Amazon Bedrock の データ保護 にも当てはまります。このモデルに従い、AWS は AWS Cloud の全てを実行するグローバルインフラストラクチャを保護する責任を負います。お客様はこのインフラストラクチャ上でホストされるコンテンツをコントロールする責任があります。あなたはお客様の1人として、利用する AWS サービスのセキュリティ設定とタスクを管理する責任があります。 Amazon Bedrock におけるデータ保護 Amazon Bedrock は、顧客のプロンプトを AWS モデルの学習や第三者との共有に使用することはありません。また、Amazon Bedrock は、サービスのログに顧客データを保存したり記録したりしません。加えて、モデルプロバイダーは、Amazon Bedrock のログや顧客のプロンプトにアクセス出来ません。その結果、Amazon Titan マルチモーダル埋め込みモデルを介して生成された埋め込みに使用される画像は、AWS モデルやサードパーティの学習に使用されたり、保存されたりすることはありません。さらに、タイムスタンプやログインしたアカウント ID などの他の使用データも、モデル学習から除外されます。 既存システムとの統合 Amazon Titan マルチモーダル埋め込みモデルは、ユークリッドの L2 アルゴリズムで学習しているので、使用するベクターデータベースはこのアルゴリズムと互換性がある必要があります。 コスト見積もり この投稿を書いている時点で、 Amazon Bedrock の価格 に基づき、Amazon Titan マルチモーダル埋め込みモデルをオンデマンド価格で使用した場合、このソリューションの推定コストは以下の通りです。 インデックス作成コスト – 画像ギャラリーに 1,000 枚の画像を想定すると、インデックス作成 1 回あたり $ 0.06 分類コスト – 毎月 10 万枚の入力画像に対して $ 6 クリーンアップ 利用しないときは、作成した Amazon SageMaker ノートブックインスタンス などのリソースを削除して、今後の課金を回避してください。 まとめ このポストでは、IDP ワークフローにおけるドキュメント分類について低コストなソリューションを構築するために、Amazon Titan マルチモーダル埋め込みモデルを使用する方法を説明しました。既存のドキュメントの画像ギャラリーを作成し、新しいドキュメントとの類似度検索を行って分類する手順を示しました。また、ドキュメント分類にマルチモーダル画像埋め込みを利用することで、様々な様式の文書に対応でき、スケーラブルで低レイテンシーという利点があることを説明しました。 ビジネスワークフローで新しいドキュメントテンプレートと様式が導入されると、開発者は Amazon Bedrock API を呼び出して動的にベクトル化し、IDP システムに追加して文書分類機能を迅速に強化できます。これにより、さまざまな構造化されていない企業の文書に対応できる、低コストで無限に拡張可能な分類が可能になります。 全体として、この記事は、Amazon Titan マルチモーダル埋め込みを使用して IDP ワークフローにおける文書分類のための低コストのソリューションを構築するための指針を提供しています。 次のステップとして、 Amazon Bedrock とは を確認し、サービスの利用を開始できます。また、 AWS Machine Learning Blog の Amazon Bedrock をフォローすると、Amazon Bedrock の新機能とユースケースの最新情報を入手できます。 本記事は、 Cost-effective document classification using the Amazon Titan Multimodal Embeddings Model を翻訳したものです。翻訳は Technical Account Manager の Hiroaki Hattori が担当しました。 著者について Sumit Bhati は、AWS のシニアカスタマーソリューションマネージャーです。企業顧客のクラウド移行を加速させることを専門としています。Sumit は、移行の加速からワークロードのモダナイゼーション、革新的な実践のファシリテーションまで、顧客のクラウド導入のあらゆる段階でお客様をサポートすることに尽力しています。 David Girling は 20 年以上の経験を持つシニア AI/ML ソリューションアーキテクトで、企業システムの設計、主導、開発に携わっています。David は、顧客がデータを活用しユースケースに合わせてこれらの高機能サービスを学び、革新し、利用することを支援する専門チームの一員です。 Ravi Avula は、エンタープライズアーキテクチャに重点を置く AWS のシニアソリューションアーキテクトです。Ravi は 20 年間にわたるソフトウェアエンジニアリングの経験があり、決済業界でソフトウェアエンジニアリングおよびソフトウェアアーキテクチャのリーダーシップを数多く担ってきました。 George Belsian は、AWS のシニアクラウドアプリケーションアーキテクトです。顧客のモダナイゼーションとクラウド導入を加速させることに注力しています。ジョージは顧客チームと協力して、革新的でスケーラブルなソリューションの戦略立案、アーキテクチャ設計、開発を行っています。

この記事は Building Developer Portals with Backstage and Amazon EKS Blueprints を翻訳したものです。 現代のソフトウェア開発環境の複雑さにより、近年、 内部開発者プラットフォーム （IDP）の作成と採用が進んでいます。IDP の目的は、仕事を遂行するために多数のツールや製品を使用する必要があるソフトウェア開発者の認知負荷を軽減することです。このような断片化は、時間のかかるコンテキストの切り替えを引き起こし、新規参加者の学習曲線を険しくします。IDP は、統一されたフロントエンドを提供することで、このような欠点に対処します。このフロントエンドでは、さまざまなツールや製品が1つのカタログにまとめられ、開発者が利用できるようになっています。 Backstage は Spotify で発足した、 2020年3月にオープンソース化された デベロッパーポータル（DP）です。DP は、IDP の機能を探索し、アクセスするためのユーザーインターフェースの役割を果たします。DP として、Backstage は企業内のさまざまな種類のエンティティを一元管理します： 例えば、API、リソース、ユーザー、チーム、ドキュメントなどです。また、例えば AWS の Proton プラグイン のように、追加のサードパーティコンポーネントを同じコンテキストでプラグインして利用できる拡張可能なアーキテクチャも特徴です。 Amazon EKS Blueprints for CDK （以後、Amazon EKS Blueprints と呼ぶ）は、Infrastructure as Code（IaC）モジュールのセットで、アカウントやリージョンをまたいで、完全な Amazon Elastic Kubernetes Service（Amazon EKS）クラスタを最小限のコードで迅速にブートストラップするのに役立ちます。当初はAWSで開発され、 2022年4月にオープンソース化 されました。アドオンは Amazon EKS Blueprint の構成要素で、クラスタのコンテキスト内で実行される Kubernetes アドオンの管理 を支援します。 このブログでは、Amazon EKS Blueprints Patterns の助けを借りて、Amazon EKS Blueprints 用の Backstage アドオンをインストールして設定する方法を紹介します。このアドオンを使用すると、新しくデプロイされた Amazon EKS クラスターに Backstage アプリケーションを効果的にインストールできます。Elastic Load Balancing（Amazon ELB）を介して Backstage にアクセスできるようになります。このブログでは、Amazon EKS Blueprints と Backstage の間の緊密な統合、例えば、環境、パイプラインのステータス、チームのオンボーディングなどを表示および制御することについては触れていません。 ソリューション概要 次の図は、このブログで説明する完全な解決策を示しています： Backstage のビルド済み Docker イメージが必要で、お好みのプラグインを追加するなどして、お好みの構成にしてください。このステップと次のステップを実行する方法に関する技術的な詳細については、この投稿の後の「Backstage のデプロイ」のセクションを参照してください。 Backstage のパターンはこのようになります： このイメージを新しい Amazon EKS クラスタにデプロイします。 Amazon EKS クラスタの VPC に、新しい Amazon Relational Database Service (Amazon RDS) for PostgreSQL インスタンスを作成します。 上記のデータベースの認証情報を AWS Secrets Manager でシークレットとして設定します。 データベースの認証情報を反映した External Secret を作成します。 External Secret から Kubernetes Secret を作成し、環境変数 $POSTGRES_USER と $POSTGRES_PASSWORD として Backstage に読み込ませます。 AWS Load Balancer Controller アドオン をインストールし、Backstage Helm チャートの Ingress に記載されているルールを実装して、 Application Load Balancer （ALB）をデプロイします。 ALB 用の証明書を作成します。 前提条件 この記事のステップを完了するには、以下のものが必要です： AWS アカウント aws-cli  、 aws-cli の設定 make Node.js npm Docker AWS Cloud Development Kit (CDK)、選択したアカウントとリージョンでの bootstrap また、ここに示す AWS マネジメントコンソールの画像と同様に、 Amazon Route 53 のパブリックホストゾーンの1つに保持されるドメイン名が必要です： Amazon EKS Blueprints Pattern をクローンする お気に入りのコマンドライン・インターフェース（CLI）を開き、EKS Blueprints Patterns GitHub リポジトリをクローンします： $ git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git Backstage をデプロイする EKS Blueprints Patterns リポジトリの docs フォルダ にある Backstage ファイルの指示に従ってください。必要な手順は以下の通りです： Backstage アプリケーション を作成し、 Docker イメージをビルド します。 Amazon Elastic Container Registry （Amazon ECR）とリポジトリの作成します。 新しく作成したリポジトリに Docker イメージをアップロードします。 AWS CLI プロファイルの一部としてアカウントとリージョンを設定し、CDK コンテキストに必要なパラメータを入力します： 説明 パラメータ 説明 backstage.namespace.name Backstage をデプロイする Kubernetes 名前空間 – 例. “backstage” backstage.image.registry.name イメージレジストリ – 例. Amazon Elastic Container Registry (ECR)： “{account}.dkr.ecr.{region}.amazonaws.com” backstage.image.repository.name 上記のレジストリにあるリポジトリ – 例. “backstage” backstage.image.tag.name Backstageイメージのタグ – 例. “latest” backstage.parent.domain.name サブドメインと関連証明書が作成されるドメイン名 – 例. “example.com” backstage.subdomain.label Backstage に割り当てるサブドメインの作成に使用するラベル – 例. “example.com” この場合、最終的なサブドメインは例えば次のようになる – 例. “backstage.example.com” backstage.hosted.zone.id あなたのドメイン名を保持する Route 53 の Hosted Zone を表す20文字の文字列 backstage.certificate.resource.name 証明書リソースに割り当てられる名前 – 例. “backstage-certificate” backstage.database.resource.name データベースリソースに割り当てられる名前 – 例. “backstage-database“ backstage.database.instance.port 新しい Backstage データベースに割り当てるポート – 例. 5432 backstage.database.secret.resource.name Secret リソースに割り当てられる名前（CDK内での参照として使用されます – 例. “backstage-database-credentials” backstage.database.username データベースのユーザー名 – 例. “postgres” backstage.database.secret.target.name Kubernetes マニフェストで Secret に割り当てられる名前 – 例. “backstage-database-secret”   Amazon EKS Blueprints Patterns ドキュメントの説明に従ってデプロイします。 $ make deps $ npm i $ make build $ make pattern backstage deploy 最後に、ウェブブラウザで {"parent.domain.name"}.{"subdomain.label"} に移動します。Backstage アプリケーションの設定によっては、以下のような画面が表示されます： コード解析 実際の Backstage アドオンは Amazon EKS Blueprints リポジトリの下でホストされている一方で、アドオンを構成して必要なリソースをデプロイする方法を示す Backstage パターンは Amazon EKS Blueprints Patternsリポジトリ の下でホストされていることに注意することが重要です。 このアドオンは、 GitHubで公開されている Backstage Helmチャートに依存しています。 その値を通して、Helm チャートを以下のように設定する必要があります： Ingress パラメータを設定する Backstage アプリケーションの Docker イメージの場所を提供する Backstage アプリケーションに渡す： 割り当てるサブドメイン データベース・エンドポイントと環境変数（後にデータベース認証情報に設定される) 実際のデータベース認証情報を保持するシークレット名 Ingress の最も注目すべき構成は、Certificate の Amazon リソース名（ARN）です。 デフォルトのインメモリ SQLite データベースではなく、PostgreSQL を使用することで、 より優れたスケーラビリティ 、 並行性 、 集中化 、 制御 を実現しています（詳細については Backstage ガイド にアクセスしてください）。この認証情報は、Secret から取得した環境変数を介して Backstage アプリケーション Pod に注入されます。チャートは、Secret名に関する情報を backstage.extraEnvVarsSecrets 値から取得し、Kubernetes Deployment マニフェストのenvFromセクションに設定します： kind: Deployment … containers: … envFrom: {{- range .Values.backstage.extraEnvVarsSecrets }} … したがって、アドオンが期待するパラメータは以下の通りとなります： subdomain: string, certificateResourceName: string, imageRegistry: string, imageRepository: string, imageTag?: string, databaseResourceName: string, databaseSecretTargetName: string このパターンは、アドオンの依存関係を提供します。 Resource Provider ( DatabaseInstanceCredentialsProvider ) は、 AWS Secrets Manager (ASM)にデータベースの認証情報を作成し、保存します。 2番目のリソースプロバイダ( DatabaseInstanceProvider )は、クラスタVPC内にAmazon RDS for PostgreSQLデータベースインスタンスを作成し、コンテキストからASMのシークレット名を取得し、作成時にそれをデータベースに渡します。 External Secrets アドオン を活用するアドオン（ BackstageSecretAddOn ）は、 ASM を指す ClusterSecretStore オブジェクトと、ASM から認証情報を取得する ExternalSecret を作成し、 POSTGRES_USER と POSTGRES_PASSWORD をキーとする新しい Kubernetes Secret に注入します： … data: [ { secretKey: "POSTGRES_PASSWORD", remoteRef: { key: databaseInstanceCredentialsSecretName, property: "password" } }, { secretKey: "POSTGRES_USER", remoteRef: { key: databaseInstanceCredentialsSecretName, property: "username" } }, ], … 前回説明したように、Secret 内に保持されている認証情報は、環境変数 $POSTGRES_USER と $POSTGRES_PASSWORD としてポッドに渡されます。 3つ目のResource Provider( CreateCertificateProvider )は、Amazon Route 53 Hosted Zoneにサブドメインを作成し、AWS Certificate Manager(ACM)に関連証明書を作成します： blueprints.EksBlueprint.builder() … .resourceProvider(blueprints.GlobalResources.HostedZone, new blueprints.ImportHostedZoneProvider(props.hostedZoneId, props.parentDomain)) .resourceProvider(props.certificateResourceName, new blueprints.CreateCertificateProvider("elb-certificate", subdomain, blueprints.GlobalResources.HostedZone)) 証明書は、コンテキストからBackstageアドオンによって取得され、その ARN が抽出され… const annotations = { … "alb.ingress.kubernetes.io/certificate-arn": clusterInfo.getResource<ICertificate>(helmOptions.certificateResourceName)?.certificateArn }; … と Ingressに割り当てられます： setPath(values, "ingress.annotations", annotations); AWS マネジメントコンソール の Route 53 セクションに、このスクリーンショットのように新しいサブドメインレコードが表示されます： 証明書は AWS Certificate Manager セクションに表示されます： 今から何ができるでしょうか？ Backstage は、場所に関係なく組織のリソースを単一の画面で表示できるほか、開発ツールの導入や使用開始を簡単に行うことができます。また、バックエンドやフロントエンド・アプリケーションなどの新しいリソースを、ポータルから簡単に作成することもできます。 Developer Platform のセットアップが完了したら、その利点を活かして Software Catalog の作成から始めましょう。Software Catalog を使用すると、環境内のすべてのソフトウェア（サービス、Web サイト、ライブラリ、パイプラインなど）の所有権とメタデータを一元的に追跡できます。カタログは、ソース・コントロールに保存されたメタデータ YAML ファイルから作成され、Backstage にさまざまな方法で登録され、開発者に包括的なビューで表示されます。 検討したいもう 1 つの機能は、エンジニアリング チームがコンポーネントを構築し、チームのベスト プラクティスに合わせた新しいプロジェクトを迅速に作成できるようにする Software Templates です。これは、エンジニアリングチームがコンポーネントを構築し、チームのベストプラクティスに沿った新しいプロジェクトを迅速に作成することを可能にします。これにより、エンジニアリングチームは、車輪の再発明を避け、意思決定を少なくし、よりコアな活動に集中することができます。Software Templates は Golden Paths の概念の基礎であり、バックエンド サービス、Web アプリケーション、CI/CD パイプラインなどを構築するための Backstage としてのやり方であり、支持される方法です。Golden Paths を使えば、慣習や標準を法的に制定するのではなく、チームが新しいプロジェクトを適切な状態で簡単に始められるようにすることができます。 さらに、 TechDocs を使ってドキュメントを作ることもできる。これにより、関連するコードと同じ場所に保存されるMarkdown ファイルを書くことができます。これらのファイルは、Backstage でクリーンかつ明確に表示されます。 Backstage の詳細なドキュメントや機能、ユースケースについては、 Backstage のウェブサイト をご覧ください。 後片付け 今後の課金を避けるため、 make pattern backstage destroy コマンドを実行してください。 まとめ この投稿では、Amazon EKS Blueprints の Backstage アドオンと Amazon EKS Blueprints Patterns の Backstage パターンを使用して、ビルド済みで設定済みの Backstage アプリケーションをデプロイする方法を紹介しました。また、依存関係を含む Backstage を実行する完全なソリューションを実現するために、パターンの設定パラメーターと、パターンがリソースプロバイダーや他のアドオンをどのように結び付けるかについて説明しました。 Riccardo Freschi Riccardo Freschi は AWS のシニアソリューションアーキテクトで、アプリケーションモダナイゼーションにフォーカスしています。パートナーや顧客と密接に連携し、既存アプリケーションのリファクタリングやクラウドネイティブでの新規アプリケーションの構築を通じて、AWS クラウドへの移行における IT ランドスケープの変革を支援しています。 本記事は、Riccardo Freschi による “ Building Developer Portals with Backstage and Amazon EKS Blueprints ” を翻訳したものです。翻訳はソリューションアーキテクトの堀 竜慈が担当しました。

私たちは 生成人工知能 (AI) の時代、つまり、急速なイノベーションの時代に生きています。Anthropic が 3 月 4 日に Claude 3 基盤モデル (FM) を発表したとき、弊社は即日、スキルとスピードのバランスがとれたモデルである Claude 3 Sonnet を Amazon Bedrock で利用できるようにしました。3 月 13 日、弊社は Amazon Bedrock で Claude 3 Haiku モデル をリリースしました。これは、ほぼ瞬時の応答性を実現する、Claude 3 ファミリーの中で最も高速かつ最もコンパクトなモデルです。 4月16日、 Anthropic の Claude 3 Opus が Amazon Bedrock で 利用可能になったことをお知らせします。これは、非常に複雑なタスクで市場最高レベルのパフォーマンスを発揮する、最もインテリジェントな Claude 3 モデルです。オープンエンドのプロンプトや、これまでに経験のないシナリオに、驚くべき流暢さと人間のような理解力で対応でき、汎用知能のフロンティアをリードします。 Amazon Bedrock で Claude 3 Opus が利用できるようになったことで、企業は生成 AI アプリケーションを構築してタスクを自動化したり、ユーザー向けアプリケーションを通じて収益を生み出したりできるほか、複雑な財務予測を実行し、さまざまなセクターにわたる研究開発を加速することもできます。他の Claude 3 ファミリーと同様に、Opus は画像を処理してテキスト出力を返すことができます。 Claude 3 Opus では、難しいオープンエンドの質問に関して、Claude 2.1 に比べて推定 2 倍の精度の向上を実現しています。これにより、誤った応答の可能性が低減されます。企業のお客様は、ヘルスケア、金融、法律調査などのさまざまな業界で Claude を利用しているため、高い安全性とパフォーマンスを実現には精度の向上が不可欠です。 Claude 3 Opus のパフォーマンス Claude 3 Opus は、 学部レベルの専門知識 (MMLU)、 大学院レベルの専門的推論 (GPQA)、 基礎数学 (GSM8K) など、AI システムの一般的な評価ベンチマークのほとんどで競合製品を上回るパフォーマンスを発揮しています。複雑なタスクにおいて高いレベルの理解力と流暢さを示し、汎用知能のフロンティアをリードします。 出典: https://www.anthropic.com/news/claude-3-family Claude 3 Opus モデルでサポートされているユースケースをいくつかご紹介します。 タスクオートメーション : API、データベース、インタラクティブコーディングにわたる複雑なアクションの計画と実行 研究 : ブレーンストーミングと仮説の生成、研究レビュー、創薬 戦略 : チャートとグラフ、財務と市場動向、予測の高度な分析 Claude 3 Opus の特徴や機能の詳細については、 Bedrock での Anthropic の Claude ページと、Amazon Bedrock ドキュメントの「 Anthropic Claude models 」をご覧ください。 Claude 3 Opus の動作 Anthropic のモデルを初めて使用する場合は、 Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択します。 Claude 3 Opus のためのアクセスを個別にリクエストします。 コンソールで Claude 3 Opus をテストするには、左側のメニューペインの [プレイグラウンド] で、 [テキスト] または [チャット] を選択します。その後、 [モデルを選択] を選択し、カテゴリとして [Anthropic] 、モデルとして [Claude 3 Opus] をそれぞれ選択します。 さらに多くの Claude プロンプトのサンプルをテストするには、 [サンプルをロード] を選択します。四半期レポートの分析、ウェブサイトの構築、横スクロールゲームの作成など、Claude 3 Opus に固有のサンプルを表示および実行できます。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id anthropic.claude-3-opus-20240229-v1:0 \ --body "{\"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\" Your task is to create a one-page website for an online learning platform.\\n\"}]}],\"anthropic_version\":\"bedrock-2023-05-31\",\"max_tokens\":2000,\"temperature\":1,\"top_k\":250,\"top_p\":0.999,\"stop_sequences\":[\"\\n\\nHuman:\"]}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt Claude 3 モデルのリリースに関する以前の記事で述べたように、画像処理などの一部の Claude 3 モデルの機能には、新しい Anthropic Claude Messages API 形式 を使用する必要があります。 Anthropic Claude Text Completions API を使用しており、Claude 3 モデルを使用したい場合は、 Text Completions API からアップグレード する必要があります。 私の同僚の Dennis Traub と Francois Bouteruche は、AWS SDK を使用して Amazon Bedrock 用のコードサンプル を作成しています。Amazon Bedrock で Claude 3 を呼び出して テキストを生成 したり、 画像分析用のマルチモーダルプロンプト を実行したりする方法については、Amazon Bedrock のドキュメントをご覧ください。 Messages API リクエストを送信してテキストを生成するサンプル JavaScript コードを次に示します。 // claude_opus.js - Messages API を使用して Anthropic Claude 3 Opus を呼び出します。 import { BedrockRuntimeClient, InvokeModelCommand } from "@aws-sdk/client-bedrock-runtime"; const modelId = "anthropic.claude-3-opus-20240229-v1:0"; const prompt = "Hello Claude, how are you today?"; // 新しい Bedrock Runtime クライアントインスタンスを作成します const client = new BedrockRuntimeClient({ region: "us-east-1" }); // モデルのためにペイロードを準備します const payload = { anthropic_version: "bedrock-2023-05-31", max_tokens: 1000, messages: [{ role: "user", content: [{ type: "text", text: prompt }] }] }; // ペイロードを使用して Claude を呼び出し、応答を待ちます const command = new InvokeModelCommand({ contentType: "application/json", body: JSON.stringify(payload), modelId }); const apiResponse = await client.send(command); // Claude の応答をデコードして出力します const decodedResponseBody = new TextDecoder().decode(apiResponse.body); const responseBody = JSON.parse(decodedResponseBody); const text = responseBody.content[0].text; console.log(`Response: ${text}`); これで、AWS SDK for JavaScript Runtime Client for Node.js をインストールし、 claude_opus.js を実行できるようになりました。 npm install @aws-sdk/client-bedrock-runtime node claude_opus.js さまざまなプログラミング言語の他の例については、 「Amazon Bedrock ユーザーガイド」のコードサンプルのセクション を確認し、Community.aws にて Anthropic Claude でシステムプロンプトを使用する 方法を学習してください。 今すぐご利用いただけます Claude 3 Opus は現在、米国西部 (オレゴン) リージョンでご利用いただけます。今後の更新については、 リージョンの詳細なリスト をご覧ください。 Amazon Bedrock コンソール で Claude 3 Opus を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

コンテナはアプリケーション開発を加速し、環境間でのデプロイの一貫性を高めるため、組織のプロダクティビティとアジリティを向上させることができます。 Amazon Elastic Container Service (Amazon ECS) などの AWS コンテナサービスは、アプリケーションの管理を簡素化し、イノベーションとビジネスニーズに注力できるようサポートします。 顧客体験はすべての組織にとって、アプリケーションのパフォーマンスを測る上で最も重要な指標です。さまざまなリクエストのパターンに対して、エンドユーザーへの信頼性と一貫性のある体験を維持することは、すべての組織が直面する課題です。ベストプラクティスとして、Amazon ECS サービスでタスクの望ましい数を自動的に増やす (スケールアウトする) ことや、減らす (スケールインする) ことができます。これにより、トラフィックの急増に対して手動でリアルタイムに対応する必要がなくなります。オートスケーリングを活用し、実際に必要なリソースにのみ支払うことで AWS サービス利用時の使用量とコストを適切に制御することができます。 AWS では、Amazon ECS サービスをオートスケーリングするための複数の機能を利用できます。適切なオプションを選択することで、アプリケーション全体の信頼性が向上し、運用コストと複雑さが軽減され、エンドユーザエクスペリエンスが向上します。この投稿では、まず AWS Application Auto Scaling について学び、これを使って Amazon ECS サービスのオートスケーリングを設定する方法を説明します。次に、アプリケーションオートスケーリングに使用できる Amazon ECS Service Connect と AWS Distro for OpenTelemetry (ADOT) についても説明します。 アプリケーションのオートスケーリング サービスのオートスケーリングを使用すると、お使いの Amazon ECS サービス内のタスク数を自動的に増減できます。Amazon ECS はこの機能を提供するために、Application Auto Scaling サービスを利用しています。デフォルトでは、Amazon ECS は Amazon CloudWatch に CPU とメモリの使用状況を公開します。これらの CloudWatch メトリクスまたはその他のカスタムメトリクスを使って、サービスをスケーリングできます。Amazon ECS サービスのオートスケーリング機能では、以下のようなオートスケーリングの種類がサポートされています。 ターゲット追跡スケーリングポリシー – 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減できます。例えば、CPU 使用率が 75% を超えた場合はサービスにタスクを追加し、CPU 使用率がターゲット値の 75% を下回った場合はタスクを削除するというスケーリングポリシーを定義できます。時には、アプリケーション固有のメトリクス (リクエスト数など) や、他の AWS サービスが公開したメトリクスに基づいてスケーリングしたい場合もあるでしょう。その際は、算術演算や関数を用いて、ターゲット追跡ポリシーで使用するメトリクスをカスタマイズできます。カスタムメトリクスに基づくオートスケーリングの詳細については、 こちらの記事 を参照してください。次のスクリーンショットはターゲット追跡スケーリングポリシーの設定例を示しています。 ステップスケーリングポリシー – アラームの閾値超過の程度によって異なる一連のスケーリング調整を行うことをステップ調整と呼びます。これに基づいて、サービスが実行するタスク数を増減できます。ステップスケーリングでは、メトリクスのしきい値と、追加または削除するリソース量を選択できます。例えば、CPU 使用率が 50% から 75% の場合はタスクを 2 つ増やし、25% 未満の場合は 2 つ減らすというスケーリングポリシーを定義できます。次のスクリーンショットは、ステップスケーリングポリシーの設定例を示しています。 スケジュールされたスケーリング – サービスで実行されるタスクの数を、日付と時刻に基づいて増減させることができます。例えば、ピーク時にサービス中のタスク数を増加させ、オフピーク時にタスク数を減らすよう、スケジュールを設定できます。スケジュール設定に基づくスケーリングは、 AWS コマンドラインインターフェース (AWS CLI) で設定できます。スケジュール設定に基づくスケーリングとスケーリングポリシーを組み合わせて使うと、事前のスケーリングアプローチと事後のスケーリングアプローチの両方のメリットを得られます。スケジュールされたスケーリングアクションを実行した後、スケーリングポリシーが容量をさらにスケーリングする必要があるかどうかを判断します。これにより、アプリケーションの負荷に対応するのに十分な容量を確保できます。 サービスのオートスケーリングは Amazon ECS サービスを簡単にスケーリングできる仕組みで、 AWS マネジメントコンソール 、AWS CLI、AWS SDK を使ってスケーリングを設定できます。 スケーリングポリシーは、クールダウン期間をサポートしています。これは、スケーリングアクションが有効になるまでの待機秒数です。スケールアウト時にタスクは継続的に増加しますが、スケールイン時にはタスクが慎重に減少します。アプリケーションの可用性を守るために、クールダウン期間が終了するまでスケールイン活動はブロックされます。 次の図は、ターゲット追跡スケーリングポリシーの動作例を示しています。 Application Auto Scaling の料金 この機能を使用するための追加料金はかかりません。アプリケーションを保管および実行するために作成する AWS リソースの料金のみがかかります。利用したリソースに対してのみ課金され、最小利用料金はありません。 Amazon ECS Service Connect Amazon ECS Service Connect は、アプリケーションコードの変更なしに、シームレスなサービス間接続性と、リッチなトラフィックテレメトリを提供します。これは、Amazon ECS 内にサービスディスカバリとサービスメッシュの両方を構築することで実現されます。Service Connect 構成を使用すると、Amazon ECS は新しいタスクを起動するたびに、サイドカープロキシコンテナを各タスクに自動的に注入します。Amazon ECS はこの構成を自動的に管理します。 低レイテンシーが要件で、新規クライアント数、受信リクエスト数、エラー率、失敗した TLS 接続数などのメトリクスを監視する必要がある場合は、Amazon ECS Service Connect の設定をお勧めします。Amazon ECS Service Connect は、トラフィックのルーティングと管理のために、サービスメッシュの集中管理アーキテクチャを使用します。Amazon ECS Service Connect によって作成されるトラフィック監視のためのメトリクスは、Amazon ECS コンソールから直接確認でき、これらのメトリクスは CloudWatch にも送信されます。一度 CloudWatch でメトリクスを利用できるようになれば、それらを使って Amazon ECS サービスタスクのオートスケーリングを設定することができます。 以下は、Amazon ECS Service Connect を通じて提供され、最も一般的に使用されるメトリクスです。また、 完全なリストはこちら になります。 ActiveConnectionCount クライアントからのアクティブな同時接続の総数 NewConnectionCount クライアントから確立された新しい接続の総数 TargetResponseTime アプリケーションのリクエスト処理レイテンシ ClientTLSNegotiationErrorCount TLS 接続が失敗した総数 HTTPCode_Target_5XX_Count HTTP レスポンスコード 500 から 599 の数 Amazon ECS Service Connect を使用すると、 AWS Cloud Map が提供する名前空間を使って論理名でサービスを参照および接続でき、ロードバランサーをデプロイして構成することなく、Amazon ECS タスク間でトラフィックを自動的に分散できます。さらに、Amazon ECS コンソールには、運用の利便性向上と簡易なデバッグのための、リアルタイムのネットワークトラフィックメトリクスを表示できる便利なダッシュボードが用意されています。次の図では、Amazon ECS Service Connect でのリクエストの流れと、メトリクスが CloudWatch に公開される様子を示しています。 以下のスクリーンショットは、Service Connect によって測定されたトラフィックの状況を示すトラフィックヘルスビューを示しています。このビューには、Service Connect を経由するアクティブな接続数と、サービス内のすべてのタスクに対する応答の HTTP ステータスコードが表示されます。Amazon ECS Service Connect は、インフラストラクチャのプロビジョニング、コードのデプロイ、サービスの監視のために、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) 、 AWS Copilot 、 AWS Proton で完全にサポートされています。 Amazon ECS Service Connect の料金 Amazon ECS Service Connect によるサービスディスカバリ、接続機能、トラフィックテレメトリについての追加料金はありません。 Amazon ECS Service Connect エージェント が消費するリソース分のみの料金がかかります。お勧めとしては、Service Connect コンテナに 256 CPU ユニットと 64 MB のメモリを追加することです。これは別途設定するものではありませんが、タスク割り当て時に考慮されます。アイドル時の消費は約 100 CPU ユニットと 40 MB のメモリです。 AWS Distro for OpenTelemetry (ADOT) OpenTelemetry (OTEL) コレクターには、CloudWatch などさまざまなデータソースにデータをエクスポートするコンポーネントが含まれています。OpenTelemetry は、オープンソースのテレメトリ収集プロジェクトで、様々なアプリケーションやインフラストラクチャからデータを収集して単一の出力形式で提供します。 AWS Distro for OpenTelemetry Collector (ADOT コレクター) は、AWS がサポートしている OpenTelemetry コレクターで、AWS から配布およびサポート提供されています。このコンポーネントにより、テレメトリデータを CloudWatch やその他のサポート対象な監視ソリューションに送信できます。 Amazon ECS で ADOT を利用してオブザーバビリティを有効にするには、以下の 2 つのステップが必要です。 一度の計装で関連ログ、メトリクス、トレースを 1 つ以上のモニタリングソリューションに送信できます。プログラミング言語用の エージェント を有効化すれば、コードを変更せずに自動計装を使用できます。 以下の 2 つの方法のうち、いずれかを使用して ADOT Collector をデプロイします。 サイドカーパターン（タスク内のアプリケーションコンテナとは別のコンテナに ADOT Collector をデプロイする方法） Amazon ECS サービスパターン（独立した Amazon ECS サービスとして ADOT Collector をデプロイする方法） ADOT コレクタは ECS メタデータエンドポイント をスクレイピングし、コンテナの CPU、メモリ、ネットワーク、ディスク使用量などのメトリクスを収集します。ADOT を CloudWatch と統合することで、これらのメトリクスを CloudWatch コンソールから直接収集、分析、可視化できます。次の図は、ADOT SDK を使用してアプリケーションを計装する方法、ADOT コレクタによるメトリクスのスクレイピング方法、および CloudWatch EMF エクスポーターによる メトリクス の CloudWatch への送信方法に関するハイレベルのフローを示しています。 ADOT コレクターには、メトリクスを収集するためのデフォルト設定が備わっています。このデフォルト設定により、メトリクスパイプラインで AWS EMF エクスポーター ( awsemfexporter ) が有効になります。これは OTEL メトリクスを CloudWatch が受け付ける形式のバッチログに変換してから CloudWatch に送信します。CloudWatch コンソールからは、ログをクエリできるほか、ダッシュボードで可視化したり、メトリクスアラームを作成することができます。 ECS で実行しているアプリケーションが CloudWatch に送信できるメトリクスのタイプを、カスタマイズすることもできます。例えば、以下のメトリクスを収集できます: ecs.task.memory.utilized (タスクのメモリ使用量)、ecs.task.memory.reserved (タスクの予約メモリ量)、ecs.task.cpu.utilized (タスクの CPU 使用量)、ecs.task.cpu.reserved (タスクの予約 CPU 量)、ecs.task.network.rate.rx (タスクのネットワーク受信量)、ecs.task.network.rate.tx (タスクのネットワーク送信量)、ecs.task.storage.read.bytes (タスクのディスク読み取りバイト数)、ecs.task.storage.write.bytes (タスクのディスク書き込みバイト数)。 これらのメトリクスが CloudWatch で利用できるようになると、Amazon ECS サービスタスクのオートスケーリング設定にこれらのメトリクスを使用することができます。 AWS Distro for OpenTelemetry の料金 AWS Distro for OpenTelemetry の利用には料金はかかりません。CloudWatch に送信されるトレース、ログ、メトリクスの料金のみが課金されます。CloudWatch は前払い料金やサービス最低料金がなく、利用分のみを支払えばよいサービスです。詳細は CloudWatch の 料金ページ をご確認ください。 まとめ この記事では、Amazon ECS サービスをスケールするために利用可能な、AWS ネイティブなスケーリングオプションについて学びました。さまざまな規模の企業が、高い信頼性で一貫した顧客体験を維持する戦略の一環として、この方法を採用し、 Amazon ECS サービスをスケールできます。適切なメカニズムは、デプロイの敏捷性、事前/事後/予測スケーリングや、料金などの観点から決まります。 詳細については、 AWS Well-Architected フレームワーク 、 Amazon ECS でアプリケーションを実行する際のベストプラクティス 、 Amazon Elastic Container Service のセキュリティ を参照してください。私たちにお手伝いできることがあれば、 AWS サポート および AWS アカウントチームにご連絡ください。 本記事は、 Scale your Amazon ECS using different AWS native services! (2024 年 3 月 8 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

世界中の AWS コミュニティで AWS Community Day カンファレンスが絶賛開催中です。先週開催された AWS Community Day Poland には、600 人を超えるクラウド愛好家が参加しました。1 日を通じて、コミュニティスピーカーである Agnieszka Biernacka 氏や Krzysztof Kąkol 氏などが講演して観客を魅了し、これらをきっかけに活気のあるディスカッションが繰り広げられました。私のチームメイトである Wojtek Gawroński もイベントに参加し、来年また参加することを既に心待ちにしています! 4月８週のリリース 4月8日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon CloudFront が Lambda 関数 URL オリジンに対するオリジンアクセスコントロール (OAC) のサポートを開始 – 指定された CloudFront ディストリビューションからのアクセスのみを許可する Amazon CloudFront のオリジンアクセスコントロール (OAC) を使用して、 AWS Lambda URL オリジンを保護できるようになりました。「 CloudFront デベロッパーガイド 」には、指定された CloudFront ディストリビューションからの Lambda 関数 URL へのアクセスを認証するために CloudFront OAC の使用を開始する方法が詳しく説明されています。 AWS Client VPN と AWS Verified Access の移行と相互運用性のパターン – 現在 AWS Client VPN 、または類似する VPN ベースのサードパーティーソリューションを使用してアプリケーションへのセキュアなアクセスを提供しているならば、嬉しいお知らせがあります。新規または既存のアプリケーションのために AWS Client VPN と AWS Verified Access の使用を組み合わせることが可能になりました。 Amazon Bedrock のナレッジベースに関する次の 2 つの発表が目に留まりました。 メタデータフィルタリングによる検索精度の向上 – メタデータフィルタリングでは、適用されたメタデータフィルターと関連付けられた値に基づいて、意味的関連性のあるチャンクだけでなく、これらの関連性のあるチャンクの明確に定義されたサブセットも取得できます。 RetrieveAndGenerate API 向けのカスタムプロンプトと最大取得結果数の設定 – これらは、検索タイプとともにクエリオプションとして選択できるようになった 2 つの新しい機能で、検索結果の制御を可能にします。結果はベクトルストアから取得され、回答の生成のために 基盤モデル に渡されます。 AWS からの発表の完全なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS ニュース AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo がこちらの Open Source Newsletter を毎週執筆して、AWS コミュニティからの新しいオープンソースプロジェクト、ツール、およびデモを紹介しています。 近日開催予定の AWS イベント AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お住まいの地域が南北アメリカ、アジア太平洋、日本、EMEA であるかにかかわらず、地域内で開催される 今後の AWS Summit イベントに関する情報については、こちらをご覧ください 。 AWS Community Day – この記事の冒頭で紹介したものと同じような AWS Community Day イベント で、地域のエキスパート AWS ユーザーや業界リーダーが主導するテクニカルディスカッション、ワークショップ、ハンズオンラボに参加しましょう。 ケニア 、または ネパール にお住まいの場合は、4月15日週末に地域で開催されるイベントがあります。 こちらで、 近日中に開催されるすべての対面およびバーチャルイベントを閲覧 することができます。 4月15日週のニュースは以上です。4月22日週の Weekly Roundup もお楽しみに! – Veliswa この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします。 原文は こちら です。

PartyRock Generative AI Hackathon は4月初めに終了しました。参加者は、 PartyRock を利用して、4 つのチャレンジカテゴリのいずれかに基づいた機能的なアプリケーションを構築するよう求められました。既存のアプリケーションをリミックスするオプションもありました。このハッカソンには 7,650 名の登録者が集まり、1,200 を超えるプロジェクトが提出され、250 を超えるプロジェクトのブログ記事が community.aws で公開されました。 私は審査員の一員として、審査を依頼された応募作品の創造性と洗練さに驚かされました。参加者は、プロンプトエンジニアリングを実践し、基盤モデルについて学ぶ機会を得て、可能なことの限界を押し広げました。 上位 3 位の受賞者を簡単に見てみましょう… 第 1 位 まず、総合第 1 位の 20,000 USD の AWS クレジットを獲得したのは、 Param Birje 氏 による Parable Rhythm – The Interactive Crime Thriller です。このプロジェクトでは、PartyRock の生成機能を使用して、魅力的かつインタラクティブで没入できるストーリーを提供します。信じられない質の高さです。 詳細については、 ハッカソンでの提出物 および ブログ記事 をご覧ください。 第 2 位 第 2 位の 10,000 USD のクレジットを獲得したのは、 Michael Oswell 氏 による Faith – Manga Creation Tools です。このクリエイティブアシスタントアプリケーションを使用すると、ボタンをクリックするだけで独自のマンガのコマを生成できます。とても多くの可能性が秘められています。 詳細については、 ハッカソンでの提出物 をご覧ください。 第 3 位 最後に、総合第 3 位は、 Arghhhh! Zombie ( Michael Eziamaka 氏 ) です。これは、AI を活用した非常に面白い生成ゾンビゲームで、審査員たちもハラハラさせられていました。Michael、すばらしい作品でした! 詳細については、 ハッカソンでの提出物 をご覧ください。 拍手喝采 各カテゴリの受賞者全員にも大きな拍手を送りたいと思います。 カテゴリ/順位 提出物 賞金 (USD) AWS クレジット 総合 第 1 位 Parable Rhythm – 20,000 USD 総合 第 2 位 Faith – Manga Creation Tools – 10,000 USD 総合 第 3 位 Arghhhh! Zombie – 5,000 USD クリエイティブアシスタント 第 1 位 Faith – Manga Creation Tools 4,000 USD 1,000 USD クリエイティブアシスタント 第 2 位 MovieCreator 1,500 USD 1,000 USD クリエイティブアシスタント 第 3 位 WingPal 500 USD 1,000 USD 実験的なエンターテインメント 第 1 位 Parable Rhythm 4,000 USD 1,000 USD 実験的なエンターテインメント 第 2 位 Arghhhh! Zombie 1,500 USD 1,000 USD 実験的なエンターテインメント 第 3 位 Find your inner potato 500 USD 1,000 USD インタラクティブラーニング 第 1 位 DeBeat Coach 4,000 USD 1,000 USD インタラクティブラーニング 第 2 位 Asteroid Mining Assistant 1,500 USD 1,000 USD インタラクティブラーニング 第 3 位 Unlock your pet’s language 500 USD 1,000 USD フリースタイル 第 1 位 MindMap Party 1,000 USD 1,000 USD フリースタイル 第 2 位 Angler Advisor 750 USD 1,000 USD フリースタイル 第 3 位 SafeScares 250 USD 1,000 USD ボーナス: Remix ChatRPG Inferno – 2,500 USD ボーナス: Remix ChatRPG Chat RPG Generator – 2,500 USD インタラクティブラーニングエクスペリエンスから実験的なエンターテインメントまで、発揮された創造性と技術的な実行力は並外れたものでした。 そしてもちろん、生成 AI で可能なことの限界を押し広げてくれた 7,650 名の参加者全員に心から感謝します。皆さんの参加は大変誇るべきことです。 パーティーに参加しよう 上記の画像のいずれかをクリックすると、アプリケーションをご自身でお試しいただけます。それらをリミックスしてカスタマイズしたり、独自のアプリケーションを構築したりすることもできます (開始方法については、私の記事「 Build AI apps with PartyRock and Amazon Bedrock 」をお読みください)。 以上となります。受賞者の皆様に改めて祝意を表したいと思います。また、PartyRock チームとすばらしいスポンサーの皆様に心から感謝します。皆さんが次に何を構築するのか楽しみです。それまで、構築と学習を継続し、楽しみ続けましょう! – Jeff ; 原文は こちら です。

組織は、ベストプラクティスに従ってアプリケーションを実行できるよう、クラウドインフラストラクチャに対してコンプライアンスルールを適用しています。 AWS Config を活用して、内部のガイドラインに従って構成された設定に対する、全体的なコンプライアンス状況を確認します。この確認は、AWS アカウントでクラウドリソースを作成した後で行なわれます。 この記事では、AWS アカウントでクラウドリソースを作成する前に、 AWS CDK Aspects を利用してベストプラクティスに従っているかどうかをチェックしたり、従うための調整を行なう方法を紹介します。 AWS Cloud Development Kit (AWS CDK) は、TypeScript、Python、Java、.NET などの馴染み深いプログラミング言語を使ってクラウドアプリケーションリソースを定義できるオープンソースのソフトウェア開発フレームワークです。インフラストラクチャを定義するためにプログラミング言語の表現力を活用することで開発プロセスを加速させ、開発者体験を向上させることができます。 AWS Config は、AWS リソースの構成を評価・監査できるサービスです。AWS リソースの構成を継続的に監視・記録し、記録された構成が望ましい状態かどうかの評価を自動化できます。非準拠リソースが見つかった場合は、そのリソースを自動または手動で望ましい状態に修正できます。 AWS Config は、お客様がコンプライアンスに準拠した状態で AWS 上でワークロードを実行できるように支援しますが、前もって非準拠リソースを検知し、コンプライアンスに準拠したリソースのみをプロビジョニングしたいと考えるお客様も存在します。リソースの構成にはお客様にとって非常に重要なものもあるため、最初からコンプライアンスに準拠していない限りリソースをプロビジョニングしないと考える場合があります。たとえば次のような構成です。 Amazon S3 バケットは、パブリックアクセスを許可せずに作成する必要がある Amazon S3 バケットの暗号化を有効にする必要がある データベース削除保護を有効にする必要がある CDK Aspects CDK Aspects は、特定のスコープ内のすべての construct に対して共通の操作を適用する方法です。Aspect は、construct の状態について何らかの検証 (すべてのバケットが暗号化されていることを保証する、など) を行なったり、タグを追加するなど construct に対する修正を行なうことができます。 Aspect は、以下に示す IAspect インターフェイスを実装するクラスです。Aspect は Visitor パターンを採用しているため、既存のオブジェクト構造を修正することなく新しい操作を追加できます。オブジェクト指向プログラミングやソフトウェア工学において、 Visitor デザインパターン とは、オブジェクト構造からその上で動作するアルゴリズムを分離する手法のことです。 interface IAspect { visit(node: IConstruct): void ; } cdk deploy を呼び出すと、AWS CDK アプリケーションは以下のようにライフサイクルフェーズが遷移します。これらのフェーズは下の図でも表現されています。CDK アプリケーションのライフサイクルについての詳細については、 こちら のページを参照してください。 Construction Preparation Validation Synthesis Deployment CDK Aspect は Preparation フェーズで関係してきます。この Preparation フェーズでは、construct の最終的な状態を設定するための最後の変更ラウンドが実行されます。Preparation フェーズは自動的に実行されます。すべての construct は、内部に Preparation フェーズ中に呼び出され適用される Aspect のリストを持っています。次のメソッドを呼び出すことで、指定したスコープにカスタム Aspect を追加できます。 Aspects.of(myConstruct).add(new SomeAspect(...)); 上記のメソッドを呼び出すと、construct は内部の Aspect リストに カスタム Aspect を追加します。CDK アプリケーションが Preparation フェーズを処理するとき、AWS CDK は 指定した construct およびその配下の construct について上位から下位の順で、Aspect オブジェクトの visit メソッドを呼び出します。 visit メソッドは、construct に対して任意の変更を適用できます。 CDK Aspects を利用してリソース構成のコンプライアンスをチェックする方法・準拠させる方法 次のセクションでは、クラウド リソースをプロビジョニングする際のいくつかの一般的なユースケースにおいて、CDK Aspects を実装する方法をご紹介します。CDK Aspects は拡張可能です。追加のルールを実装することで、ユースケースに合わせて拡張できます。 以下のコードでは、Aspects を利用してベストプラクティスに照らし合わせて検証するクラウドリソースを作成しています。 import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as rds from 'aws-cdk-lib/aws-rds'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Construct } from 'constructs'; export class AwsCdkAspectsStack extends cdk.Stack { constructor(scope: Construct, id: string, props ?: cdk.StackProps) { super(scope, id, props); //Create a VPC with 3 availability zones const vpc = new ec2.Vpc(this, 'MyVpc', { maxAzs: 3, }); //Create a security group const sg = new ec2.SecurityGroup(this, 'mySG', { vpc: vpc, allowAllOutbound: true }) //Add ingress rule for SSH from the public internet sg.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(22), 'SSH access from anywhere') //Launch an EC2 instance in private subnet const instance = new ec2.Instance(this, 'MyInstance', { vpc: vpc, machineImage: ec2.MachineImage.latestAmazonLinux2(), instanceType: new ec2.InstanceType('t3.small'), vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }, securityGroup: sg }) //Launch MySQL rds database instance in private subnet const database = new rds.DatabaseInstance(this, 'MyDatabase', { engine: rds.DatabaseInstanceEngine.mysql({ version: rds.MysqlEngineVersion.VER_8_0 }), vpc: vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS }, deletionProtection: false }) //Create an s3 bucket const bucket = new s3.Bucket(this, 'MyBucket') } } このセクションでは、Aspects を利用して以下のベストプラクティスに照らし合わせてリソースを検証するユースケースとコードを示しています。 VPC の CIDR 範囲は特定の CIDR IP から始まる必要がある セキュリティグループには public ingress ルールを設定してはいけない EC2 インスタンスは許可されたインスタンスタイプのみが利用可能である S3 バケットの暗号化を有効にする必要がある S3 バケットのバージョン管理を有効にする必要がある RDS インスタンスでは削除保護を有効にする必要がある import * as cdk from 'aws-cdk-lib'; import * as ec2 from 'aws-cdk-lib/aws-ec2'; import * as rds from 'aws-cdk-lib/aws-rds'; import * as s3 from 'aws-cdk-lib/aws-s3'; import { Stack, IAspect, Annotations, Tokenization } from 'aws-cdk-lib'; import { IConstruct } from 'constructs'; //Verify VPC CIDR range export class VPCCIDRAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof ec2.CfnVPC && node.cidrBlock) { if (! node.cidrBlock.startsWith('192.168.')) { Annotations.of(node).addError('VPC does not use standard CIDR range starting with "192.168."'); } } } } //Verify public ingress rule of security group export class SecurityGroupNoPublicIngressAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof ec2.CfnSecurityGroup) { checkRules(Stack.of(node).resolve(node.securityGroupIngress)); } function checkRules (rules : Array<ec2.CfnSecurityGroup.IngressProperty>) { if(rules) { for (const rule of rules.values()) { if (! Tokenization.isResolvable(rule) && (rule.cidrIp == '0.0.0.0/0' || rule.cidrIp == '::/0')) { Annotations.of(node).addError('Security Group allows ingress from public internet.'); } } } } } } //Verify instance type of EC2 instance export class EC2ApprovedITAspect implements IAspect { public visit(node: IConstruct) { const its = ['x', 'z', 'p', 'g', 'i', 't'] if (node instanceof ec2.CfnInstance && node.instanceType) { const instanceType = node.instanceType ; if (its.some(its => instanceType.startsWith(its))) { Annotations.of(node).addError('EC2 Instance is not using approved instance type.'); } } } } //Verify that bucket versioning is enabled export class BucketVersioningAspect implements IAspect { public visit(node: IConstruct): void { if (node instanceof s3.CfnBucket) { if (! node.versioningConfiguration || (! Tokenization.isResolvable(node.versioningConfiguration) && node.versioningConfiguration.status !== 'Enabled')) { Annotations.of(node).addError('S3 bucket versioning is not enabled.'); } } } } //Verify that bucket has server-side encryption enabled export class BucketEncryptionAspect implements IAspect { public visit(node: IConstruct): void { if (node instanceof s3.CfnBucket) { if (! node.bucketEncryption) { Annotations.of(node).addError('S3 bucket encryption is not enabled.'); } } } } //Verify that DB instance deletion protection is enabled export class RDSDeletionProtectionAspect implements IAspect { public visit(node: IConstruct) { if (node instanceof rds.CfnDBInstance) { if (! node.deletionProtection) { Annotations.of(node).addError('RDS DB instance deletion protection is not enabled.'); } } } } Aspect を作成したら、特定のスコープにそれらを追加します。スコープとして App、Stack、Construct が指定できます。以下の例では、すべての Aspect を Stack のスコープに追加します。 import * as cdk from 'aws-cdk-lib'; import { Aspects } from 'aws-cdk-lib'; import { AwsCdkAspectsStack } from '../lib/cdk-aspect-stack'; import { BucketEncryptionAspect, BucketVersioningAspect, EC2ApprovedITAspect, RDSDeletionProtectionAspect, SecurityGroupNoPublicIngressAspect, VPCCIDRAspect } from '../lib/cdk-aspect-rules'; const app = new cdk.App(); const stack = new AwsCdkAspectsStack(app, 'MyApplicationStack'); Aspects.of(stack).add(new VPCCIDRAspect()); Aspects.of(stack).add(new SecurityGroupNoPublicIngressAspect()); Aspects.of(stack).add(new EC2ApprovedITAspect()); Aspects.of(stack).add(new RDSDeletionProtectionAspect()); Aspects.of(stack).add(new BucketEncryptionAspect()); Aspects.of(stack).add(new BucketVersioningAspect()); app.synth(); 上記のコードで Aspect が追加された状態で cdk deploy を呼び出すと、次のような内容が出力されます。エラーを解決しリソースをルールに準拠させないかぎり、デプロイは実行されません。 コンプライアンスチェックだけではなく、Aspects を利用してリソースに共通の変更を加えることもできます。たとえば、タグに対応したすべてのリソースに必須のタグを設定できます。こうした機能を実現するために CDK Aspects を実装している例として Tags があります。 以下のようなコードを実装することで、Construct のスコープ内のすべてのリソースとその配下のリソース (タグに対応したリソースのみ) に、タグを追加したり削除したりできます。 Tags.of(myConstruct).add('key', 'value'); Tags.of(myConstruct).remove('key'); 以下は、Stack のスコープ内で作成されたすべてのリソースに Department タグを追加する例です。 Tags.of(stack).add('Department', 'Finance'); 開発者の皆さんには、Aspect の利用してインフラストラクチャリソースに動的な変更を加えることは避けることをお勧めします。そのような実装をすると、Synthesis フェーズで Stack に意図しない変更が発生してしまう可能性があります。IaC としての決定性が弱まり、CDK コードが唯一の信頼できる情報源ではなくなってしまいます。 (翻訳者補足: 外部から取得したパラメータを設定値として利用するなどの動的な変更をリソースに加えることは可能なかぎり避けて、決定論的な記述を心がけましょう。これは IaC の一般的なベストプラクティスです。Aspects を利用してリソースに変更を加える場合は、万が一意図しない変更が発生してしまったときの影響範囲が大きくなってしまう可能性があるため、とくにこの点を注意しましょう。) 追加の推奨事項 CDK Aspects は、開発者が選択したプログラミング言語を使用して、インフラストラクチャの構成をベストプラクティスに従うようにしたり、チェックしたりするための方法です。AWS CloudFormation Guard ( cfn-guard ) は、コンプライアンス管理者がシンプルな policy-as-code 言語でポリシーを記述し、ベストプラクティスを強制できるようにします。Aspects は CloudFormation テンプレートの生成前の Preparation フェーズで適用されますが、cfn-guard は CloudFormation テンプレートの生成後、Deployment フェーズの前に適用されます。開発者は CI/CD パイプラインの一部として Aspects または cfn-guard、あるいはその両方を使って非準拠リソースのデプロイを停止できます。ただし、非準拠リソースのデプロイを防ぎコンプライアンスを「強制する」意図が強い場合は、 CloudFormation Guard が適していると言えるでしょう。 cdk-nag は、AWS CDK Aspects を利用して多くのルールを実装し、パッケージとして提供するオープンソースプロジェクトです。たとえば AWS Solutions、HIPPA、NIST 800-53 などのパッケージがあります。このプロジェクトを利用すると、すでにパッケージ化されているルールを使って、CDK アプリケーションがベストプラクティスに従っているかどうかをチェックできます。評価したくないルールがある場合は、パッケージの中の一部のルールの評価を抑制できます。 まとめ インフラストラクチャの構築に AWS CDK を利用している場合は、リソースが作成される前にベストプラクティスに従うように、Aspects を使い始めることができます。CloudFormation テンプレートでインフラストラクチャを管理している場合は、この ブログ を読めば、CloudFormation テンプレートを AWS CDK に移行する方法がわかります。移行した後は、CDK Aspects を利用して、リソースがベストプラクティスに従っているかを、リソースの作成前に評価できます。 (翻訳者補足: 2024 年 4 月現在では、IaC 管理外のリソースもしくはデプロイ済みの CloudFormation スタックを CDK アプリケーションに移行できる CDK Migrate コマンド が利用できます。) 著者について Om Prakash Jha Om Prakash Jhaは AWS の Solutions Architect です。彼は小売業界のお客様が well-architected なアプリケーションを構築できるように支援しています。彼はミッション クリティカルなアプリケーションの開発、設計、アーキテクティングにおいて 10 年以上の経験を持っており、DevOps や Application Modernization に情熱を持っています。仕事以外では本を読んだり、映画を見たり、家族と一緒に世界を旅したりすることが好きです。 本記事は 2021/10/07 に投稿された  Align with best practices while creating infrastructure using CDK Aspects を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

製造業のお客様は、しばしば人材の不足が組織の生産性に影響を与えていると話しています。このように感じているのは、あなただけではありません。製造業の事業者の興味関心事項を集めている業界団体の全米製造業協会 (U.S. National Association of Manufacturers) は、CEO に対して四半期ごとに主要な事業課題についてアンケートを実施しています。最新のアンケート( 2023年第4四半期製造業の概況 )では、71%を超える製造業の企業が「優秀な人材を惹きつけ、維持できない」という問題が、他のいかなる問題よりも事業に影響を与えていると回答しています。この問題は長年にわたって懸念事項のトップであり、「製造業のスキルギャップ」という独自のブランディングさえされています。簡単に言えば、30年の経験を持つ製造業の従業員が退職し、次世代が参入せず、現世代にはさまざまな考え方や期待があるため、製造現場では純粋に20%の従業員が減少している状況です。パンデミックによってこの状況はさらに悪化しています。 製造業の企業は、離職率が高い今の時代に生産性を維持するため、恒常的に新しい従業員をすばやく訓練する必要があります。また、革新の速度や必要なスキルセットの変化に対応するために、既存の従業員の能力向上や再訓練を行う必要があります。さらに、専門家の退職や離職によって既存の知識が失われるリスクを回避するため、できるだけ早期に既存の知識を収集し制度化しなければなりません( “the silver tsunami” と呼ばれることがあります)。多国籍企業にとっては、組織内の知識が一つの言語で入力されているが、別の言語で利用する必要があるなど、さらなる課題があります。 組織における隠れた知識を収集、統合し、これらを解放して簡単にアクセス可能にすることは、自然言語処理技術の最前線にある課題です。このブログでは、生成 AI の技術、特に非構造化・分散した情報を文脈化して洞察を抽出する能力が、どのように製造業の企業のスキルギャップ解消に向けた進歩に役立っているかを明らかにします。 生成AIとは 生成 AI とは、膨大な量の幅広い非構造化データセットで学習された、数十億のパラメーターを持つ機械学習 (ML) モデルの領域を指します。これらの生成 AI モデル、一般に基盤モデル (FM) または大規模言語モデル (LLM) と呼ばれるモデルは、情報の取得と要約、質問への回答、オリジナルコンテンツの生成など、幅広い文脈に適用できる複雑な要求を解釈する能力を持っています。FM には、テキストを生成する (Text-to-Text モデル)、画像を生成する (Text-to-Image)、マルチモーダル (Text-to-Image, Image-to-Text) などさまざまな種類のモデルがあります。例としては、Anthropic Claude、Meta Llama、 Amazon Titan などの基盤モデルがあります。 基盤モデルは、一般的な知識タスクにおいて、そのままでも良好な性能を発揮しますが、ドメイン固有の知識は限られています。従業員のスキルギャップを埋めるために、多くの場合に企業の専有情報や機密と見なされるドメイン固有の能力こそが、製造業の顧客が必要としているものです。 データサイエンティストは、一から高度に特化したモデルを開発するよりも、むしろ既存の汎用 FM を出発点として活用し、ドメイン固有の情報にアクセスできるようにしてモデルの応答を微調整するソリューションを設計しています。よく知られた費用対効果の高いアーキテクチャパターンとして、Retrieval Augmented Generation(RAG) があります。RAG では、ドメイン固有の機密性の高い情報にスマートな検索を実行し、最も関連性の高い情報を探し出します。検索した結果は基盤モデルに渡され、その複雑な情報を解釈する能力を活用して、検索結果から意味を抽出し、ドメイン固有の知識に基づいて要約、質問回答、オリジナルコンテンツの生成を行います。この手法により、製造業のような事実を重要視する業界で最も重要なことですが、回答が正確になり、同時に機密情報を保護することができます。RAG を使えば、基盤モデル、知識ストア、スマート検索サービスを柔軟に選択することで、パフォーマンスとコストを最適化することもできます。 企業は、文書ナレッジベース、ERP(Enterprise Resource Planning)、MES(Manufacturing Execution Systems) などの企業が専有するデータソースと基盤モデルを組み合わせ、ドメイン固有で高度にパーソナライズされた技術情報を扱える学習チャットボットなどのソリューションを提供できます。 生成AIがスキルギャップの解消にどのように役立つか RAG アーキテクチャが作業員を支援する情報をどう活用するかを理解するために、たとえばチャットボットが設備の修理技術者を支援し、問題の診断に費やす時間を短縮するケースを想像してみましょう。設備が停止すると、重要な製造ラインの稼働が妨げられる可能性があります。ラインを稼働させ続けることは、すべての製造事業者の主要な業績評価指標の要素(総合装置効率, OEE の一部である Uptime) であり、企業の収益に直接影響することがあります。診断時間の短縮は修理時間の短縮へとつながり、機器の可用性を高めます。 このチャットボットは、裏側で Retrieval Augmented Generation(RAG) を使って基盤モデルと診断マニュアル、サービスニュース、過去の原因分析、保守システムの情報などの追加情報源を組み合わせます。これらの情報は紙の書類の場合があります。紙の文書では、関連する情報をデジタルデータの形で抽出する処理が必要になります。また、スマート検索と生成 AI はコンテンツがデジタル化されていることを前提としており、特定のファイル形式を使えば、単語、概念、語意のセマンティクスや類似性を解釈する能力が高まります。そのため、デジタル化されているソースの文書でも変換が必要になる場合があります。 AWS Step Functions 、 Amazon Textract 、 AWS Lambda などの AWS のマネージドサービスを活用した自動コンテンツ処理パイプラインを構築することで、新しい情報が追加されるたびに抽出・変換が可能です。多国籍企業や多言語の従業員がいる企業では、パイプラインの中で Amazon Translate を使って、ソース言語から一つ以上のターゲット言語に翻訳する手順が加わります。 このコーパスは、基盤モデルがドメインに特化したデータソースを参照して正確な回答を行うためのものです。基盤モデルは文脈を把握しながら情報を要約して人間が理解しやすくし、既存の検索手法を超えた対話型の質問と回答を可能にします。 企業には何千件もの知識文書のコーパスがある場合があります。修理技術者がそれらをすべて読んでいるとは限らず、さらに重要なことに、重大な問題を診断する際に適切な情報を見つけるのは非常に難しいでしょう。 Amazon Kendra や Amazon OpenSearch Service などの AWS サービスを使ってスマートな検索を実現すれば、技術者は数千件の知識文書を現在の問題に最も関連性の高いごく一部に絞り込むことができます。これにより数千件から数十件と技術者の認知負荷は軽くなりますが、それでも負担があります。その数十件の文書を Amazon Bedrock で実行されるマネージドな基盤モデルに渡せば、RAG プロセスを完成させ、数千件の知識文書全体を1つの段落や絞った手順に要約できます。 数千件から数十件へ、そして最終的には、修理を行う技術者が重大な生産の問題を診断し、解決するまでの時間短縮に役立つ1つの簡潔な回答へとたどり着きます。 上記のソリューションは、生成 AI 対応のアーキテクチャを製造業の課題解決に適用できる例の一つに過ぎません。このアーキテクチャには AWS のマネージドサービスが含まれています。技術的なアーキテクチャと全体的なソリューションを確認し、個別の要件を満たすために拡張、機能強化、最適化することをお勧めします。 ソリューションの概要 それでは、修理技術者の診断時間を短縮するために、診断マニュアルなどの静的で構造化されたデータと、センサーのテレメトリデータや異常検知アラートなどの動的なデータの両方にアクセスする方法を主眼としたアーキテクチャ例を見てみましょう。 既存の静的なコンテンツから知識を抽出 診断マニュアルなどの知識源はあまり変更されることがなく、修理用チャットボットで継続的に再利用するために処理して保存することは理にかなっています。これらの文書には、フォームやチャートなど、前処理が必要なコンテンツが含まれることがよくあります。Amazon Textract などのサービスを使用して、この情報を抽出することができます。複数の言語を扱う場合は、必要に応じて Amazon Translate を使用して、異なる言語間で翻訳することもできます。文書から抽出され翻訳された情報は処理されたのち、Amazon Kendra (他の選択肢も可能)などのセマンティック検索が可能なコンテンツ知識リポジトリに追加されます。RAG ベースのチャットボットは、この情報を使用して、基盤モデルに渡す関連情報を見つけ出します。 図面、診断マニュアル、SOP などの組織の知識源が、 Amazon S3 に保存されています。 AWS Lambda 関数がトリガーとなり、S3 の変更イベントに応じて AWS Step Functions のオーケストレーションが開始されます。 Step Functions のワークフローは、Amazon Textract を使用してこれらのデータソースから情報を抽出し、文書の性質に応じてAmazon Translateを使用して翻訳するように構成されています。 処理された文書が最終的なコーパスとして Amazon S3 に保存されます。 Amazon Kendra は、多言語の文書コーパスが保存されている Amazon S3 バケットを参照し、検索用にインデックス化します。 エンタープライズアプリケーションと設備監視システムからの知識の抽出 産業設備は、ライン上の機器に接続されたセンサーからテレメトリーデータを生成します。このデータを分析し、予測アルゴリズムを使用して異常を検出します。異常が検出されると、アラートが発報されたり、技術者による問題解決のためにワークオーダーが自動的に作成されます。アーキテクチャの例では、 Amazon Monitron と Amazon Lookout for Equipment が異常を検知するサービスとして示されています。Amazon Kendra は、多くの AWS サービスや保全システムを含む業界で標準的なデータソースとネイティブで接続でき、カスタムコネクタを介して他のデータソースにもアクセスできます。 産業機器および製造工程からのテレメトリーデータは、さまざまなセンサーを通して収集されます。産業ゲートウェイがこれらのセンサーからデータを収集し、クラウドに送信します。 製造業のお客様は、 Amazon SageMaker などの機械学習やアナリティクスサービスを使用して、このテレメトリーデータを処理・分析できます。 この分析の結果に基づいて、なんらかの異常やイベントが AWS Lambda 関数をトリガーします。 AWS Lambda 関数は、設備管理システムで保守作業依頼を作成します。Amazon Kendra は、情報源として設備管理システムを使用します。 コンテンツやアプリケーションリポジトリと生成AIを結合する Amazon Kendra により、診断マニュアルなどの既存の静的で頻繁に更新されない知識ストアを、設備監視システムや EAM などの企業アプリケーションからのトランザクションデータと組み合わせることができます。 Amazon Bedrock は、Amazon Kendra などのデータソースを利用して、ドメイン固有の情報を検索し、コンテキスト化、要約、インタラクティブな質問と回答のためにさまざまな基盤モデルに渡します。Amazon Bedrock は API 駆動型であり、チャットボットアプリケーションや内部システム (既存のメンテナンスシステムなど) に機能を埋め込むことができます。Amazon Bedrock では、修理技術者のチャットボットを企業全体で広範囲に展開する際に重要な要素となる、正確な回答を適切なコストで提供するモデルを選択できます。 Amazon Kendra は、この例では静的コンテンツとトランザクションアプリケーションの知識ソースの両方を参照します。 Amazon Bedrock は、ドメイン固有の検索に Amazon Kendra を使用し、コンテキスト化、要約、インタラクティブな質問への回答のために基盤モデルを実行します。 エンドユーザーが Amazon Bedrock と接続されたチャットボットを使用します。 終わりに 数千から数十へ、最終的には従業員が使用できる 1 つの簡潔な回答へと、生成 AI と検索拡張生成 (RAG) アーキテクチャには、製造業の従業員を大いに力づけ、閉じ込められた知識を解放する可能性があります。基盤モデルと独自のデータソースを組み合わせることで、学習チャットボットなどのソリューションは、従業員のドメイン固有の質問に対して、関連性が高く理解しやすい回答を迅速に提供できます。これにより、作業員が情報検索に費やす時間が大幅に短縮され、機器の診断や修理などのプロセスが加速されます。最終的には、これが現場での生産性と効率性の向上につながります。 本ブログで紹介したソリューションはあくまで一例ですが、生成 AI によって従業員が組織内の情報へのアクセス方法を変革する可能性を示しています。アーキテクチャをカスタマイズして組織独自のデータソースを活用することで、この技術はあらゆる企業のニーズに適用できます。生成 AI が進化し続ける中で、これを活用してスキルギャップを解消し労働者を支援する絶好の機会が製造業のお客様に訪れています。 本ブログはAWS Blog の “ Closing the manufacturing skills gap with generative AI ” をソリューションアーキテクトの山本が翻訳しました。 Danny Smith Danny Smith は、自動車・製造業界のプリンシパル ML ストラテジストであり、顧客の戦略アドバイザーを務めています。彼は、役員室から製造現場に至るまで、主要な意思決定者がデータ、テクノロジー、数学を活用してより良い意思決定を行えるよう支援することに注力してきました。最近は、デジタルトランスフォーメーションの推進、データ主導型への移行、人工知能と機械学習の民主化戦略に関する話題がほとんどでした。彼は産業サプライチェーンの分野でキャリアをスタートし、今もなおこの分野を好み、特に鉄道が好きです。Danny は、ジョージア工科大学で産業管理の学士号を、ジョージア州立大学で意思決定科学の修士号を取得しています。 Garry Galinsky Garry Galinsky は、アマゾンウェブサービスのソリューションアーキテクチャを担当しています。電気通信、ローカル検索、インターネット、金融業界で 20 年以上にわたって進歩的なハイテクの経験を積んできました。Garry はキャリアの中で、北米、ヨーロッパ、中東、アジアの中小企業、大企業の顧客向けに、インターネット、Web 2.0、ローカル＆ソーシャル検索、モバイルソリューションの設計、開発、提供、普及に成功してきました。 Ravi Soni Ravi Soni は、製造システム、デジタルトランスフォーメーション、AI/ML、IoT、インダストリー 4.0、AWS クラウドなどに関する豊富な技術スキルを持つ製造ソリューションスペシャリストです。ダッソー、Google X、NuvaSiveで勤務した経験を持つ Ravi は、産業機械、プロセス製造、CPG、医療機器、航空宇宙産業にまたがる幅広い専門知識を持っています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 最近暖かくなってきたと思ったら、最近はウォーキングで少し汗ばむぐらいになってきましたね。お昼のウォーキングも快適で、個人的には1年中これぐらいの気温だと良いのですが。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月8日週の主要なアップデート 4/8(月) Amazon OpenSearch Service now lets you update node count without blue/green Amazon OpenSearch Service で、専用のクラスター管理ノード（クラスターマネージャーノード）を持たないクラスターにおいて、Blue/Greenデプロイメント無しでデータノードの数を更新する機能が拡張されました（専用のクラスター管理ノードがある環境では以前より可能でした）。これにより、Blue/Greenデプロイメント実行中の一時的なノード数の増加をが不要になり、迅速にノード数変更が可能になりました。 Amazon CloudWatch RUM is generally available in 11 additional AWS Regions Amazon CloudWatch RUM を利用可能なリージョンが追加され、新たに大阪を含む11のリージョンで使えるようになりました。CloudWatch RUMはクライアント側からのリアルユーザーモニタリング (RUM)を支援するサービスです。追加されたリージョンは以下の通りです。Africa (Cape Town), Asia Pacific (Jakarta), Asia Pacific (Mumbai), Asia Pacific (Osaka), Asia Pacific (Seoul), Canada (Central), Europe (Milan), Europe (Paris), Middle East (Bahrain), South America (Sao Paulo), US West (N. California) 4/9(火) Amazon Route 53 adds support for 18 additional Top-Level Domains Amazon Route 53 は権威DNSサーバーの機能だけでなく、ドメインのレジストレーションサービスも提供しています。今回新たに18のトップレベルドメイン(TLD)が追加され、合計351のTLDが利用可能になりました。追加されたTLDは以下の通りです。.beer, .bid, .bio, .christmas, .contact, .design, .fan, .fun, .law, .llc, .ltd, .pw, .shopping, .ski, .software, .stream, .vote, .work Amazon RDS for MySQL supports rds_superuser_role for easier implementation of role based privileges Amazon RDS for MySQL v8.0.36 以降で rds_superuser_role というロールが追加されました。v8.0.36 以降で管理者ユーザーが直接DB内の表への変更を行うことが非推奨になり、新しいロールベース権限モデルに移行したのですが、これを支援するためのロールです。このロールは、DB内の表を操作する多くの権限を持っており、デフォルトの管理者に付与される形でこれまでとの互換性を維持しています。詳細は こちらのドキュメント をご覧ください。 Knowledge Bases for Amazon Bedrock now supports Claude 3 Haiku Amazon Bedrock の Knowledge Bases は、基盤モデル（FM）を社内のデータソースに安全に接続して検索拡張生成（RAG）を行い、より適切で正確な回答を提供することを支援する仕組みです。今回の改善で Anthropic の Claude 3 Haiku 基盤モデルをサポートしました（Claude 3 Sonnet はすでにサポート済です）。 AWS AppSync forwards application request headers to AWS Lambda custom authorizer functions AWS AppSync はサーバーレスで高性能な GraphQL サービスです。今回の改善で GraphQL リクエストを承認する際に、アプリケーションリクエストヘッダーを AWS Lambda カスタムオーソライザー関数に渡すことができるようになりました。カスタムオーソライザーでは認証ヘッダーの値に基づいて認証を実行できるようになります。 4/10(水) AWS Clean Rooms Differential Privacy is now generally available AWS Clean Rooms Differential Privacy (差分プライバシー) が一般提供開始（GA）になりました。Differential Privacyは、共有されたデータを分析する際に、統計的な影響を生まない範囲でのノイズ（エラー）を追加することでより匿名性を高めたり、プライバシーバジェット（予算）という仕組みの導入で、クエリの量のコントロールを実現する機能です。詳細はこちらの プレビュー時のブログ をご覧ください。 4/11(木) Amazon CloudWatch Container Insights announces observability for Windows containers on Amazon EKS Amazon CloudWatch Container Insights で、Amazon Elastic Kubernetes Service (EKS) で稼働する Windows コンテナに対応しました。CloudWatch Container Insights はコンテナ化されたアプリケーションやマイクロサービスからメトリクスとログを収集、集計、要約するオブザーバビリティのサービスです。 Introducing workflow monitor for AWS Media Services AWS Elemental MediaConnect, Elemental MediaLive, Elemental Media Packageといった、AWSのメディアサービスのワークフローを管理するためのworkflowmonitor for live videoが利用可能になりました。Elemental MediaLive console から利用可能です。 詳細はこちらのブログをご覧くださ い。 Amazon Braket adds experimental capabilities for QuEra device via Braket Direct フルマネージド量子コンピューティングサービスである Amazon Braket の Braket Direct で、QuEra の Aquila がサポートされました。 Braket Direct はリソースの予約といった機能に加えて、実験的な機能も利用可能にするものです。詳細は こちらのドキュメント をご覧ください。 Amazon CloudFront now supports Origin Access Control (OAC) for Lambda function URL origins Amazon CloudFront が Lambda Function URL をオリジンとする際にOrigin Access Control (OAC)でのアクセスを可能にしました。これによりLambda Functionを公開する際に、LambdaへのアクセスはCloudFrontからのリクエストに限るという設定が容易に可能になります。 4/12(金) AWS Step Functions Announces Optimized Integration for AWS Elemental MediaConvert AWS Step Functions で AWS Elemental MediaConvert との連携がより容易に行えるようになりました。例えば、MediaConvert CreateJob API 用の Run a Job (.sync) という統合パターンを利用すると、非同期の MediaConvert トランスコーディングジョブが完了するのを待ってから次のステップに進むといったワークフローを記載することが可能になるなど、より複雑なメディア処理のパイプラインが構築可能になります。 AWS KMS announces more flexible automatic key rotation AWS Key Management Service (AWS KMS) で、自動キーローテーションについて複数のアナウンスがありました。ローテーション期間の頻度が 90 日から 最大 7年 (2560 日) まで延ばすことが可能になり、過去のすべてのローテーションの履歴を確認できるようになりました。また、 価格についても変更があり、キーローテーションの最初の2回は1ドル/月の費用がかかりますが、3回目以降にはローテーションの費用がかからなくなりました。この変更は2024年5月の支払いサイクルから適用されます。詳細は こちらのホームぺージ をご覧ください。 それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

このブログは 2024 年 4 月 11 日に Kenneth Hui (シニアソリューションアーキテクト) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ランサムウェアの脅威により、データ保護はすべての企業にとって最優先事項となっています。 Sophos 社の「State of Ransomware Report 2023」 によると、2022 年には 66 % の組織が被害を受け、ランサムウェアによる支払い額の中央値は 40 万ドル (平均支払い額は 154 万ドル) でした。バックアップを使用した場合の復旧コストの中央値は身代金支払いの半分 (75 万ドルに対して 37 万ドル) であるため、信頼性の高いバックアップを用意することは贅沢ではなく、組織にとって不可欠です。 同時に、組織はクラウドデータ保護のコストなどのクラウドコストの最適化を検討しています。 Flexera 社の「2023 State of the Cloud Report」 によると、クラウドを利用しているすべての組織の 82% が、クラウド支出の管理を最優先事項としています。AWS ユーザーからは、包括的な多層防御戦略と費用対効果の高いデータ保護戦略とのバランスを取る必要があるというフィードバックが一貫して提供されています。 AWS Backup は、ハイブリッドリソースの大規模なデータ保護を簡素化する、費用対効果の高いフルマネージド型のポリシーベースのサービスをユーザーに提供するネイティブクラウドソリューションです。13 万人の AWS Backup のお客様 (2023 年 9 月現在) がデータ保護の支出を最適化できるように、何千人ものユーザーとの作業から集めた AWS Backup のコスト最適化のベストプラクティスを概説する一連の記事を公開しています。この記事では、コスト最適化の定義、コストを最適化するための AWS Backup の構築方法、およびバックアップコストを最適化する際に考慮すべき原則について概説します。 コスト最適化とは何ですか？ コスト最適化とは「賢く」支出することであり、必ずしも支出を減らすことではありません。ガートナー社は、 コスト最適化 を「ビジネス価値を最大化しながら、支出とコスト削減を促進するためのビジネスに焦点を当てた継続的な規律」と定義しています。同様に、AWS はコスト最適化を「システムを運用してビジネス価値を最も低いコストで提供する能力」と定義しています。AWS Backup などのマネージドクラウドサービスは、コストの削減、イノベーションとモダナイゼーションの促進、運用効率とビジネスの成長の促進、ビジネスリスクの軽減により、IT インフラストラクチャからより多くの価値を引き出すのに役立ちます。 AWS Backup がデータ保護コストを最適化する方法 AWS Backup は、データを保護しながら経済的および運用上のメリットを得るのに役立つ主な方法が 3 つあります。 AWS Backup は、バックアップと復旧のインフラストラクチャ全体の支出を削減するのに役立ちます。 バックアップサーバーやストレージをプロビジョニングして管理する必要はありません。リソースの増大に合わせて容量を手動でスケールアップする必要はありません。AWS Backup を使用しても、年間のソフトウェアライセンスコストはかかりません。資本的支出や運用上のオーバーヘッドなしで、AWS Backup にすぐにアクセスでき、使用した分だけ支払います。 AWS Backup はバックアップ操作を簡素化するので、バックアップ操作に費やす時間とサイクルを減らし、代わりにイノベーションとモダナイゼーションに焦点を当てることができます。 AWS Backup を使用すると、サポートされた AWS サービスを一元的に保護できます。ネイティブの AWS サービスのバックアップを管理するために、購入または構築した複数のソリューションを管理する必要はありません。AWS Backup はマネージドサービスであるため、リソースのプロビジョニングやソフトウェアのパッチ適用、キャパシティプランニングなど、区別できないタスクに時間とサイクルを費やす必要がなくなります。 AWS Backup は、組織全体のバックアップコストを監視および最適化するための管理ツールを提供しています。 コスト配分タグなどのツールを使用して、バックアップのコストを追跡できます。AWS Backup ポリシーエンジンを使用すると、バックアップデータの保持とサポートされたサービスのライフサイクルを制御して、必要な時に以降データが保持されないようにすることができます。 AWS Organizations と統合することで、これらのポリシーを複数の AWS アカウントに一元的に適用できます。 考慮すべきコスト最適化の原則 バックアップコストを最適化するための万能のソリューションはありません。代わりに、総合的なアプローチを取り、ビジネス目標を達成しながら効率的に支出する方法を検討する必要があります。以下のテーマについて詳しく説明します。 1. 現在のクラウドのバックアップコストを評価して理解する バックアップコストの計算には、ストレージの料金を知るだけでは不十分です。インフラストラクチャやソフトウェア、運用コストを含め、現在のソリューションにいくら支払っているか知っていれば、コストをより適切に比較して最適化できます。 総保有コスト (TCO) を理解します。 バックアップストレージのコストだけでなく、現在のバックアップソリューションの TCO も考慮することをお勧めします。TCO を評価するためには、ソフトウェアライセンス、コンピューティング、運用などの追加コストを考慮する必要があります。 支出を追跡します。 実際の支出を理解していなければ、コストを最適化することはできません。AWS Backup は、バックアップコストの追跡と最適化に役立つツールを提供しています。コスト配分タグを使用してバックアップのコストを追跡できます。 AWS Cost Explorer を使用してタグ付けされたリソースをフィルタリングすると、部門やプロジェクトなどのさまざまな基準でバックアップコストを表示できます。 2. コストの計算方法を理解する バックアップコストはサポートされたリソースによって異なり、 AWS Backup の料金ページ に記載されています。各リソースのコストモデルを理解し、それらのポリシーに基づいてバックアップポリシーを設定することで、コストを最適化できます。 永久増分バックアップのコストへの影響を理解します。 従来のバックアップソリューションでは、増分バックアップに加えて、定期的なフルバックアップも必要とする方式が使用されていました。AWS のバックアップは、フルスナップショットを 1 つだけ作成することを必要とする永久増分スナップショットに基づいています。例えば、100 GB の Amazon Elastic Block Store (Amazon EBS) ボリュームで、日次の変更率が 2 % の場合、30 日間の保持期間で 1 か月間の日次バックアップを行うと、最大 160 GB のスナップショットデータが蓄積されます。週次のフルバックアップを行う従来の方法では、同じボリュームに最大 600 GB のスナップショットデータが蓄積されます。 さまざまなリソースのバックアップ料金を理解します。 AWS Backup は、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Simple Storage Service (Amazon S3) 、VMware vSphere、 SAP HANA on Amazon EC2 など 20 のリソース・AWS サービスのバックアップ管理をサポートしています。サービスによってコストモデルは異なる場合があり、それらのコストモデルを理解しすることは、コストを予測および制御するのに役立ちます。例えば、Amazon RDS では AWS Backup を通じて継続的なバックアップを提供しています。これらのバックアップは最大 35 日間保存でき、その保持期間中に作成されたバックアップは無料で提供されます。 3. バックアップストレージにライフサイクル管理を使用する バックアッププランのバックアップ頻度やライフサイクル、リソース選択の粒度を制御できます。何をどのくらいの期間保護するかを選択できます。これらの設定はいつでも変更できます。 バックアップ頻度を制御します。 バックアップのコストは、データをバックアップする頻度に直接関係します。ワークロードごとの目標復旧時間と目標復旧時点に基づいて、ワークロードを分類し、バックアップ頻度を設定することをお勧めします。 保持ポリシーを決定します。 同様に、保持要件に従ってワークロードを分類することをお勧めします。例えば、日次バックアップは 1 か月だけ保持し、月次バックアップは 1 年間保持する要件がある場合があります。コストを制御するために、バックアップデータを必要以上に長く保持したくない場合があります。 長期間の保持のためにコールドストレージにバックアップを階層化します。 AWS Backup によって保護されている一部のリソースは、コールドストレージへの階層化をサポートしています。保持要件に従ってワークロードを分類し、必要に応じてコールドストレージに階層化することをお勧めします。 まとめ データが貴重で攻撃を受けている今、AWS Backup などのソリューションを使用してデータを保護することは不可欠です。しかし、その要件とコストの最適化の必要性とのバランスが取られる必要があります。AWS Backup には、最も低い料金でビジネス価値をもたらすシステムを運用できるだけでなく、バックアップの管理に役立つツールとベストプラクティスが用意されています。2024 年中に AWS Backup のコスト最適化に関する記事が他にもありますので、ぜひご覧ください。一方、AWS Backup の詳細については、 製品ページ をご覧ください。また、この Amazon ストレージブログの記事 を読んで、AWS Backup でコスト配分タグを使用する方法を学んでください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。 Kenneth Hui Kenneth Hui は AWS 州政府と地方自治体チームのシニアソリューションアーキテクトです。エンタープライズテクノロジー分野で 20 年以上の経験があり、複数の移行プロジェクトを主導したり、参加したりしてきました。ケンはニューヨーク市に住んでおり、さまざまなレストランで食事をしたり、さまざまな料理を試したりすることを楽しんでいます。