株式会社リクルートは、日本国内のHR・販促事業及びグローバル斡旋・販促事業をおこなう事業会社です。リクルートでは、『スタディサプリ』というスマートフォンアプリ、パソコンで利用可能なオンライン学習サービスのデータベースとして Amazon Aurora PostgreSQL を採用しています。 2023 年 5 月にこの Aurora PostgreSQL を Aurora Serverless v2 に変更しました。採用検討から 1.5 ヶ月と短期間で導入を決定しましたが、入念な検証の結果 Aurora の運用負荷を大幅に削減し、サービスの安定運用も実現しています。本ブログは、『スタディサプリ』の Aurora PostgreSQL を Aurora Serverless v2 に変更した時の検討から移行後の効果や課題についてご紹介します。 アーキテクチャ 以下は、Aurora Serverless v2 採用前のアーキテクチャです。データベースとしては、Aurora PostgreSQL をご利用されています。システムは下記右側の図に示すようなマイクロサービスアーキテクチャ (2023/03 時点) で構成されており、本番・開発環境含めて 26 の Aurora クラスタを利用しておられました。また、各クラスタは冗長化のためマルチ AZ 構成を採用していました。 Aurora Serverless v2 採用前の課題 『スタディサプリ』では、中学・高校の授業が始まる前の朝 8 時ごろにアクセスが集中する傾向にありました。このアクセス増による負荷は、この時間帯のみの一時的なものであり、その他の時間帯はこの時間帯と比較して約 1/3 程度とリソースとして余裕がある状況でした。そして、この負荷の高い時間帯を基準としながら、受験シーズンなど季節的な要因や今後のユーザー数の増加、機能追加などによる処理量を考慮してデータベースをサイジングする必要があったため、インスタンスサイズを大きめにサイジングする必要があり、これが結果的にコスト増になっていました。そしてさらに、コロナ禍によるユーザー数の増加でデータベースへの処理量も増加しました。これによるサービスへの影響なども懸念されたため、アクセスが集中する 8 時台の状況を注視する状況が続いていました。 この状況を改善するため、Aurora に Reader インスタンスを追加して負荷を分散させる案も検討されましたが、アプリケーションの特性として Write 処理が支配的であった為、Reader インスタンスの追加や Auto Scaling などでは負荷分散が限定的になってしまうことがわかりました。 Aurora Serverless v2 の導入 このような状況から、 Aurora Serverless v2 の検討が進められました。Aurora Serverless v2 は負荷に応じてシームレスにスケールアップ・ダウンすることができる Aurora の機能の一つです。Aurora Serverless v2 は Writer インスタンスにも適用できるため、今回の『スタディサプリ』というアプリケーションの特性に合った機能でした。 Aurora Serverless v2 採用に向けた検討のポイントとしては大きく 3 つありました。 1 つ目はコスト、 2 つ目は性能影響、 3 つ目は移行性です。 コスト 検討ポイントの 1 つ目はコストです。今回のように特定の時間帯だけ負荷が増大するようなケースだと、通常の Provisioned インスタンスの場合ではピークに合わせたサイジングが必要となり、ピーク時間帯以外は過剰なインスタンスサイズとなってしまいます。また、ピークは最も処理量が多いケースでもリソースが不足しないようサイジングするため、実際にピークで使用されるリソース以上のインスタンスサイズが必要となります。さらに、障害を考慮してマルチ AZ 配置 を採用する場合、 Reader インスタンスも Writer インスタンスと同じインスタンスサイズで構成する必要があります。一方、Aurora Serverless v2 の場合、アプリケーションのワークロードに合わせてインスタンスのリソースが動的に変更されます。この為、今回のような特定の時間帯だけリソースを使うようなワークロードの場合、Aurora Serverless v2 だと特定の時間帯だけリソースを大きくしてその他の時間帯は小さくするといった運用を実現し、リソースを有効に使用できます。また、今回のケースのように障害時に備えて Reader インスタンスを構成している場合、Aurora Serverless v2 の Reader インスタンスの昇格階層を 2 〜 15 に設定することで指定された Aurora Capacity Unit(ACU) の最小値までスケールダウンして運用することができます。これにより、 Reader インスタンスのコストを大幅に削減することが可能になり、結果的に Provisioned の時と比較してほぼ同程度のコストで運用可能であると確認することができました。 性能影響 2 つ目が性能影響です。リクルート様では、本番の負荷が発生した際のレイテンシーやスループット、スケーリングについて Provisioned インスタンスと Aurora Serverless v2 で比較検証されました。検証の結果、レイテンシーについては、 Provisioned インスタンスとほぼ同程度の結果となり、問題ないことを確認することができました。スケーリングについては、スケーリング時の性能影響は問題ありませんでしたが、 MinACU が小さい状態で急激に処理量が増加したときにフェイルオーバーが発生することがありました。 ACU とは Aurora Capacity Unit の略で Aurora Serverless v2 のキャパシティの単位であり、ワークロードのトラフィックに応じてインスタンスの ACU が増減します。 MinACU は負荷がおさまってスケールインする際の ACU の最小値を意味します。今回の場合、 2 分の間に 10 倍の負荷が増加するワークロードを想定してテストしていましたが、 MinACU を小さく設定しすぎていたため、スケールアップ処理が完了する前に耐え切れないほど IO が増加してしまい、結果としてフェイルオーバーを引き起こしていることがわかりました。この為、このような処理量の増加を想定して MinACU もある程度大きく設定することで、フェイルオーバーの問題も回避することができました。以上の結果、Aurora Serverless v2 移行による性能面への影響は許容可能であるということを確認することができました。 移行性 3 つ目が移行性です。インスタンスを Provisioned インスタンスから Aurora Serverless v2 に変更する場合、Aurora Serverless v2 の Reader インスタンスを追加してフェイルオーバーするだけで、Provisioned インスタンスから Aurora Serverless v2 に簡単に切り替えることができます。この為、万が一、本番で Aurora Serverless v2 を起因した問題が発生した場合、再度フェイルオーバーすることで元の Provisioned インスタンスに切り戻すことが簡単にできます。また、アプリケーションとしても、Design for Failure にもとづき DB のフェイルオーバーがビジネス的に問題にならないよう障害を考慮した設計されていました。このように、Aurora Serverless v2 への切り替えや Provisioned への切り戻しが容易であるということで、本番トラブル時の切り戻しを考慮する必要がなくなり、本番導入への心理的な負担も抑えることができたことは短期間で採用することができた要因でした。 本番への導入 以上、 3 つのポイントについて検討、検証した結果、Aurora Serverless v2 の本番導入が決定されました。Aurora Serverless v2 の検討開始から本番への導入は、 1.5 ヶ月という短期間で実施することができました。導入は、 26 クラスタの中から数クラスタに対して変更を実施して問題がないことを確認した後で、その他のクラスタへの適用を進めました。Aurora Serverless v2 を採用してから 2024 年 3 月現在まで、導入後約 1 年近くが経過しましたが、導入当初は細かい事象が発生していたものの、現在は安定して運用することができています。 Aurora Serverless v2 導入効果と課題 今回、Aurora Serverless v2 を導入したことで気づいた点も何点かありました。導入して得られた効果については大きく 3 つでした。 想定外の負荷でも対処不要に Provisioned インスタンスの時は、負荷を考慮したインスタンスサイズが割り当てられていましたが、それでも想定外に負荷が増加した場合はデータベースサーバーのリソースが不足する可能性があり、パフォーマンスへの影響調査や障害対応などの作業が発生していました。Aurora Serverless v2 に変更したことで、想定外の負荷でも動的にスケールアップ/ダウンされるため、負荷が増加した時のリソース不足の懸念がなく、 8 時台の状況を注視するような運用負荷を削減することができています。 Provisioned インスタンスの時と同程度のパフォーマンス 検証ではパフォーマンスについて確認していたものの、本番導入後のパフォーマンスについては心配もありましたが、Aurora Serverless v2 に変更したことによる大きな問題はありませんでした。 Aurora Serverless v2 でのコスト削減 Aurora Serverless v2 のコストは一般的に Provisioned インスタンスと比較して高くなることもありますが、『スタディサプリ』ではピーク時のインスタンスサイズを常時確保する必要がなくなったことと、Reader インスタンスのサイズを抑えられることができたため、結果として僅かですが Provisioned インスタンスの時よりコストを削減することができています。 Aurora Serverless v2 導入後の課題や気づき 一方、 Aurora Serverless v2 導入による課題や気づきもありました。 MinACU が小さいことによるフェイルオーバー MinACU が小さいことでフェイルオーバーする事象が発生しました。MinACU が小さいと Aurora の CPU やメモリなどのリソースも小さい状態になるため、ディスク I/O が上昇してスケーリングが間に合わずにエラーになることがありました。Aurora のフェイルオーバーの時間は数十秒であり、アプリケーションとしても、エラー後に再接続するような処理になっていたため、ユーザーへの影響は極小化することができていましたが、再発防止のため、 MinACU を大きくしてリソースが小さくなりすぎないよう制御することで問題を解消することができています。また、Performance Insights を使用している場合、Reader インスタンスの MinACU の最小値は 2 ( 参考ドキュメント ) である為、Reader インスタンス側の MinACU の値も変更されました。 Aurora Serverless v2 のコスト 今回のシステムの多くの Aurora クラスタでは、ワークロードの特性から Provisioned インスタンスと同程度で運用することができていますが、その他一部の Aurora クラスタでは Aurora Serverless v2 の方がコストが高いケースがあるため、特性を見定めて Aurora Serverless v2 を採用している状況です。Aurora Serverless v2 の料金がもう少し下がると他システムでの採用もしやすくなると考えています。 まとめ 今回のブログでは、Aurora Serverless v2 の導入により、短期間で Aurora の運用課題を改善した事例をご紹介しました。リクルートでは、今回の Aurora Serverless v2 導入のように、新しい機能やサービスも採用しています。 AWS の SA や Sales と連携し、新しい技術採用に関しても相談しながらシステム開発を進めることができている点も、今回のように Aurora Serverless v2 を短期間で導入することができた要因の一つと言えそうです。 今後も、リクルートでは AWS の新しい機能やサービスを利用しながら、システムの安定化やコスト最適化、サービス向上などを実現していく予定です。

世界のパブリック・クラウド市場は、今後数年間で大幅な成長が見込まれており、「エンドユーザーの支出額は2024 年に6790 億ドルに達すると予測されています[ 1 ]」。この急成長は、企業による既存ワークロードの継続的な移行、新しいクラウドネイティブアプリケーションの開発、そして生成AI のような革新的なユースケースの出現によって促進されています。 AWS のクラウドエコノミクスチームは、コスト削減、スタッフの生産性、オペレーショナルレジリエンス、ビジネスの俊敏性、サステナビリティなど、さまざまな柱にわたってクラウド・コンピューティングのビジネス価値を訴求するクラウドバリューフレームワーク（CVF）を開発しました。私たちは、組織と密接に協力し、変革の道のりに寄り添いながら、CVF の柱に沿って成果を定量化することで、5 年間の包括的な総所有コスト（TCO）予測を提供しています。しかし、ビジネス状況の変化に応じて進捗状況を追跡し、ROI (Return on Investment, 投資対効果)の進捗状況を追跡し確実にすることは、極めて大事なことです。 そこで重要な役割を果たすのが、主要業績評価指標（key performance indicators, KPIs）です。KPI は、インプットに基づく標準化された手法を提供し、テクノロジーとビジネスの側面から組織のクラウド成熟度を評価します。このブログでは、テクノロジー分野のKPI について詳しく説明し、後続にリリースするブログではビジネス分野のKPI について説明していきます。 KPI を理解する KPI は、特定の目標や目的に対する組織のパフォーマンスを評価するための貴重なツールです。ユニットメトリクス（訳注：単位あたりの経済性や採算性）は、特定の活動をきめ細かく測定し、コスト削減イニシアチブの影響を測定するのに有用なのに対し、KPI は、包括的な視点を提供し、組織が戦略的優先事項に集中することを可能にし、全体的な影響についてより広い視野を提供することができます。その重要性と複数の利害関係者からのインプットが必要であることを考えると、KPI の導入は非常に困難を伴います。とはいえその重要性は、そこに必要な労力を正当化するのに十分だといえるでしょう。これらの指標を活用することで、組織は、継続的な改善や是正措置の必要性について、十分な情報に基づいた意思決定を行い、戦略を軌道に乗せることができます。 適切なKPI を選択する 適切なKPI を選択するには、慎重な検討が必要です。以下にいくつかのガイドラインを示します。 簡潔にする： ステークホルダーを圧倒しないよう、KPI は5 つ以内にする。 SMART 基準を使用する： KPI は目標設定のフレームワークであるSMART（具体的（Specific）、測定可能（Measurable）、達成可能（Attainable）、経営目標に関連した（Relevant）、時間制約がある（Time-Bound))を基準にする。 実行可能なものにする： 特定のアクションの影響を測定するために、インプットパラメータとアウトプットとの相関関係に焦点を当てる。 どのKPI を追跡するかを決定する際には、社内の調整、データ収集の合理化、ガバナンスの確立に重点を置くべきです。KPI は、関連する経営幹部や利害関係者によってレビューされるべきであり、データ収集は標準化されるべきであり、報告と是正措置のプロセスが確率されるべきです。また、選択した KPI が時間の経過とともに有効であるかどうかを評価する、継続的な回顧的メ カニズムを検討することも重要となります。 ビジネス価値の柱ごとにみるKPI の例 ビジネス価値を測定するためのKPI の選定は、顧客満足度、業務効率、収益成長などへの影響を直接測定する分野に焦点を当てるべきです。万能のアプローチは存在しませんが、事例をとおしていくつかの共通テーマが見いだせてきています。以下は、ビジネス価値の柱ごとにみるKPI の例になります。 コスト削減 コスト削減のトレンド分析 では、クラウドのコスト増がオンプレミスのコスト減よりも低い割合で増加しており、クラウドのコストが正しい方向にトレンドしているかどうかを測定する。 クラウド効率 とは、クラウド費用を売上高で割ったものである。これは、クラウド費用のコスト効率と、時間経過による収益の変化を測定し比較するものである。 インフラの平均利用率 は、AWS のコンピュート、データベース、データウェアハウスのサービスがどれだけ効率的に利用されているかを測定する。組織の成熟度が高まるにつれて、リソースの利用率は上昇傾向になる。 生成AIのトレーニングやファインチューニングのコスト は、企業がROI を計算するための基本的な部分として、計算リソース、データ取得、人間のアノテーション作業など、生成AIに関連するコストを測定することを可能にする。 スタッフの生産性 新しいアカウントとインフラストラクチャコンポーネントの展開にかかるリードタイム は、組織の財務、セキュリティ、およびアーキテクチャのガイドラインを満たす一般的なインフラストラクチャコンポーネントで新しいアカウントをプロビジョニングする時間を測定する。さらに、コンピュート、データベース、ストレージなどの導入時間を測定することもできる。 管理者一人あたりが管理する仮想マシンの数 は、管理者の責任範囲の縮小による運用効率の向上を測定する。この KPI を成功させるためには、企業は組織変更管理のための追加的な対策を実施する必要がある。 欠陥密度（コード単位当たりの欠陥数を測定） は、コード単位当たりに発見された欠陥の数を測定する。コード単位とは、特定の関数やコード行などを指す。 生成AIによるコスト回避 は、チャットサポート、要約、一般的なコンテンツ生成、反復的なソフトウェアコードや単体テストなど、以前は手作業や従来の方法によって行われていたタスクやプロセスを自動化することによって達成されるコスト削減を測定する。 オペレーショナルレジリエンス ダウンタイムの総量（またはインシデントごとの平均ダウンタイム） は、インシデントごとの計画外ダウンタイムまたは計画外ダウンタイムの総量を測定する。自動化された検知・監視メカニズムを採用することで、インシデント発生後の対応の迅速性を測定することができる。 設定ミスに起因するセキュリティインシデントの件数 は、リソースの設定ミスやセキュリティ態勢の脆弱性に起因するセキュリティインシデントの件数を測定する。 平均解決時間 は、組織がクラウドネイティブメカニズムを使用してより迅速な復旧・対応時間を開発するにつれて、平均修復時間が短縮されるかどうかを測定する。 平均検出・対応時間 は、プロアクティブな通知・対応メカニズムによってインシデント対応時間が短縮されるかどうかを測定する。 SLA 違反ペナルティ （顧客との契約や規制上の義務の一部として SLA が定義されている組織の場合）は、SLA 違反ペナルティの合計を顧客総数で割った値が、さまざまなセキュリティと回復力のメカニズムによって時間の経過とともに減少するかどうかを測定する。 ビジネスの俊敏性 リリースの頻度と、リリースごとの新しい更新/機能の平均数 は、特定の期間における新しいリリースの数と、リリースごとに導入された新機能の数を測定する。 リリースごとのコードレビューの回数と、コードレビューごとに費やされる平均時間 は、リリースごとの手作業によるコードレビューの削減と、コードレビュー会議ごとのスタッフの効率改善を測定する。 マイクロサービスアーキテクチャを使用するアプリケーションの数 は、相互依存性を排除するためにモノリシックアーキテクチャからマイクロサービスアーキテクチャに移行するアプリケーションの数を測定する。 生成AIを使用したイノベーション率 は、ビジネスチャンスや競争上の優位性につながる、生成AIによって生み出された新しいアイデア、コンセプト、ソリューションの数を追跡する。 サステナビリティ グリーンコンピューティングイニシアチブ は、オンプレミスのIT オペレーションの削減、再生可能エネルギーの使用とクラウドのインフラ効率の組み合わせ、およびマネージドサービスの使用によって節約できるカーボンフットプリントの削減を測定する。 廃棄物削減の指標 は、オンプレミスのインフラストラクチャの廃棄物のうち、リサイクルされたものの割合や、埋立による処分ではなく環境に優しい方法で処分されたものの割合を測定する。 ガバナンスと結論 KPI のガバナンスには、経営陣との連携、一貫したデータ収集プロセス、ネガティブな傾向が発生した場合の是正措置が求められます。トレンド分析と定期的な改善に注力することで、組織はクラウド導入のペースを正確に把握し、効率を最適化し、利害関係者に具体的なメリットを強調することができます。 クラウド移行のビジネス価値を測るために適切なKPI を選択するには、熟慮することが必要です。インフラのフットプリントを最適化し、クラウドでコスト削減を実現することは必須ですが、クラウド移行の進捗状況や、社内関係者や社外顧客への影響を追跡することも、競争力を高めることにつながります。業種を問わず、5 つの価値の柱を中心に共通のKPI があると考えられます。一方で、各組織独自の状況や優先事項を加味することによって、組織ごとの最適なKPI が導出されます。成功のためには、利害関係者と連携し、一貫したデータ収集を体系化することが不可欠です。 状況が変化するにつれて、既存のKPI を定期的に再評価し、改良する必要があります。トレンド分析は、単独のデータポイントで判断するよりも有意義な洞察をもたらします。最終的に、適切なKPI は、その組織のデジタルトランスフォーメーションが戦略的目標のために進んでいるかどうか、また長期にわたって差別化されたビジネス価値をもたらすかどうかを示します。 KPI は、デジタルトランスフォーメーションの健全性をユニークに測定し、成功の積み重ねを可能にします。 [ 1 ] Gartner® Press Release, Gartner Forecasts Worldwide Public Cloud End-User Spending to Reach $679 Billion in 2024, November 13, 2023, https://www.gartner.com/en/newsroom/press-releases/11-13-2023-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-reach-679-billion-in-20240.GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. 著者について Chris Hennesey hris Hennesey はAWS のエンタープライズファイナンスストラテジストです。エンタープライズファイナンスストラテジストとして、世界中の企業幹部と連携し、クラウドを活用することでスピードと俊敏性を向上させ、顧客により多くのリソースを割けるようにするための財務管理経験や戦略を共有している。AWS 入社以前は、Capital One で複数のシニア・テクノロジー・ファイナンスを担当。ファイナンスの理学士号と経営学の修士号を取得している。 Bhavin Desai Bhavin Desai はAWS のプライベート・エクイティ・チームのバリュークリエイションストラテジストです。プライベート・エクイティ企業やその投資先企業と協働し、プリスクリプティブアプローチを用いてクラウドの価値を理解、創造、測定することを支援している。AWS 入社以前は、クラウド・センター・オブ・エクセレンス（CCoE）の構築を主導し、ナスダックの長期クラウド戦略策定チームの中核を担った。過去15 年にわたり、さまざまなデジタルトランスフォーメーションや買収統合イニシアチブでチームを率いてきた。ペンシルベニア州立大学で電気工学の学士号を、リーハイ大学でMBA を取得。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

2017 年のローンチ以降、 VMware Cloud on AWS を利用することで Amazon Web Services (AWS) のお客様はネイティブの VMware 仮想マシン (VM) を AWS グローバルインフラストラクチャ上で稼働させることができるようになりました。 VMware Cloud on AWS をすでに運用している、または利用する予定がある場合、セキュリティ上の特別な考慮事項があるかどうかを気にされるかもしれません。この記事では、 AWS クラウド導入フレームワーク （AWS CAF） を VMware Cloud on AWS に適用する方法について説明し、セキュリティとコンプライアンスの要件を満たすために各目的をレビューし、関連する機能を適用するのに役立ちます。 VMware Cloud on AWS は、現在オンプレミスで使用されているのと同じ VMware ソフトウェアをクラウドで提供します。これにより、ワークロードを迅速に AWS にリフト＆シフトできますが、セキュリティ、コンプライアンス、およびガバナンスに対する新しい視点も提示されます。VMware Cloud on AWS を使用してリフト＆シフトを行うお客様には、このフレームワークを新たなインフラストラクチャに適用するための手助けが必要です。 AWS CAF は、その機能をビジネス、人、ガバナンス、プラットフォーム、セキュリティ、オペレーションの 6 つの視点でグループ化しています。それぞれは、クラウドジャーニーにおいて、機能的に関連するステークホルダーが所有または管理する一連の機能で構成されています。 CAF のセキュリティの観点では、AWS ワークロードのセキュリティ機能を構築し、ベストプラクティスを採用する際のガイドとして使用されます。以下に示すこれらの機能を使用して、クラウドセキュリティ、コンプライアンス、ガバナンスを評価し、クラウドワークロードの機密性、完全性、可用性の実現を支援することができます。 VMware Cloud on AWS では、VMware と AWS の両方のセキュリティとコンプライアンスのスコープを適用するため、より注意が必要となります。 図 1: AWS CAF のセキュリティの観点の機能 お客様の観点 AWS におけるデプロイメントに関して、 セキュリティのベストプラクティス やパターンについてのリソースは多数存在しますが、VMware Cloud on AWS では考慮すべき新たな側面があります。例えば、 Amazon GuardDuty や Amazon Inspector （エージェントレス） などのサービスとは統合されていません。 VMware Cloud on AWS は、VMware が管理する仮想プライベートクラウド （VPC） 上で VMware によって運用される マネージドサービス であるため、監視と構成管理にはクラウドとオンプレミスのハイブリッドアプローチを適用することになります。また、マネージド VPC の監視やベースとなるサービスコンポーネントのセキュリティ保護など、セキュリティとコンプライアンスの一部は VMware の責任範囲 となります。 AWS に移行する場合、VMware Cloud on AWS ではオンプレミスのデータセンターと同じ VMware のツールとプロセスを維持することができるため、速度の向上とリスクの軽減が可能になります。規制の厳しい業界では、セキュリティとコンプライアンスが極めて重要であり、新たな考慮が必要な基盤技術を追加導入することで移行時間が長くなる可能性があります。 VMware Cloud on AWS は、AWS のネイティブサービスと統合されています。セキュリティとコンプライアンスの環境には、Amazon Inspector、 AWS Config 、 Amazon EventBridge 、または AWS Security Hub に調査結果を集約できる多数のサービスが含まれる可能性があります。通常、セキュリティとガバナンスのためのソリューションはすでにオンプレミスにありますが、これらを AWS Security Hub と統合するか、2 つの異なるシステムを運用する必要があります。 CAF のセキュリティの観点の VMware Cloud on AWS への適用 AWS CAF の セキュリティの観点 は、9 つの機能で構成されています。ここでは、AWS ネイティブワークロード、VMware Cloud on AWS ワークロード、およびオンプレミスシステムのハイブリッド環境において、これらの機能をどのように適用するかを学びます。この総体的なアプローチにより、セキュリティ体制の信頼性を高めながら、移行とモダナイゼーションを迅速に行うことができます。 セキュリティガバナンス セキュリティガバナンスには、セキュリティを定義し周知する役割と責任が含まれます。ポリシー、プロセス、手順を作成し、説明責任の所在を明確にします。遵守すべき法律や規制を適用し、継続的に更新する必要があります。 以下の図 2 では、VMware、AWS、お客様の間で責任を共有しています。お客様は、Software-Defined Data Center （SDDC） 内のワークロードの構成、VMware ファイアウォールルール、およびその他の SDDC の構成に対して責任を負います。 緑色の部分を見ますと、SDDC だけでなくマネージド仮想プライベートクラウド （VPC） や関連する AWS リソースに対しても VMware が責任を負っていることが分かります。一方、AWS はグローバルインフラストラクチャと基盤サービスを担当しています。 図 2: VMware Cloud on AWS の責任共有モデル SDDC や VMware ファイアウォールなど、セキュリティやコンプライアンスを考慮する必要のある新しい構成が存在します。これらの構成の一部は VMware によって管理されていますが、お客様で変更することも可能です。 セキュリティ保証 セキュリティ保証については、クラウドベンダーのレポートやコンプライアンス証明書をレビューして実施されているコントロールを理解するだけでなく、継続的な改善を適用しながらセキュリティメカニズムを監視、評価、管理します。お客様は、どのコンプライアンスフレームワークを適用するかを決定し、VMware のコントロールをそれらの要件にマッピングする責任を負います。 VMware は、コンプライアンス文書を提供し、それぞれの管理を実施する責任があります。VMware のスコープに関する詳細については、 VMware Trust Center を参照してください。これは、AWS のセキュリティおよびコンプライアンス情報が掲載されている AWS Artifact と組み合わせて使用できます。 アイデンティティとアクセス管理 Identity and Access Management （IAM） を使用することで、アイデンティティ・プロバイダの集中管理と多要素認証 （MFA） を使用して最小特権アクセスを実装できます。 VMware は SDDC をプロビジョニングする前に、お客様の身元証明でもある有効な AWS アカウントを持っていることを顧客に要求します。 サービス説明 のページでは、VMware がどのようにクラウドサービスポータル （CSP） を保護し、MFA との統合をサポートしているかについての詳細情報を提供しています。 アイデンティティ・プロバイダ （既存のアイデンティティ・プロバイダとのフェデレーションを推奨） と同様に、SDDC 内の仮想マシンの認証を管理する責任はお客様にあります。VMware Cloud on AWS のアイデンティティとアクセス管理については 規範ガイダンス を参照してください。 脅威検出 この機能には、様々なデータソースと相関性のある脆弱性のスキャンと修復の発見が含まれ、修復とその結果の状況をステークホルダーに伝えます。ユーザアクティビティ、ネットワークアクティビティ、アプリケーションアクティビティのログの記録など、SDDC 内の仮想マシンの脅威検出はお客様の責任となります。 ユーザーアクティビティのログ記録には、CSP や API アクションを含む SDDC 内で実行された管理アクティビティを記録する Aria Operations for Logs を利用できます。ネットワークアクティビティのログ記録には、SDDC ネットワーク上のパケットキャプチャが含まれ、SDDC ではこのトラフィックを調査するために ポートミラーリング を有効化することができます。 さらに、IP Flow Information Export (IPFIX) ログは、ネットワークトラフィックを要約するためにコレクターに送ることができます。アプリケーションログは、 CloudWatch Logs Agent を使用して Amazon CloudWatch に転送することができ、セキュリティ情報イベント管理 （SIEM） やその他のログ収集ソリューションにログのコピーを送信することで ログを転送 することができます。 VMware は サービス概要 に記載されているとおり、サービスを提供しているシステムの脅威の検出、分類、エスカレーション、および修復に責任を負います。 脆弱性の管理 脆弱性管理機能には、SDDC 内の VM だけでなく、VMware Cloud on AWS サービスを提供するために使用されるシステムのスキャンとパッチ適用が含まれます。SDDC 内のワークロードのスキャンとパッチ適用はお客様責任となりますが、 AWS Systems Manager を利用することができます。 VMware は、 Service Lifecycle ガイドに記載されているように、SDDC と基盤となるサービスコンポーネントのスキャンとパッチを管理します。 インフラストラクチャの保護 この機能には、深層防御を活用してセキュリティのレイヤーを提供する一方で、システムをグループ化するためのネットワークゾーンを定義し、必要に応じてトラフィックの検査とフィルタリングを実装することが含まれます。SDDC ファイアウォールを設定してアクセス制御リスト （ACL） を作成し、トラフィックを許可するだけでなく、ルーティングを設定してトラフィックフローを確立します。 さらに、VPC ルートテーブル、セキュリティグループ、ネットワーク ACL （NACL） を管理し、SDDC から VPC に流れるトラフィックを制御します。よりセンシティブなシステムを保護する場合は、 ゼロトラスト アプローチを検討してください。 VMware は SDDC ファイアウォールとルーターのコンポーネントのパッチ適用を管理し、稼働時間を確保します。 アプリケーションのセキュリティ この機能では、ソフトウェア開発プロセス中に脆弱性を検出して対処することで、本番環境に投入されるコードのセキュリティを強化します。コードのスキャンとセキュリティ問題のパッチ適用を自動化することで、人手による作業を最小限に抑える必要があります。 VMware は、VMware Cloud on AWS サービスに関連するコードのセキュリティを確保する責任を負います。 インシデント対応 インシデント対応には、インシデントと問題の管理が含まれ、実行計画に従ってタイムリーに対応します。GameDay 演習を通してセキュリティイベントをシミュレートし、継続的に対応を改善することができます。また、インシデントの事後分析を実施して根本原因を特定し、発見から学ぶこともできます。 VMware は、VMware Cloud on AWS サービスに関するインシデントおよび問題管理 （検出、分類、記録、エスカレーション、サービス復帰） に責任を持ちます。 まとめ 企業は VMware Cloud on AWS を活用して、AWS へのクラウド移行を簡素化し、加速しています。この戦略は、自社データセンターとの運用上の一貫性を提供しますが、セキュリティとコンプライアンスの観点からは AWS 上で実行される VMware ワークロードならではの追加の知見が必要であることを理解することが重要です。 本稿では、AWS クラウド導入フレームワーク （CAF） のセキュリティの観点を VMware Cloud on AWS で評価し適用する方法を解説しました。また AWS の責任共有モデル を紹介し、VMware、AWS、お客様の間でどのように責任を分担するかについても説明しました。 参考文献 AWS Artifact AWS Identity and Access Management AWS Cloud Adoption Framework Security Perspective VMware Cloud on AWS Enterprise Federation VMware Cloud on AWS Service Description VMware Trust Center 翻訳は SA 太田が担当しました。原文は こちら です。

多数のアカウントと Amazon Virtual Private Cloud (Amazon VPC) リソースを管理している場合、多くの DNS リソースを共有して各 VPC に関連付けるのは大きな負担となることがあります。共有と関連付けに関する制限にしばしば悩まされ、アカウントと VPC 全体に DNS 設定を伝播するために独自のオーケストレーションレイヤーを構築するまでに至ったお客様もいらっしゃるかもしれません。 4月22日、 Amazon Route 53 プロファイルを発表します。これは、組織のすべてのアカウントと VPC における DNS の管理を統合する機能を提供します。Route 53 プロファイルを使用することで、Route 53 プライベートホストゾーン (PHZ) の関連付け、Resolver 転送ルール、Route 53 Resolver DNS ファイアウォールルールグループなどの標準 DNS 設定を定義し、その設定を同じ AWS リージョン内の複数の VPC に適用できます。プロファイルを使用すると、個別の Route 53 リソースを処理するという複雑さに煩わされることなく、簡単な操作で、すべての VPC が同じ DNS 設定を持つようにできます。多数の VPC にわたる DNS の管理が、単一の VPC のそれらの同じ設定を管理するのと同じ程度にシンプルになりました。 プロファイルは AWS Resource Access Manager (RAM) とネイティブに統合されるため、アカウント間で、または AWS Organizations アカウントと、プロファイルを共有できます。プロファイルは、アカウント間で共有される際に組織がこれらの同じ設定にアクセスできるようにするため、既存のプライベートホストゾーンを作成してプロファイルに追加することを可能にすることによって、Route 53 プライベートホストゾーンとシームレスに統合します。 AWS CloudFormation を利用すると、アカウントが新しくプロビジョニングされる際に、プロファイルを使用して VPC の DNS 設定を一貫して行うことができます。4月22日のリリースでは、マルチアカウント環境の DNS 設定をより適切に管理できるようになりました。 Route 53 プロファイルの仕組み Route 53 プロファイルの使用を開始するには、Route 53 の AWS マネジメントコンソール に移動します。ここでプロファイルを作成し、そのプロファイルにリソースを追加して、VPC に関連付けることができます。その後、AWS RAM を使用して、作成したプロファイルを別のアカウントと共有します。 Route 53 コンソールのナビゲーションペインで、 [プロファイル] を選択し、次に [プロファイルを作成] を選択してプロファイルを設定します。 プロファイルの設定に MyFirstRoute53Profile などのわかりやすい名前を付け、必要に応じてタグを追加します。 DNS ファイアウォールルールグループ、プライベートホストゾーン、Resolver ルールの設定の構成や、アカウント内に既に存在しているそれらの設定の追加は、すべてプロファイルコンソールページ内で実行できます。 [VPC] を選択して、VPC をプロファイルに関連付けます。タグを追加できるほか、再帰的 DNSSEC 検証や、VPC に関連付けられた DNS ファイアウォールの障害モードの設定を行うこともできます。また、DNS 評価の順序を制御することもできます。最初に VPC DNS、次にプロファイル DNS としたり、または最初にプロファイル DNS、次に VPC DNS としたりできます。 VPC ごとに 1 個のプロファイルを関連付けることができ、最大 5,000 個の VPC を 1 個のプロファイルに関連付けることができます。 プロファイルを使用すると、組織内のアカウント全体で VPC の設定を管理できます。VPC ごとに逆引き DNS ルールを設定するのではなく、プロファイルが関連付けられている VPC ごとに逆引き DNS ルールを無効にできます。Route 53 Resolver は、逆引き DNS ルックアップのルールを自動的に作成して、さまざまなサービスが IP アドレスからホスト名を簡単に解決できるようにします。 DNS ファイアウォール を使用する場合、ファイアウォール用に設定を通じて障害モードを選択して、フェールオープンまたはフェールクローズを選択できます。また、Route 53 (または他のプロバイダー) で DNSSEC 署名を使用せずに、プロファイルに関連付けられた VPC 用に再帰的 DNSSEC 検証を有効にするかどうかを指定することもできます。 プロファイルを VPC に関連付けるとします。VPC に直接関連付けられているリゾルバールールまたは PHZ と、VPC のプロファイルに関連付けられているリゾルバールールまたは PHZ の両方に、クエリが正確に一致するとどうなるでしょうか? プロファイルとローカル VPC のどちらの DNS 設定が優先されるのでしょうか? 例えば、VPC が example.com の PHZ に関連付けられており、プロファイルに example.com の PHZ が含まれている場合、その VPC のローカル DNS 設定がプロファイルよりも優先されます。競合するドメイン名についてクエリが実行された場合 (例えば、プロファイルに infra.example.com の PHZ が含まれており、VPC が account1.infra.example.com という名前の PHZ に関連付けられている場合)、最も具体的な名前が優先されます。 AWS RAM を利用してアカウント間で Route 53 プロファイルを共有する AWS Resource Access Manager (RAM) を利用して、前のセクションで作成したプロファイルを他のアカウントと共有します。 [プロファイルの詳細] ページで [プロファイルを共有] オプションを選択するか、または AWS RAM コンソールページに移動して [リソース共有を作成] を選択します。 リソース共有の名前を入力し、 [リソース] セクションで「Route 53 Profiles」を検索します。 [選択されたリソース] でプロファイルを選択します。タグを追加することもできます。その後、 [次へ] を選択します。 プロファイルは RAM マネージド許可を利用するため、各リソースタイプに異なる許可をアタッチできます。デフォルトでは、プロファイルの所有者 (ネットワーク管理者) のみがプロファイル内のリソースを変更できます。プロファイルの受信者 (VPC の所有者) は、プロファイルの内容のみを表示できます (ReadOnly モード)。プロファイルの受信者が PHZ または他のリソースをそのプロファイルに追加することを許可するには、プロファイルの所有者は、必要な許可をリソースにアタッチする必要があります。受信者は、プロファイルの所有者によって共有リソースに追加されたリソースを編集または削除できません。 デフォルトの選択をそのままにして、 [次へ] を選択し、他のアカウントにアクセスを付与します。 次のページで、 [すべてのユーザーとの共有を許可] を選択し、他のアカウントの ID を入力して、 [追加] を選択します。その後、 [選択されたプリンシパル] セクションでそのアカウント ID を選択し、 [次へ] を選択します。 [確認と作成] ページで、 [リソース共有を作成] を選択します。リソース共有が正常に作成されました。 次に、プロファイルを共有する別のアカウントに切り替えて、RAM コンソールに移動します。ナビゲーションメニューで、 [リソース共有] に移動し、最初のアカウントで作成したリソース名を選択します。 [リソース共有を承認] を選択して招待を受け入れます。 これで完了です。 ここで Route 53 プロファイルページに移動し、共有されているプロファイルを選択します。 共有されたプロファイルの DNS ファイアウォールルールグループ、プライベートホストゾーン、および Resolver ルールにアクセスできます。このアカウントの VPC をこのプロファイルに関連付けることができます。リソースを編集または削除することはできません。プロファイルはリージョンレベルのリソースであり、リージョン間で共有することはできません。 今すぐご利用いただけます Route 53 プロファイルは、 AWS マネジメントコンソール 、 Route 53 API 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、および AWS SDK を使用して簡単に開始できます。 Route 53 プロファイルは、カナダ西部 (カルガリー)、AWS GovCloud (米国) リージョン、および Amazon Web Services の中国リージョンを除くすべての AWS リージョンで利用可能になる予定です。 料金の詳細については、 Route 53 の料金 ページにアクセスしてください。 今すぐ プロファイル の使用を開始して、通常の AWS サポートのお問い合わせ先や、Amazon Route 53 の AWS re:Post を通じてフィードバックをぜひお寄せください。 – Esra 原文は こちら です。

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。過去の記事はこちらになります。 ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 ガバメントクラウド活用のヒント『ガバメントクラウド上で 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 ; 原文は こちら です。